基于风险的测试
风险是指负面或不希望发生的后果或事件发生的可能性。当引起客户、用户、参与者或干系人对产品质量或项目成功的信心减弱的问题可能发生时，风险就存在。当潜在问题主要影响的是产品质量时，它们被称为质量风险、产品风险或产品质量风险。而当潜在问题主要影响的是项目成功时，它们则被称为项目风险或计划风险。
在基于风险的测试中，在干系人参与的产品质量风险分析的过程中对质量风险进行识别和评估。测试团队设计、实施和执行测试来缓解质量风险。质量包括影响客户、用户和干系人满意度的全部功能、行为、特征和属性。因此，质量风险是产品可能存在质量问题的情况。系统质量风险的例子包括报告中的错误计算（与准确度相关的功能风险），用户输入响应慢（与效率和响应时间相关的非功能风险），界面和字段难以理解（与易用性和易理解性相关的非功能风险）。当测试找出了缺陷时，通过让他人意识到这些缺陷，并在发布前有机会处理这些缺陷，测试缓解了质量风险。当测试不再发现缺陷时，通过确保在测试条件下，系统可以正常运作，测试也缓解了质量风险。
基于风险的测试使用产品质量风险来选择测试条件，为这些条件分配测试工作，并为生成的测试用例设定优先级。基于风险的测试有各种各样的技术，这些技术在采集的文档的类型和级别，以及运用的形式方面大相径庭。基于风险的测试明确指出的或隐含的目的就是用测试来降低整体的质量风险水平，具体而言是把风险水平降低到可接受的范围。
基于风险的测试包含四个主要活动：
1、风险识别
2、风险评估
3、风险缓解
4、风险管理
要想取得最佳的效果，风险识别和评估小组应包括所有项目和产品干系人的代表，不过有时项目的实际情况导致某些干系人代理其它干系人。例如，在大众市场的软件开发中，可能抽样一小部分潜在客户，要求他们帮助识别潜在的严重影响他们使用软件的缺陷；在这个例子中，抽样的小部分潜在客户就是作为所有最终客户群的代理人。由于测试人员在产品质量风险和失效方面的专长，他们应该积极参与风险识别和评估过程
一、风险识别
干系人可通过下列的一项或多项技术来识别风险：
1、专家咨
2、独立评估
3、使用风险模版
4、项目回顾
5、风险研讨会
6、头脑风暴
7、检查表
8、参考过去的经验
对参与风险识别的干系人的抽样越广泛，风险识别过程就越有可能识别出越多的严重产品质量风险。
风险识别通常会产生一些副产品，例如，识别出并非产品质量风险的问题。例子包括有关产品或项目的一般疑问或问题，或参考的文档，如需求和设计说明中的问题。质量风险识别的另一副产品是识别出项目风险，不过项目风险并不是基于风险的测试关注的焦点。然而，项目风险管理对于包括基于风险测试在内的所有测试方法都是很重要的
二、风险评估
识别了风险后，就开始风险评估，即研究识别出的这些风险。具体而言，风险评估包括对每个风险进行分类，确定风险发生的概率和影响。风险评估还可能涉及评价或分配每个风险的其它属性，如风险责任人。
风险的分类就是将每个风险划分到适当的类型中，例如性能、可靠性、功能性等等。有些组织使用 ISO9126（ISO 9126 标准正在被 ISO 25000 标准所取代）的质量特征进行分类，但大多数组织采用的都是其它的分类方案。风险分类时使用的检查表通常与风险识别使用的相同。有通用的质量风险检查表，许多企业都根据自己的需要定制这些检查表。如果使用检查表作为风险识别的基础，在风险识别时通常就进行了风险的分类。
确定风险的级别通常包括评估每条风险发生的可能性，以及发生之后的影响。发生的可能性是指被测系统存在潜在问题的概率。换句话说，可能性是对技术风险的级别的评估。
影响产品和项目风险发生的可能性的因素包括：
1、技术和团队的复杂性
2、业务分析师、设计师和程序员的人员和培训问题
3、团队内部的冲突
4、与供应商的合同问题
5、异地工作的团队队员
6、旧方法与新方法对立
7、工具和技术
8、管理或技术领导不力
9、时间、资源、预算和管理压力
10、缺乏前期的质量保证活动
11、高变更率 早期的高缺陷率
12、 接口和集成问题
风险发生的影响是指风险发生对用户、客户或其它干系人的影响的严重程度。换句话说，影响来自于业务风险。影响项目和产品风险的影响程度的因素包括：
1、使用受影响的特性的频率
2、该特性对于实现业务目标的关键程度
3、声誉的损害 商业损失
4、潜在的财务、生态、社会损失或法律责任
5、民事或刑事法律制裁
6、吊销执照
7、缺乏合理的变通
8、明显的失效导致负面声誉
9、安全性
风险的级别既可定性也可定量地评估。如果确定了可能性和影响的量化数据，可以将这两个值相乘，计算出定量的风险优先级数值。不过通常风险的级别只能通过定性的方式确认。也就是说，我们可以将可能性形容成很高、高、中、低或很低，但无法用精确的百分比表达出来；同样地，我们可以将影响形容成很高、高、中、低或很低，但也不能完整或精确地表达财务上的影响。不应该认为定性的方法比定量的方法差；实际上，如果风险级别的定量评估使用不当的话，会误导干系人对风险程度的理解和管理。风险级别的定性评估通常通过乘法或加法相结合，得到一个风险总分。这个风险总分可能被称为风险优先数，但确切来说，它应是定性的、有序的相对评级。
另外，除非风险分析基于广泛的、有效统计的风险数据，风险分析应该更多基于干系人对于可能性和影响的主观感知。通常，项目经理、编程人员、用户、业务分析师、架构师和测试人员的感知各不相同，因此针对各项风险的风险级别可能有不同的意见。风险分析过程应包括达成共识，或者即使在最糟的情况下，也要有确立都同意的风险级别的方式（如通过管理层下达命令或通过取该风险级别的平均值，中间值或众数值）。此外，还应检查风险级别的分布情况，确保风险的评分对于测试排序、优先级设定和分工能起到实际的指导作用。否则，将无法使用风险级别来指导风险缓解活动。
三、风险缓解
基于风险的测试从质量风险分析（识别和评估产品质量风险）开始。质量风险分析是主测试计划和其它测试计划的基础。正如计划中所述，测试的设计、实施和执行是为了覆盖风险。开发和执行测试的工作量与风险的级别成一定比例，也就是说风险的级别越高，使用的测试技术就越细致（如结对测试），风险的级别越低，使用的测试技术就越不细致（如等价类划分或有时限的探索性测试）。此外，开发和执行测试的优先级也是依据风险级别而设定。有些安全规范（如 FAA DO-178B/ED 12B,IEC 61508）规定了基于风险级别的测试技术和覆盖率。另外，风险的级别还应影响到一些决策，例如使用项目工作产品（包括测试）的评审、独立的级别、测试人员的经验水平、确认测试（再测试）和回归测试的程度。
在项目开展期间，测试团队仍应对改变质量风险集和／或已知质量风险的风险级别的补充信息保持了 解。应该定期调整质量风险分析，至少在项目的主要里程碑到来时（进行这种调整），以此来指导对测试的调整。调整包括识别新风险，重新评估现有风险的级别和评价风险缓解活动的有效性。例如，如果在需求阶段，基于需求规格说明进行了一次风险识别和评估，那么当设计规格说明定案后，就应对已有的需求规格风险重新进行评价。再如，如果在测试中发现某个组件包含的缺陷要远比预期的缺陷数多，则可得出在此区域缺陷的可能性比预期的要高的结论，并将风险的可能性和整体风险级别上调，根据调整结果就应增加该组件测试的工作量。
在测试执行开始之前也可以缓解产品质量风险。例如，如果在风险识别时发现了需求的问题，项目组就可以通过实施全面的需求规格说明评审来缓解这一风险。这样做可以降低风险的级别，可能意味着缓解残余质量风险所需的测试数目减少。
四、生命周期中的风险管理
理想情况下，在整个生命周期期间都在进行风险管理。如果组织有测试方针文档和／或测试策略文档，这些文档中应当描述测试中管理产品风险和项目风险的一般过程，以及风险管理怎样集成到测试的各个阶段中，并使其发挥作用。
一个成熟的组织，风险意识应遍及整个项目组，在这样的组织中，风险管理并非仅仅发生在测试中，而是发生在各个方面。重要的风险不仅在特定测试级别的前期就得到处理，而且在早期的测试级别中也得到了处理。例如，如果性能被识别为一个关键质量风险区域，性能测试在系统测试的前期就会开始进行，而且在单元测试和集成测试时也会运行性能测试。成熟的组织不仅识别风险，还识别风险的来源和风险一旦发生将带来的后果。对于那些确实发生的风险，使用根本原因分析来深入理解风险的来源和实施过程改进，防范于未然。风险缓解贯穿于整个软件开发生命周期。风险分析获得了充足的信息，考虑到了相关的工作活动、系统行为分析、基于成本的风险评估、产品风险分析、最终用户风险分析和责任风险分析。当测试团队参与并对整个程序范围的风险分析产生影响的情况下，风险分析超越了测试的范畴。
大多数基于风险的测试方法还包括用风险级别来对测试进行排序和优先级设定的技术，以此确保测试执行时尽早覆盖最多的重要区域，发现最多的重要缺陷。某些情况下，所有的高级别风险的测试都是在较低级别风险测试之前进行的，且测试的运行严格按照风险排序（通常称为“深度优先” ）；其它情况下，测试优先级根据抽样方法来制定。抽样方法就是选择一个测试样本，该测试样本可以覆盖到所有已识别的风险。用风险覆盖率评估选出的测试样本，确保每条风险至少被覆盖到一次（通常称为“广度优先” ）。
无论基于风险的测试是深度优先还是广度优先，分配给测试的时间都有可能不足。基于风险的测试使得测试人员能以剩余风险级别的方式向管理层报告当前测试状态，让管理层决定是否要增加测试时间或将剩余的风险转移给用户／客户、服务／技术支持人员和／或运营人员。
在测试执行期间，最先进的基于风险的测试技术（并不一定是最正式或重量级的技术）让项目参与人、项目和产品经理、高层行政管理人员和项目干系人根据剩余风险级别监督和控制软件开发生命周期，包括做出是否发布的决策。这就要求测试经理在汇报有关风险的测试结果时，要确保所有干系人都能理解。
