1.为什么要基于风险的做测试

在测试过程中经常会遇，穷尽测试不可能，如何选择测试重点？如何在有限的测试时间内完成测试？如何合理利用测试资源完成测试。通过采用基于风险的测试，平衡测试时间、成本、范围与质量。

2.什么是基于风险测试

RBT(Risk-Based Testing)即基于风险的测试，James Bach在《Heuristic Risk-Based Testing》中将基于风险的测试描述为“列出一个风险的列表”，“进行考察每项风险的测试”，“当风险消失而新的风险出现的时候，调整测试计划”。

3.基于风险的测试的实施过程

基于风险的测试是一种以软件质量风险作为测试出发点和测试活动主要参考依据的测试方法。通过对项目质量相关信息的收集与分析处理，可有效地识别与划分、归类不同的风险域，再结合对测试粒度、方法及实施人员能力等方面的认识对测试做出优化安排。主要过程包括项目范围及风险识别，风险评级、基于风险的测试、风险闭环。

基于风险的实施过程

3.1风险及范围识别

 风险识别目标是发现尽可能多的风险，以力求使得所有重要的风险都被识别。风险识别包括新老特性分析、风险基础性预测、历史运营数据分析等，并可以进行相关头脑风暴会议、专家讨论等。

新老特性分析：需要持续的针对业务情况进行分析，可以采用继承性分析法。

历史运营数据分析：主要通过线上反馈，对用户特性特性、模块稳定度、线上漏测率等进行分析。

除了以上内容，还需要对风险基础性预测，如下图

风险识别模型

时间进度风险：用户需求发生重大变更及设计计划的大幅调整给测试带来风险，导致测试时间、资金投入增加。

对产品认识的风险：对产品质量需求或产品特性理解不准确，造成测试范围分析误差，出现测试盲区或验证标准错误。

质量目标风险：质量标准不是很清晰，如适用性测试、易用性测试等。

人员风险：测试开始后，相关测试人员因故不能及时到位。

测试环境的依赖性风险：特定测试环境不到位，包括真实环境及仿真环境。

测试充分性风险：测试用例设计不到位，忽视了部分边界条件、深层次的逻辑、用户场景等；部分软件缺陷不易重现以及回归测试一般不运行全部测试用例，有选择性地执行。

工具风险：能否及时准备相关测试工具，测试人员对新工具无法熟练运用等情况也时有发生。

通过对各项分析形成特性需求表，为风险评估提供基础保障。

3.2风险评估

风险评估针对测试范围清单的每一项内容，进行度量和评估，包括风险概率、风险影响分析，并对风险进行综合评估，以此制定出风险策略。

风险分析的第一步就是要进行特性失效的概率有多大，这个需要根据具体业务情况确定，在此不详细叙述。

列出所有的特性后，针对每一个特性参考借鉴测试风险评估中测试特性故障影响评估的方法，根据调查统计、用户信息收集、系统缺陷分析等信息来确定各特性的失效影响度。

与测试风险评估中不同，对于特性失效影响的主要依据是：用户对特性功能的使用和关注程度(市场调研反馈，例如，局方人员绩效考核要素，用户的使用投诉等)

具体的操作步骤如下：

步骤1: 确定失效影响定义级别（可参考表2中的故障影响级别定义）

步骤2: 确定特性的失效影响度

根据失效影响的级别定义给出各特性的初始失效影响度值以及分析依据填入失效影响度分析表中。参见表3，注：蓝色部分为填写示例

失效影响分析表

步骤3:特性的失效影响度修正

在根据用例类型分析表（参见表4示例），明确系统所面向的不同的用户类型以及和它们所对应的修正系数。

用户类型：对于系统的操作使用较为一致的一类用户的集合。

特性范围：该用户类型所关注的特性集合。

使用概率修正：该用户使用特性中的功能的可能性，用于修正使用概率分析的结果。

失效影响修正：该用户对于特性能发生故障后的关注程度，用于修正故障影响分析的结果。

用户类型用户标识涉及特性使用概率修正失效影响修正评估依据

用户类型分析表

3.3基于风险的测试

在风险评估分析完成后，根据每个测试分析得出的风险分析进行测试设计、测试资源分配、详细测试方案制定。在测试过程中需要对风险高的优先测试，风险高的覆盖尽可能全，同时对风险持续评估、关注风险变化。

3.4风险闭环评估

测试完成后，根据测试的结果、测试数据度量分析我们的风险识别、风险分析及测试过程中存在的问题，予以风险警示，不断进行过程改进。这个是基于风险测试中非常重要的一环，很多时候我们忘记了这个环节，导致后续测试中，出现重大线上问题。

基于风险的测试最重要的观点是将软件的潜在风险作为测试安排的依据和目标。对当前潜在风险的全面分析和把握，才能有效地设计并组织恰当的测试；用尽可能少的测试资源，发现尽可能多的潜在缺陷，最大限度规避潜在风险降低维护成本。

2019年连续32天修心 土司于北京