基于风险的测试策略
9月中旬开始陆续和大家分享了性能测试系列文章，从今天开始未来两周将和大家一起讨论分享测试策略相关系列文章，包括基于风险的测试策略、基于需求测试策略、基于质量模型的测试策略、基于上下文驱动的测试策略等文章，欢迎大家一起学习讨论。本文延展阅读请参考《全面的质量保障体系之回归测试策略》，更多文章见文末链接。
- 1 -
为什么要基于风险测试
在测试过程中经常会遇，穷尽测试不可能，如何选择测试重点？如何在有限的测试时间内完成测试？如何合理利用测试资源完成测试。通过采用基于风险的测试，平衡测试时间、成本、范围与质量。
- 2-
什么是基于风险测试
RBT(Risk-Based Testing)即基于风险的测试，James Bach在《Heuristic Risk-Based Testing》中将基于风险的测试描述为“列出一个风险的列表”，“进行考察每项风险的测试”，“当风险消失而新的风险出现的时候，调整测试计划”。
基于风险测试实施过程
3.1 风险及范围识别
风险识别目标是发现尽可能多的风险，以力求使得所有重要的风险都被识别。风险识别包括新老特性分析、风险基础性预测、历史运营数据分析等，并可以进行相关头脑风暴会议、专家讨论等。
新老特性分析：需要持续的针对业务情况进行分析，可以采用继承性分析法。
历史运营数据分析：主要通过线上反馈，对用户特性特性、模块稳定度、线上漏测率等进行分析。
除了以上内容，还需要对风险基础性预测，如下图
时间进度风险：用户需求发生重大变更及设计计划的大幅调整给测试带来风险，导致测试时间、资金投入增加。
对产品认识的风险：对产品质量需求或产品特性理解不准确，造成测试范围分析误差，出现测试盲区或验证标准错误。
质量目标风险：质量标准不是很清晰，如适用性测试、易用性测试等。
人员风险：测试开始后，相关测试人员因故不能及时到位。
测试环境的依赖性风险：特定测试环境不到位，包括真实环境及仿真环境。
测试充分性风险：测试用例设计不到位，忽视了部分边界条件、深层次的逻辑、用户场景等；部分软件缺陷不易重现以及回归测试一般不运行全部测试用例，有选择性地执行。
工具风险：能否及时准备相关测试工具，测试人员对新工具无法熟练运用等情况也时有发生。
通过对各项分析形成特性需求表，为风险评估提供基础保障。
3.2 风险评估
风险评估针对测试范围清单的每一项内容，进行度量和评估，包括风险概率、风险影响分析，并对风险进行综合评估，以此制定出风险策略。
风险分析的第一步就是要进行特性失效的概率有多大，这个需要根据具体业务情况确定，在此不详细叙述。
列出所有的特性后，针对每一个特性参考借鉴测试风险评估中测试特性故障影响评估的方法，根据调查统计、用户信息收集、系统缺陷分析等信息来确定各特性的失效影响度。
与测试风险评估中不同，对于特性失效影响的主要依据是：用户对特性功能的使用和关注程度(市场调研反馈，例如，三方人员绩效考核要素，用户的使用投诉等)
具体的操作步骤如下：
步骤1: 确定失效影响定义级别（可参考表2中的故障影响级别定义）
步骤2: 确定特性的失效影响度
根据失效影响的级别定义给出各特性的初始失效影响度值以及分析依据填入失效影响度分析表中。参见表3，注：蓝色部分为填写示例
步骤3:特性的失效影响度修正
在根据用例类型分析表（参见表4示例），明确系统所面向的不同的用户类型以及和它们所对应的修正系数。
用户类型：对于系统的操作使用较为一致的一类用户的集合。
特性范围：该用户类型所关注的特性集合。
使用概率修正：该用户使用特性中的功能的可能性，用于修正使用概率分析的结果。
失效影响修正：该用户对于特性能发生故障后的关注程度，用于修正故障影响分析的结果。
用户类型用户标识涉及特性使用概率修正失效影响修正评估依据
3.3 基于风险的测试
在风险评估分析完成后，根据每个测试分析得出的风险分析进行测试设计、测试资源分配、详细测试方案制定。在测试过程中需要对风险高的优先测试，风险高的覆盖尽可能全，同时对风险持续评估、关注风险变化。
3.4 风险闭环评估
· 推 荐 阅 读 ·RECOMMENDATION
京东金融App端链路服务端全链路压测策略
一次服务端性能问题排查过程再读《性能之巅》学习心得
你点的每个“在看”，我都认真当成了喜欢！