一、问题：接口测试脚本的三要素缺口
一个完整的接口测试用例由三部分组成：输入参数、测试步骤、预期结果。
纯提示词工程可以解决"测试步骤"的生成------把 Controller 层代码输入给大模型，让它生成 JMeter 或 pytest 脚本骨架。但输入参数和预期结果依赖被测系统的私域知识（数据库数据、业务约束），大模型无法凭空生成。
解决方案是两步走：用 RAG 从 Swagger 文档生成测试脚本骨架，用 Text2SQL 从数据库动态生成测试数据。
二、提示词工程生成测试步骤
第一步先用提示词工程生成脚本骨架。系统提示词的设计思路：
- 角色设定：资深测试开发专家，精通 SpringBoot/Spring Cloud 微服务架构和 JMeter 5.3
- 输入：用户粘贴 Controller 层的 API 函数代码
- 输出：逐个 API 生成 JMeter 5.3 格式的
.jmx脚本
提示词用伪代码结构组织，从 main 函数开始，明确调用关系：分析Controller的API → 逐个调用 developJMeter5_3脚本 → 返回脚本列表。
适用场景：推荐在 IDE 中使用（如 Cursor、VS Code + Cline），可以直接选中源代码作为输入，避免手动复制粘贴。
这一步只解决了测试步骤，输入参数和预期结果仍需补齐。
三、RAG 从 Swagger 生成 pytest 骨架
Swagger JSON 文件包含了接口的完整定义（路径、方法、参数、响应结构），是生成接口测试脚本的理想知识源。
实现方案（基于 LlamaIndex）：
- 下载 Swagger JSON 文件到本地
- 用
JSONNodeParser将 JSON 解析为 Node 对象（每个 Node 代表一个文档 Chunk） - 构建
VectorStoreIndex，使用 BM25 检索器（BM25Retriever） - 组装
RetrieverQueryEngine，注入提示词模板 - 用户输入自然语言描述（如"生成用户登录接口的测试脚本"），引擎返回 pytest 代码
提示词模板的关键约束：
Your answer must be a Python markdown only.
Assert response code and the response json's length.
param_list does not reference other variables.
param_list's length is 1.这一步生成的 pytest 脚本包含参数化占位符（param_list），参数值尚未填充。
四、Text2SQL 从数据库生成测试数据
Text2SQL 将自然语言转换为 SQL 查询，直接从数据库获取真实数据填充测试参数。
三种查询引擎模式 （QueryEngineType）：
| 模式 | 原理 | 适用场景 |
|---|---|---|
| DEFAULT | 建立数据库向量索引，直接映射自然语言到 SQL | 数据库结构清晰、查询意图明确 |
| QUERYTIME | 查询时动态选择表格，不依赖预定义模式 | 用户不熟悉数据库结构，查询需求不固定 |
| RETRIVER | 基于检索匹配已有 SQL 模板 | 查询模式固定、需要快速响应 |
实现基于 LlamaIndex 的 NLSQLTableQueryEngine（DEFAULT 模式）或 SQLTableRetrieverQueryEngine（QUERYTIME 模式），底层 LLM 和 Embedding 模型通过 Ollama 本地运行。
Text2SQL 的提示词模板约束大模型只生成数据，不生成 SQL：
Your goal is designed the api test code's param to answer queries.
Your only generate data.
Your answer must be a json markdown only, don't answer sql.五、完整流水线
三步串联，形成端到端的接口测试脚本自动生成流程：
Step 1：用户输入测试意图 + Swagger JSON → RAG 查询引擎 → 生成 pytest 脚本骨架（含参数化占位符）
Step 2：提取脚本中参数化部分的代码 → 大模型生成参数 Schema（字段名、类型、约束）
Step 3 ：将 Schema + 提示词 → Text2SQL 查询引擎 → 从数据库生成符合等价类划分的测试数据 → 替换脚本中的 param_list
最终输出：可直接运行的数据驱动 pytest 脚本，覆盖正常值、边界值、异常值。
六、关键技术选型说明
LlamaIndex RetrieverQueryEngine：检索 → 后处理 → 整合三阶段流程。检索阶段用 BM25 或向量相似度找 top-k 相关节点；后处理阶段按分数重排、过滤；整合阶段将检索结果 + 用户问题 + 提示词模板送入 LLM 生成最终输出。
本地模型部署 ：LLM 使用 Ollama 推理框架（gpt-oss:120b-cloud），Embedding 模型同样走 Ollama。好处是数据不出本地，适合处理公司内部代码和数据库信息。
数据安全边界：公司内部代码、数据库 Schema、业务数据严禁上传公网大模型服务。本地部署 Dify + Ollama 是企业场景的标准选择。
七、局限与适用边界
这套流水线目前适合以下场景：接口定义清晰（有 Swagger 文档）、数据库结构相对稳定、参数数量在合理范围内。
对于全新接口（无历史测试物料）、参数极其复杂的场景，Text2SQL 生成的数据质量依赖数据库中已有数据的覆盖度。端到端 UI 测试（Web/App）不在本方案覆盖范围内，需要结合 Playwright MCP Server 等工具另行处理。