接口自动化处于金字塔结构的中层，业界普遍认为它很有价值做，尤其当今金字塔结构慢慢趋向于棱形结构的。
接口自动化的价值体现在1、日常功能测试回归 (修改后，未变动的功能) 2、发布生产回归测试 (上线前回归验证) 3、常用测试数据创建 (为手工、自动化提供测试数据）
自动化接口有其的价值，但是也需要人力的投入，我们该怎么计算投入产出比，通过每个迭代发现的bug，千行代码的bug？还是其他？
这个问题我们朋友间也讨论过。大概分两种思路
- 第一种：就是写接口自动化发现了多少bug，发现的bug是什么等级；因为回归测试发现的bug数量是很少的，但是一旦发现就是大问题，所以可以通过bug的重要程序衡量；
- 第二种：代码覆盖率；设计了接口，覆盖了多少代码行，也可以作为一个产出比；
价值通常是3个方向评估的，质量、效率、成本。
如果没有接口测试，人工测试无法支持频繁交付，从单次交付的过程中比手工测试提效了多少去对比。如果公司交付较多，收益越明显，如果公司一个月交付一次，那么收益就越小。这是最大的收益来源。测试的时间缩短、发现bug的时间缩短，支持更多交付等。
接口测试因为完成了自动化，那么在质量上就会有了比较稳定的覆盖，就可以逐步的提高覆盖度，手工测试的执行无法累积。无法获得累计收益。
但是在代码覆盖度什么的，不具备可比性，就算是手工测试，也可以做到较高的覆盖率提升，所以这个不是优势。真正的收益是自动化具备的累计优势，从而为公司构建了一个稳定的质量保护体系。这就是质量上的提升。如果接口测试能够与精准化测试结合，那么这块的收益会更清晰。
结构良好的自动化测试可以更容易的设计用例、分析用例执行，对测试的把控会更强。比如自动化测试可以自动diff新老版本的change，这些都是手工测试难以设计和执行的。
在成本上，其实自动化和人工的投入成本是一致的，所以成本上可比较的并不大。但是收益方面，自动化更大，这就是ROI。收益是来自于质量与效率的提升。
1 个赞
老师您好，针对收益，测试时间的缩短，发现bug的时间缩短在实际的项目中应该如何合理的度量呢？接口自动化并不带页面，对于手工测试来说依然会进行功能测试，那么提效的时间通过哪些维度来度量呢 发现bug的时间缩短，怎么度量？如何通过数据来反应出具体的指标