有个问题比较困惑，请各位表达下自己的观点，跪谢~~
从去年我们项目就在做后端的接口代码覆盖率自动化测试，衡量指标就是代码代码行覆盖率和函数覆盖度，现在覆盖率也达到了 70% 多，
除了一些特别的接口之外，基本上逻辑上的接口能达到 95% 以上，但是发现接口的 bug 一个也没有，项目接口数大概 60 个接口，接口 case 差不多 250 条。
现在我就比较疑惑了，我做接口自动化的意义在哪？
覆盖率越高越好吗？越说明我写的接口代码逻辑越全吗？还是说服务端的质量很好？那服务端质量很好的话投入挺多回报是什么呢？
我觉得意义在于原有业务逻辑的快速回归吧，如果你们的接口业务不会经常变，那搞一套自动化当做监控脚本也挺好的，省时省力。覆盖率这个东西只能说明你的接口测试 case 覆盖了哪些代码逻辑，并不表明覆盖了的就是 ok 的，但是不懂技术的老板喜欢看你的产出，这个算是其中之一吧
感觉没 2000 字讲不清楚，不同测试部门的定位不同，需要自动化测试的原因不同，自动化测试能达到的水平不同，需要的自动化测试 case 也不同，你还是得想明白团队（测试 + 开发团队）的作用和期望，再来看自动化的价值；
从楼主的描述，我觉得提到了两个问题：
- 接口自动化的意义
- 代码覆盖率的意义
目前我们实践来看接口自动化测试的意义有下面几点，更多的还没能力去探索：
- 微服务升级、框架升级、各种升级和改版的时候做 diff 用，快速验证是否影响老的逻辑
- 业务造数，通过 API 组合来快速构造测试数据
- 提测准入验证，因为执行时间很短，可以结合 CI 做快速检查提测版本的功能
- 批量回归测试
- 辅助性能测试和开发自测
代码覆盖率的意义：
- 删除冗余代码
- 辅助测试人员衡量测试覆盖度，尤其是新增的行覆盖率、branch 覆盖率、method 覆盖率，可以非常有效的提升新增业务逻辑的覆盖场景
- 快节奏项目下，评估测试范围和影响的利器
- 海量用例下，评估需要使用的 case，而不是无脑的回归
- 针对新增 diff 数据未覆盖的代码进行用例补充
- 有效补充上面的 API 自动化 case
- 通过可视化、可度量的方式，促进测试进行自我检视，衡量研发自测效果和水平
- 更多智能化的应用就不赘述了，以免贻笑大方
发现接口的 bug 一个也没有?
1.接口测试测完能证明你跑的那些 case 是没问题的。当然前提是你自己的测试代码没 bug 哈
2.覆盖率 100% 也不能说明质量越高
return a/(b+c)
以上代码 a=1,b=1,c=1 就 100% 代码覆盖和函数覆盖了。但是 b+c=0 时呢？
3.覆盖率是在业务场景覆盖完之后，帮你做漏测分析的，不要把覆盖率单独拿出来说事儿，覆盖率越高也不一定代表质量越好。另外覆盖率用来做用例质量分析，用来做精准测试，他不香么。
- 接口测试和自动化测试是两件事；
- 接口是个手段. 至于到底怎么测，什么阶段用。是看能取出数/搞进去数就可以了，还是带着复杂的业务逻辑去弄, 只能凭实操者的 良心; 要是后者，不要拼什么框架了，用命令行 curl 就成。 千万别迷信 xxx 框架, 各种场景/业务都搞不清楚，再花哨也管不了什么用；但是我发现好多人确实是上网上多了，分不清楚现实和虚拟；
现在的问题就是太迷信测试会写代码
- 自动化一般是为了回归，不是为了开发阶段发现 bug( 所以我怀疑楼主为此质疑自己)；
1、你能获取到这些指标数据，比如 70% 的覆盖率，特别接口 95% 的覆盖。
2、没有产生一个 bug。
上面这俩都是价值了，你能作为参考，告诉你业务基本没问题。
这东西就跟空气一样，不产生问题的时候，什么都好。 哪天没了空气你试试，会举步维艰
请问下楼主，有没有人工发现了 bug 但是自动化没检测出来呢，如果没有可能真的没 bug？
督促开发删除冗余代码 + 精简代码 + 完善测试用例（尤其是条件覆盖之类的是否完全）是我们目前引入覆盖率测试看来下比较好的地方吧，当发现开发写了 “废话” 的时候，以覆盖率为由，让他改。当然了这种针对是否满足业务需求，没啥用。
恒温
回复
自动化比较难发现问题是对的，可是楼主做到了 95% 的覆盖率就不一样了，当然这数据水分有多少就不知道了，就算路径、场景覆盖很全，但是断言字段不全也是一个遗漏点。然后一些 bug 是因为各种数据产生的，按照常规的自动化数据也是发现不出 bug。
对于经常重构的开发团队来说，我觉得自动化回归的 case 真的很有用。。。