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

基于风险的测试

基于风险的测试（RBT） 是一种基于风险概率的软件测试类型。它涉及根据软件复杂性、业务关键性、使用频率以及最有可能出现问题的区域来评估风险。 缺陷基于风险的测试优先测试软件应用程序中那些影响更大、更容易出现缺陷的特性和功能。

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

风险可以是积极的，也可以是消极的。

• 积极风险 被称为机遇，有助于企业的可持续发展。例如，投资新项目、改变业务流程和开发……ping 新产品。
• 负面风险 这些都被视为威胁，必须采取措施最大限度地减少或消除这些威胁，项目才能成功。

由于该技术是分配资源而不是增加新的测试级别，因此它位于其他技术之上。 软件测试类型 而不是替换其中任何一个。

何时实施基于风险的测试

基于风险的测试可以实施在

• 项目存在时间、资源或预算限制。
• 可以使用基于风险的分析来检测漏洞的项目 SQL注入攻击.
• 云计算环境下的安全测试。
• 存在高风险因素的新项目，例如缺乏使用相关技术的经验或缺乏业务领域知识。
• 渐进式和迭代式交付模式。

风险管理流程

现在让我们来了解一下风险管理流程的各个步骤。

风险识别

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

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

风险分解结构在风险规划中扮演着重要角色。它有助于识别风险易发区域，并支持在项目过程中进行有效的评估和风险监控。它有助于为风险管理活动分配充足的时间和资源，并对项目风险可能产生的各种来源进行分类。

下面的示例展示了风险分解结构如何将项目风险分组到不同的类别中，从而避免遗漏任何风险来源。

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

一旦确定了潜在风险清单，下一步就是分析这些风险并按重要性进行筛选。风险矩阵（将在后续章节介绍）是定性风险分析技术之一。该技术用于确定风险发生的概率和影响。

风险应对计划

根据分析结果，我们可以判断这些风险是否需要应对。例如，有些风险需要在项目计划中加以应对，有些风险需要在项目监控中加以应对，而有些风险则完全不需要任何应对措施。

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

风险缓解是一种风险应对方法，旨在减轻潜在威胁带来的不利影响。这可以通过消除风险或将其降低到可接受的水平来实现。下图将风险应对计划置于更广泛的风险管理周期中。

风险应急

应急预案可以理解为可能发生的不确定事件，其影响未知或无法预测。应急预案也称为行动计划或最坏情况应对方案。换句话说，它决定了当不可预测的事件发生时可以采取哪些措施。

风险监控

风险控制和监控流程用于 trac对已识别的风险进行评估，监控剩余风险，识别新风险，更新风险登记册，分析任何变更的原因，执行风险应对计划，并监控风险触发因素。然后评估这些措施在降低风险方面的有效性。

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

下表提供了有关风险监测和控制的输入、工具和输出的信息。

我们需要记住，随着技术变革、项目规模扩大、项目周期延长、赞助机构数量增加、项目估算增加、工作量增加以及相关技能短缺，风险也会增加。

基于风险的测试方法

上述管理流程为下文的测试方法提供数据。每个编号步骤都会产生一个输入，供下一步使用。

1. 分析需求。
   • 审核文档（SRS、FRS、用例）。此项工作的目的是查找并消除错误和歧义。
   • 需求验收是降低项目后期变更风险的有效方法之一。文档基线确定后，任何需求变更都需要经过变更控制流程和后续审批。
2. 评估风险 通过计算每项要求对项目可能产生的可能性和影响，同时考虑成本、进度、资源、范围、技术性能、安全性、可靠性和复杂性等既定标准。
   • 确定故障发生的概率和高风险区域。这可以通过风险评估矩阵来实现。
   • 使用风险登记册列出已识别的风险。更新、监控和 track 定期定期评估风险。
   • 在此阶段需要进行风险分析，以了解风险能力和风险承受水平。
3. 根据评级对要求进行优先排序。
   • 风险导向型测试流程已制定。
   • 对于高度危急和中等风险，可以考虑制定缓解计划、实施措施和进度监测。低风险可以列入观察名单。
   • 进行风险数据质量评估，分析数据的质量。
4. 根据评分标准规划和制定测试方案。
   • 采用合适的测试方法和测试设计技巧，优先测试风险最高的项目。高风险项目可由具备良好领域知识和经验的人员进行测试。
   • 可以使用不同的测试设计技术——例如， 决策表 高风险试题的技术，而且仅 等价划分 适用于低风险测试题。
   • 测试用例 旨在涵盖多种功能和端到端的业务场景。
   • 准备测试数据、测试条件和测试平台。
5. Rev查看测试文档 — 测试计划、测试策略、测试用例、测试报告以及测试团队创建的任何其他文档。
   • 同行评审是识别缺陷和降低风险的重要步骤。
6. 对结果进行试运行和质量检查。
   • 测试用例按照风险项的优先级执行。
   • 保持 trac风险项、涵盖这些风险项的测试、这些测试的结果以及测试过程中发现的缺陷之间的可比性至关重要。所有正确执行的测试策略都能降低质量风险。
   • 基于风险的测试可以应用于各个级别的测试—— 元件, 积分, 系统 以及验收测试。
   • 在系统层面，我们需要关注应用程序中最重要的部分。这可以通过考察功能的可见性、使用频率以及故障可能造成的损失来确定。
   • 退出标准评估：所有高风险区域均已全面测试，仅剩少量残余风险。
7. 报告基于风险的测试结果 并分析各项指标。
   • 根据关键风险指标重新评估现有风险事件和新风险事件。
   • 更新风险登记册。
   • 应急计划可作为应对高风险情况的备用方案或紧急预案。
   • 缺陷分析和缺陷预防用于消除缺陷。
   • 重新测试和 迭代测试 根据预先计算的风险分析验证缺陷修复情况，高风险区域应重点关注。
   • 如果可行，采用基于风险的自动化测试。
   • 残余风险计算。
8. 监测并控制风险。
   • 可以根据不同的风险等级分别制定退出标准或完成标准。所有关键风险均已采取适当的措施或应急预案加以应对，风险敞口已达到或低于项目商定的可接受水平。
   • 风险分析重新评估和客户反馈。

基于风险的系统测试方法

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

下图清晰地概述了上述过程。

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

功能测试 确保产品或应用程序满足客户和业务需求。另一方面， 非功能性测试 这样做是为了验证产品在质量、可靠性、易用性、性能和兼容性方面是否符合客户的期望。

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

本节介绍基于风险的测试流程，该流程分为五个阶段。

1. 风险识别
2. 风险分析
3. 风险应对
4. 测试 Scoping
5. 测试流程定义

这五个阶段相互衔接，如下所示。

1. 在此过程中，风险被识别和分类，风险登记册草案被编制出来，风险排序被确定为重大风险。
2. 风险应对包括根据风险制定测试目标，并选择适当的技术，使测试活动或测试技术达到这些测试目标。
3. 为了计算测试有效性得分，需要考虑已记录的依赖关系、需求、成本以及软件测试所需的时间。
4. 测试分数ping 审查活动需要所有利益相关方和技术人员的参与。务必遵守商定的风险范围。这些风险需要通过测试来应对，所有成员必须同意分配给他们的职责以及为这些活动分配的预算。
5. 确定测试范围后，必须将每个测试阶段的测试目标、假设和依赖关系汇编成标准格式。

下面的示例将每个需求与其相关的风险以及解决该风险的测试目标进行对应。

让我们考虑功能需求 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 相关的风险

• 测试目标 N2 — 通过测试证明系统运行特性正常，并且风险 NR2 可以通过非功能性测试解决。
• 测试 - 安全测试 是一种用于检查应用程序是否安全或容易受到攻击、是否存在任何信息泄露以及验证 NR2 是否可以通过安全测试解决的技术。

具体测试目标： 所列风险和测试目标均针对特定测试类型，如下所述。

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

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

该登记册的第1列和第2列分别包含标识符和风险描述。其余列的说明如下。

对每项风险的概率（1 低，5 高）和后果（1 低，5 高）进行评估，因为两个登记表都包含风险评估。trac如下所示。

• 测试暴露量已计算。
• 测试人员分析每项风险，并评估该风险是否可测试。
• 针对可测试风险，制定了测试目标。
• 测试人员会指定应按计划执行的测试活动，以达到测试目标（静态审查、检查、系统测试、集成测试、验收测试、HTML 验证、本地化测试等等）。
• 这些测试活动可以分为多个阶段（组件测试或 单元测试（集成测试、系统测试、验收测试）。
• 有时，一项风险可能需要通过多个测试阶段来解决。
• 确定依赖关系和假设（技能、工具、测试环境和资源的可用性）。
• 计算测试有效性。测试有效性是指测试人员对通过测试能够彻底解决风险的信心程度。测试有效性得分介于 1 到 5 之间（5 = 高度确信，1 = 低度确信）。
• 估算准备和执行这些测试所需的工作量、时间和成本。

接下来的两个例子tracts 显示剩余的注册列和测试有效性评分。

• 测试优先级数是通过计算概率、后果和测试效果得分的乘积得到的。
• 125（最大值）——这是一个非常严重的风险，可以通过检测发现。
• 1（最低）——风险极低，无法通过检测发现。
• 根据测试优先级编号，测试重要性可分为高（红色）、中（黄色）和低（绿色）。风险最高的项目优先测试。
• 将测试活动分配到各个测试阶段。指定负责在不同测试阶段（单元测试、集成测试、系统测试、验收测试）执行每个目标测试的团队。

下面显示了各测试阶段的分配情况。

测试范围的界定在测试大纲中确定。ping 相。

• 每个阶段都定义了测试目标、被测组件、责任人、测试环境、准入标准、准出标准、测试工具、测试技术和测试成果。

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

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

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

• 组件测试
• 整合测试
• 系统测试
• 验收测试

让我们来考虑系统测试阶段。

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

优先级和风险评估矩阵

风险评估矩阵是概率-影响矩阵。它使项目团队能够快速了解​​风险以及应对每项风险的优先级。

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。

• 灾难性的 ——严重的后果可能导致项目完全停滞，甚至导致项目终止。这必须是风险管理中的重中之重。
• 危急 ——后果严重，可能导致巨大损失。该项目面临严重威胁。
• 边缘 — 短期损害，仍可通过修复活动逆转。
• 微不足道 — 损失或损害轻微或极小。可通过常规程序进行监测和处理。

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

• 严重
• 高
• 中
• 低

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

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

适用介质： 此类风险以黄色标记。必须采取合理且切实可行的措施来最大程度地降低这些风险。

低： 此类风险以绿色标记，通常可以接受，因为它们不会造成任何重大问题。但仍需定期审查，以确保控制措施持续有效。

基于风险的测试通用检查清单

该矩阵决定了风险等级的评定方式。下面的清单决定了哪些候选对象首先要进入该矩阵。

• 项目中的重要功能。
• 用户在项目中可见的功能。
• 对安全影响最大的功能。
• 对用户经济影响最大的功能。
• 源代码中高度复杂的部分以及容易出错的代码。
• 可以在开发周期早期测试的特性或功能。
• 在产品设计的最后一刻添加的特性或功能。
• 导致类似或相关先前项目出现问题的关键因素。
• 对运营和维护费用产生巨大影响的类似或相关项目的主要因素或问题。
• 需求不明确会导致设计和测试不完善，这可能会对项目目标和交付成果产生影响。
• 最糟糕的情况下，产品可能存在严重缺陷，无法返工，只能彻底报废，这将严重损害公司声誉。请确定哪些问题对产品目标至关重要。
• 会导致持续客户服务投诉的情况或问题。
• 可以轻松进行端到端测试，重点关注系统的多种功能。
• 能够最大限度提高风险覆盖率的最佳测试组合。
• 哪些检测方法能在最短时间内覆盖高风险人群？

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

1. 测试报告撰写。 报告测试状态的目的是有效地向项目利益相关者传达测试结果，让他们清楚地了解测试结果，并展示测试结果与测试目标的对比情况。
   • 计划测试用例数与已执行测试用例数之比。
   • 通过或失败的测试用例数量。
   • 已发现的缺陷数量、缺陷状态和严重程度。
   • 仍存在多个关键缺陷。
   • 环境停机时间（如有）。
   • 如果有的话，就是那些令人惊艳的亮点。
   • 测试总结报告和 测试覆盖率 报告。
2. 指标准备。 指标是用于比较软件流程、项目和产品的两种或多种衡量标准的组合。
   • 工作量和进度安排的差异。
   • 测试用例准备效率。
   • 测试设计覆盖率。
   • 测试用例执行效率。
   • 风险识别效率百分比
   • 风险缓解效率
   • 测试有效性百分比
   • 测试执行覆盖率。
   • 测试执行效率。
   • 缺陷泄漏率
   • 缺陷检测效率，以及 缺陷密度.
   • 需求稳定性指标。
   • 质量成本。

然后将这些措施与风险进行对比：

• 根据缺陷状态和测试通过或失败结果的数量，分析非功能性类别（性能、可靠性和可用性）的风险，并将其与风险联系起来。
• 使用测试指标、缺陷状态和测试通过或失败状态，分析功能类别中的风险与风险之间的关系。
• 确定关键的领先指标和滞后指标，并创建预警指标。
• 通过分析数据模式、趋势和相互依存关系，监测和报告领先和滞后风险指标（关键风险指标）。

固有风险与残留风险评估

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

• 固有风险： 控制和应对措施实施之前已识别或存在于系统中的风险。固有风险也称为总风险。
• 剩余风险： 实施控制和应对措施后仍然存在的风险。这些剩余风险被称为净风险。
• 次要风险： 风险应对计划实施带来的新风险。
• 复发风险： 最初风险再次发生的可能性。

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

风险分析和客户反馈

风险评估是一个为客户找到最佳投资风险水平的过程，需要考虑客户所需的风险、风险承受能力和风险容忍度。

1. 所需风险 是客户为了获得满意的回报需要承担的风险水平。
2. 风险承受能力 是客户能够承受的财务风险水平。
3. 风险承受能力 这是客户愿意承担的风险水平。

客户的反馈意见： 收集客户反馈和评价，以改进业务、产品、服务和体验。

基于风险的测试的好处

风险导向型测试的优势如下。

• 提高生产效率并降低成本。
• 改善市场机会（上市时间）和准时交付。
• 服务性能提升。
• 质量得到提升，因为应用程序的所有关键功能都经过了测试。
• 清晰的测试覆盖率信息。通过这种方式，团队可以清楚地了解哪些内容已经测试过，哪些内容尚未测试。
• 根据风险评估分配测试工作量是最大限度降低发布后剩余风险的最有效方法。
• 基于风险分析的测试结果测量能够帮助组织识别测试执行过程中剩余的质量风险水平，并做出明智的发布决策。
• 采用明确的风险评估方法进行优化测试。
• 客户参与、良好的报告和进展，提高了客户满意度。 trac王。
• 及早发现潜在问题区域，以便采取有效的预防措施。
• 在项目的整个生命周期内持续进行风险监测和评估，有助于识别和解决风险，并解决可能危及项目总体目标实现的问题。

常见问题