介绍一下背景，我们部门只编写了接口自动化未做 ui 自动化，冒烟测试时接口自动化覆盖的功能不会再去通过手工测试，发布前接口自动化已经全部通过，但是后面发现前端更改了请求，直接请求 404 了，想请教一下这种问题如何规避
- 接口测试只是分层测试的其中一环，整体的测试策略起码要在 UI 上多做一层 UI 自动化或者手工测试作为补充。
- 要从流程上去分析，为什么前端改了代码而没测试到的原因是什么。 如果这个改动完全没有遵守流程（不在需求里面，没有提测给测试），那就是开发流程的问题，要去补充强化流程； 如果是开发已经提测了，但是测试以为跑个接口测试就能覆盖，那就是测试策略的错误，需要去强化测试设计和加强测试用例评审流程； 如果开发也是无意中带出来的改动，或者因为代码部署错误，把没提测的东西带上去了，就需要去强化你们的回归测试策略，不管有没有前端的改动，该做的回归测试都要做，并且基于这个去设计你们的自动化测试（包括 UI 和接口）
- 接口测试只是分层测试的其中一环，整体的测试策略起码要在 UI 上多做一层 UI 自动化或者手工测试作为补充。
- 要从流程上去分析，为什么前端改了代码而没测试到的原因是什么。 如果这个改动完全没有遵守流程（不在需求里面，没有提测给测试），那就是开发流程的问题，要去补充强化流程； 如果是开发已经提测了，但是测试以为跑个接口测试就能覆盖，那就是测试策略的错误，需要去强化测试设计和加强测试用例评审流程； 如果开发也是无意中带出来的改动，或者因为代码部署错误，把没提测的东西带上去了，就需要去强化你们的回归测试策略，不管有没有前端的改动，该做的回归测试都要做，并且基于这个去设计你们的自动化测试（包括 UI 和接口）
对
sir
回复
sir
回复
要看自动化替代的是哪部分测试， 如果你是手工测试接口，那做成自动化就能替代这部分的手工； UI 的自动化对应就是替代页面的手工点点点。
我个人工作感受，自动化没有覆盖全部场景（包括深度，脚本健壮性的完善）的情况下，它最大的意义就是给领导做汇报用的。
能通过自动化发现的 bug，基本上不会是什么复杂的问题；复杂的问题，基本上都是靠人工测试的逻辑去发现的。
自动化的场景对象，最好是那种重要程度不高的，但又属于主流程业务的，这样即使出现问题，其实后果不会很严重。