我最近在整理质量标准，质量标准是个什么东西呢？

质量标准是产品生产、检验和评定质量的技术依据。产品质量特性一般以定量表示，例如强度、硬度、化学成分等；所谓标准，指的是衡量某一事物或某项工作应该达到的水平、尺度和必须遵守的规定。而规定产品质量特性应达到的技术要求，称为 “产品质量标准”。--（百度百科）

大白话就是，我们把在研发过程中所有和质量相关的可以度量的数据拿出来，整理一个基线，形成质量标准。我们拿这个标准来规范整个研发流程，包括开发活动和测试活动。我们试图推广质量标准的时候，遇到了一些阻力，其中有一项就是关于代码覆盖率（行覆盖率和变更覆盖率）的质疑。

这 70% 的覆盖率，这是你拍脑袋的吗？

有点尴尬，我回答不出，仔细捋了下，没有发现这个数据背后的逻辑支撑。问了团队的小伙伴也不知道出处。按常理，我们能得出一个标准的时候，必然是经过了各种实践和演进，覆盖率从 0 到 70 的过程中，一定是有什么变化，才会推动覆盖率的上升。那是怎样的变化呢？我试图找出这背后的逻辑支撑。

Google 经验

丽姐告诉我，可能来自谷歌，于是我网上搜了下，在谷歌里，有两篇文章关于谷歌的代码覆盖率，一篇是《Code coverage at Google》，这是篇论文。一篇是《Code Coverage Best Practices》，这是篇最佳实践，来自已经很久没有更新的 google test blog。

文章说通过谷歌数不清的经验得出来的数据：

行覆盖率：

1. 60% 为 “可接受”
2. 75% 为 “推荐”
3. 90% 为 “出色的”

变更覆盖率:

1. 90% 为底线
2. 99% 为合理

对于不同等级的系统：

1. Level 1 Coverage automation disabled —— 没有自动化覆盖率
2. Level 2 Coverage automation enabled —— 有自动化覆盖率
3. Level 3 Project coverage at least 60%; Changelist coverage at least 70% —— 覆盖率>=60%，变更覆盖率>=70%
4. Level 4 Project coverage at least 75%; Changelist coverage at least 80% —— 覆盖率>=75%，变更覆盖率>=80%
5. Level 5 Project coverage at least 90%; Changelist coverage at least 90% —— 覆盖率>=90%，变更覆盖率>=90%

我相信国内就有很多公司就直接搬了这套规则，毕竟谷歌的东西比较香。

阿里经验

我也想看看国内是否有类似的标准，在阿里的《Java 开发手册（嵩山版）》中找到了相关的信息

行覆盖率：

1. >=70%
2. 核心模块行覆盖率 100%
3. 核心模块分支覆盖率 100%

所以基本上，阿里内部的项目应该是把这个基线定在了 70%，但是为啥是 70%，依然没有找到答案。

讨论

我继续和研发讨论，我们首先达成共识：

1. 质量很重要
2. 覆盖率肯定要
3. 不能一味的追求覆盖率数字
4. 有效的单测覆盖率才对

再讨论的过程中，我们去看了一些覆盖率 90 或者 100 的案例，发现了一个比较有趣的特点，这些代码的覆盖率之所以高，往往是因为它没有异常分支和异常处理。它覆盖率的确高，的确漂亮，可惜它太脆弱了。

我看过很多代码，基本上一个函数中，有效代码或者主路径代码大概在 60%-80% 之间，其余的都是异常处理，这是比较常见或者合理的（或者可以用二八原则来解释，有点牵强，但是有点道理）。而对于开发而言，他的单测覆盖了这 60% 到 80% 的代码，也是比较合理的。至此，我对 70% 这个数字的感觉稍微笃定了些。

至于为什么不是 80 或者甚至更高？你来写单测的话，想 100 都可以。在效果和成本之间永远需要有折中。

问题

不知道，你们公司的覆盖率规则是怎样的？可以留言讨论下。