前面的文章中我们为大家介绍了我们测试团队在创建之初面临的一些困难和困惑，以及针对这些困难，我们探讨出来的质量体系覆盖图。本文我们继续来针对这种质量体系覆盖图进行展开，分享我们软件测试团队的管理体系设计思路。

我们都知道底层基础会决定上层建筑，地基打不稳，楼层就盖不高。底层也就是我们讲的过程管控，上图中的线上指的就是“上层建筑”，下面的部分指的就是过程管控。在过程管控部分，从需求、研发、测试、到发布环节都会有相应的度量指标。

需求环节的指标有：需求问题数、需求缺陷率和需求变更率，目前我们还在做的是需求变更率，也就是说在需求评审完最后，是不是有一些变更。

研发阶段目前我们关注比较多的是“提测成功率”，这个也是大家知道的。“代码问题数”目前还在调研，还没有放在这个度量体系中来。“缺陷按期修复率”目前我们的要求是，P0、P1的缺陷要求在4个小时内修复完，P2的缺陷要求在8个小时内修复完。“缺陷REOPEN率”我们期望是控制在5%，甚至是更低的范围内。

在测试阶段，我们会看缺陷有效率、测试遗漏率、人均缺陷数、代码覆盖率。

测试遗漏率指的是生产的故障和生产的缺陷除以整个过程到线上的缺陷数。这个是一个比较好的衡量我们测试的工作做得好不好的指标之一。

人均缺陷数我们会比较关注，将整个测试流程中测试工程师花费的时间和发现的缺陷数做一个对比和参考。

代码覆盖率是我们目前一直在做的，对 java 的代码覆盖率目前定的标准是60%的覆盖率。除此之外，重点产品会做一些区分。目前主要做的是java的代码覆盖率，未来我们也会扩展到 golang 和 jason 的代码覆盖率。

发布部分我们会追求交付成功率、发布失败率、紧急发布率、计划内不可用时长。

我们对交付成功率的期望肯定是希望每次发布都是一次成功，而不是发布很多次甚至是发布失败。另外还有紧急发布率，这个指标可以评估整个团队在前期的规划和上线之后，是否有很多 hotfix，可以做一些度量。

计划内不可用时长这个指的发布窗口对用户的影响时长是多长。我们不可能定发布的周期是从下午的6点到晚上的10点，这明显就是不合理的一个发布时长。

最下面还有一部分审计，我们也叫过程符合率，主要指的是在这四个阶段中，我们做的事情，哪些是按照公司定的标准在执行的。

以上是为大家解读的图中展示的“过程部分”，后面的文章会继续为大家介绍软件测试“线上部分”的内容，欢迎大家继续关注。