测试杂感：分析代码覆盖率的时机

在我们的项目中，代码覆盖率是产品发布的标准。通常的要求是托管程序的语句块覆盖率达到80%，本地程序的语句块覆盖率达到70%。有一次，项目临近结束，测试组的同事Kyle正在为测试覆盖率“达标”而努力奋斗。那是一个比较大的本地程序，其中有一些代码，利用端到端的系统测试很难覆盖。于是，Kyle创造性地使用调试工具Windbg来提高覆盖率。他将Windbg附加（attach）到被测试程序上，然后利用调试器的指令跳转功能，手工改变程序的执行路径，以快速覆盖任何他希望覆盖的代码。不幸的是，有一块代码在入口处就崩溃（crash）了。虽然异常被Windbg捕获，但是程序无法继续执行。在试了几次之后，他把开发人员叫了过来，说：程序在这里崩溃了，如何绕过去继续执行？开发大骇：你难道不研究一下它为什么崩溃么？Kyle怒斥：别说这些没用的，干正事要紧！

这个故事是开发人员亲口说给我听的。写在这里不是指责Kyle对崩溃不闻不问，恰恰相反，我认为Kyle的举措具有相当的合理性。第一，利用Windbg修改执行流，已经扰乱了程序状态。即便程序崩溃，也很难认定这是一个缺陷（defect）。第二，崩溃发生在一段很难被执行到的代码中。即便是程序缺陷，也不会引入显著的风险。第三，项目临近结束，还有许多高优先级的测试工作。结束手上的工作，将精力集中在那些暴露高风险的“正事”上，才是正途。

这个故事的经验是，在项目即将结束时分析代码覆盖率不会收到好的效果。正如上一篇杂感所言，只有在充分理解代码与测试的前提下，代码覆盖率信息才能得到有效的利用。在项目结束前，测试者往往有许多Bug要做回归测试，要分析压力和性能测试的结果，要与其他团队配合进行跨系统的集成测试。在这种情况下，他们没有充足的时间来阅读并理解代码。此时的代码覆盖率统计只是一项必须完成的任务，难以给项目带来明显的收益。

那么何时才是分析代码覆盖率的最佳时机呢？我的建议是，从项目一开始就收集代码覆盖率，并一直持续到项目结束。如果说测试是对代码的反馈，那么代码覆盖率就是对测试的反馈。根据敏捷开发的思路，反馈自然是越早越好、越频繁越好。测试者应该从项目早期就开始理解代码，并逐步增加测试用例。这时，代码覆盖率是分析代码的有效工具。随着项目的展开，测试者需要知晓代码的变化和测试的不足，这时代码覆盖率能提供有帮助的信息。大爆炸的集成会带来错综复杂的困境，于是开发实践转向持续集成（continous integration）和一键发布（push button release）。大爆炸式的代码覆盖率统计会提供令人窒息（overwhelming）的海量信息，因此测试者也需要用持续的代码覆盖率分析来逐步建立对代码和测试的理解。

那么持续分析应该怎么做呢？基本策略有三。

1. 如果有每日构建（daily build），那么每日构建应该生成程序的发布版（release version）、调试版（debug version）和覆盖版（coverage version）。通常覆盖版都是对调试版进行代码插桩（code instrumentation）所得，行为与调试版一致。除了一些性能敏感的测试用例，其他测试用例都可以在覆盖版上执行，从而获得大部分测试用例的覆盖率。在我的部门，有一个项目组就是这么做的。他们的每日测试（daily test）会生成一份当天的代码覆盖率报告供测试者参考。

2. 定期生成被测试程序的覆盖版，分析代码覆盖率。现在代码覆盖率工具很多，测试者很容易独自收集代码覆盖率信息。例如，Visual Studio 2008提供了GUI和CUI来收集C#和VB.NET的代码覆盖率。工具的门槛很低，关键在于投入精力，坚持收集并分析。

3. 不借助代码覆盖率工具，通过阅读代码、在调试器中执行测试用例来分析代码覆盖率。这种方法的优点是启动成本低，可以随时执行；缺点是难以生成美观的代码覆盖率报告。从提高测试质量的角度，其效果与其他策略相当，甚至可能更好。因为代码覆盖率的关键不是工具，是对代码的理解。

在敏捷开发中，“测试-开发-重构”是一个小循环，在每天的开发中不停地迭代。代码覆盖率分析也应该加入到测试开发与执行的小循环中。持续分析代码覆盖率可以及时获得测试质量反馈，以尽早地暴露一些显著的风险。