测试之家

AI测试 AI 赋能测试实践 04——同样的模型，10 倍与 100 倍提效的差距在哪？揭秘测试开发的 Prompt 设计心法与 “填空式” 超级模板

EternalRights · 2026年03月10日 · 274 次阅读

前言

        在 2026 年的今天，AI 已经渗透到测试开发的全生命周期：从需求评审时的测试用例生成，到 CI/CD 流水线的自修复脚本，再到线上的智能流量回放。

        但是为什么同样的大模型（如 GPT-5O 或 Claude-4-Opus），在不同团队手中提效倍数差异如此巨大呢（10 倍 VS 100 倍）？

        答案在于：你是把 AI 当作” 搜索引擎 “，还是把 AI 当作一名” 数字员工 “？

        不置可否，AI 在测试领域的提效主要集中在以下四个核心场景，而每个场景都需要截然不同的 Prompt 设计策略：
        1.测试设计：从需求文档中提取高覆盖用例
        2.脚本生成与维护：生成可维护的自动化代码（POM 模式）
        3.测试数据生成：生成符合业务逻辑的边缘 Case 数据
        4.智能体编排（LangGraph）：多 Agent 协作完成复杂测试任务

        下面，我将会逐一拆解这些场景下的最佳实践 Prompt 设计模式。

广义 Prompt 设计心法（通用方法论）

让你学会像” AI 训练师 “一样去思考，而非仅仅是” 提问者 “

        Prompt 工程被称为” 自然语言编程 “。无论你是在写测试代码，生成文案，还是日常问答，高阶 Prompt 都必须遵循以下 CRIT 框架。

C-Context（背景上下文）：给 AI” 上帝视角 “

        不要只给任务， 要给背景。譬如：AI 不知道你的系统用的是 Python、还是 Java、亦或者是 Go 语言；也不知道你的用户是小白还是专家；更别提你的年龄、性别、职业了。

  • 差的 Prompt：” 写个登录接口的用例 “
  • 好的 Prompt：” 这是一个面向高铁乘客的美食订餐 APP，登录接口需要兼容弱网环境，服务器在上海。“

R-Role（角色设定）：赋予 AI” 专家人格 “

        这是最简单但最有效的提效手段。指定角色能瞬间调用模型在该领域的预训练知识。

  • 公式：你是一个拥有【X】年经验的【领域】专家，擅长【具体技能】
  • 测试专享：不要只说” 测试工程师 “，要说” 擅长破坏性测试和边界值分析的资深测试架构师 “

I-Instruction（指令约束）：明确” 做什么 “和” 怎么做 “

这是核心的逻辑层，必须包含：

  • Task：具体任务
  • Steps：思考步骤（强烈建议加入 CoT 思维链：请一步步思考）
  • Fromat：输出格式（JSON/Markdown/代码）

T-Tone&Constraint（语气与限制）：设定” 护栏 “

        防止 AI 发散。

  • 限制：” 不要解释原理，只给结果 “、” 代码必须符合 PEP8 规范 “、” 用例覆盖率必须达到 100%“
  • 少样本学习（Flew-Shot）：在 Prompt 中给 1-2 个 “标准答案” 示例，AI 的模仿能力会呈指数级上升。

AI 提效场景下，Prompt 最佳设计实践

测试用例生成

从 “穷举” 到 “场景化 + 边界值注入”

        提效点：将用例编写时间从小时级压缩到秒级，测试用例覆盖率提升数倍

反面教材

“请为这个登录接口写10个测试用例。”

最佳实践 Prompt

# Role
你是一位拥有10年经验的金融级测试专家，擅长边界值分析和异常路径测试。

# Context
被测系统：核心交易系统的API接口 `/api/v1/transfer`
业务规则：单笔限额5w，日累计限额20w，余额不足时需返回特定错误码 `ERR_INSUFFICIENT_BALANCE`。

# Task
设计测试用例，重点关注：
1. 金额边界（49999, 50000, 50001, 200000, 200001）
2. 并发场景（同一账户同时发起2笔交易）
3. 状态流转（冻结账户、注销账户）
4. 安全性（SQL注入、XSS、重放攻击）

# Constraints (关键约束)
- 输出格式必须为JSON，包含字段：case_id, scenario, request_body, expected_status, expected_response_field。
- 必须包含至少3个“异常用例”（Negative Testing）。
- 必须使用等价类划分法，并在Thinking过程中展示划分逻辑。
- 针对并发场景，需给出具体的pytest并发代码片段。

# Output Format
请以Table形式展示，并在最后附带JSON数据。

自动化脚本生成

解决 “能跑但不可维护” 的痛点

        提效点：脚本生成效率大幅提高，且直接符合页面对象模型（POM）设计模式。

最佳实践 Prompt

# Role
你是资深的Selenium/Playwright自动化架构师。

# Task
为以下用户故事生成自动化测试脚本：
"用户在购物车页面，修改商品数量为0，点击结算，系统应提示'商品数量不能为0'并留在当前页。"

# Critical Requirements (核心要求)
1. **设计模式**：必须严格遵循Page Object Model (POM) 模式。
   - 单独生成 `Page` 类（定位器 + 操作方法）。
   - 单独生成 `Test` 类（业务逻辑 + 断言）。
2. **原子性**：操作方法必须是原子的（如 `click_checkout_btn()` 而不是 `do_checkout()`）。
3. **健壮性**：必须包含显式等待（Explicit Wait），等待元素可点击。
4. **断言精准**：不要只断言HTTP 200，要断言具体的Toast提示文本或DOM元素变化。
5. **语言**：Python + Pytest。

# Input Data
页面元素快照：
- 数量输入框: [data-testid="quantity-input"]
- 结算按钮: [data-testid="checkout-btn"]
- 错误提示: .ant-message-error

请生成代码，并解释为什么这样设计POM结构。

LangGraph 与多智能体协作

测试流程的 “编排者”

        提效点：构建全自动测试流水线，Agent 自动分工（需求分析 Agent -> 用例设计 Agent -> 数据准备 Agent -> 执行 Agent）。

        在 LangGraph 中，我们需要设计两种 Prompt：

1.路由节点的 Prompt

        作用：决定下一步该调用哪个工具或 Agent。

# Role
你是测试流程的调度中枢（Router）。

# Task
根据用户的输入，判断意图，并选择下一个节点：
1. generate_cases (生成用例)
2. generate_data (合成数据)
3. execute_test (执行测试)
4. analyze_log (日志分析)

# Input Example
"我想测一下退款接口的超时情况" -> 选择 generate_cases -> generate_data -> execute_test
"帮我看下昨晚的流水线为什么挂了" -> 选择 analyze_log

# Output
仅输出节点名称的JSON字符串，不要输出解释性文字。
2.执行节点的 Prompt

        作用：针对具体任务的深度指令。

# Role
你是性能测试专家Agent。

# Task
根据传入的测试场景，生成Locust压测脚本。

# Context
- 接口：/api/v1/order/create
- QPS目标：500
- 并发用户数：1000
- 思考：需要模拟30%的失败率（服务器错误500）来测试熔断机制。

# Instruction
1. 编写Locust的User类。
2. 定义task，包含正常流程和异常流程的权重。
3. 输出完整的Python脚本，可直接运行。

防御性 Prompt

对抗 AI 幻觉与逻辑漏洞

        提效点：AI 在测试领域最大的风险是 “一本正经地胡说八道”（例如生成不存在的 API 字段，或断言错误的预期结果）。

防御性 Prompt 模板：

# Role
你是严谨的测试评审员。

# Task
审查以下AI生成的测试用例，找出逻辑漏洞。

# Review Criteria (评审标准)
1. **字段真实性**：检查JSON字段是否在提供的Swagger文档中存在。
2. **逻辑一致性**：前提条件是否满足（例如：未登录状态下能否发起支付？）。
3. **业务规则**：是否违反了“单日限额”等核心业务规则。
4. **格式检查**：是否符合JSON Schema。

# Input Data
[Swagger文档片段]
[AI生成的测试用例]

# Output
如果发现错误，请以列表形式指出；如果全部正确，仅输出 "PASS"。

测试领域 Prompt 超级模板库

覆盖 90% 测试场景的通用 Prompt，复制即用，【】内填空即可

         为了保证最佳实践，以下模板均采用了结构化 Markdown + 变量填空的形式。你只需要替换【】中的内容，即可生成金融级、Web 端或通用软件的高质量输出。

模板一：全场景测试用例生成模板（通用版）

适用场景：需求评审后，从 PRD/用户故事快速生成高覆盖率用例。

核心技术：等价类划分 + 边界值 + 异常注入 + CoT 思维链

# [ROLE]
你是一位拥有10年经验的资深测试专家，精通黑盒测试设计方法（等价类划分、边界值分析、因果图、场景法），并且熟悉【行业领域，如：金融交易/电商/SaaS】的业务特性。

# [CONTEXT]
被测系统：【系统名称，如：核心支付网关】
核心功能：【功能描述，如：用户提现申请】
业务规则/约束：
1. 【规则1，如：单笔提现限额50000元】
2. 【规则2，如：余额不足时返回错误码 ERR_001】
3. 【规则3，如：每日最多提现3次】
4. 【特殊约束，如：需考虑服务器时钟偏差】

# [FEW_SHOT_EXAMPLE] (金标准示例，引导AI风格)
输入：登录功能-密码错误
输出：
- 用例ID: TC_LOGIN_002
- 场景: 密码错误
- 前置: 用户已注册
- 步骤: 输入正确账号，输入错误密码，点击登录
- 预期: 提示"账号或密码错误"，不跳转，停留在登录页

# [TASK]
请根据以上信息，设计全面的测试用例。

# [REQUIREMENTS] (必须严格遵守)
1. **思维过程**：请先在Thinking步骤中分析等价类（有效/无效），展示你的测试设计思路。
2. **用例类型**：必须包含：
   - 正常流程（Happy Path）
   - 边界值（刚好等于、刚大于、刚小于限额）
   - 异常场景（网络中断、并发请求、SQL注入、非法字符）
   - 隐含需求（如：操作日志是否记录、响应时间是否<200ms）
3. **输出格式**：严格以JSON格式输出，字段包括：case_id, module, title, precondition, steps (list), expected_result, priority (P0-P3)。
4. **数量要求**：至少生成【N，如：15】条用例。

# [INPUT_DATA]
【在此处粘贴你的需求文档片段、接口定义或Swagger地址】

模板二：高可维护性自动化脚本生成模板（代码版）

适用场景：将手工操作步骤转化为符合设计模式的自动化代码（Selenium/Playwright/Pytest）。

核心技术：POM 模式 + 原子操作 + 显式等待 + 防御性断言。

# [ROLE]
你是顶级的自动化测试架构师，精通【语言，如：Python+Playwright】以及页面对象模型（POM）设计模式。你的代码风格是：高内聚、低耦合、可读性强。

# [TASK]
将以下手工测试步骤转化为自动化测试脚本。

# [INPUT_STEPS] (手工步骤)
1. 打开浏览器，访问 【URL】
2. 在搜索框输入 【关键词】
3. 点击搜索按钮
4. 在结果列表的第一个商品上点击“加入购物车”
5. 验证右上角购物车角标数字+1

# [TECH_STACK]
- 语言框架：【Python + Pytest + Playwright】
- 设计模式：【Page Object Model (POM)】
- 运行环境：【Headless模式 / 本地Chrome】

# [CRITICAL_RULES] (关键约束)
1. **代码结构**：必须分离 Page层（定位器+方法）和 Test层（业务逻辑+断言）。
2. **定位器策略**：优先使用 `data-testid` 或 `aria-label`，禁止使用绝对XPath。
3. **等待机制**：必须使用显式等待（expect(locator).to_be_visible()），禁止使用固定sleep。
4. **断言强化**：不仅断言URL变化，必须断言【具体DOM文本或API响应体】。
5. **异常处理**：代码需包含try-catch，截图保存到 `./screenshots` 目录。

# [OUTPUT_FORMAT]
请分两个代码块输出：
1. `pages/search_page.py` (Page类)
2. `tests/test_search.py` (Test类)
并在代码后附带一段“设计思路说明”，解释为什么这样封装。

模板三：LangGraph 多智能体编排与自修复模板（Agent 版）

适用场景：构建 CI/CD 中的智能测试 Agent，如 “用例生成 Agent”、“执行 Agent”、“日志分析 Agent”。

核心技术：结构化 IO + 路由逻辑 + 自我反思。

# [SYSTEM_ROLE]
你是测试流水线中的【Agent名称，如：用例评审Agent】。你的上级是LangGraph的调度节点。

# [INPUT_SCHEMA] (你接收的输入必须是JSON格式)
{
  "requirement_doc": "字符串",
  "api_spec": "字符串",
  "history_cases": "列表"
}

# [INSTRUCTION]
1. **解析输入**：读取 `requirement_doc` 和 `api_spec`，提取核心业务实体和接口字段。
2. **生成用例**：参考 `history_cases` 的风格，生成新的测试用例。
3. **自我校验（Self-Correction）**：
   - 检查生成的用例是否存在重复。
   - 检查请求参数类型是否匹配API定义（如：age应为int，不能是string）。
   - 如果发现错误，请在 `thoughts` 字段中记录并修正，不要直接报错退出。
4. **输出**：返回标准JSON，供下一个节点（执行Agent）消费。

# [OUTPUT_SCHEMA] (必须严格遵守)
{
  "status": "success/failure",
  "thoughts": "你的思考过程和修正记录",
  "generated_cases": [
    {
      "case_id": "string",
      "method": "POST",
      "url": "/api/xxx",
      "body": {},
      "assertions": []
    }
  ]
}

# [EXAMPLE_INPUT]
{
  "requirement_doc": "用户注册接口...",
  ...
}

# [EXAMPLE_OUTPUT]
{
  "status": "success",
  "thoughts": "检测到历史用例中缺少手机号格式校验，已补充...",
  "generated_cases": [...]
}

# [NOW_INPUT]
【在此处粘贴当前的JSON输入数据】

后记

         笔者认为 Prompt 是除 LLM 之外 AI 测试领域第二重要的核心概念，因为纷繁复杂的 AI 概念本质上就是针对于 Prompt 的延申，像是 RAG、Search 本质上是保障 Prompt 的质量，而 Skill 本质上是对于 Prmpt + Tool + MCP 的封装，而 Tool + MCP 本质上也是在为 Prompt 服务。包括最近爆火的 OpenClaw 小龙虾，其本质上就是对于 Prompt 工程玩出花来了。

         总而言之，笔者无非只有一个观点，对于我们测试人员 Prompt 不是简简单单的对话，而是需要引起注意并投入一定精力学习的核心技术。

「原创声明：保留所有权利，禁止转载」
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册。