我说下我们公司的现状：
每次开发提交新版本，然后自动化脚本跑一遍，并分析错误，全员抄送自动化测试报告，也能发现一些 bug，但是比较少，感觉价值没充分体现。
不知道大家所在的自动化测试价值是如何体现的？
发现不了的 bug 也都是后端的么？
你这边说到 “自动化团队的价值”，其实也就是测试的价值
测试的价值可以体现在四个方面：
- 预防缺陷
- 发现缺陷
- 增强信心
- 提供信息
题目里说的情况，“发现 bug”，只是测试价值的其中一个方面，毕竟随着测试的进行、产品质量的提升，发现的 bug 越来越少其实是合理的
所以从这个角度来看，自动化测试的价值并不是只有发现 bug，如果自动化测试没有发现 bug，说明系统的表现和行为都是符合预期的（自动化脚本没有问题的情况下），这可以为系统增强信心。同时，通过使用自动化来替代手动测试，为持续测试提供了可能性，可以更频繁地触发测试，比如在每日部署和版本部署之后进行，可以比手动更快地发现可能引入的新 bug（或者更快地保证被测功能没有受影响），并且这个信息也可以提供给更多的人（主楼里提到的 “全员抄送”），让其他利益相关方都知道自动化测试的结果，也有助于提高团队的质量意识，这些其实都体现了自动化测试的价值。
梁建辉
回复
你说能发现一些 bug 但是比较少；所以是不是存在其他发现不了的 bug？然后这些自动化测试发现不了的 bug 是属于前端问题还是后端问题？
卢绍齐
回复
自动化测试主要是回归测试，所以没发现的 bug 主要分为 3 类
1：新业务的 bug，也就是没被自动化覆盖的业务的 bug， 这个不属于自动化测试的锅
2： 用例不全 ，目前自动化测试主要是对测试用例的脚本翻译成自动化，所以这个是测试用例设计者的锅
3：脚本对用例覆盖不全，导致漏测，这实实在在是自动化测试的锅
梁建辉
回复
了解；当然，确实如果辛辛苦苦写了很多自动化脚本，结果新版本一上通过率极高，但是还是有很多 bug 没能发现，这确实会” 对人生产生怀疑 “；其实不能说自动化测试发现的 bug 少，它的价值就不高。因为随着迭代的进程，bug 必然会越来越少。新业务的 bug 没有被自动化测试体现出来，说明开发新业务的时候对原有系统的破坏性（改造）小，这也是好事。（不过我的项目组就没有这个烦恼，开发经常改着改着就破坏原业务了
）至于如何进一步提升所谓的价值，我确实没有相关经验。期待你的后续分享吧
自动化在我理解中，主要是不是用来发现 BUG。
那用来干嘛？有以下几点：
- 回归测试，上线后回归，需要耗费大量时间，并且是重复的。因此非常适合自动化
- 测试准入，自动化配合 CI，开发提交测试后，如果跑不过自动化，直接打回。
- 造数据，比如在电商场景中，需要创建一个待评价的订单，手动创建的话，需要很多步骤。但有了自动化，运行对应的用例即可。
首先，需要团队正确认识自动化团队的价值，包括自动化团队本身。
我刚接手测试团队的时候，情况跟你描述的一模一样，前面大佬们把理论讲的很多了，用来跟其他角色辩论够用了，我说一下改进的方向：
- 多次的，大量的跑。自动化脚本写出来之后，最大的优势就是可以大量的执行，执行的次数越多越划算。脚本就是一次投入，多次产出，用经济一点的话说叫分摊研发成本。方式呢就是与 CI 结合，提交代码就跑。做质量门禁，想转测就跑。做每日的质量监控，下班前跑，想下班就要保证环境没问题。 当然，要保证脚本能在多个环境，大量的跑有一定的稳定性，我们的的脚本也要有相应的优化。
- 提升自动化测试信心，自信的跟业务测试的小伙伴说：跑过了脚本，你只用测测新功能就好了。不管是接口还是 UI，可以试试把一个模块做精，或者开发几条长链条的端到端测试，经过不断的打磨验证，交付一个可以切实代替人工回归的模块并交付使用。当然，一切的立足之本还是脚本要足够的健壮。
毕竟我也是经过了这样的日子：辛辛苦苦跟大家解释自动化不是为了发现 BUG 而是为了回归测试防止引入，不是为了节省人力而是为了提升质量，到了年底又问我你们今年节省了多少人力投入。
想确认下，楼主是在独立的自动化团队（专门写自动化脚本），还是在业务团队兼顾写自动化脚本？
如果是后者，价值体现应该比较容易，节省自己的工作量就是价值了。
如果是前者，光靠自动化体现价值比较难。还是要基于自动化扩展下更多的事情。单纯自动化价值实在有限。
