软件测试风险分析

《软件测试风险分析》由会员分享，可在线阅读，更多相关《软件测试风险分析（5页珍藏版）》请在装配图网上搜索。

1、作为计划的一部分，软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分，那么会使 软件的测试成功性大大增加，且可将由风险异常引发的额外成本（如人力，时间等）降到最低。查阅了网上很多关 于软件测试风险控制的，其中不乏精品之作。本文将此类知识进行了归纳，查漏补缺，并在思维导向性上给出了简 单的实施步骤，以使得在实际应用中能得到更好的运用。第一部分：软件测试项目级的风险分析1. ?从人、料、法、环、时等方面分析测试项目级的风险分布探寻测试隐藏的风险时，应招集测试全组成员举行会议，建议采用头脑风暴和询问5Why的方式进行，以集 思广益和深度挖掘。下面就在鱼骨图中以 TQM （全面）

2、 的人、机、料、法、环等五个方面来全方位的分析和罗 列项目级可能隐藏的风险 （注：考虑到在软件测试中“机”这一项更多的属于环境这一分类，故删除此类。另外时间 对于软件测试是一个非常重要的属性，故添加之）。下面对鱼骨图中的各个分支及子分支进行相应注解：人，即测试人员： 业务不熟：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透侧、理解错误等。 测试人员变动：离职，岗位调动，请假等。 定位效应：测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能是可靠的。 疲态：某一些功能点一直由某一位测试人员测试，经过多次回归后，测试人员对该功能点的测试显示出倦意

3、和缺乏兴趣。 同化效应：经过和开发的长时间接触，往往会被开发的思维逻辑所同化，渐渐丧失从用户角度出发的测试观察点。料，即测试相关文档（在TQM中指的是生产原材料）： Spec （详细规格说明书）缺失：只有PRD （项目需求概要说明书），没有spec。笔者所在的公司，早些时候的产品更多的时候只有PRD，没有Speco 需求变更：这是最不想，但又最经常发生的事情 测试用例/数据设计不充分：某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。 质量标准不统一：如某些的优先级方面，测试和开发的认同不一致。法，即测试方法和实施： 错误或缺失测试方法：对功能点没有采用正确的测试方法，或某些测试方

4、法没有被忽视，如边界测试等，导致测试不充分。 场景的缺失或部分缺失：Spec非常详细，所有的精力放在功能点的测试上，忽视了业务场景（Spec中无定义）的全（100%）测试。 测试用例实施不充分：测试用例由于各种原因没有完全测试，如在回归测试中。环，即测试环境： 被测软件版本不统一：没有有效的，这种情况及易出现 测试软件环境不一致：测试员之间或和开发之间的类型不一致、操作系统的干净程度不一致。 测试硬件环境不一致：测试员之间或和开发的设备不一致，如 CPU 频率，内存大小等。 测试硬件未及时到位时，即测试时间： 测试时间不足：里程碑之间留给测试的时间无法满足全测试要求。 测试时间延长：由于需求方

5、突然宣布原进度表中的里程碑时间点延后，导致项目的进度表一下松弛了许多。 笔者参加过的两个项目就遇见过这种情况，我们为世界某着名品牌电脑供应商开发并提供随机软件。在项 目进展到中后期时，客户忽然通知我们暂时不安排我们的软件在他们这一版本系统中进行安装，要等到下 一版本，时间延迟可能长达三个月，甚至更多。注：以上五个方面不可能将所有软件测试中潜在的风险全部罗列，旨在给出思维方式。2.?采用FMEA评估及分析风险项在采用FMEA对风险进行评估和分析前，有必要先熟悉一些FMEA的知识点。（1）FMEA （Failure Mode Effects Analysis） ：潜在失效模式和结果分析。即找出产品

6、/过程中潜在的故 障模式根据相应的评价体系对找出的潜在故障模式进行风险量化评估；列出故障起因/机理，寻找预防或改进措施（2）FMEA关键项： Function （功能要求）： What is design/process/service supposed to do at this stage? Failure Mode （潜在失效模式）： A specific means by which a design （product）, process, or ser vice may fail. Effect （潜在失效后果）： What happens when the failure occu

7、rs? Severity （严重度）： ? How serious is the consequence of the failure? The value is 110. Cause （潜在的失效起因）： What can occur to cause the failure? Occurrence （频度）： How often will the cause/failure occur? The value is 110. Current Control （现行控制）： ? Current method to detect/prevent transmission of failures

8、to sub sequent “customers”. Detection （探测度）： Can the cause/failure be detected if it occurs? The value is 110. RPN （风险顺序数）： Review Risk Priority Numbers,RPN = （Severity） x （Occurrence） x （Detection） Recommended Actions （建议措施）： What can we do? Responsibility & Target Completion Date （ 责任及目标完成日期）: Whe

9、n it can be fixed? Actions Taken Result （措施结果）： The actually result after action have been taken.（3）FMEA流程：本文只给出了简单流程示意图，更详细的流程做法，请参看FAILURE MODES AND EFFECTS ANALYSI SKenneth Crow 中的 FMEA Procedure 章节。下面给出一个FMEA的简单模板，可以参照下图的表格填写上面人、料、法、环、时五大因素中所提及的各 个风险子项填写在 Function 一列，并按公司的切实情况填写后续各列。第二部分：软件测试用例级

10、的风险分析1. ?测试用例风险分析的目的在进行回归测试等情况下，从所有测试用例集（含功能点和场景测试两部分）中如何选择最小测试用例集，是 一个值得思考的问题，本文仅想从测试用例风险系数等级划分来对这一问题进行部分探讨。对所有测试用例进行 风险系数等级划分，并按等级数进行排序。在选择回归测试用例集时，从中挑选风险系数等级级别的高的测试用 例进行优先测试，最后根据项目进度条件从风险等级高到等级低的合理选择回归测试用例集。2.?采用风险矩阵评估及分析测试用例优先级测试用例风险出现概率（110）后果与影响（广10）风险系数（=出现概率X影响）规避措施第三部分：总结与说明1.本文没有对项目管理方面的隐藏

11、风险进行探寻，如项目经费成本风险分析等。仅从测试本身考虑了风险分 布，角色定位于测试项目Leader，而前者则是PM。2. 本文的标题定为测试风险分析，所以对于发生风险后所应该采用的规避措施，没有在文中给出，可采用根 据公司内容的实际情况采用头脑风暴进行解决方案的探讨和筛选，也可参考网上一些文章所建议的解决方案。3风险分析的方法有很多种，如Boehm的六步风险管理法、Rex Black在软件测试核心过程一书中提到 的风险分析过程等都是比较优秀的方法，但其精髓和FMEA、风险分析矩阵是如出一辙，个人觉得以表格的形式 展示更加形象化。参考：1、测试有道 - 微软测试测试技术心得 梁博，许珊等 电子

12、工业出版社2、测试风险的管理3、风险列表 noone_pm?4、软件测试管理常见问题及其回答 songfun?软件测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低 测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终 测试不到或验证的标准不对；二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；五、测试用例设计不

13、到位，忽视了一些边界条件、深层次的逻辑、用户场景等；六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多 被漏检的缺陷可能性就大；八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。 前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后 一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。针对上述软件测试的风险，有一些有效的测试风险控制方法，如：测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员 按已列出条目逐条检查；?有

14、些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的 低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷， 很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉 (Diasble)那个新功能，转移这种风险；有些风险不可避免，就设法降低风险，如如程序中未发现的缺陷这种风险总是存在，我 们就要通过提高测试用例的覆盖率(如达到%)来降低这种风险；?为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的 处理还要制定一些应急的、有效的处理方案，如：在做资源、时间、成本等估算时，要留有余地，不要用

15、到100%; ?在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计 划中；对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一 旦离开公司， ? 项目不会受到严重影响，仍能可以继续下去；制定文档标准，并建立一种机制，保证文档及时产生；对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块 上相互调换；对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。？要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立 一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅 可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期 和整个项目的测试周期。