所以要回归所有 P0 功能啊，不过全靠人力有点不现实，最好能用自动化解决。

当然，最主要的，还是要开发心里明白这个方法在哪些地方被用到，对哪些模块有影响，然后做针对性测试

1. 加强 code review
2. 对这种未通知测试的改动行为要定责任
3. 你说的两个问题，第一个是测试进入时间有问题，应该在代码合并之后测试。第二个就像层一说的，这种支付 p0 级用例需要回归，当然保险起见是上线前，有 p0 级别用例自动回归

说好的精准测试呢

把控代码合入，有改动，让开发给出改动点，测试建议，好重点回归测试

他这个没法精准，精准的前提是知道。。他现在是不知道。。

这个确实不好回归,主要其它业务线的功能 服务公用了 一个

我记得 2019 大会，陆金所那个 topic 专门讲过啊

跟我默读：测试不要信研发，要信就信自己。没有 CI 覆盖到的地方一定会有问题，区别就是什么时候，在哪里暴雷。你这个案例很经典，还跟 money 有关。请加入 CI 豪华套餐内。