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

基于风险的测试

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

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

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

积极风险 被视为业务可持续发展的机会和助力。例如，投资新项目、改变业务流程、开发新产品。
负面风险 被称为威胁，必须实施建议以尽量减少或消除这些威胁，以确保项目成功。

何时实施基于风险的测试

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

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

风险管理流程

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

风险识别

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

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

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

风险分解结构示例

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

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

风险应对规划

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

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

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

风险应急

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

风险监控

风险控制与监控流程用于跟踪已识别的风险、监控剩余风险、识别新的风险、更新风险登记册、分析变化的原因、执行风险应对计划和监控风险触发因素等，并评估其在降低风险方面的有效性。

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

下表提供了有关

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

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

基于风险的测试方法

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

基于风险的系统测试方法

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

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

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

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

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

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

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

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

让我们考虑功能需求 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 XNUMX 列）
8	测试目标	将使用什么测试目标来解决这个风险
9	测试技术	用什么方法或技术
10	依赖	测试人员假设什么并依赖什么
11	功夫	这项测试需要付出多少努力
12	时间刻度	做这个测试需要多少时间
13	测试阶段A-单元测试测试阶段B-集成测试测试阶段C-系统测试	进行此活动的个人或团体的名称

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

测试曝光量计算
测试人员分析每个风险并评估该风险是否可测试
针对可测试风险定义测试目标
测试人员指定应按计划开展的测试活动以满足测试目标（静态审查、检查、系统测试、集成测试、验收测试、html 验证、本地化测试等）
这些测试活动可分为几个阶段（组件测试/单元测试、集成测试、系统测试、验收测试）
有时，风险可能通过一个或多个测试阶段来解决
确定依赖关系和假设（技能、工具、测试环境、资源的可用性）
测试有效性是经过计算的。测试有效性与测试人员对通过测试确定风险的信心水平有关。测试有效性分数是 5 到 1 之间的数字。（XNUMX-高信心，XNUMX-低信心）
估计准备和执行这些测试所需的工作量、时间和成本。

测试优先级数是计算出来的。它是概率、后果和测试有效性分数的乘积。
- 125-Maximumà通过测试可以检测到的非常严重的风险
- 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

灾难性的 – 严重后果使项目完全无用，甚至可能导致项目停工。这必须是风险管理的首要任务。
危急– 后果严重，可能导致巨额损失。项目受到严重威胁。
边缘 – 短期损害仍然可以通过修复活动逆转。
微不足道– 损坏或损失很少或极小。这可以通过常规程序进行监控和管理。

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

严重
高
中等
低

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

高：属于这一类的风险用红色标记，并采取相应行动或风险管理策略。必须立即采取行动，隔离、消除、替代风险，并实施有效的风险控制。如果这些问题不能立即解决，则必须制定严格的时间表来解决这些问题。

适用介质： 属于此类的风险以黄色标记。必须采取合理、切实可行的措施将风险降至最低。

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

基于风险的测试通用检查表

基于风险的测试中需要考虑的重要点综合列表

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

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

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

计划测试用例数与执行测试用例数
通过/失败的测试用例数
发现的缺陷数量及其状态和严重程度
缺陷数量及其状态
严重缺陷数量-仍未解决
环境停机时间（如果有）
精彩内容 – 如果有的话，测试总结报告、测试覆盖率报告

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

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

固有风险与残留风险评估

风险识别与分析还应包括固有风险、剩余风险、次生风险和经常性风险

固有风险：在实施控制和响应之前已识别/已存在于系统中的风险。固有风险也称为总体风险
剩余风险：实施控制和响应后剩余的风险。剩余风险称为净风险
次要风险： 风险应对计划实施引发的新风险
经常性风险： 初始风险发生的可能性。

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

风险分析和客户反馈

风险分析是根据客户所需风险、风险能力和风险承受能力，为客户找到最佳投资风险水平的过程。

所需风险是客户为获得满意回报需要承担的风险水平
风险承受能力是指客户能够承担的财务风险水平
风险承受能力是客户愿意承担的风险水平

客户反馈

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

基于风险的测试的好处

基于风险的测试的好处如下

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

总结

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

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

测试按照风险优先顺序执行。风险监控流程有助于跟踪已识别的风险，并减少剩余风险的影响。

你可能会喜欢：