在软件测试中，有一个重要的概念叫做代码覆盖率，一般在单元测试中作为测试充分性的重要衡量指标，那么代码覆盖率达到100%是否就算覆盖全了？答案显然是否定的，有篇博文《代码覆盖率浅谈》已经说明的很详细了。

　　在Lee Copeland的《A Practitioner's Guide to Software Test Design》第一章练习中给了这么一道题，简单翻译如下：

　　哪四个输入能够发现下面程序的问题？你是怎么考虑选择到这四个的？对你的启发是什么？

　　读者不妨考虑一下：）

　　本身这个程序要做到100%代码覆盖率非常简单，但是要发现这个程序的问题却需要我们分析实际程序内部的结构，笔者在实际工作中就遇到做类似的问题（需要分析hash表内部的边界值来反推外部输入值才能测试出相应的问题），继而根据工程方法（边界值，等价类，正交等等）进行测试设计。

　　同样的例子比如循环体，多线程，多进程等都需要具体分析程序的内部结构，才能设计出适宜的测试用例，笔者在上篇文中《软件测试时为什么没有发现这些问题？》说过“测试就是赌博”，测试是无穷尽的，那么怎么样让我们赌赢更有把握，其中重要的一个方法是研究，分析程序的内部结构，测试人员既需要从外部（客户）的角度了解软件，同时需要了解程序内部结构，即需要做到灰盒测试。

　　要使赌赢的几率更大，100%的代码覆盖率的远远不够的，况且实现100%代码覆盖并不容易，笔者经历过的项目单元测试基本没有达到过100%（除非凑数），更别说系统测试或者更高层级的测试了。

　　笔者认为，代码覆盖率非常重要的意义在于：

　　1、分析未覆盖部分的代码，从而反推在前期黑盒测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？需求/设计不够清晰，测试设计的理解有误，工程方法应用后的造成的策略性放弃等等，之后进行补充测试用例设计。

　　2、检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。

　　3、代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去，可以作为测试自我审视的重要工具之一。