关于AI生成测试用例的实践记录（一）
2026-05-23 12:53 第二个卿老师 阅读(89) 评论(0) 收藏 举报关于AI生成测试用例的实践记录
背景
又是半年没写了，去年下半年开始投身于AI，随着AI能力越强，慢慢发现内容变得廉价，手工内容的产出是一件困难的事，这篇本该是26年1月发布的，一直拖延了，为了记录这大半年的变化，后续会持续更新（本篇纯手打）
今年下半年（2025年11月）开始，AI Coding发展迅速，团队开始积极拥抱AI，其中测试用例的设计，存在较多固定与重复的内容，于是准备使用AI生成
思考与实践
由于目前手工用例采用xmind格式组织的，所以准备找一个契合的用例生成prompt，来指导AI生成的用例是可用、有效的。
于是网上找了很久，都没有找到比较契合的，这里的原因其实是大家的xmind用例组织格式与规范不一致，所以prompt还得自己弄。
第一个问题：我的用例组织格式与规范是怎么样的？
我是由excel过渡到xmind格式的，因为接触的是互联网C端产品，经验告诉我们一般会按照功能或者页面两种方式来设计，两个方式各有利弊。
按功能模块来设计用例：重业务流，轻UI，一个页面可能需要测试多次，可能会遗漏UI细节
按页面模块来设计用例：重UI，轻业务流，业务流的测试用例定义比较模糊，多人协作不便
于是业界渐渐发展出两者融合的模式，我之前的模式比较灵活，从excel转变过来的，用例的设计链：按照页面模块分 ——> 依次验证页面组件 ——> 然后验证业务逻辑 ——> 最后补充异常场景，用例类似如下：
个人风格偏简洁，也图方便，所以存在测试点与测试用例糅合的形式，虽然后续方便评审额外加了的冒烟测试用例和接口测试用例，也达到过其它伙伴的不同风格的测试用例，比如预期结果通过连接线连在一起、各种符号标识等等
不过在加入创业团队后，个人风格得以保留，不过也在思考是否有更好的组织形式？在询问AI后，得出的也是混合模式编写，但也有差别。
chatgpt说：
deepseek说：
claude说：
gemini说：
问题总结
- chatgpt分三层，看着正确，但是业务和场景本来就很难拆分，存在很大冗余用例
- deepseek中，页面属于功能模块下，基本无冗余，但是两个功能模块存在相同页面就不好划分
- claude把功能和UI分开，功能测试专注业务流，UI测试关注页面，补充专项测试，基本无冗余，但是功能测试的颗粒度完全靠经验
- gemini说得不够详细，但基本和deepseek说的差不多
结合目前的偏敏捷的开发节奏，在测试开始介入时，应该关注业务流，然后才会关注页面的元素，所以借鉴claude的建议，我重新设计了用例的组织形式，参考如下：
按照目前测试要求拆分为三层：业务场景层，页面验证层，专项测试层（我这里主要接口测试，可扩展），业务场景层专注核心业务场景的验证（业务流），页面验证层专注UI样式、页面组件、页面功能及逻辑（单个功能），专项测试层作为补充测试，比如接口的越权、并发与幂等测试，每个大层会有专门的二级分类。这样整体用例基本无冗余，但是依旧存在部分问题：
- 业务场景层的异常场景设计定位不够清晰
- 用例级别的聚合和划分存在模糊地带，需要提前定义
- 专项测试中的验证点可能与页面功能的验证点冗余
另外用例的竖向格式确定了，现在来确定横向格式。
想既然AI这么强大，那么直接用AI生成prompt就行了，那么，问题就来了
第二个问题：现在模型这么多，那用哪个模型生成prompt？
于是做了一个实验，同样的一句话，让各个模型生成各自的prompt，于是找到了比较常用的模型（2025年11月），
首次输入的是：
第二次输入的是：
最终得到了以下4份测试用例的Prompt：
chatgpt：
点击查看代码
# prompt.md — 将需求（.md）自动拆解为 XMind 测试点模板的提示语
## 目的
本提示语用于指导 AI（或自动化脚本）读取项目的需求 Markdown 文件（requirements.md），并基于你提供的测试点模版与约束，输出**符合 XMind 目录结构**的测试点（以 Markdown 格式表达，便于直接导入或人工复制到 XMind）。最终输出包含 3 层测试设计：业务场景层 / 页面层 / 接口层；并将每条测试点关联到需求文档中的对应位置以便可追溯性。
---
## 输入（AI 将接收的内容）
1. `requirements.md` 的文本内容（完整的功能模块、用户故事、边界条件、需求条目、核心实体、成功指标、假设、技术说明、澄清记录等）。
2. 可选：额外的产品上下文（例如：目标用户、版本号、已知约束、测试计划摘要）。
---
## 输出要求（必须严格遵守）
输出为 Markdown 文档，使用缩进的 `-` 列表结构，匹配下列 XMind 模版的层级和命名规则：
* 用例设计：<功能模块名称> （必须来自 requirements.md 的模块标题）
* 业务场景
* 通过性场景
* <子功能或业务动作>
* （覆盖：单人单次、单人多次、多人单次、多人多次 — 若不适用可写 N/A）
* 举例：<操作 + 数据 示例>
* 期望：<期望结果>
* 异常场景
* <子功能或异常类型>
* （覆盖：角色异常、数据错误、未授权等 — 若不适用可写 N/A）
* 举例：<操作 + 数据 示例>
* 期望：<期望结果>
* 页面验证
* <页面名 或 弹窗名>
* 页面UI样式验证 / 弹窗UI样式验证
* 正常页验证 / 缺省页验证
* <展示项或断言>
* 页面字段验证 / 弹窗字段验证
* <字段名>
* 验证点：长度/格式/必填/占位/Placeholder/默认值等
* 页面交互功能验证 / 弹窗交互功能验证
* <交互项>
* 测试操作+数据：...
* 期望：...
* 页面业务逻辑验证 / 弹窗业务逻辑验证
* <业务点>
* 测试操作+数据：...
* 期望：...
* 接口测试
* <接口名>
* 验证类型：跨权限 / 幂等 / 并发 / 参数校验 / 失败恢复等
* 操作+数据：请求方法、路径、请求体/参数、鉴权信息、并发数量（如并发测试）
* 期望：状态码、返回字段、数据一致性、性能阈值（如适用）
**必须包含的元数据（每个顶层子节点或具体测试点至少包含）**：
* `id`：自动生成的唯一标识（例如：MOD1-BIZ-001 或 MOD1-PAGE-001）
* `来源`：需求文档的标题或行号（便于回溯），格式如 `requirements.md#章节标题` 或 `line:123-132`
* `优先级`：P0/P1/P2（默认根据成功指标与风险评估自动判断，但允许人工覆盖）
* `类型`：功能/UI/接口/安全/兼容/性能
* `前置条件`（如有）
* `操作+数据`：明确的用户操作步骤和所用数据（可用示例或模板数据）
* `期望结果`：具体可断言的期望（文本、状态码、UI 显示、DB 变化等）
---
## 规则 & 约束（基于你的说明）
1. **需求来源**：需求以 `md` 文档为准，模块化迭代开发。AI 解析时要优先依据 `requirements.md` 的模块、用户故事与需求条目。若信息缺失，可基于合理默认值推断，并在输出中标注“[推断]”。
2. **三层设计**：每个需求功能模块必须拆分出三类测试点：业务场景层、页面层、接口层。若某模块不包含页面或接口，明确标注 `N/A`。
3. **业务场景层链路**：业务场景 → 子功能 → 验证类型 → 操作+数据 → 期望。输出应遵循此链路。
4. **页面层链路**：页面 →（页面UI/字段/交互/业务逻辑）→ 子元素/子功能 → 验证类型 → 操作+数据 → 期望。
5. **接口层链路**：接口测试 → 接口名 → 验证类型 → 操作+数据 → 期望。
6. **适度测试原则**：不要对每个字段或每种边界都生成测试点（避免过度设计）。AI 应基于：需求的成功指标、数据敏感性、业务风险、使用频率、外部影响面来自动判定是否需要深度覆盖，并在输出里写明判定理由（例如：高风险、需兼容、关键 KPI 影响）。
7. **重复与合并**：若同一验证点在页面与接口层重复出现，AI 应合并并标注“测试复用：页面+接口”，并分别给出页面断言与接口断言的实现要点。
8. **命名规范**：测试点标题应该短而明确，最好含有动词，例如 `注册 — 成功注册生成 UID` 或 `订单列表 — 分页展示`。
9. **并发/负载**：并发测试必须说明并发数量或并发场景（例如：100并发、50虚拟用户），并给出性能判定阈值（如果需求中提供）或建议阈值（若无则标注为建议）。
10. **安全/权限**：跨权限测试需明确角色与期望结果（如管理员可见，普通用户不可见）。
11. **示例数据生成**：对于常见字段（email、phone、身份证号、UUID、金额、时间戳），AI 应提供一个或多个示例数据模板并标注是否需要脱敏或特殊格式。
---
## 输出格式样例（短版）
* 用例设计：用户注册模块
* 业务场景
* 通过性场景
* 注册 - 使用 Email 注册（MOD1-BIZ-001）
* 覆盖：单人单次/单人多次
* 举例：操作：在注册表单输入 email=[test@example.com](mailto:test@example.com), 密码=Abc12345；提交。
* 期望：返回 200，响应体包含 `userId`，数据库 `users` 表存在该记录。
* 页面验证
* 注册页面
* 页面字段验证
* email 字段（MOD1-PAGE-001）
* 验证点：必填、格式校验、最大长度 254
* 操作+数据：输入 `1.com` 并提交
* 期望：页面显示 `请输入合法的邮箱` 提示，表单不提交。
* 接口测试
* POST /api/v1/register（MOD1-API-001）
* 验证类型：参数校验、幂等性
* 操作+数据：请求体 `{email: "test@example.com", password: "Abc12345"}`
* 期望：返回 201/成功体，且重复提交不会创建重复用户（幂等断言）
---
## 示例（从需求片段到测试点）
**需求片段（requirements.md）**：
```
模块：用户注册
用户故事：作为未注册用户，我希望可以使用 email 完成注册，以便获得账户访问权限。
边界说明：支持 email 最大长度 254；密码至少 8 位，需包含字母与数字。
成功指标：注册成功率 > 98%（在正常网络环境下）
```
**AI 输出（对应测试点示例）**：参见“输出格式样例”。
---
## 额外建议（可选）
* 输出同时生成一个扁平的 CSV/表格，字段包含：`id, module, layer, title, type, priority, source, precondition, action_and_data, expected, notes`，方便批量导入到测试管理工具（如 TestRail、Zephyr）。
* 对于关键用例给出 `自动化建议` 字段（例如：适合 UI 自动化 / API 自动化 / E2E / 性能），并说明可复用步骤。
---
## 处理不明确或歧义的策略
* 当需求文档缺少页面名或接口信息时：AI 应从用户故事或核心实体推断页面/接口的存在，标注为 `[推断]` 并在 `来源` 中写明依据（例如：`requirements.md#用户故事：购买流程`）。
* 当需求中含有多种实现方式（例如：前端由 SPA 或 SSR 实现）而影响测试点生成时：优先以 `最保守` 的测试策略生成（即覆盖更多断言），并在 `notes` 中标注实现假设。
---
## 使用说明（给调用者）
1. 将 `requirements.md` 的文本粘贴或上传给 AI。
2. 调用 AI 并传入本 `prompt.md` 作为指令上下文。
3. 检查 AI 输出的 `来源` 链接（或行号），做人工复核并在必要时调整优先级或测试深度。
---
> 记住：AI 的目的是加速测试点设计并保证可追溯性与一致性，但不应替代产品经理或测试经理的最终判定。输出应作为第一版草案，由测试/产品团队确认后纳入测试计划。
---
*结束*
claude的：
点击查看代码
# 测试用例生成Prompt
## 角色定义
你是一位资深的软件测试工程师，擅长从需求文档中提取关键信息，设计分层、结构化的测试用例。你需要基于Markdown格式的需求文档，生成符合XMind模板格式的测试点。
## 任务目标
分析Markdown需求文档，采用**3层测试设计**（业务场景层/页面层/接口层）生成测试用例大纲，确保测试深度和广度适中，避免过度设计。
---
## 输入内容说明
### 需求文档结构（Markdown格式）
需求文档通常包含以下部分（并非所有部分都必须存在）：
- **功能模块名称**：本次迭代的功能模块标题
- **用户故事**：描述用户角色、需求和价值（如：作为XX角色，我希望XX，以便XX）
- **边界情况说明**：特殊场景、极端情况的处理逻辑
- **需求条目**：详细的功能需求列表
- **核心实体**：涉及的数据模型、字段定义
- **成功指标**：功能验收标准或度量指标
- **假设**：前置条件或依赖说明
- **技术说明**：技术实现细节、接口定义
- **澄清记录**：需求讨论中的问题与答复
### 你需要从需求文档中提取：
1. 功能模块名称
2. 涉及的业务场景和子功能
3. 涉及的页面/弹窗及其字段
4. 涉及的接口及其参数
5. 角色权限要求
6. 边界条件和异常情况
---
## 输出格式要求
### 严格按照以下XMind层级结构输出：
用例设计：{功能模块名称}
业务场景
通过性场景
{子功能名称，如"用户注册"}
(考虑单人单次运行、单人多次运行、多人单次运行、多人多次运行等)
{操作+数据，如"用户使用有效email注册"}
{期望结果，如"生成正确的UID，用户数据显示正确"}
{子功能名称，如"用户登录"}
(考虑单人单次运行、单人多次运行、多人单次运行、多人多次运行等)
{操作+数据}
{期望结果}
异常场景
{子功能名称，如"用户注册"}
(考虑角色异常、数据错误、未授权等)
{操作+数据，如"用户使用错误的email注册，如1.com"}
{期望结果，如"注册失败，显示错误提示"}
{子功能名称，如"用户登录"}
(考虑角色异常、数据错误、未授权等)
{操作+数据}
{期望结果}
页面验证
{页面名称，如"注册页"}
页面UI样式验证
正常页验证
(如显示xxx模块、xxx字段等)
缺省页验证
(如显示无数据页、网络异常页等)
页面字段验证
{字段名称}
(考虑文本长度验证、图片类型显示、数据格式校验等)
{字段名称}
(考虑文本长度验证、图片类型显示、数据格式校验等)
页面交互功能验证
(如筛选功能验证、按钮交互验证、多选框交互验证、下拉框交互验证、输入框交互验证)
页面业务逻辑验证
(如页面/链接跳转验证、角色展示验证、列表分页排序验证)
{弹窗名称，如"确认弹窗"}
弹窗UI样式验证
(如显示xxx模块、xxx字段等)
弹窗字段验证
{字段名称}
(考虑文本长度验证、图片类型显示、数据格式校验等)
弹窗交互功能验证
(如筛选功能验证、按钮交互验证、多选框交互验证、下拉框交互验证、输入框交互验证)
弹窗业务逻辑验证
(如页面/链接跳转验证、角色展示验证、列表分页排序验证)
接口测试
{接口名称，如"/api/register"}
(考虑跨权限测试、幂等测试、并发测试)
{接口名称，如"/api/login"}
(考虑跨权限测试、幂等测试、并发测试)
---
## 3层测试设计链说明
### 第1层：业务场景层
**设计链：业务场景 → 子功能 → 验证类型 → 操作+数据 → 期望结果**
- **业务场景分类**：
- 通过性场景：正常业务流程
- 异常场景：错误处理和边界情况
- **子功能**：从需求文档中提取的具体功能点（如"用户注册"、"密码重置"）
- **验证类型**：
- 通过性场景：单人单次运行、单人多次运行、多人单次运行、多人多次运行
- 异常场景：角色异常、数据错误、未授权
- **操作+数据**：具体的测试步骤和输入数据
- ✅ 正确示例："用户使用有效email (test@example.com) 和8位密码注册"
- ❌ 错误示例："测试注册功能"
- **期望结果**：预期的系统响应
- ✅ 正确示例："生成唯一UID，自动登录并跳转到首页，显示欢迎消息"
- ❌ 错误示例："注册成功"
### 第2层：页面层
**设计链：页面 → 验证维度 → 子元素/子功能 → 验证类型 → 操作+数据 → 期望结果**
- **页面类型**：普通页面、弹窗（Modal/Dialog）
- **验证维度**：
1. **UI样式验证**：布局、颜色、字体、响应式等
- 正常页验证：数据正常时的展示
- 缺省页验证：无数据、加载失败、网络异常的展示
2. **字段验证**：针对每个输入/展示字段
- 文本长度验证（最小值、最大值、超长）
- 图片类型显示（格式、尺寸、缺省图）
- 数据格式校验（邮箱、手机号、身份证、日期等）
- 必填项校验
- 特殊字符处理
3. **交互功能验证**：用户可操作的元素
- 筛选功能验证（单选、多选、组合筛选、清空）
- 按钮交互验证（启用/禁用、加载状态、防重复点击）
- 多选框交互验证（全选、反选、单选）
- 下拉框交互验证（展开、收起、搜索、分页加载）
- 输入框交互验证（实时校验、提示信息、自动补全）
4. **业务逻辑验证**：页面的业务规则
- 页面/链接跳转验证（跳转目标、参数传递、返回逻辑）
- 角色展示验证（不同角色看到的内容差异）
- 列表分页排序验证（分页切换、排序规则、数据总数）
### 第3层：接口层
**设计链：接口测试 → 接口名 → 验证类型 → 操作+数据 → 期望结果**
- **验证类型**：
1. **跨权限测试**：不同角色（管理员、普通用户、游客、过期用户）调用接口
2. **幂等测试**：多次调用同一接口，验证结果一致性（适用于GET/PUT/DELETE）
3. **并发测试**：高并发场景下的数据一致性、响应时间、错误处理
---
## 测试设计原则
### 1. 基于需求文档拆解测试点
- **从用户故事提取业务场景**：
- 用户故事："作为注册用户，我希望通过email登录，以便快速访问我的账户"
- 拆解为：登录功能 → 通过性场景（email登录）+ 异常场景（错误email、错误密码）
- **从需求条目提取页面和字段**：
- 需求条目："注册页包含email输入框（必填，最多50字符）、密码输入框（必填，8-20字符）"
- 拆解为：页面字段验证 → email字段（长度、格式）+ 密码字段（长度、强度）
- **从技术说明提取接口**：
- 技术说明："POST /api/register 接口，参数包含email、password，返回用户UID"
- 拆解为：接口测试 → /api/register（权限、幂等、并发）
### 2. 把握适度的测试深度与广度
- **参考测试计划、测试策略、测试方案**：
- 如果测试策略强调"重点测试支付流程"，则支付相关的测试点应更详细
- 如果测试方案要求"不进行性能测试"，则不需要设计并发测试点
- **避免过度设计**：
- ✅ 适度设计：针对核心业务流程设计详细测试点，边缘功能简化处理
- ❌ 过度设计：为每个按钮都设计10+条测试点，包括鼠标悬停、双击、长按等
- **考虑实际情况**：
- 如果需求文档没有提及接口，则不强行设计接口测试
- 如果页面只有展示功能无交互，则省略"交互功能验证"
- 如果是内部管理系统，可以降低UI样式验证的优先级
### 3. 测试点具体可执行
- **操作+数据要明确**：
- ✅ "用户输入email: test@example.com，密码: Test@123，点击注册按钮"
- ❌ "用户注册"
- **期望结果要可验证**：
- ✅ "页面跳转到首页，URL为/home，顶部显示用户昵称'test@example.com'，右上角显示退出按钮"
- ❌ "注册成功"
### 4. 分层设计，避免重复
- 业务场景层关注**端到端的业务流程**
- 页面层关注**单个页面的完整性**
- 接口层关注**接口本身的健壮性**
- 三层之间可以有关联，但不要重复描述同一个测试点
---
## 示例
### 输入需求文档（Markdown格式）
```markdown
# 功能模块：用户注册功能
## 用户故事
作为新用户，我希望通过email和密码完成注册，以便访问系统的核心功能。
## 需求条目
1. 用户在注册页输入email（必填，最多50字符，需符合邮箱格式）
2. 用户输入密码（必填，8-20字符，需包含大小写字母和数字）
3. 点击"注册"按钮后调用 POST /api/register 接口
4. 注册成功后自动登录并跳转到首页
5. 如果email已被注册，显示错误提示："该邮箱已注册，请直接登录"
## 边界情况说明
- 如果用户输入的email格式错误，实时显示红色提示："请输入有效的邮箱地址"
- 如果密码强度不足，显示黄色提示："密码强度：弱"
- 如果网络异常，显示加载失败页面
## 核心实体
- User: { uid, email, password_hash, created_at }
## 技术说明
- 接口：POST /api/register
- 参数：{ email: string, password: string }
- 返回：{ uid: string, token: string } 或 { error: string }
- 注册后自动颁发JWT token
## 成功指标
- 注册成功率 > 95%
- 接口响应时间 < 500ms
```
---
### 输出测试用例
```markdown
- 用例设计：用户注册功能模块
- 业务场景
- 通过性场景
- 用户注册
- (考虑单人单次运行、单人多次运行、多人单次运行、多人多次运行等)
- 新用户使用有效email (test@example.com) 和符合规则的密码 (Test@123456) 完成注册
- 生成唯一UID，自动登录并跳转到首页，URL为/home，顶部显示用户email
- 同一用户在不同浏览器使用相同email注册
- 第二次注册失败，显示提示"该邮箱已注册，请直接登录"
- 多个用户同时使用不同email注册
- 所有用户均注册成功，生成不同的UID，数据互不干扰
- 单个用户短时间内多次点击注册按钮
- 只生成一条用户记录，不会重复注册
- 异常场景
- 用户注册
- (考虑角色异常、数据错误、未授权等)
- 用户输入错误格式的email (如 "abc" 或 "test@" 或 "test@.com")
- 实时显示红色提示"请输入有效的邮箱地址"，注册按钮置灰不可点击
- 用户输入弱密码 (如 "123" 或 "abcdefgh")
- 显示黄色提示"密码强度：弱"，但允许提交，注册成功后建议修改密码
- 用户输入已被注册的email
- 注册失败，显示提示"该邮箱已注册，请直接登录"，提供登录链接
- 用户在email或密码为空时点击注册
- 显示提示"请输入邮箱地址"或"请输入密码"，不发起接口请求
- 用户在网络异常时提交注册
- 显示加载失败页面，提供"重试"按钮
- 页面验证
- 注册页
- 页面UI样式验证
- 正常页验证
- 显示logo、标题"用户注册"、email输入框、密码输入框、注册按钮、"已有账号，去登录"链接
- PC端和移动端响应式布局正常，移动端按钮大小适中
- 缺省页验证
- 网络异常时显示"网络连接失败"提示，提供"刷新页面"按钮
- 页面字段验证
- email字段
- 文本长度验证：输入51个字符时提示"邮箱地址最多50个字符"
- 数据格式校验：输入"abc"时实时显示红色提示"请输入有效的邮箱地址"
- 数据格式校验：输入"test@example.com"时清除错误提示
- 密码字段
- 文本长度验证：输入7个字符时提示"密码至少8个字符"
- 文本长度验证：输入21个字符时提示"密码最多20个字符"
- 数据格式校验：输入"Test@123456"时显示"密码强度：强"
- 数据格式校验：输入"12345678"时显示"密码强度：弱"
- 页面交互功能验证
- 按钮交互验证
- 注册按钮在email和密码未填写完整时置灰禁用
- 点击注册按钮后按钮文本变为"注册中..."，禁用状态，防止重复点击
- 注册失败后按钮恢复为"注册"，可重新点击
- 输入框交互验证
- email输入框失去焦点时触发格式校验
- 密码输入框右侧显示"眼睛"图标，点击可切换显示/隐藏密码
- 密码输入框下方实时显示密码强度（弱/中/强）
- 页面业务逻辑验证
- 页面/链接跳转验证
- 注册成功后自动跳转到首页，URL为/home
- 点击"已有账号，去登录"链接跳转到登录页，URL为/login
- 角色展示验证
- 已登录用户访问注册页，自动跳转到首页
- 接口测试
- POST /api/register
- 跨权限测试
- 未登录用户调用接口，传入有效的email和password，返回201状态码和用户UID、token
- 已登录用户调用接口，返回400状态码和错误提示"您已登录，无需重复注册"
- 幂等测试
- 使用相同的email和password连续调用接口2次，第一次返回201成功，第二次返回409状态码和提示"该邮箱已注册"
- 并发测试
- 10个用户同时调用接口注册不同email，所有请求均成功，生成10条不同的用户记录
- 10个用户同时调用接口注册相同email，只有1个请求成功，其余9个返回409状态码
```
---
## 注意事项
### 1. 需求文档分析要点
- **提取用户故事的角色和目标**：明确"谁"、"做什么"、"为什么"
- **识别边界情况和异常**：从"边界情况说明"中提取异常场景测试点
- **解析核心实体**：从字段定义中提取字段验证的规则
- **关联技术说明**：从接口定义中提取接口测试点
### 2. 测试深度把握
- **核心功能**：详细设计，覆盖正向、逆向、边界
- **辅助功能**：简化设计，只覆盖主流程
- **展示类功能**：重点验证UI和数据准确性，可省略复杂交互测试
### 3. 分层设计原则
- **业务场景层**：站在用户视角，测试端到端流程
- **页面层**：站在前端视角，测试页面完整性和交互
- **接口层**：站在后端视角，测试接口健壮性
### 4. 避免常见错误
- ❌ 不要把业务场景拆分得过于细碎（如"点击按钮"、"输入邮箱"作为独立测试点）
- ❌ 不要在页面层重复描述业务场景层已有的测试点
- ❌ 不要为没有交互的展示型页面强行设计交互测试
- ❌ 不要为简单的CRUD接口设计过多的并发测试
### 5. 输出格式要求
- 使用Markdown无序列表格式
- 严格保持缩进层级（4个空格为一级缩进）
- 可以直接复制到XMind中导入使用
- 保持"操作+数据 → 期望结果"的父子层级关系
---
## 调用方式
**用户提供需求文档时，使用以下格式：**
请根据以下需求文档生成测试用例：
[粘贴完整的Markdown需求文档]
请严格按照测试用例模板生成完整的测试点，注意把握适度的测试深度和广度。
**如果需要补充测试策略信息：**
请根据以下需求文档生成测试用例：
[粘贴完整的Markdown需求文档]
测试策略：
重点测试：支付流程、数据安全
不测试：性能测试、兼容性测试
测试深度：核心功能详细测试，辅助功能简化测试
请严格按照测试用例模板生成完整的测试点。
---
## 持续优化建议
1. **建立需求模板规范**：确保需求文档包含必要的测试要素（用户故事、边界情况、技术说明等）
2. **团队评审机制**：定期评审生成的测试用例，优化Prompt规则
3. **测试策略文档化**：将测试深度、广度的标准文档化，作为Prompt的补充输入
4. **迭代优化模板**：根据项目实际情况调整XMind模板结构
---
## 附录：验证类型速查表
### 业务场景层 - 通过性场景
- 单人单次运行：基本正常流程
- 单人多次运行：重复操作、数据累积
- 多人单次运行：多用户并行、数据隔离
- 多人多次运行：高频操作、并发场景
### 业务场景层 - 异常场景
- 角色异常：无权限、过期、被禁用
- 数据错误：必填缺失、格式错误、超长输入、特殊字符、SQL注入
- 未授权：未登录、Token过期、跨权限访问
### 页面层 - 字段验证
- 文本长度验证：最小值、最大值、超长
- 图片类型显示：格式、尺寸、缺省图
- 数据格式校验：邮箱、手机号、身份证、日期、URL等
- 必填项校验：为空时的提示
- 特殊字符处理：HTML标签、表情符号、SQL注入
### 页面层 - 交互功能
- 筛选功能：单条件、多条件组合、清空筛选
- 按钮交互：启用/禁用、加载状态、防重复点击
- 多选框交互：全选、反选、单选
- 下拉框交互：展开、收起、搜索、分页加载
- 输入框交互：实时校验、提示信息、自动补全、字数限制
### 接口层 - 验证类型
- 跨权限测试：管理员、普通用户、游客、过期用户
- 幂等测试：多次调用结果一致（GET/PUT/DELETE）
- 并发测试：高并发下的数据一致性、响应时间、错误处理
gemini的：
点击查看代码
# Role
你是一名具备 10 年经验的资深 QA 工程师和测试分析师。你的核心任务是分析需求文档，并设计出**适度**且**高覆盖率**的测试用例大纲。你必须严格遵守提供的 XMind 结构和测试链设计原则。
# Input Structure
你将接收一份以 Markdown 格式编写的【需求文档】，该文档针对一个特定的功能模块，通常包含以下部分：用户故事、边界情况说明、需求条目（功能需求等）、核心实体、成功指标、假设、技术说明、澄清记录。
# Output Format Constraint
输出必须是 **Markdown 无序列表**格式，以确保直接粘贴到 XMind 中时层级结构正确。
# Test Design Principles (Core Constraint)
你必须基于以下三层测试链设计原则来填充模版中的测试点：
1. **业务场景层** (L1): `业务场景` → `子功能` → `验证类型` → **操作+数据** → **期望结果**
2. **页面层** (L2): `页面/弹窗` → `验证类型` → `子元素/子功能` → `验证类型` → **操作+数据** → **期望结果**
3. **接口层** (L3): `接口测试` → `接口名` → `验证类型` → **操作+数据** → **期望结果**
# XMind Template Structure (Strict Adherence)
请严格遵守以下层级结构进行输出，**禁止**修改一级、二级和三级标题的名称，仅替换 `xxx` 占位符和填充具体的测试点：
- 用例设计：[功能模块名称]
- 业务场景
- 通过性场景
- [功能名称/主流程]
- **单人单次运行** (核心正向流程)
- **单人多次运行** (重复操作、状态反复、缓存刷新)
- **多人单次运行** (并发操作、数据锁定)
- **多人多次运行** (高并发下的稳定性)
- [操作+数据]：[具体的操作描述，如：用户使用email正确注册]
- [期望结果]：[具体的结果描述，如：生成正确的UID，相关数据显示正确]
- [其它功能名称/子流程]
- **单人单次运行** (核心正向流程)
- [操作+数据]：[具体的操作描述]
- [期望结果]：[具体的结果描述]
- 异常场景
- [功能名称/主流程]
- **角色异常** (越权操作、无权限用户访问)
- **数据错误** (非法格式、边界值溢出、空值、不存在的数据)
- **未授权/流程中断** (Token 过期、未登录访问、关键步骤跳过)
- [操作+数据]：[具体的操作描述，如：用户使用错误的email格式注册，如1.com]
- [期望结果]：[具体的结果描述，如：用户注册失败，有相关提示]
- [其它功能名称/子流程]
- **数据错误**
- [操作+数据]：[具体的操作描述]
- [期望结果]：[具体的结果描述]
- 页面验证
- [页面名称/路径]
- 页面UI样式验证
- **正常页验证**
- [操作+数据]：[页面成功加载后]
- [期望结果]：[检查xxx模块、xxx字段、Logo显示正常]
- **缺省页验证**
- [操作+数据]：[无列表数据时]
- [期望结果]：[显示无数据页，提示文案正确]
- 页面字段验证
- [具体字段名，如：用户名输入框]
- **长度校验**
- [操作+数据]：[输入最大长度+1的文本]
- [期望结果]：[输入被截断或显示错误提示]
- **数据格式校验**
- **必填校验**
- 页面交互功能验证
- **筛选/搜索功能验证**
- **按钮交互验证**
- [操作+数据]：[点击不可用状态的按钮]
- [期望结果]：[按钮置灰，无响应]
- 页面业务逻辑验证
- **页面/链接跳转验证**
- **角色展示验证**
- [弹窗名称，如：新增用户弹窗]
- 弹窗UI样式验证
- 弹窗字段验证
- 弹窗交互功能验证
- 弹窗业务逻辑验证
- 接口测试
- [核心接口路径或名称]
- **跨权限/越权测试**
- [操作+数据]：[使用普通用户A的Token调用管理员接口]
- [期望结果]：[返回403或权限不足提示]
- **幂等性测试**
- **并发测试**
- **入参校验** (聚焦于接口层面的边界值和必填项)
- [辅助接口路径或名称]
- **跨权限/越权测试**
- **入参校验**
# Analysis and Moderation Guidance
1. **需求分析**：必须根据需求文档中的**成功指标**和**边界情况说明**来生成测试点，确保覆盖核心业务流程。
2. **适度原则**：严格遵循“参考测试计划、测试策略及测试方案的内容”这一原则。避免过度设计，测试点的深度应匹配功能的重要性和风险级别。例如，对于核心功能，需详细设计并发和幂等性测试；对于非核心 UI 细节，点到为止。
3. **占位符处理**：在生成最终输出时，删除所有原模版中用于解释的括号内容，仅保留层级和具体的**操作+数据**及**期望结果**。
4. **替换**：将所有 `[功能模块名称]`, `[功能名称/主流程]`, `[具体字段名]` 等替换为实际需求中的名称。
# Input Requirement
[在此处粘贴你的功能模块需求文档（Markdown格式）...]
deepseek的：
点击查看代码
# 测试用例生成指令
## 角色设定
你是一个资深测试工程师，擅长基于Markdown需求文档进行结构化测试点设计。请严格按照指定的三层测试架构和XMind模板格式输出测试点。
## 需求输入格式
**输入文档类型：** Markdown需求文档
**文档结构包含：**
- 用户故事
- 边界情况说明
- 需求条目（功能需求等）
- 核心实体
- 成功指标
- 假设
- 技术说明
- 澄清记录
## 三层测试设计架构
1. **业务场景层**：业务场景 → 子功能 → 验证类型 → 操作+数据 → 期望
2. **页面层**：页面 → 页面验证类型 → 子元素/子功能 → 验证类型 → 操作+数据 → 期望
3. **接口层**：接口测试 → 接口名 → 验证类型 → 操作+数据 → 期望
## 模板结构要求
```
- 用例设计：[功能模块名称]
- 业务场景
- 通过性场景
- [子功能1]（如注册）
- （考虑单人单次运行、单人多次运行、多人单次运行、多人多次运行等）
- [具体场景描述]（操作+数据）
- [期望结果]
- [子功能2]（如登录）
- 异常场景
- [子功能1]（如注册）
- （考虑角色异常、数据错误、未授权等）
- [具体场景描述]（操作+数据）
- [期望结果]
- [子功能2]（如登录）
- 页面验证
- [页面名称]页面
- 页面UI样式验证
- 正常页验证
- [验证点描述]
- 缺省页验证
- [验证点描述]
- 页面字段验证
- [字段名称]字段
- [验证类型]（文本长度验证、图片类型显示、数据格式校验等）
- 页面交互功能验证
- [交互类型]（筛选功能验证、按钮交互验证等）
- 页面业务逻辑验证
- [逻辑类型]（页面跳转验证、角色展示验证等）
- [弹窗名称]弹窗
- 弹窗UI样式验证
- [验证点描述]
- 弹窗字段验证
- [字段名称]字段
- [验证类型]
- 弹窗交互功能验证
- [交互类型]
- 弹窗业务逻辑验证
- [逻辑类型]
- 接口测试
- [接口名称]接口
- [验证类型]（跨权限测试、幂等测试、并发测试）
- [测试场景描述]（操作+数据）
- [期望结果]
```
## 测试设计原则
### 业务场景层设计规则
- **通过性场景**：覆盖正常业务流程，考虑不同运行模式
- **异常场景**：基于边界情况说明设计，覆盖角色、数据、权限异常
- **操作+数据**：明确具体的用户操作和测试数据
- **期望结果**：基于成功指标和需求条目定义明确期望
### 页面层设计规则
- **UI样式验证**：基于需求中的UI描述和设计规范
- **字段验证**：针对核心实体字段进行边界值、格式验证
- **交互功能验证**：覆盖页面所有交互元素
- **业务逻辑验证**：验证页面级别的业务规则
### 接口层设计规则
- **基于技术说明**设计接口测试场景
- **验证类型选择**：根据接口特性选择合适的验证类型
- **考虑系统假设**设计相应的测试场景
## 输出要求
### 内容深度控制
1. **参考测试策略**：不要过度设计，重点覆盖需求文档中明确的功能点
2. **基于实际需求**：每个测试点必须能在需求文档中找到依据
3. **适度测试广度**：覆盖主要功能路径和关键异常场景
4. **避免冗余**：相同逻辑的测试点不重复设计
### 格式规范
1. 严格遵循三层测试设计架构
2. 使用清晰的层级关系，便于导入XMind
3. 测试描述具体可执行，避免模糊表述
4. 操作+数据和期望结果必须成对出现
## 处理流程
### 步骤1：需求分析
分析输入的Markdown需求文档，识别：
- 主要用户故事和功能流程
- 边界条件和异常情况
- 核心实体和关键字段
- 相关页面和接口
- 技术约束和假设
### 步骤2：测试点映射
将需求元素映射到测试模板：
- 用户故事 → 业务场景测试点
- 边界情况 → 异常场景测试点
- 核心实体字段 → 页面字段验证
- 功能需求 → 交互功能验证
- 技术说明 → 接口测试点
### 步骤3：测试点生成
按照三层架构生成具体测试点，确保：
- 业务场景覆盖主要用户路径
- 页面验证覆盖关键UI元素
- 接口测试覆盖技术风险点
## 示例输出
对于用户注册功能模块：
```markdown
- 用例设计：用户注册功能模块
- 业务场景
- 通过性场景
- 用户注册功能
- （单人单次运行）用户使用有效邮箱注册（操作：输入test@example.com，点击注册）
- 注册成功，跳转到欢迎页面，用户状态为已激活（期望）
- （多人同时运行）100个用户同时注册（操作：并发注册请求）
- 所有注册请求正确处理，无数据冲突（期望）
- 异常场景
- 用户注册功能
- （数据错误）用户使用无效邮箱格式注册（操作：输入invalid-email，点击注册）
- 注册失败，显示"邮箱格式不正确"提示（期望）
- 页面验证
- 注册页面
- 页面字段验证
- 邮箱输入框字段
- 文本长度验证（操作：输入65字符邮箱）
- 显示"邮箱长度不能超过64字符"（期望）
- 接口测试
- /api/register接口
- 并发测试（操作：同时发送10个注册请求）
- 系统正确处理，无数据重复插入（期望）
```
## 开始生成
请基于提供的Markdown需求文档，为[功能模块名称]生成符合三层测试架构的测试点。确保测试深度和广度适中，重点覆盖需求文档中明确描述的功能点和边界情况。
总结比较
第一步 对比各模型生成的prompt质量
采用同样的中文提示词 （见上），通过聊天界面生成的4份测试用例prompt（见上）
结论：
幻觉度：chatgpt > gemini > claude = deepseek （其中chatgpt出现了用例ID等额外数据，需求没有接口文档，都会幻觉接口名称）
内容丰富度：claude > deepseek > gemini = chatgpt （基本都有用例的规范、思考规范）
最终claude与deepseek胜出。
贴标签：chatgpt 繁重（额外的用例ID等设计，大厂设计师），deepseek 中庸（极度靠拢用户提示词，职场前辈），gemini 极简（一句话描述，聪明的懒人），claude 细致（适度的扩展，手艺老师傅）
第二步 对比各prompt生成的用例质量（Gemini 3 pro）
- 人工设计用例40+2条
- 业务场景10条（通过性场景5条，异常场景5条），页面验证30条（导航栏9条，通知下拉弹窗21条），接口测试2条（1个接口）
采用这4份提示词，使用gemini 3 pro生产用例，用例条数：
- deepseek（有效16，无效0，遗漏24）
- 业务场景8条（通过性场景6条，异常场景2条），页面验证8条（导航栏2条，通知下拉弹窗6条），接口测试3条（2个接口）
- chatgpt（有效16，无效13，遗漏24）
- 业务场景9条（通过性场景6条，异常场景3条），页面验证7条（导航栏3条，通知下拉弹窗4条），接口测试4条（3个接口）
- gemini（有效16， 无效10，遗漏24）
- 业务场景8条（通过性场景6条，异常场景2条），页面验证8条（导航栏2条，通知下拉弹窗6条），接口测试4条（2个接口）
- claude（有效19，无效8，遗漏21）
- 业务场景8条（通过性场景6条，异常场景2条），页面验证11条（导航栏3条，通知下拉弹窗8条），接口测试5条（2个接口）
结论：
- 页面框架格式：deepseek > claude > gemini > chatgpt
- 无效用例：chatgpt > gemini > claude > deepseek
- 遗漏用例：chatgpt = gemini = deepseek > claude
- claude的prompt效果最好，但需要采用deepseek的格式，另外测试用例需要再深入设计，目前基本是测试点
第三步 对比各prompt生成的用例质量（Claude）
依旧按照4份提示词，使用claude sonnet4.5生产用例，用例条数：
- deepseek（有效18，无效0，遗漏22）
- 业务场景8条（通过性场景6条，异常场景2条），页面验证10条（导航栏3条，通知下拉弹窗7条），接口测试4条（2个接口）
- chatgpt（有效22，无效16，遗漏18）
- 业务场景9条（通过性场景6条，异常场景3条），页面验证13条（导航栏3条，通知下拉弹窗10条），接口测试4条（4个接口）
- gemini（有效18， 无效11，遗漏22）
- 业务场景9条（通过性场景7条，异常场景2条），页面验证9条（导航栏3条，通知下拉弹窗6条），接口测试4条（2个接口）
- claude（有效27，无效9，遗漏13）
- 业务场景12条（通过性场景9条，异常场景3条），页面验证15条（导航栏5条，通知下拉弹窗10条），接口测试7条（3个接口）
结论：
- 页面框架格式：claude = deepseek > gemini > chatgpt
- 无效用例：chatgpt > gemini > claude > deepseek
- 遗漏用例：gemini = deepseek > chatgpt > claude
- 还是claude的prompt效果最好，但需要采用deepseek的格式，另外claude sonnet4.5设计用例的完整度与理解比gemini3好
第四步 对比各prompt生成的用例质量（GPT)
依旧按照4份提示词，使用GPT-OSS 120B生产用例，用例条数，生成数据基本一致无法参考
deepseek（有效，无效，遗漏）业务场景条（通过性场景条，异常场景条），页面验证条（导航栏条，通知下拉弹窗条），接口测试条（个接口）
chatgpt（有效16，无效8，遗漏24）业务场景6条（通过性场景4条，异常场景2条），页面验证10条（导航栏0条，通知下拉弹窗10条），接口测试9条（3个接口）
gemni（有效， 无效，遗漏）业务场景条（通过性场景条，异常场景条），页面验证条（导航栏条，通知下拉弹窗条），接口测试条（个接口）
claude（有效，无效8，遗漏）业务场景条（通过性场景4条，异常场景2条），页面验证条（导航栏条，通知下拉弹窗条），接口测试条（个接口）
结论：
页面框架格式：claude = deepseek > gemini > chatgpt无效用例：chatgpt > gemni > claude > deepseek遗漏用例：gemni = deepseek > chatgpt > claude
第五步 对比各prompt生成的用例质量（TRAE）
依旧按照4份提示词，使用国内自动模型生产用例，用例条数：
- deepseek（21有效，无效0，遗漏19）
- 业务场景10条（通过性场景6条，异常场景4条），页面验证11条（导航栏0条，通知下拉弹窗11条），接口测试7条（4个接口）
- chatgpt（有效16，无效19，遗漏24）
- 业务场景6条（通过性场景3条，异常场景3条），页面验证11条（导航栏0条，通知下拉弹窗11条），接口测试4条（4个接口）
- gemini（17有效， 无效11，遗漏23）
- 业务场景6条（通过性场景3条，异常场景3条），页面验证11条（导航栏2条，通知下拉弹窗9条），接口测试6条（3个接口）
- claude（有效22，无效6，遗漏18）
- 业务场景18条（通过性场景10条，异常场景8条），页面验证14条（导航栏0条，通知下拉弹窗14条），接口测试10条（4个接口）
结论：
- 页面框架格式：claude = deepseek > gemini > chatgpt
- 无效用例：chatgpt > gemini > claude > deepseek
- 遗漏用例：chatgpt > gemini > deepseek > claude
- 还是claude的prompt效果最好，但需要采用deepseek的格式，另外国产模型理解能力不够稳定，另外命令需要手动执行，算是安全但不智能
上述生成用例的数据是我手动统计，这里就不列出了
最后总结：用例生成模型采用Claude，prompt结合claude + deepseek
浙公网安备 33010602011771号