基于风险的测试——方法、矩阵、流程和示例
基于风险的测试 (RBT)
这是基于风险概率的软件测试的一个子类别。在这个测试中,会对软件进行评估以识别风险。它包括评估业务的 критичность、使用频率、可能出现问题的区域等。这种类型的测试强调对易受缺陷影响的软件特性和功能进行测试。
风险是指任何可能对项目结果产生影响(正面或负面)的意外事件的发生。风险可以是先前发生的事件,也可以是当前事件,甚至是未来可能发生的事件。这些事件会影响项目的成本、业务、技术和质量标准。
风险分为两种:
积极风险——这些被称为机会,能够促进业务的可持续性。例如,投资新项目、改变业务流程等。
消极风险——这些被称为威胁,应该执行减少或消除它们的建议以确保项目成功。
何时执行基于风险的测试
可以在以下情况下进行:
拥有适当的时间、资源、预算等的项目。
可以进行风险分析以查找冗余和SQL注入攻击漏洞的项目。
云计算中的安全测试。
具有高风险因素的项目,例如,缺乏项目中涉及的技术专业知识或缺乏领域知识。
迭代和逐步模型。
风险管理流程
以下是风险管理流程的步骤:
风险识别——这可以通过风险研讨会、检查表、头脑风暴、访谈、德尔菲技术、因果图、以往项目的观察、根本原因分析、领域专家和主题专家来实现。
风险登记册——这是一个电子表格,其中包含已识别的风险、可能的响应和根本原因的列表。它在整个项目中跟踪和监控风险。风险应对策略用于处理积极和消极风险。风险分解结构对于风险规划至关重要。它有助于识别易受风险影响的区域,并有助于有效评估和监控整个项目的风险。它有助于为风险管理留出足够的时间和资源。它还有助于对项目可能产生的风险来源进行分类。
风险分析——列出潜在风险后,将根据其重要性对它们进行分析和筛选。这包括定量和定性风险分析。定性风险分析的一种技术是风险矩阵,用于估计风险的概率和影响。
风险应对计划——根据此分析,可以确定风险是否需要响应。某些风险本质上需要在项目规划中做出响应,而某些风险可能需要在项目监控中做出响应,而某些风险甚至根本不需要做出响应。风险所有者确定选项以最大限度地减少已分配任务的概率和有效性。
风险缓解——这是一种最大限度地减少风险或潜在威胁的影响的方法。它是通过消除风险或将其最小化到指定的可接受水平来执行的。
风险应急——这是无法预测的事件的可能性,其影响既未知也无法估计。应急计划也称为行动计划或针对最坏情况的备用计划。它有助于决定在意外事件发生时应采取的步骤。
风险监控和控制——这是一个跟踪已识别风险、监控残余风险、发现新风险、更新现有风险、分析变化、执行响应计划和监控风险触发器的过程。这可以通过风险评估、风险审计、差异和趋势分析、测量技术性能、更新状态会议和追溯会议来实现。
请注意,随着技术的变化、项目规模、项目长度或持续时间、赞助机构的数量、工作量和缺乏适当技能,风险会增加。
基于风险的测试方法
分析需求。
审查文档,例如 SRS、FRS、用例等,以检测和消除错误和歧义。
为了避免在项目中引入任何后期更改,采用了称为“需求签核”的风险降低技术。在对文档进行基线化之后,如果必须进行任何更改,则需要更改控制流程和后续批准。
通过确定每个需求对项目的影响和可能性来评估风险,同时考虑已定义的标准,例如成本、进度、资源、范围、技术性能安全、可靠性等。
确定故障概率和易受风险影响的区域。这是使用风险评估矩阵完成的。
维护风险登记册以记录已识别的风险。定期更新、跟踪和监控风险。
在此阶段执行风险分析以确定风险的能力和容忍度水平。
根据其等级对需求进行优先排序。
定义基于风险的测试流程。
高度关键和中等风险将被纳入缓解规划、实施和进度监控,而低风险则列入观察清单。
通过风险数据质量评估来评估数据质量。
根据等级规划测试。
采用适当的方法和测试设计技术来设计测试用例,以便首先测试最高风险的项目。可以使用具有专家领域知识的资源来测试此类项目。
可以采用不同的测试设计技术,例如对于高风险测试项目使用决策表技术,而对于低风险项目使用等价划分。
测试用例还涵盖多个功能和端到端业务场景。
开发测试数据、条件和测试平台。
审查测试计划、测试策略、测试报告以及测试人员创建的其他文档。这对于识别和减少缺陷至关重要。
进行试运行并检查结果质量。
确保风险、涵盖它们的测试、其结果以及在测试中发现的缺陷之间的可追溯性。
在系统级别,重点关注软件中最重要的内容。这可以通过查看功能的可见性、使用频率和估计的故障成本来实现。
评估退出标准。到目前为止,所有高风险区域都已测试完毕,只有少量风险未得到处理。
报告基于风险的测试结果。
根据关键风险指标 (Key Risk Indicators) 重新评估之前的和新的风险事件。
更新风险登记册。
分析和防止缺陷以消除它们。
执行回归测试,以根据估计的风险分析验证修复程序。必须全面覆盖高风险区域。
如果可行,执行基于风险的自动化测试。
计算残余风险。
对不同风险级别使用退出或完成标准。
评估风险分析和客户反馈。
基于风险的测试方法
技术系统测试——也称为环境测试和集成测试,包括在开发、测试和生产环境中进行测试。
功能系统测试——这测试所有功能、特性、程序和模块。其目标是评估系统是否满足指定的要件。
非功能系统测试——这测试非功能方面、性能、负载测试、压力测试、配置、安全、备份和恢复程序以及文档。
优先级和风险评估矩阵
风险评估矩阵,也称为概率影响矩阵,使测试人员能够快速了解风险以及解决风险的优先级。
概率是衡量意外事件发生可能性的指标。时间、接近程度和重复次数的暴露程度以百分比表示。
它们是:
频繁 (A)——预期在大多数情况下会发生多次。(91-100%)
可能 (B)——很可能在大多数情况下发生多次 (61-90%)
偶尔 (C)——有时可能会发生 (41-60%)
罕见 (D)——不太可能发生/有时可能会发生 (11-40%)
不可能 (E)——在罕见情况下可能会发生 (0-10%)
已消除 (F)——不可能 (0%)
严重性是衡量意外事件造成的损失程度的指标。其评分为1-4级,具体分类如下:
灾难性 = 1 − 严重影响,导致生产力降至零。也可能导致项目终止。在风险管理中具有最高优先级。
严重 = 2 − 重大影响,可能造成巨大损失,严重威胁项目。
轻微 = 3 − 短期影响,但可逆。
可忽略 = 4 − 损失很小,可以通过常规程序进行管理。
优先级分为4个类别:严重、高、中、低。
严重 − 必须终止项目,并立即采取有效措施隔离风险。除非风险降低到低或中等水平,否则项目不予恢复。
高 − 立即采取措施隔离、消除和替代风险,采取有效的风险控制措施。如果不能立即解决,则定义严格的时间表来解决。
中 − 采取合理可行的措施将风险降至最低。
低 − 通常不会构成任何威胁,可以忽略。但是,应定期审查以确保控制措施有效。
结果报告和指标
测试报告准备 − 测试状态报告包括有效地与利益相关者沟通结果。它提供了对测试结果和目标的清晰理解和比较。
计划和执行的测试用例数量。
通过和失败的测试用例数量。
已识别缺陷的数量、严重性和状态。
现有严重缺陷的数量。
环境故障。
指标准备 − 指标是多个度量的组合,用于比较软件流程、项目和产品。
进度和工作量变化。
测试用例编制效率。
测试设计覆盖率。
风险识别效率
风险缓解效率
测试有效性。
测试执行覆盖率。
测试执行效率。
缺陷遗漏。
缺陷识别效率。
需求稳定性指数。
质量成本
根据缺陷状态以及测试通过和失败状态的数量,分析功能和非功能方面所涉及的风险及其与风险的关系。
确定关键的领先指标和滞后指标,制定预警指标。
通过分析数据模式、趋势和依赖关系来跟踪和报告领先指标和滞后指标。
基于风险的测试的优势
基于风险的测试测试软件的所有重要功能。它提供了对项目中涉及风险的实时清晰理解。
强烈强调业务项目的风险,而不是信息系统的功能。
测试可以用所有利益相关者都能理解的语言进行。
它专注于最佳测试交付、生产力和成本降低。