📌  相关文章
📜  基于风险的测试和故障模式和影响分析

📅  最后修改于: 2022-05-13 01:57:00.431000             🧑  作者: Mango

基于风险的测试和故障模式和影响分析

风险是概率 负面或不受欢迎的结果或事件。风险是可能会降低客户、用户、利益相关者对质量和/或项目成功的感知的任何问题。

风险类型：
有两种类型的风险——产品风险和质量风险。

  1. 产品风险-
    当潜在问题的主要影响是对产品质量的影响时，则潜在问题称为产品风险。它也可以称为质量风险。示例- 可能导致系统崩溃或金钱损失的缺陷。
  2. 项目风险-
    当潜在问题的主要影响是 项目的整体成功，那些潜在的问题被称为项目风险。它们也可以称为规划风险。示例 - 可能会延迟项目完成的人员配备问题。

并非所有风险都同等重要。我们可以通过多种方式对风险等级进行分类。最简单的方法是看两个因素-

  1. 问题发生的可能性。可能性源于技术考虑。
  2. 影响 的问题，如果它发生。影响来自商业考虑。

什么是基于风险的测试？
在基于风险的测试中，我们使用在风险分析期间识别的风险项目，以及与每个风险项目相关的风险级别来指导测试。它是一种主要基于风险概率的软件测试技术。基于风险的测试包括以下步骤：

  1. 基于软件质量访问风险。
  2. 使用频率。
  3. 业务的关键性。
  4. 可能存在缺陷的区域等。

基于风险的测试 (RBT) 的特征：
以下是基于风险的测试（RBT）的一些特征-

  1. RBT 策略将测试工作的水平与风险水平相匹配。风险越高，测试工作量越大。这适用于测试执行以及其他测试活动，如测试设计和实施。
  2. 它使测试顺序与风险级别相匹配。较高风险的测试往往会发现更多缺陷或与应用程序中更重要的领域相关，或者两者兼而有之。因此风险更高，我们会在设计和执行周期的早期计划测试。这也有助于建立业务利益相关者的信心。
  3. 通过工作量分配和维护测试顺序，质量风险得到系统和可预测的降低。通过维护测试与风险和识别到风险的缺陷的可追溯性矩阵，将风险报告为剩余风险是有意义的。这允许相关的利益相关者决定何时停止测试，即何时继续测试的风险超过测试完成的风险。
  4. 如果进度缩减需要缩减范围，则更容易决定需要完成什么。由于商定了风险级别，因此对于业务利益相关者来说，它总是可以接受和解释的。
  5. 为了识别风险，我们需要从各种来源获取输入，例如需求规范、设计规范、现有应用程序数据、以前的事件记录等。但是，如果这些信息不容易获得，我们仍然可以通过从以下来源获取输入来使用这种方法风险识别和评估过程的利益相关者。

在这里，请注意，维持很少或没有文档的能力使得这种测试策略更加健壮（如果不是防故障），因为在一定程度上减少了对上游流程（如需求收集）的依赖。

何时实施基于风险的测试？
基于风险的测试方法在以下场景中实施：

  1. 存在时间/资源或预算限制。例如 - 要在生产中部署的修补程序。
  2. 实施概念验证时。
  3. 当团队不熟悉技术平台或正在测试的应用程序时。
  4. 在增量模型或迭代模型中进行测试时。
  5. 安全测试是在云计算环境中完成的。

如何实施基于风险的测试？
风险可以通过多种方式指导测试，但以下是主要的——

  1. 工作量由测试经理按比例分配 与测试项目相关的风险。
  2. 以匹配的方式选择测试技术 基于测试项目的风险级别所需的严格性和广泛性。
  3. 测试活动应反向进行 风险顺序，即应首先测试最高风险项目。
  4. 缺陷的优先级和解决方案应根据相关的风险级别进行适当的处理。
  5. 在测试计划和控制过程中，测试管理者应对所有重大风险项进行风险控制。相关风险水平越高，应越彻底地控制。
  6. 报告应根据剩余风险进行。 示例 - 哪些测试尚未运行？哪些缺陷尚未修复？

重要的是要注意风险管理不是在项目开始时发生的事情。应该是一个持续的 整个项目生命周期的活动。但是，风险的性质会根据我们所处的测试阶段而不断变化。
风险应定期进行 根据项目的新发展与风险等级一起进行评估。这可能会导致一些风险被低估甚至关闭。根据结果，测试工作分配和其他测试控制活动也将发生变化。
此外，应该努力通过运行测试、发现缺陷来降低质量风险，并通过缓解和应急措施来降低项目风险。

基于风险的测试 (RBT) 的好处：
通过识别和分析与系统相关的风险，可以使测试变得高效和有效-

  1. 高效的-
    RBT 是高效的，因为您可以在周期的早期测试系统的最关键区域（检测到缺陷越早，解决这些问题的成本就越低）
  2. 有效的-
    RBT 是有效的，因为您的时间是根据风险评级和缓解计划花费的。你不会把时间花在那些在整体计划中可能不是很重要的项目和活动上。
  3. 减少测试用例-
    随着测试用例变得更加集中，测试用例数量会减少。
  4. 降低成本-
    由于关键问题在周期的早期得到解决，因此降低了每质量成本，从而降低了变更成本。
  5. 更快的上市时间-
    使用 RBT 方法更容易实现更快的上市时间，因为最重要的功能在周期早期处于可发货位置。

失效模式和影响分析 (FMEA)：
FMEA 是一种系统技术，用于识别称为故障模式的质量风险项目，即识别被测系统可能在何处以及如何发生故障，然后评估不同故障的相对影响。
该过程涉及的步骤是：

  1. 故障模式-
    什么会失败？
  2. 失败原因——
    为什么会发生失败？
  3. 失效影响——
    每次失败的结果是什么？

FMEA 方法是迭代的，即需要反复进行剩余风险的重新评估。该技术最初旨在帮助防止设计和实施阶段的缺陷，因此预计将在周期的早期使用。
当涉及到故障模式分析对用户的影响时，需要细粒度，客户也需要被识别。由于需要这种深度的分析，FMEA 文档可能很复杂。
它主要用于安全关键、高风险和保守的项目。例如-工业控制软件，核控制软件等。
FMEA 对于在实施之前评估新流程以及评估提议的变更对现有流程的影响非常有用。

FMEA流程：
本节详细介绍 FMEA 过程。以下是步骤-

1. 回顾流程——使用流程流程图来识别每个流程组件并在 FMEA 表中列出每个流程组件。
2. 识别潜在的故障模式并绘制它们的潜在影响-

  1. 查看现有文档、设计和数据，以确定每个组件无法列出详尽列表的方式。
  2. 将每个故障映射到每个故障对最终产品或流程中后续步骤的影响。
  3. 为每个故障分配严重性。
Severity RankDescription
10Hazardous, without warning
9Hazardous, with warning
8Very High
7High
6Moderate
5Low
4Very Low
3Minor
2Very Minor
1None

3. 一旦确定了影响和严重性，还要分配发生率等级。

  1. 发生是与故障模式及其相关原因将出现在被分析项目中的可能性相关联的排名数字。出现排名具有相对意义而非绝对值，并且在确定时不考虑检测的严重性或可能性。
  2. 对于系统和设计 FMEA，发生率排名考虑了产品设计寿命期间发生的可能性。
Occurrence RankDescription
10>100 Per 1,000
950 Per 1,000
820 Per 1,000
710 Per 1,000
65 Per 1,000
52 Per 1,000
41 Per 1,000
30.5 Per 1,000
20.1 Per 1,000
1<0.01 Per 1,000

4.分配检测排名

  1. 检测排名根据定义的标准考虑检测到故障模式/原因的可能性。
  2. 检测是特定 FMEA 范围内的相对排名，其确定与发生的严重性或可能性无关。
Detection RankDescription
10Absolutely Impossible
9Very Remote
8Remote
7Very Low
6Low
5Moderate
4Moderately High
3High
2Almost Certain
1Certain

5. 计算风险优先级数。

  1. RPN 是通过将三个评分列相乘来计算的 -
    1. 严重性（点 2）。
    2. 发生（第 3 点）。
    3. 检测（第 4 点）。

6. 根据 RPN 制定行动计划。

  1. 根据风险优先级编号确定应优先处理哪些故障。最高的 RPN 获得最高优先级。
  2. 定义行动计划、负责人和预期完成日期。

7. 实施行动计划。

8. 重新评估并重复。

  1. 改进后重新评估每个潜在故障并确定改进的影响。
  2. 重复该过程以识别下一步操作。

FMEA 模板

FMEA 的好处：
以下是 FMEA 的好处-

  1. 它是精确的 和彻底 因此不太可能忽略风险。
  2. 它提供了一个整体 考虑潜在问题，因为我们需要对预期的系统故障进行详细分析
  3. 它提供了理由 因为没有进行某些测试，即失败概率最小的地方。

FMEA 的挑战：
以下是 FMEA 的挑战-

  1. 它需要大量文档，因此非常耗时。
  2. 当试图确定失败的原因时，从中间影响确定真正的原因可能具有挑战性。
  3. 许多组织未能认识到 FMEA 不是静态模型。为成功进行风险管理，应在识别新的潜在故障模式并制定相应的控制计划时定期更新 FMEA。