美文网首页项目管理软件测试软件测试相关
代码覆盖率达到100%是否就算覆盖全了?

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

作者: 豪哥的世界 | 来源:发表于2016-10-13 10:01 被阅读216次
    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%),代码质量不会高到哪里去,可以作为测试自我审视的重要工具之一。

    相关文章

      网友评论

        本文标题:代码覆盖率达到100%是否就算覆盖全了?

        本文链接:https://www.haomeiwen.com/subject/borwyttx.html