关于测试覆盖率牵扯出的一系列问题，你了解吗？

都是用来刷 KPI 与美化年报的东西。 单元测试的代码覆盖率至少还有工具能量化，但覆盖率低到底是测试代码写的不完善还是工程代码里那些额外的异常处理代码太多这又是另一个撕逼点了。

接口测试这种黑盒测试谈覆盖率就更加搞笑了。 你可以说有针对一个接口做过接口测试就算覆盖到了，也可以说接口的每一个参数每种可能性都要测到才算覆盖。 而那种动辄几十个参数的接口想完全覆盖是打算写几千万条用例跑上一整天才能测完么？

需求覆盖率？ 有哪个产品可以满足一切用户需求的？ 又有几个需求文档是精确定义每一个功能而不是摸棱两可的？搞笑！

单看这个没啥意义
比如你写了个方法算 sin 的值叫 f
测试的时候直接写
f(45 度)等于根号 2
就算覆盖了

@pckillers 接口测试现在可以做到和单元测试一样，按代码行 /分支来产生覆盖率报告

@billlee 用接口覆盖率搜了一下。 貌似只搜到个用于 java 的 jacoco 。 还要在运行程序前加载 jacoco 的代码。

后端不是 java 的话有办法搞么？比如 go 和 php 。

如果要了解概念，可以看一下 wiki： https://en.wikipedia.org/wiki/Code_coverage
针对你的问题：
1. 实际落地一般经常看的有行覆盖率，函数覆盖率（好统计，容易提升），分支覆盖率，例如以前百度 C++模块要求 80%行覆盖率，60%分支覆盖率（时间长了，记忆不一定准确）。有工具可以统计出来，基本思路就是对代码插桩。
2. 自动化跟代码覆盖率没有关系，无论手动测试、自动化测试，亦或者是单元测试、接口测试、集成测试都是可以获取覆盖率的。
3. 接口自动化覆盖率应该是自己定的一个概念，互联网服务以 http 形式的 API 居多，相对独立。如果这个接口有一条或者多条自动化测试用例覆盖，那就接口覆盖了。跟代码覆盖率不是一个概念。至于需求覆盖率，应该类似，很少听到这种提法。

补充一点：覆盖率不能表示测试覆盖的完备性，只是用来指导如何提高提高测试覆盖完备性的手段。

@pckillers 我不是很清楚要怎么弄，都是测试部门搞出来的