AI测试 为什么市面上基本所有的 AI 生成测试用例都是工作流
如题请教一下各位大佬为什么市面上基本所有的 AI 生成测试用例都是工作流，没有对话流或者混合模式
有这样一个场景：上传需求文档 or 输入需求 ------ 生成用例 ------ 会话保存 ------ 拿到第一个需求的补充需求 ------ 打开会话 ------ 上传新需求------llm 检索上下文根据之前的用例和需求文档追加生成新需求的用例
目前公司期望我做到这一点，有没有比较好的解决方式
和算法那边请教了，那边给的是需要把会话 id 存在数据库，需求文档存在向量库
考虑一下如果是对话流的话生成用例的输出本来就多，多循环几次会造成上下文爆炸，以及导出用例，导出的是哪一版用例，总不能一个会话的所有内容都下载
目前从 0 到 0.5 的平台开发好了，基于 React+Fastapi+langchain 和 langgraph 实现的，新建会话后用户上传需求/文档/照片，输入生成用例/需求分析/UI 识别，主管智能体会进行意图识别调用对应的智能体进行输出，在同一会话内再次上传内容只需要在输入内加上追加/增加等字样，智能体可基于上下文的内容追加生成，目前还在持续开发中，之后的功能打算加上自动生成 UI 和接口自动化脚本和 MCP 配置以及知识库，到时候再开源
目前我们是将 prompt 分为一下结构：用例结构（页面、功能、测试点），测试方法分组（提交类、查询类、场景组合等方法论的实际少样本提示）、标签分组、覆盖测试类型分组（兼容、接口、性能等）。针对依赖度不高的需求已经可以较好的应对，对于人工采纳在结构上也较友好。对于持续迭代版本，你说的依靠历史用例上下文检索效果也不是特别好，我们的做法是建立功能背景文档，帮助描述历史需求，专门设计历史依赖组合的类目去进行设计。
柠檬Yuki
回复
是的，单独一个历史功能大全，然后拆分出一个分组，历史功能组合。你可以给 AI 圈定场景组合的方式。逆向数据使用，重复数据使用等类似的小样本案例。AI 就知道可能要考虑历史功能对当前功能的影响，同理现有功能对历史功能数据的影响。这种一般都是人工补充的，所以再规范格式的时候一定要清晰，起码保证人工审核的时候是高效的。你可以先从无背景的需求下手，再递进到有需求背景的业务。慢慢的你就知道需要设置什么样的 AI 角色了
问下你这些市面上的 ai 生成测试用例都是在哪找的
新建项目好像有问题
这个 ai 测试平台用的人多嘛。不多的话可以用 ai 的 ide 做这个，就不用搭建平台了。
而且这玩意要需求文档够明确，如果需求文档有点模糊的话容易抽风把。而且还有需求文档内容超过大模型上下文等问题。
feng666
回复
其实是只要需要 AI 干活的文档等输入内容都得写详细，如果很模糊做不了 AI 相关的工作，需求文档超过上下文这一点这个确实，但是目前来说如果用 AI 做测试前准备的话，拆分为一个模块一个模块的给 AI 生成的东西最准确也最具有实际价值，整个业务流程的可以专门另外再加一个智能体和提示词专门用于全流程的冒烟分析
feng666
回复
用的多不多不太清楚，但是我用 MCP 和 skill 确实可以做到 UI 自动化的冒烟测试以及编写测试用例这些功能，但是难以进行集成，缺少数据的集中管理，用 ide 还有个问题加上 token 消耗特别大，如果公司给钱另说，但是应该愿意给测试分配资源的公司应该不多吧，我现在就再自掏腰包
目前从 0 到 0.5 的平台开发好了，基于 React+Fastapi+langchain 和 langgraph 实现的，新建会话后用户上传需求/文档/照片，输入生成用例/需求分析/UI 识别，主管智能体会进行意图识别调用对应的智能体进行输出，在同一会话内再次上传内容只需要在输入内加上追加/增加等字样，智能体可基于上下文的内容追加生成，目前还在持续开发中，之后的功能打算加上自动生成 UI 和接口自动化脚本和 MCP 配置以及知识库，到时候再开源
我觉得现在核心挑战在于，许多产品连需求文档本身都模糊不清。在一个完整的开发周期中，理想流程应是 AI 首先进行深度需求分析，将模糊需求拆解为明确、可衡量、可验证的任务项，再基于这些任务项生成测试用例。然而，测试用例往往篇幅冗长，大模型的上下文承载能力有限，导致最终生成的结果要么存在缺失，要么可测性不足。目前来看，针对完整系统生成测试用例的效果仍远未达到实用标准，仅在处理单一功能点时，才能实现一定的效率提