基于风险的测试：方法、矩阵、流程和示例

基于风险的测试

基于风险的测试 (RBT) 是一种基于风险概率的软件测试类型。它涉及根据软件复杂性、业务关键性、使用频率、可能存在缺陷的区域等评估风险。基于风险的测试优先测试对软件应用程序影响更大且可能存在缺陷的功能。

风险是具有对项目可衡量成功标准产生正面或负面影响的不确定事件的发生。它可能是过去发生或当前发生的事件，或者将来可能发生的事件。这些不确定事件可能对项目的成本、业务、技术和质量目标产生影响。

风险可以是正面的，也可以是负面的。

正面风险被称为机遇，有助于业务的可持续发展。例如，投资新项目、改变业务流程、开发新产品。
负面风险被称为威胁，为确保项目成功，必须实施建议以最小化或消除它们。

何时实施基于风险的测试

基于风险的测试可应用于

具有时间、资源、预算限制等的项目。
可以利用基于风险的分析来检测 SQL 注入攻击漏洞的项目。
云计算环境中的安全测试。
具有高风险因素的新项目，例如缺乏使用技术的经验、缺乏业务领域知识。
增量和迭代模型等。

风险管理流程

现在让我们了解风险管理流程中涉及的步骤

风险识别

风险识别可以通过风险研讨会、检查表、头脑风暴、访谈、德尔菲技术、因果图、从先前项目中吸取的经验教训、根本原因分析、联系领域专家和主题专家来完成。

风险登记册是一个电子表格，其中列出了已识别的风险、潜在应对措施和根本原因。它用于在项目的整个生命周期中监控和跟踪风险（包括威胁和机遇）。风险应对策略可用于管理正面和负面风险。

风险分解结构在风险规划中起着重要作用。风险分解结构有助于识别易受风险影响的领域，并有助于在项目过程中进行有效的评估和风险监控。它有助于为风险管理活动提供足够的时间和资源。它还有助于对可能产生项目风险的许多来源进行分类。

风险分解结构示例

风险分析（包括定量和定性分析）

一旦确定了潜在风险列表，下一步就是分析它们并根据重要性筛选风险。定性风险分析技术之一是使用风险矩阵（下一节介绍）。该技术用于确定风险的概率和影响。

风险应对计划

根据分析，我们可以决定风险是否需要应对。例如，有些风险需要在项目计划中应对，有些风险需要在项目监控中应对，有些则根本不需要应对。

风险所有者负责识别选项以降低指定风险的概率和影响。

风险缓解是一种风险应对方法，用于减轻潜在威胁的不利影响。这可以通过消除风险或将其降低到可接受的水平来完成。

风险应急

应急可以描述为不确定事件的可能性，但影响未知或不可预测。应急计划也称为最坏情况下的行动计划/备用计划。换句话说，它确定了当不可预测事件发生时可以采取的步骤。

风险监控与控制

风险控制和监控过程用于跟踪已识别的风险、监控残余风险、识别新风险、更新风险登记册、分析变更原因、执行风险应对计划和监控风险触发器等。评估它们在降低风险方面的有效性。

这可以通过风险再评估、风险审计、偏差和趋势分析、技术绩效测量、状态更新会议和回顾会议来实现。

下表提供了有关以下信息

风险监控与控制的输入	风险监控与控制的工具和技术	风险监控与控制的输出
风险管理计划	项目风险应对审计	权宜之计
风险应对计划	定期项目风险审查	纠正措施
项目沟通计划	挣值分析	项目变更请求
额外风险识别和分析	技术性能测量	更新风险应对计划和风险识别核对表
范围变更	额外风险应对计划	风险数据库

我们需要记住，随着技术变化、项目规模、项目长度（更长的项目时间框架）、赞助机构数量、项目估算、工作量以及适当技能短缺，风险会增加。

基于风险的测试方法

分析需求。
审查文档（SRS、FRS、用例）。此活动旨在发现并消除错误和歧义。
需求签核是避免在项目中引入后期变更的风险降低技术之一。文档基线化后，对需求的任何更改都将涉及变更控制流程和后续批准。
通过计算每个需求对项目可能产生的影响的可能性和影响来评估风险，同时考虑成本、进度、资源、范围、技术性能、安全性、可靠性、复杂性等已定义标准。
识别失败概率和高风险区域。这可以通过风险评估矩阵来完成。
使用风险登记册列出已识别的风险集。定期更新、监控和跟踪风险。
在此阶段需要进行风险画像以了解风险承受能力和风险容忍度。
根据评级对需求进行优先级排序。
定义了基于风险的测试过程
高度关键和中等风险可考虑进行缓解规划、实施、进度监控。低风险可列入观察清单。
进行风险数据质量评估以分析数据质量。
根据评级规划和定义测试
采用适当的测试方法和测试设计技术，以确保首先测试风险最高的项目。高风险项目可由具有良好领域知识和经验的资源进行测试。
可以使用不同的测试设计技术，例如对高风险测试项目使用决策表技术，而对低风险测试项目“仅”使用等价划分。
测试用例还设计用于覆盖多个功能和端到端业务场景。
准备测试数据、测试条件和测试平台。
审查测试团队创建的测试计划、测试策略、测试用例、测试报告或任何其他文档。
同行评审是缺陷识别和风险降低的重要步骤。
对结果进行预演和质量检查
测试用例按照风险项目的优先级执行。
保持风险项目、覆盖它们的测试、这些测试的结果以及测试期间发现的缺陷之间的可追溯性。所有正确执行的测试策略都将降低质量风险。
基于风险的测试可用于测试的各个级别，例如组件、集成、系统和验收测试
在系统层面，我们需要关注应用程序中最重要的内容。这可以通过查看功能的可见性、使用频率和可能的故障成本来确定。
评估退出标准。所有高风险区域都已充分测试，仅剩少量残余风险未解决。
基于风险的测试结果报告和指标分析。
根据关键风险指标重新评估现有风险事件和新风险事件。
风险登记册更新。
应急计划——这作为高风险的备用计划/紧急计划。
缺陷分析和缺陷预防以消除缺陷。
根据预先计算的风险分析，对缺陷修复进行再测试和回归测试，高风险区域应得到最集中的覆盖。
基于风险的自动化测试（如果可行）
残余风险计算
风险监控与控制
退出条件或完成条件可用于不同的风险级别。所有关键风险均已通过适当的行动或应急计划得到解决。风险暴露已达到或低于项目可接受的水平。
风险画像再评估和客户反馈。

系统测试的基于风险的测试方法

技术系统测试 – 这指环境测试和集成测试。环境测试包括在开发、测试和生产环境中进行测试。
功能系统测试 – 测试所有功能、特性、程序、模块。此测试的目的是评估系统是否满足其指定要求。
非功能系统测试 – 测试非功能要求：性能、负载测试、压力测试、配置测试、安全测试、备份和恢复程序以及文档（系统、操作和安装文档）。

下图清晰概述了上述过程

系统测试包括功能测试和非功能测试。

功能测试确保产品/应用程序满足客户和业务需求。另一方面，非功能测试用于验证产品在质量、可靠性、可用性、性能、兼容性等方面是否达到客户期望。

如何进行基于风险的测试：完整流程

本节涵盖基于风险的测试流程

风险识别
风险分析
风险应对
测试范围
测试流程定义

在此过程中，识别并分类风险，准备风险登记册草稿，进行风险排序以识别重要风险。
风险应对涉及从风险中制定测试目标，并选择适当的技术来展示测试活动/测试技术以实现测试目标。
文档依赖关系、需求、成本、软件测试所需时间等都被考虑在内，以计算测试有效性分数。
测试范围界定是一项需要所有利益相关者和技术人员参与的审查活动。遵守商定的风险范围非常重要。这些风险需要通过测试来解决，并且所有成员都同意分配给他们的职责和为这些活动分配的预算。
在测试范围确定后，必须以标准格式编制每个测试阶段的测试目标、假设和依赖关系。

我们来考虑功能需求 F1、F2、F3 和非功能需求 N1 和 N2

F1-功能需求，R1-与 F1 相关的风险

测试目标 1- 通过测试证明系统的预期特性和功能正常工作，并且风险 R1 可以通过功能测试解决。
测试 - 进行浏览器页面测试，以执行重要的用户任务，并验证 R1（与 F1 相关的风险）是否可以在一系列场景中得到解决。

F2-功能需求，R2-与 F2 相关的风险

测试目标 2- 通过测试证明系统的预期特性和功能正常工作，并且风险 R2 可以通过功能测试解决
测试 - 进行浏览器页面测试以执行重要的用户任务，并验证 R2 是否可以在一系列场景中得到解决。

F3-功能需求，R3-与 F3 相关的风险

测试目标 3- 通过测试证明系统的预期特性和功能正常工作，并且风险 R3 可以通过功能测试解决
测试 - 进行浏览器页面测试以执行重要的用户任务，并验证 R3 是否可以在一系列场景中得到解决。

N1-非功能需求，NR1-与 N1 相关的风险

测试目标 N1-通过测试证明系统的操作特性正常，并且风险 NR1 可以通过非功能测试解决
测试 - 可用性测试是一种用于评估用户界面易用性的技术，并验证 NR1 是否可以通过可用性测试解决。

N2-非功能需求，NR2-与 N2 相关的风险

测试目标 N.2-通过测试证明系统的操作特性正常，并且风险 NR2 可以通过非功能测试解决
测试-安全测试是一种用于检查应用程序是否安全、是否存在攻击漏洞、是否存在信息泄露的技术，并验证 NR2 是否可以通过安全测试解决。

具体测试目标：列出的风险和测试目标特定于测试类型。

设计基于风险的测试过程的程序

准备风险登记册。这记录了从通用风险清单、现有检查表、头脑风暴会议中得出的风险。
包括与系统功能和非功能需求（可用性、安全性、性能）相关的风险
每个风险都被分配一个唯一的标识符

列号	列标题	描述
3	可能性	系统容易出现此故障模式的可能性
4	后果	此故障模式的影响
5	暴露	概率与后果的乘积（第 3 和 4 列）
6	测试效率	测试人员对他们能解决这个风险有多大的信心？
7	测试优先级编号	概率、后果和测试有效性（第 3、4、6 列）的乘积
8	测试目标	将使用什么测试目标来解决这个风险
9	测试技术	使用什么方法或技术来
10	依赖关系	测试人员假设和依赖什么
11	工作量	进行此测试需要多少工作量
12	时间范围	进行此测试需要多少时间
13	测试阶段 A-单元测试阶段 B-集成测试阶段 C-系统测试	执行此活动的人员或小组的名称

评估每个风险的概率（1 低 - 5 高）和后果（1 低 - 5 高）

计算测试暴露
测试人员分析每个风险并评估风险是否可测试
为可测试风险定义测试目标
测试人员指定应按计划执行的测试活动，以达到测试目标（静态评审、检查、系统测试、集成测试、验收测试、HTML 验证、本地化测试等）
这些测试活动可分为多个阶段（组件测试/单元测试、集成测试、系统测试、验收测试）
有时，一个风险可能由一个或多个测试阶段解决。
识别依赖关系和假设（技能、工具、测试环境、资源的可用性）
计算测试效率。测试效率与测试人员对风险将通过测试明确解决的信心水平有关。测试效率得分介于 1 到 5 之间。（5 - 高信心，1 - 低信心）
估算准备和执行这些测试所需的工作量、时间和成本。

计算测试优先级编号。它是概率、后果和测试有效性得分的乘积。
- 125-最大值 -> 一个通过测试可以检测到的非常严重的风险
- 1-最小值 -> 通过测试无法检测到的极低风险
根据测试优先级编号，测试重要性可分为高（红色）、中（黄色）和低（绿色）。风险最高的项目首先进行测试。
将测试活动分配到测试阶段。指定在不同测试阶段（单元测试、集成测试、系统测试、验收测试）中对每个目标执行测试的小组。
在测试范围界定阶段决定测试范围之内和范围之外的内容
对于每个阶段，定义测试目标、被测组件、职责、环境、进入标准、退出标准、工具、技术和可交付成果。

通用测试目标 - 这些通用目标适用于多个项目和应用程序

组件符合要求，可用于更大的子系统。
解决了与特定测试类型相关的风险，并实现了测试目标。
集成组件正确组装。确保组件之间的接口兼容性。
系统满足指定的功能和非功能要求。
产品组件在预期运行环境中满足最终用户需求
风险管理策略用于识别、分析和缓解风险。
系统符合行业法规要求
系统符合合同义务
制度化和实现其他设定的具体目标，例如成本、进度和质量目标。
系统、流程和人员符合业务要求

可以为不同的测试阶段定义通用测试目标

组件测试
集成测试
系统测试
验收测试

我们来考虑系统测试阶段

G4 和 G5 证明系统满足功能（F1、F2、F3）和非功能要求（N1、N2）。
通过测试证明系统的预期特性和功能正常工作，并且与 F1、F2、F3 相关的风险可以通过功能测试解决。
通过测试证明系统的操作特性正常工作，并且与 N1、N2 相关的风险可以通过非功能测试解决。
根据测试优先级编号，测试重要性可分为高（红色）、中（黄色）和低（绿色）。

优先级和风险评估矩阵

风险评估矩阵是概率影响矩阵。它为项目团队提供了风险的快速视图以及需要解决这些风险的优先级。

Risk rating = Probability x Severity

概率是衡量不确定事件发生的可能性的指标。暴露程度以时间、接近度和重复次数衡量。它以百分比表示。

这可以分为频繁（A）、可能（B）、偶尔（C）、远程（D）、不可能（E）、消除（F）

频繁 - 在大多数情况下预计会发生几次（91 – 100%）
可能：在大多数情况下很可能发生几次 (61 – 90%)
偶尔：可能偶尔发生 (41 – 60%)
远程 - 不太可能发生/可能有时发生（11 – 40%）
不可能 - 在极少数和特殊情况下可能发生 (0 - 10%)
消除 - 不可能发生 (0%)

严重性是不确定事件造成的损害或损失的影响程度。分为 1 到 4 分，可分类为灾难性 = 1，严重 = 2，轻微 = 3，可忽略 = 4。

灾难性 – 严重后果，使项目完全停滞，甚至可能导致项目关闭。这在风险管理中必须是最高优先级。
严重 – 造成巨大损失的严重后果。项目受到严重威胁。
轻微 – 短期损害，仍可通过恢复活动逆转。
可忽略 – 很少或最小的损害或损失。这可以通过常规程序进行监控和管理。

优先级分为四类，与风险的严重性和可能性对应，如下图所示。

严重
高
中等
低

严重：属于此类的风险以琥珀色标记。必须停止活动，并立即采取措施隔离风险。必须识别并实施有效的控制措施。此外，除非风险降低到低或中等水平，否则活动不得进行。

高：此类别中的风险以红色标记，需要立即采取行动或风险管理策略。必须立即采取行动隔离、消除、替代风险并实施有效的风险控制。如果这些问题无法立即解决，则必须定义严格的时间表来解决这些问题。

中等：属于此类的风险以黄色标记。必须采取合理且实际的步骤来最小化风险。

低：属于此类的风险以绿色标记，可以忽略，因为它们通常不会造成任何重大问题。定期审查是确保控制措施持续有效的必要条件。

基于风险的测试通用核对清单

基于风险的测试中要考虑的重要事项的综合清单

项目中重要的功能。
项目中用户可见的功能
对安全性影响最大的功能
对用户产生最大财务影响的功能
源代码中高度复杂的区域和容易出错的代码
可以在开发周期的早期进行测试的特性或功能。
在最后时刻添加到产品设计中的特性或功能。
类似/相关先前项目导致问题/的关键因素。
对操作和维护费用产生巨大影响的类似/相关项目的主要因素或问题。
导致设计和测试不佳的糟糕需求，这可能会对项目目标和可交付成果产生影响。
在最坏的情况下，产品可能存在缺陷，无法返工，必须完全报废，这将严重损害公司的声誉。确定哪些类型的问题对产品目标至关重要。
会导致持续客户服务投诉的情况或问题。
端到端测试可以很容易地关注系统的多个功能。
最大化风险覆盖率的最佳测试集
哪些测试将具有最佳的高风险覆盖率与所需时间比？

基于风险的测试结果报告和指标

测试报告准备报告测试状态是为了有效地将测试结果传达给项目利益相关者。并提供清晰的理解，并展示测试结果与测试目标的比较。

计划的测试用例数量与执行的测试用例数量
通过/失败的测试用例数量
已识别缺陷的数量及其状态和严重性
缺陷数量及其状态
关键缺陷数量 - 仍未解决
环境停机时间 – 如果有的话
阻碍性问题 – 如果有的话，测试摘要报告，测试覆盖率报告

度量准备度量是用于比较软件过程、项目和产品的两个或多个度量的组合。
- 工作量和进度偏差
- 测试用例准备效率
- 测试设计覆盖率
- 测试用例执行效率
- 风险识别效率 %
- 风险缓解效率 %
- 测试效率 %
- 测试执行覆盖率
- 测试执行效率
- 缺陷泄漏 %
- 缺陷检测效率
- 需求稳定性指数
- 质量成本

根据缺陷状态和测试通过/失败状态，以及它们与风险的关系，分析非功能类别（性能、可靠性和可用性）中的风险。
根据测试指标、缺陷状态和测试通过/失败状态，以及它们与风险的关系，分析功能类别中的风险。
识别关键的领先和滞后指标，并创建早期预警指标
通过分析数据模式、趋势和相互依赖关系，监控和报告领先和滞后风险指标（关键风险指标）。

固有风险与残余风险评估

风险识别和分析还应包括固有风险、残余风险、次级风险和复发风险

固有风险：在实施控制和应对措施之前，系统已识别/已存在的风险。固有风险也称为总风险。
残余风险：在实施控制和应对措施后剩余的风险。残余风险被称为净风险。
次级风险：由于实施风险应对计划而产生的新风险
复发风险：初始风险发生的可能性。

基于风险的测试结果测量有助于组织了解测试执行期间的质量风险残余水平，并做出明智的发布决策。

风险画像和客户反馈

风险画像是一个过程，旨在为客户找到最佳的投资风险水平，同时考虑所需风险、风险承受能力和风险容忍度。

所需风险是客户为获得满意回报而需要承担的风险水平
风险承受能力是客户能够承受的财务风险水平
风险容忍度是客户希望承担的风险水平

客户反馈

收集客户反馈和评论，以改进业务、产品、服务和体验。

基于风险的测试的优势

基于风险的测试的优点如下

提高生产力，降低成本
改善市场机会（上市时间）和按时交付。
提高服务性能
提高质量，因为应用程序的所有关键功能都经过测试。
提供关于测试覆盖率的清晰信息。通过这种方法，我们知道哪些已经/尚未测试。
基于风险评估的测试工作分配是最大限度地减少发布后残余风险的最有效方式。
基于风险分析的测试结果测量使组织能够在测试执行期间识别质量风险的残余水平，并做出明智的发布决策。
通过高度定义的风险评估方法优化测试。
提高客户满意度——由于客户参与以及良好的报告和进度跟踪。
及早发现潜在问题区域。可以采取有效的预防措施来克服这些问题。
在项目的整个生命周期中持续进行风险监控和评估，有助于识别和解决风险，并解决可能危及实现项目总体目标和目的的问题。

摘要

在软件工程中，基于风险的测试是根据风险指导项目最有效的方式。

测试工作得到有效组织，并对每个风险项目的优先级进行评级。然后，每个风险都与适当的测试活动相关联，如果一个测试有多个风险项目，则该测试被指定为最高风险。

测试按照风险优先级顺序执行。风险监控过程有助于跟踪已识别的风险，并降低残余风险的影响。