原文http://blog.csdn.net/roger_ge/article/details/5343039
作为软件测试计划的一部分，软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分，那么会使软件的测试成功性大大增加，且可将由风险异常引发的额外成本(如人力，时间等)降到最低。查阅了网上很多关于软件测试风险控制的文章，其中不乏精品之作。本文将此类知识进行了归纳，查漏补缺，并在思维导向性上给出了简单的实施步骤，以使得在实际应用中能得到更好的运用。
第一部分：软件测试项目级的风险分析
1. 从人、料、法、环、时等方面分析测试项目级的风险分布
探寻测试隐藏的风险时，应招集测试全组成员举行会议， 建议采用头脑风暴和询问5Why的方式进行，以集思广益和深度挖掘。下面就在鱼骨图中以TQM (全面质量管理) 的人、机、料、法、环等五个方面来全方位的分析和罗列项目级可能隐藏的风险 (注：考虑到在软件测试中“机”这一项更多的属于环境这一分类，故删除此类。另外时间对于软件测试是一个非常重要的属性，故添加之)。
下面对鱼骨图中的各个分支及子分支进行相应注解：
人，即测试人员：
l 业务不熟：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透侧、理解错误等。
l 测试人员变动：离职，岗位调动，请假等。
l 定位效应：测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能是可靠的。
l 疲态：某一些功能点一直由某一位测试人员测试，经过多次回归后，测试人员对该功能点的测试显示出倦意和缺乏兴趣。
l 同化效应：经过和开发的长时间接触，往往会被开发的思维逻辑所同化，渐渐丧失从用户角度出发的测试观察点。
料，即测试相关文档(在TQM中指的是生产原材料)：
l Spec (详细规格说明书)缺失：只有PRD(项目需求概要说明书)，没有spec。笔者所在的公司，早些时候的产品更多的时候只有PRD，没有Spec。
l 需求变更：这是最不想，但又最经常发生的事情
l 测试用例/数据设计不充分：某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。
l 质量标准不统一：如某些Bug的优先级方面，测试和开发的认同不一致。
法，即测试方法和实施：
l 错误或缺失测试方法：对功能点没有采用正确的测试方法，或某些测试方法没有被忽视，如边界测试等，导致测试不充分。
l 场景的缺失或部分缺失：Spec非常详细，所有的精力放在功能点的测试上，忽视了业务场景(Spec中无定义)的全(100%)测试。
l 测试用例实施不充分：测试用例由于各种原因没有完全测试，如在回归测试中。
环，即测试环境：
l 被测软件版本不统一：没有有效的配置管理，这种情况及易出现
l 测试软件环境不一致：测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。
l 测试硬件环境不一致：测试员之间或和开发的设备不一致，如CPU频率，内存大小等。
l 测试硬件未及时到位
时，即测试时间：
l 测试时间不足：里程碑之间留给测试的时间无法满足全测试要求。
l 测试时间延长：由于需求方突然宣布原进度表中的里程碑时间点延后，导致项目的进度表一下松弛了许多。笔者参加过的两个项目就遇见过这种情况，我们为世界某著名品牌电脑供应商开发并提供随机软件。在项目进展到中后期时，客户忽然通知我们暂时不安排我们的软件在他们这一版本系统中进行安装，要等到下一版本，时间延迟可能长达三个月，甚至更多。
注：以上五个方面不可能将所有软件测试中潜在的风险全部罗列，旨在给出思维方式。
2. 采用FMEA评估及分析风险项
在采用FMEA对风险进行评估和分析前，有必要先熟悉一些FMEA的知识点。
l FMEA (Failure Mode Effects Analysis) ：潜在失效模式和结果分析。即找出产品/过程中潜在的故障模式根据相应的评价体系对找出的潜在故障模式进行风险量化评估；列出故障起因/机理，寻找预防或改进措施。
l 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 service may fail.
ü Effect (潜在失效后果): What happens when the failure occurs?
ü Severity (严重度): How serious is the consequence of the failure? The value is 1~10.
ü Cause (潜在的失效起因): What can occur to cause the failure?
ü Occurrence (频度): How often will the cause/failure occur? The value is 1~10.
ü Current Control (现行控制): Current method to detect/prevent transmission of failures to subsequent “customers”.
ü Detection (探测度): Can the cause/failure be detected if it occurs? The value is 1~10.
ü RPN (风险顺序数): Review Risk Priority Numbers, RPN = (Severity) x (Occurrence) x (Detection)
ü Recommended Actions (建议措施): What can we do?
ü Responsibility & Target Completion Date (责任及目标完成日期): When it can be fixed?
ü Actions Taken Result (措施结果): The actually result after action have been taken.
l FMEA流程：
本文只给出了简单流程示意图，更详细的流程做法，请参看《FAILURE MODES AND EFFECTS ANALYSIS》Kenneth Crow 中的FMEA Procedure章节。
下面给出一个FMEA的简单模板，可以参照下图的表格填写上面人、料、法、环、时五大因素中所提及的各个风险子项填写在Function一列，并按公司的切实情况填写后续各列。
第二部分：软件测试用例级的风险分析
1. 测试用例风险分析的目的
在进行回归测试等情况下，从所有测试用例集（含功能点和场景测试两部分）中如何选择最小测试用例集，是一个值得思考的问题，本文仅想从测试用例风险系数等级划分来对这一问题进行部分探讨。对所有测试用例进行风险系数等级划分，并按等级数进行排序。在选择回归测试用例集时，从中挑选风险系数等级级别的高的测试用例进行优先测试，最后根据项目进度条件从风险等级高到等级低的合理选择回归测试用例集。
2. 采用风险矩阵评估及分析测试用例优先级
|
测试用例 |
风险 |
出现概率(1~10) |
后果与影响(1~10) |
风险系数(=出现概率x影响) |
规避措施 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第三部分：总结与说明
1. 本文没有对项目管理方面的隐藏风险进行探寻，如项目经费成本风险分析等。仅从测试本身考虑了风险分布，角色定位于测试项目Leader，而前者则是PM。
2. 本文的标题定为测试风险分析，所以对于发生风险后所应该采用的规避措施，没有在文中给出，可采用根据公司内容的实际情况采用头脑风暴进行解决方案的探讨和筛选，也可参考网上一些文章所建议的解决方案。
3. 风险分析的方法有很多种，如Boehm的六步风险管理法、Rex Black在《软件测试核心过程》一书中提到的风险分析过程等都是比较优秀的方法，但其精髓和FMEA、风险分析矩阵是如出一辙，个人觉得以表格的形式展示更加形象化。
参考：
《测试有道 - 微软测试测试技术心得》 梁博，许珊等 电子工业出版社
《测试风险的管理》http://www.51testing.com/html/90/n-9990.html
《风险列表》 noone_pm http://bbs.51testing.com/viewthread.php?tid=7105&highlight=%B7%E7%CF%D5
《软件测试管理常见问题及其回答》songfun http://bbs.51testing.com/viewthread.PHP?tid=39181&extra=page%3D1%26amp%3Bfilter%3Ddigest
