对梁兄的《如何引入代码覆盖率度量提高测试质量》几点看法

昨天无意中看到梁兄的《如何引入代码覆盖率度量提高测试质量》http://bbs.51testing.com/viewthread.php?tid=120122，简单牢骚几点看法。

×在好几年以前（大约是2000年前后），大学生找工作都不愿意去研究所（航天/航空/船舶等），因为待遇低，开发水平低，得不到提高。最近几年，形势发生了大的逆转，研究所成了香饽饽，一般人你还进不去，同样的原因，现在那里待遇高，实验环境好，开发水平高，尤其是在嵌入式软件这个领域。单就测试来讲，现在搞软件的研究所几乎都配备了测试中心，购买了N套测试工具。当然有测试工具并不代表测试水平高，但人家的意识起码已经走在前面了，尤其是航天。早在四年前，人家就有了自己强制遵守的编码规范，强调必须单元测试，并要求分支覆盖率——有的还有要求MCDC覆盖——必须达到100%，强调开发过程中的评审。正是有了这些严格的层层把关，我国的航天器卫星才达到这么高的成功率。

×上面的话纯属牢骚，现在转回正题。从梁兄的文章来看，基本可以得到这些信息：

• 覆盖率想让开发来做，保证在交付测试之前，开发先做基本的测试
• 覆盖率针对的是一个应用，不是一个单元或者模块（所以梁兄一再提到“无须修改代码，成本极低”）

  这里结合我所看到的和经历的，表达一下我的看法。代码覆盖率本身是开发做还是测试做，其实都可以，不过实践过程可能不同。

• 开发做，个人看法是针对单元，而不是应用。开发过程中，程序员的代码，尤其是核心代码，在baseline之前，自己先做单元测试，代码覆盖率是硬性标准。当然代码覆盖率用于单元时，就需要额外编写测试驱动或测试桩函数，可能会有一定的工作量。试想每个程序员都是只负责自己的一个单元，如果针对应用，谁愿意来承担这个任务？而且这原本就是基本的功能测试，属于测试的工作。
• 测试做，针对应用，在功能测试中。此时应用是完整的，只需要在编译时额外增加几个选项，“无需修改任何代码，成本极低”。此时，代码覆盖率可以认为是测试完整性的重要指标之一，注意不是唯一。很多单位把测试工作交给第三方测试中心，一般会要求代码覆盖率作为结束标准之一。

× “据ebay的朋友介绍。如果项目测试中实施，代码覆盖率可能一直在70%～80%左右，根据业界的一些数据显示，这个覆盖率已经非常不错了”

具体代码覆盖率到多少算不错，还是取决于上面提到的谁来做、覆盖率定义的问题。我们知道，覆盖率有很多种，最基础的是语句覆盖率和语句块覆盖率，其次是判断（分支）覆盖，航空用MCDC覆盖。

如果开发做用于单元测试，我个人看法分支覆盖达到100%才行，其实对于单元来讲，这并不困难；如果测试做用于系统的功能测试，正常情况下，有经验的测试工程师在执行完需求中定义的基本功能用例情况下，覆盖率应该可以达到70%左右，剩下的就要分析那30%如何才能达到，而这才是真正痛苦的过程。一个月可以达到70%，剩下的30%可能3个月都达不到。所以后者的覆盖率标准要根据不同单位不同项目的情况而异。

× 另要做覆盖率测试，工具是必需的。一个正确的工具几乎能决定这种测试能否坚持下去。当然正确的工具也是因编程语言因平台而异。

一家之言，不保证绝对正确。欢迎拍砖。