基于风险的测试方法、矩阵、过程和实例

基于风险的测试

基于风险的测试(RBT)是一种基于风险概率的软件测试类型，涉及到基于软件复杂性、业务的关键程度、使用频率、可能存在缺陷的领域等来评估风险。基于风险的测试优先测试软件应用程序的特性和功能，这些特性和功能更有影响力且可能有缺陷。

风险是指发生对项目的可衡量成功标准具有积极或消极影响的不确定事件。这些不确定事件可能会对项目的成本、业务、技术和质量目标产生影响。

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

积极的风险被称为机会和对业务可持续性的帮助。例如，投资一个新项目，改变业务流程，开发新产品。
负面风险被称为威胁，为了项目成功，必须实现将其最小化或消除的建议。

在本教程中，将了解-

何时实现基于风险的测试
风险管理流程
基于风险的测试方法
基于风险的系统测试方法
如何进行基于风险的测试：完整的过程
优先级排序和风险评估矩阵
基于风险的测试的通用检查表
基于风险的测试结果报告和度量
固有风险与剩余风险评估
基于风险的测试的好处

何时实现基于风险的测试

基于风险的测试可以在

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

风险管理流程

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

风险识别

风险识别可以通过风险研讨会、核对表、集思广益、面谈、德尔菲技术、因果图、从以前项目中吸取的教训、根本原因分析、联系领域专家和主题专家来完成。

风险登记表是一个表格，其中包含已识别的风险、潜在响应和根本原因的列表。IT风险应对策略可以用来管理正面风险和负面风险。

风险细分结构在风险规划中起着重要作用。风险分解结构将有助于识别易受风险影响的领域，实际上，它还有助于对项目风险可能产生的许多来源进行分类。

风险明细结构样本

风险分析(包括定量分析和定性分析)

一旦确定了潜在风险列表，下一步就是分析它们，并根据重要性将风险过滤。此技术用于确定风险的概率和影响。

风险应对计划

基于分析，我们可以决定是否需要应对风险。例如，有些风险需要在项目计划中做出响应，而有些风险需要在项目监控中做出响应，而有些则根本不需要任何响应。风险所有者负责确定降低所分配风险的概率和影响的选项。

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

偶然性可以描述为发生不确定事件的可能性，但影响是未知或不可预测的。换句话说，它决定了当不可预测的事件发生时可以采取的步骤。

风险监控

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

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

下表提供了有关

风险监测和控制的投入	风险监测和控制的工具和技术	风险监测和控制的产出
风险管理计划	项目风险应对审计	解决方案计划
风险应对计划	定期项目风险审查	纠正措施
项目沟通计划	挣值分析	项目更改求
其他风险识别和分析	技术性能测量	更新风险响应计划和风险识别表
作用域更改	其他风险应对计划	风险数据库

需要记住，风险随着技术的变化、项目的规模、项目的长度(较长的项目时间框架)、赞助机构的数量、项目估计、努力以及缺乏适当技能而增加。

基于风险的测试方法

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

基于风险的系统测试方法

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

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

系统测试既包括功能测试，也包括非功能测试。

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

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

本节介绍基于风险的测试流程

风险识别
风险分析
风险应对
测试作用域
测试过程定义

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

考虑功能需求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高)和 consequences(1 Low -5 High )

测试曝光量是计算出来的
测试人员分析每个风险，并评估该风险是否可测试
为可测试风险定义测试目标
测试人员指定应以计划的方式执行的测试活动，以满足测试目标
这些测试活动可以分为几个阶段(组件测试/单元测试、集成测试、系统测试、验收测试)
有时，可以通过一个或多个测试阶段来处理风险
确定依赖关系和假设(技能、工具、测试环境、资源的可用性)
对测试有效性进行了计算。测试有效性与测试人员对风险将被确定的置信度有关测试有效性分数是介于1和 5。( 5-高可信度 , 1-低可信度) 之间的数字
估计准备和执行这些测试的工作量、所需时间和成本。
计算测试优先级数。它是概率、结果和测试有效性分数的乘积。
- 125-最大通过测试可以检测到的非常严重的风险
- 1-最低风险A测试不会检测到的风险非常低
根据测试优先级数，可以将测试重要性分为高(红色 ) 、中(黄色)和低(绿色)。最高风险的项目首先进行测试。
将测试活动分配到测试阶段。指定将为不同测试阶段(单元测试, 集成测试, 系统测试, 接受测试) 中的每个目标执行测试的组
测试范围内和范围外的内容在测试范围确定阶段决定
对于每个阶段的测试目标，定义了测试中的组件、责任、环境、进入标准、退出标准、工具、技术和可交付成果。

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

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

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

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

考虑一下系统测试阶段

G4和G5演示了系统满足功能(F1、F2、F3) 和非功能需求(N1,N2) 。
使用测试演示系统的预期特性和功能运行良好，并且与F1、F2、F3相关的风险可以通过功能测试解决
使用测试证明系统的操作特征工作良好，并且与N1、N2相关的风险可以通过非功能测试来解决
根据测试优先级数，可以将测试重要性分为高(红) 、中(黄色)和低(绿色)。

优先级排序和风险评估矩阵

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

Risk rating = Probability x Severity

概率是不确定事件发生的可能性的度量。它是以百分比表示的。

这可以分类为频繁(A)、可能(B)、 Occasional(C) 、远程(D)、不可能(E)、已消除(F)

频繁-预计在大多数情况下会发生多次(91-100%)
可能的：在大多数情况下可能会发生几次(61-90%)
偶尔：可能在某个时候发生(41%-60%)
远程-不太可能发生/可能在某个时间发生(11-40%)
不太可能-可能在罕见和特殊情况下发生(0-10%)
消除-不可能发生(0%)

严重程度是由于不确定事件造成的损害或损失的影响程度。评分从1到4，可分为灾难性=1、危急=2、边缘=3、可忽略=4

灾难性的–使项目完全没有生产力，甚至可能导致项目停工的严酷后果。这必须是风险管理过程中的首要任务。
危急-可能导致巨大损失的重大后果。项目受到严重威胁。
边际-短期损害仍可通过恢复活动恢复。
微不足道-极小或极小的损害或损失。这可以通过常规程序进行监控和管理。

优先级分为四类，根据风险的严重程度和概率进行映射，如下图所示。

严重的
高
中
低

严重：此类别的风险以琥珀色标记。此外，除非风险降至低或中等水平，否则不得继续进行活动。

高：属于这一类别的风险以红色行动或风险管理策略标记。immedia如果这些问题不能立即解决，则必须定义严格的时间表来解决这些问题。

中：属于此类别的风险以黄色标记。必须采取合理而实际的措施，将风险降至最低。

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

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

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

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

基于风险的测试结果报告和度量

测试报告准备

报告测试状态是关于将测试结果有效地传达给项目干系人。并对测试结果与测试目标进行清晰的理解和比较。

计划与执行的测试用例数量
通过/失败的测试用例数量
识别的缺陷数量及其状态和严重程度
缺陷数量及其状态
严重缺陷数-仍未解决
环境停机-如果有

测试总结报告、测试覆盖率报告

指标准备

度量是用于比较软件过程、项目和产品的两个或多个度量的组合。

工作量和进度变化 
测试用例准备工作效率 
测试设计覆盖范围 
测试用例执行效率 
风险识别效率% 
风险缓解效率% 
测试有效性% 
测试执行覆盖率 
测试执行效率 
缺陷泄漏百分比 
缺陷检测效率 
需求稳定性指标 
质量成本

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

固有风险与剩余风险评估

风险识别和分析还应包括固有风险、残余风险、二次风险和经常性风险。

固有风险：在实现控制和响应之前在系统中识别/已经存在的风险。固有风险也称为总风险
剩余风险：实现控制和响应后遗留的风险。剩余风险称为净风险。
二次风险：实现风险应对预案带来的新风险
经常性风险：发生初始风险的可能性。

基于风险的测试结果度量有助于组织了解测试执行过程中质量风险的剩余级别，并做出明智的发布决策。

风险分析和客户反馈

风险描述是考虑所需风险、风险能力和风险承受能力，为客户找到最佳投资风险水平的过程。

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

用户反馈

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

基于风险的测试的好处

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

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

总结：

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

有效地组织了测试工作，并对每个风险项的优先级进行了评级。然后将每个风险与适当的测试活动相关联，在单个测试具有多个风险项的情况下，该测试被指定为最高风险。

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