做测试的兄弟应该都懂这种感觉产品经理扔过来一份需求文档你对着屏幕开始一条一条憋用例——正常流程、异常流程、边界值、组合场景……写了半天抬头一看才覆盖了不到三分之一。更扎心的是好不容易写完需求改了。传统的测试用例编写方式本质上是在拼两样东西时间和经验。时间够不够用决定了你能写多少条经验够不够丰富决定了你能覆盖多少死角。但这两样东西在敏捷迭代面前永远不够。所以最近大半年我开始认真研究RAG检索增强生成在测试场景里的落地。跑了几个项目之后可以负责任地说一句这东西确实能干活但前提是你得知道怎么用它。先花30秒搞清楚RAG到底在干啥RAG的全称是Retrieval-Augmented Generation翻译成人话就是“先翻资料再答题”。以前你直接让大模型生成测试用例它全靠预训练时学到的“通用知识”来编。结果就是它可能根本不认识你们公司的业务术语也不知道你们API接口到底长什么样生成出来的用例看着像模像样实际一跑全废。RAG的思路很简单在让大模型写答案之前先从你们公司的文档库里把相关的资料搜出来连同问题一起塞给模型。模型不再是“凭记忆瞎编”而是“拿着资料照着写”。类比一下就是——不RAG相当于闭卷考试RAG相当于开卷考试。开卷和闭卷的区别不用我多说了吧。测试人员用好RAG的四步实操第一步把知识库搭起来这是地基RAG的效果70%取决于你的知识库质量剩下30%才是模型和参数的事。哪些东西应该喂进去PRD/需求文档用例的来源没有这个后面的都白搭API接口文档Swagger/OpenAPI格式最好结构化程度高历史测试用例库让模型学习你们团队的用例风格和覆盖思路缺陷库/Bug报告历史踩过的坑让模型知道哪些地方容易出问题设计稿/UI说明能提取文字就提取前端测试用得上建知识库的时候有个坑要注意文档不是越大越好要切块。长文档整段塞进去检索精度会直线下降。一般建议按章节或按功能点切成小块用滑动窗口的方式保证语义连贯。向量数据库选型方面小团队用ChromaDB就够数据量大的上Milvus或Weaviate。嵌入模型中文场景推荐BGE-Large-Zh效果比较稳。第二步设计好提示词别让模型自由发挥很多测试同学把RAG用废了问题出在提示词上——太随意。一个合格的测试用例生成提示词至少应该包含这几层你是一名资深测试开发工程师。请根据以下【测试需求】和【参考知识】生成测试用例。 【测试需求】 {用户输入的需求描述} 【参考知识】 {从知识库检索到的相关文档片段} 要求 1. 覆盖正常流程、异常流程、边界值 2. 每个用例包含用例编号、前置条件、测试步骤、预期结果 3. 优先覆盖高风险场景参考历史缺陷库核心逻辑就一句话告诉模型你是谁、要干嘛、拿什么资料干、按什么格式交作业。缺了任何一环出来的东西都可能跑偏。第三步调检索参数别让模型“找不到”或“找太多”检索是RAG的咽喉。检索出来的东西不对后面生成什么都不对。几个可以调的参数Top-K每次检索返回多少条结果。K太小可能漏掉关键信息K太大上下文太长模型会“失焦”。一般5-10是个不错的起步区间。相似度阈值低于这个相似度的结果直接丢弃避免把不相关的东西喂给模型。分块大小Chunk Size块太大检索精度差块太小上下文割裂。根据文档类型调接口文档可以切小一点需求文档可以稍大。另外可以考虑混合检索——向量检索关键词检索结合。向量检索擅长语义匹配关键词检索擅长精确匹配比如接口名、字段名两者互补效果更好。第四步建反馈闭环让系统越用越聪明RAG不是一次性工程。用得越多应该越准。怎么做把测试执行的结果反向喂回去哪些用例执行通过了→说明生成质量OK标记为正样本哪些用例执行失败了→分析原因是文档错了还是模型理解错了把问题反馈到知识库或提示词里哪些场景模型漏掉了→补充到知识库中天猫技术团队的实践数据可以参考C端业务用例采纳率达到85%以上中小型需求的用例编写时效从2小时降到0.5小时提升75%。他们能做到这个水平靠的就是“需求规范化Prompt工程知识库RAG平台化集成”这套闭环策略。进阶玩法GraphRAG和多智能体前面讲的都是“朴素RAG”——向量检索生成。如果你们系统业务逻辑特别复杂实体之间关系盘根错节可以看看GraphRAG。GraphRAG在RAG的基础上加了一层知识图谱。它不只看“文本相似”还能沿着关系路径去推理。比如你要测“订单退款”场景朴素RAG可能只搜到退款相关的文档片段GraphRAG还能把“订单”“支付”“库存”“优惠券”这些关联实体的信息一并带出来覆盖更全。再往上走一步就是多智能体协作。把不同的测试任务拆给不同的Agent一个负责需求分析、一个负责用例生成、一个负责脚本编写、一个负责回归影响分析。每个Agent专注做一件事RAG作为它们共同的知识底座。苹果最近提出的Agentic RAG框架就是这么玩的目标是把质量工程师30-40%的手工编写时间省下来。最后说几句实在话RAG不是什么玄学它本质上就是一个“让AI带着资料干活”的工具。对测试人员来说最大的价值不是“取代你写用例”而是把你从重复劳动里解放出来让你把精力放在更值得花时间的事情上——比如设计更刁钻的测试策略、分析更复杂的业务场景。但前提是你得把知识库建好、把提示词写好、把检索调好、把闭环跑通。缺任何一个环节效果都会大打折扣。工具摆在那用得好不好看人。