不晓得 也在找出路

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

为什么现在还在讲接口自动化和 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 能做到和人一样去功能测试吗，复杂测试场景，复杂的造数什么的，如果只是一个简单的表单并且接口能覆盖你们业务的大部分逻辑的话，这种不算。 但是目前在论坛没找到有落地案例的

你们新迭代的需求测试，是如何使用 AI 的，能替代人工测试吗，会比没使用 AI 之前缩短测试时间吗？（主要是执行测试的时间，不算测试用例等等的，就是纯测试的时间）

想了解测试执行的这一步，想知道 AI 如何替代测试人员在测一个模块时，构造出的多种测试场景（包含复杂造数，不同的交互逻辑等等）AI 如何执行

但是没有人想一下功能测试过程中耗时最长的是测试执行吗？ 测试用例固然 AI 可以辅助生成（目前我司也实现了），但是实际过程中不写用例的公司也大有人在，对于 AI 辅助生成接口自动化脚本（其实接口也是体现的接口底层的逻辑，对 AI 设计的接口场景能否覆盖底层逻辑存疑），和 ui 自动化脚本，但是这些都不是能够解决【当前迭代】的问题，题主问的是 “目前开发的 ai coding 目前提效很好，原来开发 3 天 测试 1 天， 现在开发能在 1 天完成，测试如何在 0.3 天内把这些东西测完，测好的问题”，我在各层楼的回复中没看到有效的解决方案。

这个涉及到历史需求的质量（各种格式的需求文档，当需求有变更的时候是否及时补充到需求文档上，如果是迭代的需求，迭代的需求是否规范），测试用例的质量 等等 ，太难了。

我想的太复杂了 多谢啦

之前用了 set(list1) &set(list2) 然后不行，list 中是字典。page1 和 2 比较 2 和 3，3 和 4， 有点像冒泡排序 一个一个去比较一样

是类似发券那种操作 之前是由于列表排序引起的，可以排序的字段有两个 一个是时间 一个是金额 但这两个字段都可能有大批量的数据相同，可能是开发处理排序不当，导致分页出现了问题

如果测试片段之间有 参数的依赖呢

遍历 httpSample 节点取 start time 和 endtime 时 修改一下就可以了

你好请问你找到问题了吗 我也遇见这个问题了