在软件测试中,有一个重要的概念叫做代码覆盖率,一般在单元测试中作为测试充分性的重要衡量指标,那么代码覆盖率达到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%),代码质量不会高到哪里去,可以作为测试自我审视的重要工具之一。
网友评论