我们开发想每次他们提完代码都自动跑一次接口自动化。
被我拒绝了。
我拒绝的理由是：自动化虽然可以发现接口错误的情况，但当开发提交代码中接口变化是基于新需求时，
由于我们当时的自动化还没有根据接口变化更新，所以会误报。
把开发的新接口功能，当成 BUG 报了。
所以我建议自动化可以由测试不定期的跑，这样可能好点。
我个人认为比较合适的时间点是新版本第一轮测试后。
第一轮测试完，基本测试环境也稳定了，阻塞性 BUG 也基本没了，接口的变化测试也知道了，此时更新自动化用例。
随着开发修复 BUG，代码出现变化，可以跑一跑，验证稳定性。
大家是什么时候运行自己的接口自动化呢？
这是开发把自动化测试当成单元测试来用了，确实不合适；
自动化测试更适合每天跑一次，或者每次部署完跑一次。
代码改动会对旧逻辑产生影响，这难道不是有问题吗
其实呢，真自动化了，反正也无所谓，只要出了错开发自己看就行。不要让测试看。
Commit -> 单元 + 走查 -> 开发环境 cd -> 接口自动化
定期跑都不符合持续集成思想了，你还建议不定期跑这么离谱
万事俱备才开始自动化往往留下一堆技术栈，晚点再改==不改==屎山堆积
UI 还是接口？
领导：测试组每个月能产生 xxx 份回归报告，nice 啊！
应该提交代码之后就跑
我司每天跑一次， 然后版本发布前跑一次完事
我觉得提交代码就跑也没什么问题，可以检查到是否影响了以前的老接口，毕竟开发刚提交的时候 case 里面肯定也不会有最新提交部分的 case。
你的拒绝理由很有道理。自动化测试确实可以发现接口错误的情况，但是如果在接口发生变化后自动化测试用例没有及时更新，那么自动化测试就很可能会误报。这可能会浪费团队的时间和精力，导致团队不信任自动化测试。
我认同你的建议，不要在每次提交代码后都运行自动化测试，而是在适当的时间运行自动化测试。例如，在新版本第一轮测试后，测试环境稳定且测试用例已经基本覆盖了新的功能，这时候可以更新自动化测试用例并运行一次自动化测试。之后，每次开发修复 BUG、代码发生变化，可以在相应的时间点运行自动化测试验证稳定性。这些时间点可能包括：
版本发布前：在发布正式版本前，运行自动化测试以确保产品的质量。
合并请求前：在合并请求前，运行自动化测试以验证代码变更的稳定性。
每日构建：每日构建时，运行自动化测试以发现新增的问题。
特定事件后：例如发生故障或漏洞时，运行自动化测试以验证修复是否成功，并避免引入其他问题。
需要根据你们的具体情况，评估合适的时间点来运行自动化测试。这样能够提高自动化测试的有效性，减少测试和开发的工作负担，也能更好地支持团队的持续集成和交付。