不晓得 也在找出路

我也觉得 没人讨论技术了 ，审核确实很慢 不晓得站长怎么想的。

为什么现在还在讲接口自动化和 ui 自动化，在 AI 出来之前很多公司也没做接口自动化和 ui 自动化，更多的是在功能测试层面

还有就是跑了挺久的 但是测试的都是一些无关紧要的场景，花费的时间久还浪费 token ，现在我做的是前端和后端隔离开了，因为后端很多逻辑是底层逻辑 如果依靠前端 e2e 很多是测不到的，就单独写了后端测试的 skill ，前端 skill 只负责前端的（包括前端的业务逻辑 + 前端特有的 比如删除列表数据要重新刷新列表请求接口 这种）。你现在的这个 skill 跑的效果怎么样 实际能落地吗？ 假设说开发提测了一版需求 这个东西能替代人工部分比例吗？

不知道楼主截了我的回复的图 是认可我讲的还是不认可我讲的

“可以在开发提测后能后直接生成 UI 用例并运行后整合测试报告出来”， 这个说明你是要测试前端是吧，我觉得前端的东西更多的是 dom 渲染，还有组件是否封装过（自研组件，原生组件）。你想让 AI 帮你生成脚本然后根据你的用例执行？像人一样操作页面上的那些表单啥的？ 还是其他的？ 我也做过类似的 skill ,让 AI 根据测试用例帮你测反正挺耗费 token 的，还有你的用例要写的详细一点，还有定位仍然是一个大问题

我也搞了一个 但是离人工测试前端还差的远，因为前端很多问题是 观察 - 效果 型的

“每天看其他论坛都有被裁员的，” --- 是什么论坛？ +1 想知道

笔者不直接在主对话里跑测试——上下文会被几千行测试日志撑爆。而是让 test-runner Subagent 去执行：UI 回归用 Playwright MCP，接口回归用 pytest。Subagent 跑完只回传一份简短摘要——"156 个用例，8 个失败，其中 5 个是订单字段变更导致的断言错误"。 这里不太懂 为什么叫回归测试 而不是测试？你们生成的用例是完全 AI 可以遵照执行的吗？ 那么执行用例时 ai 需要了解的业务逻辑，库表关系是怎么处理的，ai 断言是怎么处理的啊

如果是当前迭代还需要看当前迭代的需求，就算用 AI 我们还是要测试开发的代码有没有 bug 这个是永远不会变的。 其实我现在就像知道 AI 能做到和人一样去功能测试吗，复杂测试场景，复杂的造数什么的，如果只是一个简单的表单并且接口能覆盖你们业务的大部分逻辑的话，这种不算。 但是目前在论坛没找到有落地案例的