我们这种重构都是开发改完，主流程跑完，测试测完后接口 DIFF 和流量回放通了才行的，不然鬼知道有什么坑等着你呢

正常来说主流程冒烟不过就直接打回，结果来一个直接不冒烟了，那不绝了么

我的天，这是多想不开

是所有功能还是只是做简单的页面轮询

主动离职和被裁不一样吧，突然说要裁了，然后还要牛马一样的确保交接满意，这多少有点圣人的标准要求别人了

1，写 BUG 的时候会提页面链接正常，但是你会提某个元素 XPTH 路径么？
2，很多时候这种页面的 BUG 的元素里面的值我自己都不知道他应该是什么，比如一个酒店或者景点的封面图，他就是一个图的链接，我也是要调外部接口才知道值是什么，但是我人眼看得出来这个图不属于这个酒店或者景点 AI 怎么判断呢
3，大模型怎么理解你的操作步骤和预期结果，因为这里面有你具体的业务知识，给他配一个知识库么？

自动化很关键一个指标是可靠性，特别是巡检类的，经常有本应该成功的失败了，或者本应该失败的没卡住，那对业务来说这就是鸡肋，首先会让人觉得这个不可靠，一次两次会人工确认，次数多了谁还看呢

1.任何接口测试都依赖契约的，首先想做相关的肯定得有相应的契约文档或者契约平台这些，如果没有先搭基建或者自己整理文档，接口测试也是业务相关的，首先你得知道业务的入参组合，返回情况才可能写的出来 case 和断言
2.在 1 都清楚了后，你可以 POSTMAN 也可以其他的工具调也是测接口
3.在 2 的基础上再想用平台也行，用脚本也行啥都行让他自动跑，做巡检，做发布的线上流量 DIFF，做流量回放（依赖完善的日志体系）等等
4.在前面都通了在想着和 CI/CD 流程做集成

没有，我是想知道提效的占比确认主要做啥，当全是提效没得业务了就要凉了，提效很多时候是要自证价值，自证价值就很难受了

提效和实际业务测试的比例大概是多少