关于软件测试覆盖率的思考

这个覆盖率其实也是有需求的，这个要看项目的特点，以及开发的特点，来指定多角度的覆盖率

1. 代码覆盖率（设计一个测试用例，能把代码的多少个路径和分支覆盖到，这个又分模块进行）

2. 需求覆盖率（需求又存在不明显的覆盖，所以一般要追求100%）,比如我们测试的需求分析文档中梳理的尽量的去覆盖，但是也未必能达到100%

3. 测试用例覆盖率（功能性测试覆盖率，这个也只能从需求出发，对功能和业务逻辑的覆盖，基本可以说是100%,但是设计的时候也是存在纰漏，未必能达到100%）

4. UI自动化测试覆盖率（覆盖率也不能一味的去追求，因为和时间成本，项目周期等关联着，但是用户对软件系统的使用也不是100%的都能使用到，那么就要去指定一个覆盖率的策略）

5. 接口的自动化测试覆盖率（这个相对还是比较容易，因为接口的数量尤其随着迭代的进行，还是能够100%覆盖，但是未必能达到100%的覆盖面，因为测试的设计数据未必能达到100%, 而只是在接口的数量上达到了100%）

所以覆盖率还是要又策略的，那就也是使用频率高，业务场景和业务逻辑上使用的，要做到90%的覆盖率，而且强覆盖率

我觉着UI自动化在30%是合理的，接口在60%是合理的数值

参考：https://blog.csdn.net/jfkidear/article/details/8074294

https://www.infoq.cn/article/test-coverage-ocd