这个Python代码大约花了我15分钟。然后，我利用它加载程序集，从根名空间开始遍历。结果是喜人的：几分钟后，所有的ORM代码被覆盖，一些具备无参数构造函数的类也被不同程度的覆盖。代码覆盖率在绝对值上有10%的增长（或者说，有大约10%的代码是无用的）！我倍受鼓舞，决定用两个步骤进一步完善这个程序。
1. 用Python内省（introspection）或.NET反射来获取函数的形参列表。根据形参列表，构造实参列表，并调用函数。这样就可以实例化大部分非抽象类，并调用其公有函数。
2. 利用演化测试（evolutionary testing）来自动提高代码覆盖率。在大学的时候，我研究过演化测试，并用C++实现了一个演化测试的原型，为论文提供实验数据。现在，演化测试已经渐渐从实验室走向工业应用。微软研究院的Pex利用符号执行、演化测试等技术，可以自动生成全语句覆盖的单元测试。
开发一个测试平台的想法确实很有吸引力，但是我不得不面对现实。15分钟提高10%确实很经济，投入几天的时间再提高10%值得么？捕获所有的异常，只管调用，不管结果，这是测试吗？获取代码覆盖率的目的是什么？设置代码覆盖率标准的目的又是什么？
正如测试是对代码的反馈，代码覆盖率就是对测试的反馈。获取代码覆盖率，不是要证明测试的充分性，而是要发现测试的遗漏，从而补充测试用例，以发现隐藏的缺陷。设置代码覆盖率标准，是提醒开发团队努力提高测试的覆盖率，以降低未发现缺陷的数目。所以，代码覆盖率是一种寻找缺陷的技术。它是提高测试的手段，不是测试的目的。只收集代码覆盖率，却不利用它去发现更多的缺陷，是误入歧途。
在我的工作中，我总是发现我或他人错误地理解了代码覆盖率的目标，并采取了高投入、“零产出”的方法来提高代码覆盖率。这篇博文就反映了技术人员的思维模式：将所有问题都转化为技术问题，然后提供技术性的解决方案，却忘却了最初的目的。
当然，我不是在暗示Pex是无用的。你研究一下，就会发现Pex将技术放在一个合理的位置。它通过与程序员合作来提供高质量的解决方案：程序员提供业务逻辑验证（以前后置条件的形式），Pex利用智能算法和日趋强大的CPU来提供精悍的测试输入。所以，紧盯目标，充分发挥各种资源的优势，才能事半功倍。（以上言论仅代表作者的个人观点，不代表51Testing观点）
版权声明：本文出自liangshi的51Testing软件测试博客：http://www.51testing.com/?298785
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关阅读：
