做测试的兄弟应该都懂这种感觉：产品经理扔过来一份需求文档，你对着屏幕开始一条一条憋用例——正常流程、异常流程、边界值、组合场景……写了半天抬头一看，才覆盖了不到三分之一。
更扎心的是，好不容易写完，需求改了。
传统的测试用例编写方式，本质上是在拼两样东西：时间和经验。时间够不够用，决定了你能写多少条；经验够不够丰富，决定了你能覆盖多少死角。但这两样东西在敏捷迭代面前，永远不够。
所以最近大半年，我开始认真研究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用废了，问题出在提示词上——太随意。
一个合格的测试用例生成提示词，至少应该包含这几层：
你是一名资深测试开发工程师。请根据以下【测试需求】和【参考知识】生成测试用例。
【测试需求】
{用户输入的需求描述}
【参考知识】
{从知识库检索到的相关文档片段}
要求：
- 覆盖正常流程、异常流程、边界值
- 每个用例包含：用例编号、前置条件、测试步骤、预期结果
- 优先覆盖高风险场景（参考历史缺陷库）
核心逻辑就一句话：告诉模型你是谁、要干嘛、拿什么资料干、按什么格式交作业。缺了任何一环，出来的东西都可能跑偏。
第三步：调检索参数（别让模型“找不到”或“找太多”）
检索是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带着资料干活”的工具。对测试人员来说，最大的价值不是“取代你写用例”，而是把你从重复劳动里解放出来，让你把精力放在更值得花时间的事情上——比如设计更刁钻的测试策略、分析更复杂的业务场景。
但前提是：你得把知识库建好、把提示词写好、把检索调好、把闭环跑通。缺任何一个环节，效果都会大打折扣。
工具摆在那，用得好不好，看人。
