【原创】代码覆盖率达到100%是否就算覆盖全了？不是的话，它的意义何在？

      在软件测试中，有一个重要的概念叫做代码覆盖率，一般在单元测试中作为测试充分性的重要衡量指标，那么代码覆盖率达到100%是否就算覆盖全了案显然是否定的，博客园中有篇博文 《代码覆盖率浅谈》已经说明的很详细了。        在Lee Copeland的《A Practitioner’s Guide to Software Test Design》第一章练习中给了这么一道题，简单翻译如下：哪四个输入能够发现下面程序的问题是怎么考虑选择到这四个的你的启发是什么/strong>int blech (int j) {
      j = j -1;           //正确的应该是 j = j + 1
      j = j / 30000;
      return j;
}
读者不妨考虑一下：）
本身这个程序要做到100%代码覆盖率非常简单，但是要发现这个程序的问题却需要我们分析实际程序内部的结构，笔者在实际工作中就遇到做类似的问题（需要分析hash表内部的边界值来反推外部输入值才能测试出相应的问题），继而根据工程方法（边界值，等价类，正交等等）进行测试设计。       同样的例子比如循环体，多线程，多进程等都需要具体分析程序的内部结构，才能设计出适宜的测试用例，笔者在上篇博文中《为什么没有发现这些问题span style=”line-height:16px;font-size:12px;”>》说过“测试就是赌博”，测试是无穷尽的，那么怎么样让我们赌赢更有把握，其中重要的一个方法是研究，分析程序的内部结构，测试人员既需要从外部（客户）的角度了解软件，同时需要了解程序内部结构，即需要做到灰盒测试。       要使赌赢的几率更大,100%的 代码覆盖率的远远不够的，况且实现100%代码覆盖并不容易，笔者经历过的项目单元测试基本没有达到过100%（除非凑数），更别说系统测试或者更高层级的测试了。        笔者认为， 代码覆盖率非常重要的意义在于：

1. 分析未覆盖部分的代码，从而反推在前期黑盒测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到求/设计不够清晰，测试设计的理解有误，工程方法应用后的造成的策略性放弃等等，之后进行补充测试用例设计。
2. 检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。
3. 代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去，可以作为测试自我审视的重要工具之一。

转载于:https://www.cnblogs.com/meinvhao/archive/2013/04/15/3023076.html

相关资源：轮盘赌算法matlab程序及介绍-Matlab文档类资源-CSDN文库

来源：dengyang479359