软件测试风险分析.pdf

《软件测试风险分析.pdf》由会员分享，可在线阅读，更多相关《软件测试风险分析.pdf（5页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、-作为软件测试软件测试方案的一局部，软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分，则会使软件的测试成功性大大增加，且可将由风险异常引发的额外本钱如人力，时间等降到最低。查阅了网上很多关于软件测试风险控制的文章文章，其中不乏精品之作。本文将此类知识进展了归纳，查漏补缺，并在思维导向性上给出了简单的实施步骤，以使得在实际应用中能得到更好的运用。第一局部：软件测试工程级的风险分析第一局部：软件测试工程级的风险分析1.1.从人、料、法、环、时等方面分析测试工程级的风险分布从人、料、法、环、时等方面分析测试工程级的风险分布探寻测试隐藏的风险时，应招集测试全组成员举行会议，建议

2、采用头脑风暴和询问 5Why 的方式进展，以集思广益和深度挖掘。下面就在鱼骨图中以 TQM 全面质量管理质量管理 的人、机、料、法、环等五个方面来全方位的分析和罗列工程级可能隐藏的风险 注：考虑到在软件测试中“机这一项更多的属于环境这一分类，故删除此类。另外时间对于软件测试是一个非常重要的属性，故添加之。下面对鱼骨图中的各个分支及子分支进展相应注解：人，人，即测试人员：业务不熟：测试人员对被测系统的业务流程不熟悉，表达在对需求的理解上把握不准、理解不透侧、理解错误等。测试人员变动：离职，岗位调动，请假等。定位效应：测试过的可靠的功能，特别是在屡次回归且没有发现问题，在此后往往会认为此功能是可靠

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

4、发的认同不一致。法，法，即测试方法和实施：错误或缺失测试方法：对功能点没有采用正确的测试方法，或*些测试方法没有被无视，如边界测试等，导致测试不充分。场景的缺失或局部缺失：Spec 非常详细，所有的精力放在功能点的测试上，无视了业务场景Spec 中无定义的全100%测试。测试用例实施不充分：测试用例由于各种原因没有完全测试，如在回归测试中。环，环，即测试环境：被测软件版本不统一：没有有效的配置管理配置管理，这种情况及易出现.z.-测试软件环境不一致：测试员之间或和开发之间的操作系统操作系统类型不一致、操作系统的干净程度不一致。测试硬件环境不一致：测试员之间或和开发的设备不一致，如 CPU 频率

5、，存大小等。测试硬件未及时到位时，时，即测试时间：测试时间缺乏：里程碑之间留给测试的时间无法满足全测试要求。测试时间延长：由于需求方突然宣布原进度表中的里程碑时间点延后，导致工程的进度表一下松弛了许多。笔者参加过的两个工程就遇见过这种情况，我们为世界*著名品牌电脑供应商开发并提供随机软件。在工程进展到中后期时，客户突然通知我们暂时不安排我们的软件在他们这一版本系统中进展安装，要等到下一版本，时间延迟可能长达三个月，甚至更多。注：以上五个方面不可能将所有软件测试中潜在的风险全部罗列，旨在给出思维方式。2.2.采用采用 FMEAFMEA 评估及分析风险项评估及分析风险项在采用 FMEA 对风险进展

6、评估和分析前，有必要先熟悉一些 FMEA 的知识点。1FMEA Failure Mode Effects Analysis：潜在失效模式和结果分析。即找出产品/过程中潜在的故障模式根据相应的评价体系对找出的潜在故障模式进展风险量化评估；列出故障起因/机理，寻找预防或改进措施。2FMEA 关键项：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

7、vice may fail.Effect 潜在失效后果：What happens when the failure occurs?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

8、detect/prevent transmission of failures to subsequent“customers.Detection 探测度：Can the cause/failure be detected if it occurs?The value is 110.RPN 风险顺序数：Review Risk Priority Numbers,RPN=(Severity)*(Occurrence)*(Detection)Remended Actions 建议措施：What can we do?Responsibility&Target pletion Date(责任及目标完成日

9、期):When it can be fi*ed?Actions Taken Result 措施结果：The actually result after action have been taken.3FMEAFMEA 流程：流程：本文只给出了简单流程示意图，更详细的流程做法，请参看?FAILURE MODES AND EFFECTS ANALYSIS?Kenneth Crow 中的 FMEA Procedure 章节。下面给出一个 FMEA 的简单模板，可以参照以下图的表格填写上面人、料、法、环、时五大因素中所提及的各个风险子项填写在 Function 一列，并按公司的切实情况填写后续各列。.

10、z.-第二局部：软件测试用例级的风险分析第二局部：软件测试用例级的风险分析1.1.测试用例风险分析的目的测试用例风险分析的目的在进展回归测试等情况下，从所有测试用例集含功能点和场景测试两局部中如何选择最小测试用例集，是一个值得思考的问题，本文仅想从测试用例风险系数等级划分来对这一问题进展局部探讨。对所有测试用例进展风险系数等级划分，并按等级数进展排序。在选择回归测试用例集时，从中挑选风险系数等级级别的高的测试用例进展优先测试，最后根据工程进度条件从风险等级高到等级低的合理选择回归测试用例集。2.2.采用风险矩阵评估及分析测试用例优先级采用风险矩阵评估及分析测试用例优先级测试用例风险出现概率(1

11、10)后果与影响(110)风险系数(=出现概率*影响)躲避措施第三局部：总结与说明第三局部：总结与说明1.本文没有对工程管理方面的隐藏风险进展探寻，如工程经费本钱风险分析等。仅从测试本身考虑了风险分布，角色定位于测试工程 Leader，而前者则是 PM。2.本文的标题定为测试风险分析，所以对于发生风险后所应该采用的躲避措施，没有在文中给出，可采用根据公司容的实际情况采用头脑风暴进展解决方案的探讨和筛选，也可参考网上一些文章所建议的解决方案。3.风险分析的方法有很多种，如 Boehm 的六步风险管理法、Re*Black 在?软件测试核心过程?一书中提到的风险分析过程等都是比较优秀的方法，但其精华

12、和 FMEA、风险分析矩阵是如出一辙，个人觉得以表格的形式展示更加形象化。参考：参考：1、?测试有道-微软测试测试技术心得?梁博，许珊等 电子工业2、?测试风险的管理?.51testing./html/90/n-9990.html3、?风险列表?noone_pmbbs.51testing./thread-7105-1-1.html4、?软件测试管理常见问题及其答复?songfun bbs.51testing./thread-39181-1-1.html二软件测试风险是不可防止的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试

13、工作中，主要的风险有：一、质量需求或产品的特性理解不准确，造成测试围分析的误差，结果*些地方始终测试不到或验证的标准不对；.z.-二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；五、测试用例设计不到位，无视了一些边界条件、深层次的逻辑、用户场景等；六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；八、回归测试一般不运行全部测

14、试用例，是有选择性的执行，必然带来风险。前面三种风险是可以防止的，而四至七的四种风险是不能防止的，可以降到最低。最后一种回归测试风险是可以防止，但出于时间或本钱的考虑，一般也是存在的。针对上述软件测试的风险，有一些有效的测试风险控制方法，如：测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在*个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起*个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble

15、)那个新功能，转移这种风险；有些风险不可防止，就设法降低风险，如“程序中未发现的缺陷这种风险总是存在，我们就要通过提高测试用例的覆盖率如到达99.9%来降低这种风险；为了防止、转移或降低风险，事先要做好风险管理方案和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：在做资源、时间、本钱等估算时，要留有余地，不要用到100%；在工程开场前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理方案中；对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，工程不会受到严重影响，仍能可以继续下去；制定文档标准，并建立一种机制，保证文档及时产生；对所有工作多进展互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换；.z.-对所有过程进展日常跟踪，及时发现风险出现的征兆，防止风险。要想真正回避风险，就必须彻底改变测试工程的管理方式；针对测试的各种风险，建立一种“防患于未然或“以预防为主的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进展躲避、缩短对缺陷的反响周期和整个工程的测试周期。.z.