代码覆盖率达到100%是否就算覆盖全了？

lotus_flower

在软件测试中，有一个重要的概念叫做代码覆盖率，一般在单元测试中作为测试充分性的重要衡量指标，那么代码覆盖率达到100%是否就算覆盖全了？答案是否定的。

在Lee Copeland的《A Practitioner’s Guide to Software Test Design》第一章练习中给了这么一道题，简单翻译如下
哪四个输入能够发现下面程序的问题？你是怎么考虑选择到这四个的？对你的启发是什么？

int blech (int j) {
  j = j -1;  //正确的应该是 j = j + 1
  j = j / 30000;
  return j;
}

不妨考虑一下：）

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

同样的例子比如循环体，多线程，多进程等都需要具体分析程序的内部结构，才能设计出适宜的测试用例。

有句话叫“测试就是赌博”，测试是无穷尽的，那么怎么样让我们赌赢更有把握，其中重要的一个方法是研究、分析程序的内部结构，测试人员既需要从外部（客户）的角度了解软件，同时需要了解程序内部结构，即需要做到灰盒测试。

要使赌局的赢面更大,100%的代码覆盖率是远远不够的，况且实现100%代码覆盖并不容易，笔者经历过的项目单元测试基本没有完全达到过100%（除非凑数），更别说系统测试或者更高层级的测试了。事实上也没有必要完全达到100%的代码覆盖，因为有些代码区域的覆盖代价是在抬高，得不偿失。

而代码覆盖率重要意义在于：

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

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

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