基于风险的测试，风险管理及其方法的终极指南与示例：

什么是基于风险的测试？

基于风险的测试(即Risk Based Testing，简称RBT)是进行测试或设计和执行方案，以便在生命周期的早期阶段在产品或功能中挖掘出主要的业务风险，这些风险对用户层面的业务会产生负面影响，并且通过实施缓解措施来缓解。

负面影响包括成本影响，客户不满意，糟糕的用户体验，甚至是失去客户。

换句话说，RBT方法是确保测试可以以这样的方式完成：即使用户使用中发现问题，也不会让他/她不再使用软件，或对业务不会产生严重的影响。

RBT是根据产品风险进行的测试。 RBT是提前发现这些：特定功能使用失败的风险是什么、通过对测试用例使用优先级排序，在成本和其他损害方面的业务影响是什么。

因此，基于风险的测试使用的原则是：优先考虑产品或软件的特征，模块和产品的功能。优先级是基于生产中该特征或功能失效的可能性及其对客户的影响。

基于风险的测试及其与敏捷和DevOps的相关性

在开发软件上可能需要花费300个小时，在生产环境中发现一个缺陷，可能只需30秒。

反过来，这可能会毁掉整个产品，只能将其从市场中撤出。这就是“质量测试”的重要性和必要性。

如今，“质量”正在成为软件交付的关键因素，在这种情况下，只能不断改进以提高质量，以保持客户满意。

我们经常注意到，这是一个常见的问题：几乎所有测试人员都承受着巨大的压力，他们的测试窗口受到挤压，并且通常在最后一分钟将构建交给他们进行测试。没有足够的时间和资源来运行的所有测试，并且自动化覆盖率并不总是100％并且它有自己的挑战。

The delivery timeline cannot be missed and at the same time quality cannot be compromised as well. Whatever the plan B, to add additional test resources by pulling out from the other teams, is not working out, Plan C, stop doing all the other activities and divert the effort to this alone, is not really helping. However much addition of test resources, at the end, is not working out.

交付时间表不容错过，同时质量也不容妥协。无论计划B是什么，通过从其他团队撤出来增加额外的测试资源，还没有发挥作用，C计划，停止做所有其他活动并将努力转移到这一点，并没有真正帮助。然而，最终，测试资源的大量增加并没有发挥作用。

There is no other option but just to run limited and important tests within the available time and resources.

没有其他选择，只是在可用的时间和资源内运行有限和重要的测试。

So, how do we decide which test is important at this stage? Whatever a Tester considers important may not be really important for the customers. From whose perspective is the importance of the feature or a functionality decided? Who will decide which are the important tests? And a lot of other questions keep arising.

那么，我们如何决定在这个阶段哪个测试很重要？无论测试人员认为什么重要，对客户来说可能并不重要。从这个角度来看，功能或功能的重要性决定了什么？谁来决定哪些是重要的测试？还有很多其他问题在不断涌现。

In order to answer all these questions and to handle the above situation effectively, a testing approach called ‘Risk Based Testing’, shortly called ‘RBT’, came into existence, where the team has clearly planned and identified the test scenarios based on the ‘Project Risk’ criteria.

为了回答所有这些问题并有效地处理上述情况，一种被称为“基于风险的测试”的测试方法（简称为“RBT”）应运而生，这样团队可以根据“项目风险来清楚地计划和识别测试场景。

Though the QA team has a clear picture of the important tests, RBT is a proven method of identifying the crucial and important tests from the customer and business perspective through a ‘Risk Analysis’procedure.

尽管质量保证团队对重要测试有了清晰的了解，但RBT是一种经过验证的方法，其可以通过“风险分析”程序从客户和业务角度确定关键和重要的测试。

So, now as against the traditional way of simply identifying the defects in the software, the QA approach and goal has changed with the time due to the change in the technology, increase in the competition in the market to release a quality software, introduction of ‘Automate everything’, and in totality introduction of Agile and DevOps practice of delivering the software over a period of few hours.

因此，现在与简单识别软件缺陷的传统方式相比，由于技术的变化，市场竞争的增加，以发布优质软件，引入 “自动化一切”，并全面介绍Agile和DevOps在几个小时内交付软件的做法，质量保证方法和目标随着时间的推移已经发生了变化。

Hence, the current trend of ‘Testing Principle’ is not just merely ‘identifying the defects’ but to also,

因此，“测试原理”的当前趋势不仅仅是“识别缺陷”，也包括：

#1) Focus on the area of the product where there is a high impact on business due to failure or high likelihood of failure in the production.

#2) Focusing on identifying the defects early and allowing a team to fix it as early as possible and hence allowing the software/product or feature to ‘Fail Fast’.

#3) The most important aspect of Service of the QA team now is to focus on the customer in bringing value to the customer by increasing the focus on ‘end to end customer experience’.

＃1）关注由于生产失败或失败的可能性而对业务产生重大影响的产品领域。

＃2）专注于尽早识别缺陷并允许团队尽早修复，从而允许软件/产品或功能“快速失败”。

＃3）现在QA团队服务的最重要方面是关注用户，即通过增加对“端到端客户体验”的关注来为客户带来价值。

基于风险的测试方法

It is always like preparing for an examination, that one cannot say testing is enough and there are no more defects in the software, even if they design and execute an ample number of tests.

它总是像准备考试一样，即使他们设计并执行了大量的测试，也不能说测试已经足够并且软件中不再有缺陷了。

There is a point at which software stability is not going to be doubly assured by increasing the number of test cases alone. At this point of time, it is not just to focus upon the number of tests but on what actually the customer is expecting from the release.

通过单单增加测试用例的数量，并不能确保可以提高软件的稳定性。在这个时间点，不仅要关注测试的数量，还要关注客户期望从中获得什么。

Hence, it is essential to strike a balance in optimizing the testing in order to get the maximum benefit with the reasonable effort of testing. And this is more important when the testing timelines are very tight and enough resources are not available to carry out sufficient testing.

因此，必须在优化测试方面取得平衡，以便通过合理的测试来获得最大的收益。当测试时间表非常紧张并且没有足够的资源来进行充分的测试时，这一点就更为重要。

Thus, in this case, RBT approach plays a key role in optimizing the QA effort and maximizing the testing benefit with the minimum business risk.

因此，在这种情况下，RBT方法在优化QA工作和以最小的业务风险，最大化测试效益方面起着关键作用。

So, if we focus on the above aspect, then the work of a QA will be much relieved. They do not have to burn their weekends in the office, continuously testing the software and getting worried about every S4 (Severity 4) and P4 (Priority 4) defects that come out of the testing.

因此，如果我们专注于上述方面，那么质量保证的工作将会大大减轻。他们不必在办公室里烧周末，不断测试软件并担心测试中出现的每个S4（严重性4）和P4（优先级4）缺陷。

Well, 4 is considered as lowest priority and severity of the defects in testing. They can better invest their time in other useful aspects of the project.

嗯，4被认为测试中的缺陷具有最低优先级和严重性。他们可以更好地将时间投入到项目的其他有用方面。

To summarize the key drivers of the ‘Risk-based testing’ approach:

#1) To enable testing ‘what customers want’ from a business perspective.

#2) To meet the time schedule with expected quality.

#3) To optimize the QA effort.

总结一下“基于风险的测试”方法的关键驱动因素：

＃1）从业务角度测试“客户想要什么”。
＃2）满足符合预期质量的时间表。
＃3）优化QA工作。

基于风险的测试终极指南：软件测试中的风险管理(一)相关推荐

软件测试进阶(一)A/B测试终极指南
A/B测试终极指南 A/B测试不是一个时髦名词.现在很多有经验的营销和设计工作者用它来获得访客行为信息,来提高转换率.然而,A/B测试与SEO不同的是,人们都不太知道如何进行网站分析和可用性分析.他们 ...
基于风险的测试学习总结
基于风险的测试学习总结一.RBT的概念二.什么是风险,为什么需要RBT 2.1什么是风险 2.2为什么需要RBT 三.如何进行RBT 3.1风险识别 3.1.1风险识别的手段 3.1.2风险识别中 ...
测试管理 | 基于风险的测试
基于风险的测试风险是指负面或不希望发生的后果或事件发生的可能性.当引起客户.用户.参与者或干系人对产品质量或项目成功的信心减弱的问题可能发生时,风险就存在.当潜在问题主要影响的是产品质量时,它们被称 ...
[产品相关] A/B测试终极指南（翻译）
转载地址: http://blog.sina.com.cn/s/blog_9149268d0100zrx7.html 还记得以前导师说看了英文的文章就把它翻译一下吧,这样会对文章更好地理解,也会有更深 ...
软件测试中的风险管理
项目风险管理是PMP中的一个主要章节,小编在这里主要针对风险管理在软件测试中的应用场景进行描述说明,让测试同学能够更全面的把控项目风险,确保项目按期完成交付. 什么是风险管理软件测试是保证软件质量的 ...
条形码录入测试软件,ERP软件测试中条形码测试
五.条形码测试数据设计条形码应用相对复杂的是终端扫描后维护终端程序中的单据,然后传递到后台ERP系统中,在此过程中较容易出现错误.企业的库存管理在实际应用时录入的商品往往是不固定的,有时依据入库和出 ...
iOS订阅测试终极指南The Ultimate Guide to iOS Subscription Testing
订阅测试如何测试呢?平时遇到的都是消耗型商品,没有持续性,买完就完了,而订阅型是一个持续时间段,这个时间内有很多故事发生,测试起来相对也是复杂的多.找到一篇文章,参考下: 找到并修复错误,这样你就不会 ...
软件测试中PR测试是什么意思？
在软件测试中,我们会遇到PR测试,那么软件测试中的PR测试是什么意思呢?有的人说是性能测试,是正确的答案吗?下面晟仔就给大家介绍下PR测试的意思以及做法. PR的性能测试是通过自动化的测试工具模拟多种 ...
什么是软件测试中的黑天鹅
1,黑天鹅以及软件测试中的黑天鹅在发现澳大利亚的黑天鹅之前,欧洲人认为天鹅都是白色的.所以说"黑天鹅"代表了一个小概率事件,它罕有发生,但一旦出现,就具有很大的影响力." ...

基于风险的测试终极指南：软件测试中的风险管理(一)

什么是基于风险的测试？

基于风险的测试及其与敏捷和DevOps的相关性

基于风险的测试方法

基于风险的测试终极指南：软件测试中的风险管理(一)相关推荐

最新文章

热门文章