说节省时间得先说节省的是什么时间，我先说我接口自动化的现状：
1.日常运行，确认服务的稳定性，来保障我们功能测试的流畅。
2.验证接口逻辑是否正确。
至于能否当回归测试用，我觉得效果有限，即使执行全部通过，也只说明接口没问题。
就拿我最近手工测试遇到的一个 bug 来说。接口没问题，前端把参数搞错了，所以点击按钮出现报错。这种问题用户在使用的时候是一定会出现的。可接口自动化却无法验证出来。
之前我总想的是接口自动化，可以为我们节省回归测试的时间。
可即使执行了，我们也仍然需要手工跑一遍 case，因为前端的页面功能还没有保证。
基于这点原因我觉得接口自动化有效，但是没有我想象中的（代替回归测试）那么有效。
我现在接口自动化的日常就是没事跑跑，看看开发改代码把接口影响了，或者验证服务的稳定性。
保证手工测试的流畅，和每天代码更新后测试的覆盖度。
大概就这样了，可以说有效果的，就是无法完全替代人工回归。
大家对接口自动化提升的效率有什么看法呢？
想要完整跑回归测试的话，还是要看 UI 自动化，但是 UI 又不像接口一样稳定不会经常变动，自己也得根据项目取舍
这其实是测试有效性的问题：怎么进行完整的测试。像你说的一样，用户是在前端操作的，所以你完整的端到端测试应该是前端发起；如果你看一下测试金字塔，接口测试其实是归属于分层测试的其中一个环节，也就是说只能保证你接口这一层没问题，不能保证端到端。
要解决你的疑问，应该要在接口自动化之余，加上适当的 UI 自动化，由接口去保障大部分的调用场景，由 UI 去保障端到端。
要想彻底节省工作量，还得 UI 自动化；接口自动化是可以帮你做更大范围的覆盖，保障一下单纯从界面上发现不了的问题，或者更快更直接定位到接口的错误。
接口是帮你快速发现业务底层的问题，而 UI 测试（包括自动化和手工）这是必须有的。
一般可以将全量接口导入到接口自动化测试工具中，然后定时测试，每日回归。
怎么说呢，如果是单接口的话，能节省非常多的时间， 我目前做的成果是根据自定义测试策略，比如（边界值=0）自动生成测试用例，现在平均 1 个接口的测试用例量级在 12 条。发现的 bug 也非常客观。
接口自动化测试的意义在于以下几点：
- 实现分层测试：这个才是核心重点，测试是需要分层的，而不是一股脑的丢给 UI 或者 E2E 测试，这样会给问题定位带来更大的麻烦，而且修复成本也高。就如文中的例子，你可以很直观的判断出来是 UI 调用错误，而不是接口本身的问题，如果没有接口测试，你需要做更多的排查。
2、提高测试覆盖：有些场景并不是简单的通过页面操作就可以覆盖到的，比如异步类请求，比如第三方的依赖，比如多层接口的套用调用
- 适应持续集成和交付：可以有流水线有效的结合在一起，做为基本的质量门禁
至于节省的成本，这个要从更大的时间维度来看，如果只是某个迭代，那接口测试一定是降效的，因为它意味着更多 的时间投入和维护成本，但是从半年或者 1 年的时间来看，它是能够提效的，提效的程度取决于你执行的次数。
感觉楼主说的挺对的，但是现实中领导或者面试官都不想要听到这个答案，所以....也就不知道有没有必要做这个玩意
一定程度上，自动化测试是耗时的，在脚本维护、脚本设计、脚本开发等角度看，自动化测试耗时而且费钱。从提升测试者对功能回归和特殊场景下频繁操作来看，确实是能很好的提升测试的效率
接口自动化核心目的不是在于省你集成回归测试的时间，而是做测试左右移节省服务端变更发布时的测试成本，以及做一部分线上巡检。
所以这里这里的【没有我想象中的（代替回归测试）那么有效】在出发点上就已经走偏了。前端和后端本身就是分离的，你这里应该解决的是前端自动化测试的问题，或者说集成测试（用户视角）的问题，常规方案就是 UI 自动化。
小叮当
回复
自动化测试能给测试行业带来新的职位，又能加薪，又能带动我们学习提高竞争力，不是很大的福利吗，至于有没有意义，领导怎们认为，这不是与我们无关吗，
从分层测试来看的话，接口测试是性价比最高的测试，也是我们最有可能做出成绩的点，对于测试来说是很好的一个切入点
1）市面上工具很多，也有很多成熟的方案，接入成本小
2）接口相对固定，维护成本低
3）可以拓展到压测和监控方案，可做的事情很多
接口测试虽然靠近测试金字塔底层，但实际上缺点也是无法弥补的，它的执行并不比手工测试结果可靠，优点仅仅是在执行时只用电不用人！有人觉得需要巡检，降低发布成本；我觉得我们更应该思考为什么要巡检，为什么发布成本会高，就如同我们该思考为什么要测试一样！