前言
假設你作為測試團隊負責人，要被安排讓團隊成員接入公司的大模型服務，進行測試工作提效，那麼能想到的第一個方向就是讓大模型輔助生成測試用例。
在一段時間內使用大模型對話來生成用例，可能大家一開始會有新鮮感多去嘗試，但後面可能會漸漸地覺得對話本身也是降低效率的一種表現，並且大模型生成的用例能夠被採納的可能性也是起伏波動，很難有一個亮眼的團隊數據。
因為，你首先肯定會想到該如何優化大模型的使用效率，那麼編寫適配自己團隊業務的大模型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 空格縮進。
- 禁止輸出任何額外説明，不要輸出推理過程。
測試場景：
