自动化测试主要是为了节省将来回归测试的时间。
例如下次更新版本，要对所有接口功能回归一遍，如果仍然按人手去测试，需要 4 天/人； 如果跑自动化测试脚本，可能半小时就完成了。

自动化测试，执行的次数越高，越体现出它的价值。

初期接口自动化的落点在核心流程 + 一些老功能的回归，这样测试重点扑在新功能的测试上。省去一些重复执行的时间。

沙漠中间栽下一棵树，枯死只是迟早之事；即便有足够的资源让它能够永久地生存下去，而它除了给路过的摄影师的构图上增添一分绿色气息，便再也没有其它存在的意义了。如果要想它能够长久而有生命力地活下去，并期望它能够改善生态，那就需要将其根植在一片密林之中。自动化测试，尤其是前端自动化测试，如若离开其他层次的自动化测试和技术手段与之相互配合，便会如同这棵沙漠中间的树一样，不久便灭。

这老大我喜欢

自动化测试并不会比手动测试耗时少，自动化测试 + 手动测试，提升覆盖率

我这主要目的不是提高啥效率。提高效率这套磕太虚，太依赖项目的整体素质（产品需求变动，开发技术实现好坏，项目进度等等因素）这些因素太多，能不能提高效率不好说。

实际最主要的能效和见得到的好处是，减轻每次发版前对以往重要功能的回归的覆盖率低和不能全部回归的风险问题。

自动化业务回归的话，是依赖业务流程自动化覆盖的好坏，有的业务流程便于实现自动化，有的技术上不好自动化。这都是实现自动化要解决的问题，所以自动化究竟能不能提高效率 是个可变命题，并不一定。

自动化随机遍历的话，也要解决一些问题的。

无论是自动化业务流程还是随机 都是有坑要填的。。。。要一定技术门槛的。

水得很好，破我第一帖

十年树木，百年树人

接口自动化是可以提升质量的，短时间看是浪费效率，改动频繁的话一样很吃人力。稳定后才可能提升效率。

以我的经验来看，接口自动化测试的优势在于回归测试。
比如测试一个接口，手工点点点和编写脚本都需要花费一天时间，测试出来了 N 个 bug，第二天进行回归测试的时候，手工还需要一天时间，可是自动化测试可能只需要花费 10 分钟时间。这就是提高的效率了。