基于风险的测试 – 矩阵、方法、过程和示例
敏捷测试是全球使用最广泛的开发和测试方法之一。由于敏捷测试与速度有关，您可能已经了解它在这个不断发展的竞争市场中的必要性。但是，正确执行它需要大量时间。由于大多数敏捷冲刺可能会持续数周，因此我们没有足够的时间来完成每个程序功能。随着开发的每一步，测试过程变得更加复杂。因此，同时运行数千个测试是不可行的。因此，大多数测试人员相应地优先考虑他们的测试需求。
这就是基于风险的测试发挥作用的地方。
什么是基于风险的测试？
基于风险的测试 (RBT) 是指最早设计和执行测试场景。在此过程中，测试人员识别可能对业务产生负面影响的主要业务风险。换句话说，您必须更早地测试软件的所有有风险的功能，并采取必要的步骤来降低风险。
负面影响会以多种方式对业务产生影响，导致不必要的成本、糟糕的用户体验和客户的不满，甚至可能导致客户流失。
RBT 确保即使客户在软件中遇到问题，他们也希望继续使用它。因此，它不会影响企业的生产力。
基于风险的测试可以提前发现程序的功能故障。它涉及计算如果经过认证的应用程序功能失败，公司将承受多少成本和损失的步骤。然后对每个特征或功能进行排序和相应处理。
准备基于风险的测试
无论您对软件进行多少设计和执行测试，您都无法 100% 确定是否会时不时出现缺陷。仅仅增加测试数量不会增加软件的稳定性。因此，您需要关注客户对发布的实际期望。
关键是要保持平衡，为客户提供最大利益，同时使您的测试工作保持在合理范围内。在您的资源和时间有限来进行测试过程和发布软件的情况下，这同样重要。
RBT 方法有助于优化 QA 工作并最大限度地提高测试收益，同时将风险降至最低。因此，它为 QA 提供了更多的缓解，因为他们不必为修复 S4 和 P4 缺陷而熬夜熬夜（如下所述）；被认为是测试中最低的繁荣度和严重性。相反，他们可以将时间投入到项目的更好方面。
基于风险的测试的要点：
从企业的角度关注“客户想要什么”
在规定的时间内完成过程，同时保持质量
优化 QA 的工作
什么时候是使用基于风险的测试方法的合适时机？
当测试人员必须在特定的时间、成本和资源内完成项目时，他们会进行基于风险的测试。RBT 可以帮助优化和优先考虑资源，确保在设定的时间和成本内完成整个过程。
在处理复杂的项目，尤其是风险未知的研发项目时，也可以使用RBT来减轻负担，采用新技术。
基于风险的测试方法
IT 行业使用基于风险的分析来降低与生产及其影响相关的风险。它包括诸如识别关键要素和评估其风险，然后采取必要措施降低或减轻这些风险等程序。它涉及功能优先级排序和准备风险评估矩阵等测试。
优先级和风险评估矩阵
风险评估矩阵或概率影响矩阵可帮助项目团队查看相关风险并提供足够的信息来相应地确定它们的优先级。
风险等级=概率 X 严重程度
这里的概率 是指不确定事件在时间、重复和接近度方面的机会。它以百分比表示。
概率 (P) 分为 A、B、C、D、E 和 F。
频繁(A)：表示事件可能频繁出现。(>90%<=100%)
很可能(B)：这些事件很可能经常发生。(>60%<=90%)
偶尔(C)：有时可能会发生事件。(>40%<=60%)
远程 (D)：事件不太可能发生或可能很少发生。(>11%<=40%)
不太可能 (E)：事件可能在极少数情况下发生。(>=0%<=10%)
消除(F)：不可能发生。
这里的严重性是指不确定事件可能对业务造成的损害程度。分为 1 到 4 种。
灾难性 (1) - 这意味着极端恶劣的后果使项目无法生产，甚至可能导致完全停工。因此，它被视为风险管理的重中之重。
严重 (2) - 该项目是一种威胁，其后果可能导致巨大损失。
边际 (3) - 采取必要措施后，损害是短期且可逆的。
可忽略的 (4) - 不确定性可能不会造成损害。您可以轻松监控和管理它们。
优先级分为四类：严重、高、中、低。
严重- 必须停止所有活动以立即隔离风险。团队必须确定有效的控制措施并尽快实施。在风险降至低或中之前，不得继续采取任何行动。
高- 必须实施有效的风险控制来隔离、消除或替代风险。如果无法立即遏制威胁，那么团队必须设定严格的时间表来解决它们。
中- 团队必须采取合理和实际的步骤来最小化风险。
低- 此类风险通常不会造成任何重大问题。定期审查就足够了。
结论
基于风险的测试是将敏捷原则集成到软件测试中的最有效方法之一。这里的主要角色是 QA。他们必须准备一个可量化的参数，以确定必须首先测试哪些功能。考虑到业务的最大利益，他们必须构建测试层次结构。
以上是 基于风险的测试 – 矩阵、方法、过程和示例 的全部内容， 来源链接： utcz.com/z/338645.html
