6. 增加测试用例来记录对软件的理解。软件测试是一个学习的过程，随着测试的展开，对被测试软件的理解也会更加深入和全面。学习的来源很多，如客户的反馈、手工测试发现的错误、阅读代码发现的问题、团队成员提出的建议等。应该综合这些素材，增加更多的测试用例来增强“可执行规范”。基本测试用例是一个很好的起点，随后测试应该在广度和深度上继续发展。

　　7. 利用测试覆盖率来增强测试用例集。运行代码覆盖率分析工具，查看测试没有覆盖哪些语句块，然后补充测试用例，以求100%的语句块覆盖。有时候，我只是阅读代码，搜索显式抛出异常的语句，然后构造测试用例，以触发这些异常。这是因为，快乐路径是很容易被覆盖的（如果没有被覆盖，那么基本测试用例集需要增强），没有被覆盖的往往是异常路径。抛出异常的语句是异常路径的标识，覆盖它可以增加测试覆盖率，还可以检查异常的构造和传播是否正确。对于覆盖率，我还有三点补充。

　　① 100% 语句块覆盖需要被测试代码有较好的可测试性(testability)和可观的自动化测试投入。在许多情况下，是难以实现的。但这不应该是紧耦合、强依赖代码（可测试性的死敌）得以存在的理由。[Michael04]解释了为什么可测试性是如此的重要，以及如何通过艰苦的工作去获得美妙的软件。

　　② 分支覆盖是比语句块覆盖更好的覆盖率方法，它可以揭示出更多的可执行路径。但是，我从来没有利用分支覆盖来指导测试用例构造，因此不能提供任何意见。

　　③ 测试覆盖率只能避免最差情况，而不能说明测试的质量已经足够。在分析测试覆盖率的时候，测试者要带上“攻击者的帽子”，不停地考虑：代码有没有漏掉一些逻辑？——测试覆盖率显然不能发现那些不存在、却应该存在的代码。

　　8. 重构测试代码。随着测试用例越来越多，测试方法(test method)、测试夹具(test fixture)、断言(assertion)、测试辅助(test utility)也越来越多。如果不进行有效的管理，自动化测试会包含冗余的代码和脆弱的结构。这使得测试用例的修改、增加和运行的变得困难，也使得产品代码的小修改导致测试代码的大修改。因此需要对测试代码进行持续的重构。[Gerard07]提供了一批重构手法和模式，是很好的起点。

　　测试用例的设计是一个迭代的过程，需要在测试过程中不断地收集信息并调整策略。在许多情况下，本文介绍的测试用例开发方法和手工执行的探索式测试(Exploratory Testing)很像（探索式测试并不一定是手工测试）。其关键是用自动化测试用例来记录探索过程中的重要发现。

　　Reference

　　[Cem01] Cem Kaner, James Bach , Bret Pettichord, Lessons Learned in Software Testing, Wiley, 2001.

　　[Brian07] Brian Chess, Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.

　　[Gerard07] Gerard Meszaros, xUnit Test Patterns: Refactoring Test Code, Addison-Wesley, 2007.

　　[Michael07] Michael Feathers, Working Effectively with Legacy Code, Addison-Wesley, 2007.

（以上言论仅代表作者的个人观点，不代表51Testing观点）

版权声明：本文出自liangshi的51Testing软件测试博客：http://www.51testing.com/?298785

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。