根据Module的特性决定单元测试的覆盖率要求

业务应用的单元测试覆盖率可以低一些,框架和工具箱的覆盖率必须要很高

 

单元测试的覆盖率高当然很好,但高的覆盖率意味着要写很多测试;而写测试本身是件费脑费时的事情,代价不低。 所以要在收益和代价之间取得平衡。

 

可以着眼现在,放眼未来,具体考量四个因素:

    1. 对代码正确性的要求。 要求越高,覆盖率就应该越高。

    2. 能否人肉测试。 如果用人肉可以做测试,则自动化运行的单元测试代码可以少一些

    3. 代码逻辑的易变性。    代码逻辑越易变,写的测试被浪费的概率越大,对低覆盖率的容忍度越大

    4. 发现bug时的易改性。 出现bug的代码越容易改,对低质量的容忍度越大,对低覆盖率的容忍度也越大

   

 

以互联网为例,在业务应用层面,可以为了迅速推出新产品而容忍一定的bug,可以用鼠标进行人肉测试,产品易变代码逻辑也易变,发现bug时也容易改,所以这一块的测试覆盖率可以低一些

 

而框架、工具箱等Module的代码正确性必须非常高,否则会影响很多上层模块和系统;没有界面因此不能人肉测试; 代码逻辑不怎么变,单元测试被浪费的概率不高;一旦出现bug,受牵连的上层模块和系统可能会非常多,因此不能轻易让bug出现。 所以,框架、工具箱等Module的测试覆盖率必须非常高。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.