软件测试行业的二八法则——基于风险的测试

基于风险的测试活动，简称为：RBT（Risk-Based Testing），是指在测试工作开展之前，提前进行针对项目产品的风险分析，把风险分析活动应用到对应的测试领域，通过产品风险的分析与评估的结果决定测试策略，以此指导整体测试过程的一种方法。

       基于风险进行测试，首先需要明确什么是产品风险，产品风险是指产品失效的概率与预期损失的乘积。有一个合理的表达式为：产品风险 = 失效概率 × 损失。

其中，失效效率包括使用频率和缺陷概率两个指标参数。

使用频率：在一个每天被访问很多次的系统（组件）中，缺陷被激活的机率要比每天仅访问一次的系统（组件）中的缺陷大很多倍。

 缺陷概率：缺陷概率是指产品（组件）中包含缺陷的概率。但是，产品中存在缺陷，并不意味着在交付使用后缺陷一定会出现。如果缺陷位于一个从不使用的产品部件中时，产品将不会发生对应的失效。

含缺陷的产品组件的使用频率越高，则产品失效的机率就越大。导致缺陷较为集中的因素有很多，主要是功能的复杂性已经需求的不断变更，还与开发团队中的开发人员不熟练、编写习惯不良都有很多关系。

        风险分析通常发生在编写测试计划阶段之前，在产品模块划分完毕之后，开发和测试统一对于系统模块进行风险识别和对识别出来的风险进行分析，即采用系统的产品风险分析的方法在系统层面和特性层面进行产品风险的识别与评估。

而在这之后，测试方案的编写、测试方法的选择以及后期的策略调整都要根据风险的评估结果来进行，从而更加合理的覆盖测试深度，包括测试用例书写完成之后，在评审的过程之中，也需要参考评估结果，保障测试用例对于风险功能的最优覆盖，最终形成一套基于风险测试工作的闭环。

        在整个基于风险的测试工作过程中，风险的应用顺序需要参考可运行优先，风险优先执行的策略，保证每天的风险解决，这样第二天的风险就会比第一天少；

反之如果采用先易后难的策略的话，则是需要每天面对未知的错误情况，甚至于还有新的需求变更参与进来，这就造成测试过程中提心吊胆，并且跟着缺陷走，哪里有bug到哪里进行解决。显然，这样的方式是不可取的。

       基于风险的测试策略决定测试的资源投入程度和方向，目标是用最少的资源尽可能早的发现最重

更多的软件测试视频资料，都在柠檬班的软件测试技术交流群哦~

群643368558与群内软测dalao谈笑风生