各位老师们 请教一下关于 ai 提效的相关问题
最近在尝试做一个 AI 辅助影响范围分析与测试用例生成 的小专项。
简单说，就是想把测试同学日常做需求测试时最耗时的几件事，用 AI 辅助标准化下来：
看需求，理解这次到底改了什么；
结合技术方案、代码检索、diff，判断影响范围；
区分 P0/P1/P2 测试范围；
生成测试用例、回归范围、风险点和待确认项；
要求每个影响结论尽量有代码证据支撑，而不是纯靠猜。
目前先用一个真实 B 端前端需求试跑了一版，过程中发现 AI 直接生成用例虽然格式很好，但容易漏掉 “业务结果是否正确” 这种核心场景。比如汇总页不只是要测筛选、跳转、页面展示，还要验证统计数量、数据集合、分类结果是否和来源页面一致。
所以现在这个专项的重点不是 “让 AI 替代测试写用例”，而是探索一套更稳定的协作流程：
人负责解释业务意图和判断边界，AI 负责辅助检索证据、整理影响范围、生成可复核的测试设计。
后续准备继续用更多真实需求验证，看看它在影响范围分析、漏测识别、用例生成效率上到底能提升多少，也想听听各位前辈的看法 感觉有没有搞头
阿里开源了一个类似的框架，open-code-review，我最近也在尝试接入到公司测试环境，但是这个本身是纯白盒的，关于业务理解方面我也在探索，有搞头是一定的，前提是需要有足够的、高质量的需求文档让大模型做业务理解，通过 diff 的代码和足够的业务需求文档，是可以做到随着代码 push 去生成相关测试用例的
Fengtu
回复
感谢回复！我刚了解了下 Open Code Review，它主要是基于代码变更做白盒评审。咱们现在做的方向和它有重合，但我们是站在测试侧切入：结合需求目标、技术方案、代码改动，梳理出业务判断规则，再自动输出影响范围、测试优先级、测试用例还有回归相关资产。
你提到的业务理解这块我特别认同，实际工作里需求文档经常写得不全。所以我现在额外补充了测试人员梳理的业务逻辑、现有页面和接口信息，再加待确认需求的记录流程，防止 AI 脑补补全需求导致出错。后续还打算把生成的用例直接转成接口、UI 自动化脚本。
Open Code Review 完全可以拿来做底层的代码分析能力底座。等你那边对接完测试环境跑起来之后，期待可以多多分享实际落地效果
Holmes
回复
“工作中需求文档经常写的不全”，这是一个很大的问题，我并不知道您公司的业务和部门的情况，因为我最近在一个初创公司，业务并没有那么复杂，这边的产品是通过几个 skills 去写 prd，在 prd 实现后，会根据 prd 和具体代码实现的功能沉淀额外一份功能模块文档，所以我这边的需求文档质量比较高，在进行 ai 生成测试用例的时候，经过一个比较符合业务的 skills 生成的用例质量比较高，在我看来是直接可用的，只需要自己在一些 case 上做一些探索测试即可覆盖全面。 关于这部分内容，也能看出来不是测试这边调整能做到的，需要产研测一起配合，所以我刚刚提到部门规模和情况，如果是一些发展了很久的部门，业务很复杂文档数量庞大，这确实是一个需要解决的问题，以上只是我个人经验，希望对你有帮助