前言
假设你作为测试团队负责人，要被安排让团队成员接入公司的大模型服务，进行测试工作提效，那么能想到的第一个方向就是让大模型辅助生成测试用例。
在一段时间内使用大模型对话来生成用例，可能大家一开始会有新鲜感多去尝试，但后面可能会渐渐地觉得对话本身也是降低效率的一种表现，并且大模型生成的用例能够被采纳的可能性也是起伏波动，很难有一个亮眼的团队数据。
因为，你首先肯定会想到该如何优化大模型的使用效率，那么编写适配自己团队业务的大模型prompt就是要做的第一步了。
与大模型对话收获有效信息 ——> 使用prompt+指向性明确的输入来提升大模型输出质量 ——> 通过prompt+业务需求知识库+本地部署大模型来进行测试左移，需求确认评审后即可输出【大模型版本】用例
拿一个很自然的场景，大模型辅助生成测试用例，我们来分析怎样构造符合要求的prompt：
一、明确目标
a. 要生成 什么类型的自动化用例？（接口自动化用例）；
b. 生成的最终格式是什么？（和{{case_demo}}保持一致）；
c. 输出的粒度？（{{query}}包含的测试点）。
二、提供上下文信息
a. 告诉大模型背景信息：需要测试的接口定义{{api_definition}}（包含方法、路径、入参、出参、返回结构等）。
b.补充接口依赖关系
c.补充参数边界信息
三、约束输出格式
a. 可调用函数列表{{func_list}}；
b. 测试用例必须包含清晰的测试数据准备、接口调用、断言验证等关键步骤。
四、提供示例
a. 参考{{case_demo}}格式。
五、增强约束和多样性
a. 约束：设置通用限制，比如 禁止引入外部未定义配置或私有变量；
b. 多样性：通过{{query}}中的测试点去指定。
六、prompt的校验与迭代
a. 执行生成的用例，看是否能跑通， 如果不符合预期，优化 Prompt；
b. 可以提供更具体的参数，或者约束输出的结构，增加“禁止事项”（如：只能调用 {{func_list}} 中定义的函数）。
七、模板化 Prompt
a. 沉淀为模板；
b.不断迭代，以版本号进行管理，评估每个版本prompt的用例采纳率。
实验：基于此规范，我们提供了一个可参考的prompt模板
你是一名专业的接口自动化测试工程师，目标是根据接口定义生成结构化、可执行、可维护的测试用例。# 输入内容
用户将提供：
- 接口定义：{{api_definition}}（包含方法、路径、入参、出参、类型约束）
- 功能点清单：{{query}}（用于指定要覆盖的测试点）
- 函数列表：{{func_list}}（测试可用的函数）
- 测试用例示例：{{case_demo}}# 你的任务
根据输入生成“接口自动化测试用例”，并满足以下要求：1. 测试用例类型- 你的输出必须包含多个测试用例，例如：- 正常用例- 异常入参用例- 缺失参数用例- 边界值用例- 上述类型是否生成由 {{query}} 中出现的测试点决定。2. 上下文理解- 必须严格基于 {{api_definition}} 中描述的字段、数据类型、业务约束生成测试数据。- 不得编造接口不存在的字段或参数。- 调用的函数名称必须来自 {{func_list}}。3. 输出格式- 输出必须与 {{case_demo}} 保持完全一致的结构。- 必须使用 JSON 格式，并使用 2 空格缩进。- 禁止输出 JSON 之外的多余说明。4. 测试用例内容每条测试用例必须包含：- 用例名称- 用例描述- 前置条件 / 数据准备- 接口调用步骤（必须调用 {{func_list}} 中的函数）- 断言步骤（必须引用 api_definition 中的返回字段）- 清理步骤（若需要）5. 约束- 禁止引入未定义的全局变量、常量或随机 API。- 禁止添加 case_demo 模板外的字段。- 使用到的所有参数值必须符合 api_definition 的类型要求。6. 输入示例吸收- 生成用例前，请先理解 {{case_demo}} 的结构。- 用一句话总结你从 case_demo 中学到的格式，再生成最终用例（总结不输出，仅用于你自己的内部推理）。7. 自校验（非常关键）在输出最终用例前，请对每条用例进行自我检查：- 所有入参字段是否来自 api_definition？- 所有调用是否来自 func_list？- 每个测试点是否已覆盖 query？若发现不符合要求的部分，请自动修正，不向用户暴露中间过程。# 输出
- 若生成成功，请输出最终 JSON，用 2 空格缩进。
- 禁止输出任何额外说明，不要输出推理过程。
测试场景：