功能性测试用例标准

概述

本技能提供高质量功能性测试用例编写的标准指南，以及一个八维度测试用例质量评估框架。

核心功能：

• ✅ 标准化测试用例设计，包含15种以上设计方法
• ✅ 八维度质量评估框架，支持评分
• ✅ 使用5种分析方法进行深度需求解析
• ✅ 双输出格式：Markdown（默认）和 XMind 思维导图
• ✅ 两种导出模式：评审维度与执行维度
• ✅ 基于时间戳的版本管理，确保可追溯性

需求分析方法论

在设计测试用例前，需使用以下5种方法进行深度需求分析，以提取所有测试细节：

1. 逐句分析法

对需求文档中的每一句话进行分析，识别以下四类关键词：

• 条件词：如 if、when、unless、only if 等
• 动作词：如 click、input、select、submit、delete 等
• 状态词：如 display、hide、enable、disable、active、inactive 等
• 数据词：如 create、read、update、delete、calculate、validate 等

输出：每个识别出的元素转化为一个验证项。

示例：

• 需求描述：“当用户点击提交按钮时，若所有必填字段均已填写，则显示成功提示并跳转至订单列表。”
• 提取的验证点：

- 条件：所有必填字段已填写 → 使用有效/无效组合进行测试

- 动作：点击提交按钮 → 验证按钮是否可点击且响应正常

- 状态：显示成功提示 → 验证提示文本是否准确

- 数据：跳转至订单列表 → 验证页面跳转是否正确

2. 业务流程分析法

识别从开始到结束的完整业务流程：

• 流程节点：工作流中的每一步
• 决策分支：所有 if-else 或 switch 条件
• 异常退出点：错误处理、超时、取消、回滚等
• 并行流程：并发过程或独立分支

输出：每个节点和分支均生成一个测试场景。

示例（订单流程）：

• 节点1：创建订单 → 使用有效/无效商品进行测试
• 节点2：支付 → 测试支付成功、支付失败、超时情况
• 节点3：发货 → 测试有无库存情况下的发货行为
• 分支：支付失败 → 测试重试、取消、退款流程

3. 数据流分析法

追踪数据在其完整生命周期中的流转路径：

• 数据获取：数据来源？（用户输入、API、数据库、第三方系统）
• 数据处理：数据如何被转换？（计算、校验、格式化）
• 数据存储：数据保存位置？（数据库、缓存、文件、会话）
• 数据展示：数据如何呈现？（界面、报表、导出、通知）

输出：每个数据转换环节均成为验证项。

示例（用户注册）：

• 获取：用户输入用户名、邮箱、密码
• 处理：格式校验、密码加密、唯一性检查
• 存储：插入 users 表，同步至 CRM 系统
• 展示：显示成功提示，发送确认邮件

4. 状态转换分析法

将系统建模为有限状态机：

• 识别所有状态：如草稿、待审核、已批准、已拒绝、已完成、已取消等
• 识别转换条件：触发状态变化的事件或操作
• 识别合法转换：允许的状态变更
• 识别非法转换：禁止的状态变更（应提示错误）
• 识别自转换：操作后仍停留在同一状态

输出：每个合法与非法转换均生成一条测试用例。

示例（订单状态）：

• 合法转换：草稿 → 待审核（提交），待审核 → 已批准（审批通过），已批准 → 已发货（发货）
• 非法转换：草稿 → 已发货（跳过中间状态），已发货 → 待审核（逆向变更），已拒绝 → 已批准（未修改即重新审批）

5. 用户场景分析法

从不同用户视角进行分析：

• 不同角色：管理员、经理、普通用户、访客等
• 正常场景：主流程、典型使用路径
• 异常场景：错误处理、边界情况、异常状态
• 极端场景：高并发、大数据量、网络中断、系统超时

输出：每个角色与场景的组合生成一条测试用例。

示例（文件上传）：

• 管理员 + 正常场景：上传符合大小限制的有效文件
• 普通用户 + 异常场景：上传过大文件、格式错误
• 访客 + 极端场景：在网络超时期间上传，同时发起多个上传请求

需求分析工作流程

1. 仔细阅读需求文档（不得跳过任何部分）
2. 应用全部5种分析方法，提取测试细节
3. 整理结果，形成：

- 功能模块清单

- 业务规则清单

- 异常场景清单

- 测试数据清单

1. 结合测试设计方法，将上述内容映射为具体测试用例（详见“测试设计方法论”章节）

输出格式选择

本技能支持两种输出格式，用户可自行选择：

格式模式

导出维度

用户选择指南

生成前询问用户：

1. “您更倾向于哪种输出格式？（仅 Markdown / Markdown + XMind 思维导图）”
2. “您希望使用哪种导出维度？（评审维度用于覆盖分析 / 执行维度用于测试执行）”

默认行为：若用户未指定，以评审维度生成 Markdown 格式。

XMind 思维导图结构

评审维度结构：

产品需求名称
├── I. 模块名称
│   ├── 1.1 子功能名称
│   │   ├── 1.1.1 功能点
│   │   │   ├── 测试点：条件验证
│   │   │   │   ├── [ ] 验证项 1
│   │   │   │   ├── [ ] 验证项 2
│   │   │   │   └── [ ] 验证项 3
│   │   │   └── 测试点：业务规则验证
│   │   │       ├── [ ] 验证项 1
│   │   │       └── [ ] 验证项 2

执行维度结构：

产品需求名称
├── I. 模块名称
│   ├── 1.1 子功能名称
│   │   ├── TC-001: [模块][平台] 功能 - 条件 - 验证
│   │   │   ├── 前置条件：...
│   │   │   ├── 步骤
│   │   │   │   ├── 1. ...
│   │   │   │   ├── 2. ...
│   │   │   │   └── 3. ...
│   │   │   ├── 预期结果
│   │   │   │   ├── 1. ...
│   │   │   │   ├── 2. ...
│   │   │   │   └── 3. ...
│   │   │   └── 优先级：P0/P1/P2

版本管理

时间戳版本控制

每次生成测试用例时都会创建带版本号的文件，以支持可追溯性和历史对比。

文件命名规范：

{需求名称}-v{MMdd_HHmmss}.md
{需求名称}-v{MMdd_HHmmss}.xmind

时间戳格式：

• 格式：MMdd_HHmmss（月日_时分秒）
• 示例：0318_143052 表示 3 月 18 日 14:30:52

示例：

• 需求名称：“用户注册增强”
• 生成文件：

- user-registration-enhancement-v0318_143052.md

- user-registration-enhancement-v0318_143052.xmind（若请求生成 XMind 文件）

版本管理优势：

• ✅ 所有历史版本均被保留
• ✅ 可轻松对比不同版本之间的差异
• ✅ 支持追踪测试用例随时间的演进过程
• ✅ 必要时可回退至旧版本

版本对比：

当用户请求对比多个版本时：

1. 列出所有可用版本及其时间戳
2. 展示差异内容：测试用例数量变化、覆盖范围变动、优先级调整
3. 标注新增、修改、删除的测试用例

设计原则

功能项作为基本单元

按功能项设计测试用例。将具有相似业务或操作特性的功能点归类为“功能项”——每个功能项包含一个或多个相似的功能点。针对某一功能项，输入一组特定数据或操作序列，并验证该功能项内各功能点对应的唯一输出结果。

核心原则

1. 操作粒度清晰：每个测试用例聚焦于一组相似的功能项。步骤必须明确，目标清晰。
2. 输入输出一一对应：为功能项定义唯一的输入集合，并严格验证对应的输出结果。确保测试覆盖和结果判断均无歧义。
3. 边界清晰：功能项之间界限分明。禁止跨功能项测试。避免冗余和重复操作。
4. 用例独立：每个测试用例应自成一体，不依赖其他用例。功能项间边界清晰有助于减少冗余，提升可维护性。

分层测试策略（测试金字塔）

理解测试层级划分，避免过度依赖单一类型的测试。该金字塔指导资源分配与功能测试的设计重点。

        /\
       /  \     端到端测试（数量少、速度慢、维护成本高）
      /----\    ————————————————————————————————————————
     /      \   接口/集成测试（数量适中、速度较快）
    /--------\  ————————————————————————————————————————
   /          \ 单元/组件测试（数量最多、速度最快、成本最低）
  /------------\

设计建议：

• 尽可能将测试向金字塔底层推进。
• 端到端测试应仅覆盖跨模块的关键路径和用户旅程。
• 接口测试应验证所有参数组合及异常响应。
• 单元测试应覆盖业务逻辑的所有分支和边界条件。

测试用例粒度

默认采用：二级粒度

等级 2 细粒度示例

需求：用户名限制：长度 6-20 位，仅允许小写字母和数字。

等级 2 用例：

• 名称：[用户管理][WEB] 用户注册 - 用户名长度验证
• 步骤：

1. 输入长度少于 6 个字符的用户名

2. 输入长度超过 20 个字符的用户名

• 预期结果：

1. 显示错误提示：“用户名必须在 6-20 个字符之间”

2. 显示错误提示：“用户名必须在 6-20 个字符之间”

更多细粒度示例，请参见 [reference.md](reference.md)。

命名规范

统一格式：[模块][平台] 功能 - 条件 - 验证点

• 模块：业务模块名称（如：用户管理、订单处理）
• 平台：WEB / APP / H5 / API
• 功能：被测的功能项
• 条件：具体的输入条件或规则
• 验证点：被测试的验证点或操作

命名原则：

• 使用功能项的输入条件作为命名描述，保持简洁。
• 应包含具体输入；预期结果可选，避免名称过长。
• 避免使用“验证”“测试”等模糊词汇。

示例：

• [反馈][APP] 反馈创建 - 内容 - 长度验证
• [促销][WEB] 红包活动 - 手动停止 - 影响验证
• [户外广告管理][WEB] 广告文件导入 - 模板 - 销售区域3 必填字段

用例 ID

格式：主模块_子模块_序号

• 示例：user_reg_001、order_create_014、product_import_005
• 在项目内必须唯一
• 应体现模块层级结构，便于定位

必填字段

用例类型定义

测试设计方法

设计方法分为 5 类，根据功能项特性选择合适的方法。

1. 输入域方法

• 等价类划分：将输入域划分为有效和无效等价类，每类测试一个代表性值。
• 边界值分析：测试边界值（最小值、最大值、最小值-1、最大值+1、典型值、空/空值）。

适用场景：表单字段、数值范围、长度限制、日期范围、枚举值。

2. 组合方法

• 决策表：当多个条件相互作用产生不同行为时使用。列出所有条件组合。
• 因果图法：建立原因与结果之间的映射关系，包含约束（AND、OR、NOT、M、O、R、I）。
• 正交试验：使用正交数组将多维组合爆炸问题简化为代表性子集。
• 配对测试：测试所有参数值的两两组合（Pairwise / n-wise）。

适用场景：多字段表单、配置组合、筛选组合、权限矩阵。

3. 流程与状态方法

• 场景测试：基于业务流程设计测试场景（正常流程、替代流程、异常流程）。
• 状态转换测试：将系统建模为有限状态机，测试所有合法转换、非法转换及自转换。
• 业务流程图法：从业务流程图（BPMN）中推导测试路径。

适用场景：审批流程、订单生命周期、有状态实体、多步骤操作。

4. 经验驱动方法

• 错误猜测法：基于历史缺陷数据和经验，预测可能的故障点，并设计针对性的测试用例。

适用场景：复杂遗留系统、历史缺陷密度高的区域、已修复缺陷的回归测试。

5. 现代测试方法

• 风险导向测试：计算风险评分 = 影响程度 × 发生概率。根据风险优先级分配测试资源。可使用 FMEA 进行系统性分析。
• 数据驱动测试：将测试逻辑与测试数据分离。数据存储于 CSV/Excel/数据库中。同一测试用例可使用多组数据执行。
• 关键字驱动测试：将操作抽象为可复用的关键字（如“登录”、“搜索”、“验证”）。
• 模型驱动测试：从状态机、决策树或 AI 模型生成测试用例。
• 模糊测试（Fuzzing）：使用随机、畸形或意外输入作为测试数据，覆盖边界情况。
• 属性驱动测试：定义不变性质（如“排序输出必须有序”），并生成测试数据验证这些性质。

适用场景：回归测试用例设计、复杂有状态系统的测试设计。

方法选择指南

字段规则

前置条件

• 若无前置条件则无需填写。
• 必须包含：账号角色、权限、系统数据状态或特定测试数据。
• 若用例无法在无特定条件下执行，必须明确记录。

测试步骤

• 步骤编号按顺序排列：1. 2. 3.
• 描述需具体到按钮名称、菜单路径、字段名称。
• 输入数据必须指定确切值。
• 对于二级粒度：每个步骤仅测试同一功能项内的一个边界/条件。
• 每个用例保持 2-5 个步骤；超过 7 步时应拆分。

预期结果

• 必须具体、可观测、可验证。
• 每个步骤对应一个预期结果。
• 包含操作过程中的状态变化。
• 避免使用“显示正确”、“运行正常”等模糊表述。
• 出现错误时，需包含完整的错误提示文本。
• 必须能独立判断通过或失败。

优先级分配

• P0 / 高：核心业务路径、阻塞性问题、主流程
• P1 / 中：重要功能、高频使用功能
• P2 / 低：通用功能、次要功能、边缘场景
• 不得将所有用例统一设置为单一优先级

测试数据策略

数据驱动测试

将测试逻辑与测试数据分离。数据存储于外部文件（CSV、Excel、JSON、数据库）。同一测试用例可使用多组数据执行。

适用场景：多种账户类型登录、不同有效/无效输入的表单提交、支持多种文件格式的批量导入。

模板：

| 数据集 | 输入 | 预期结果 |
|--------|------|----------|
| 有效-1 | "user01" | 成功 |
| 有效-2 | "user123456" | 成功 |
| 无效-1 | "" | 错误：用户名不能为空 |
| 无效-2 | "ab" | 错误：最小长度为6 |

参数化设计

对于仅输入值不同的用例，设计一个参数化用例：

• 使用占位符如 {username}、{password}、{amount}
• 在“测试数据”字段中记录参数约束
• 明确取值范围及边界值

Mock / Stub 策略

当依赖项在测试设计阶段不可用或不稳定时：

• 明确记录被模拟的外部系统
• 为正向和负向场景指定 mock 响应数据

用例生命周期

创建 -> 审查 -> 维护 -> 归档

维护触发条件

• 需求变更（功能或 UI）
• 生产环境发现未被现有用例覆盖的缺陷
• 测试数据或环境变更
• 流程优化（合并/拆分用例）

常用术语规范

团队内使用一致的术语：

8维度质量评估框架

对每位测试用例作者从以下 8 个维度进行评估（0-10 分制）：

1. 命名规范

• 9-10 分：>90% 符合 [模块][平台] 功能 - 条件 - 验证点 格式
• 7-8 分：60%-90% 符合格式，存在少量不一致
• 5-6 分：30%-60% 符合格式，风格混杂
• 3-4 分：<30% 符合格式，多为自由命名
• 0-2 分：无格式一致性，名称模糊不清

2. 结构完整性

• 9-10：所有用例均包含具体步骤和可验证的预期结果，必要时已填写前置条件
• 7-8：完成度超过80%，存在少量遗漏
• 5-6：完成度为50%-80%，存在明显缺失
• 3-4：完成度低于50%，大量字段为空
• 0-2：基本为模板框架，缺乏具体内容

3. 步骤可执行性

• 9-10：步骤明确指向按钮/字段/菜单，任何人可直接执行
• 7-8：大部分步骤具体，个别描述模糊
• 5-6：具体与模糊步骤混合
• 3-4：多数步骤模糊，难以一致执行
• 0-2：步骤为空或无意义

4. 预期结果可验证性

• 9-10：每一步均有具体、可量化、可观测的预期结果
• 7-8：大多数具备实质内容，少数描述模糊
• 5-6：约一半具体，另一半模糊或为空
• 3-4：多为模糊表述，如“显示正确”
• 0-2：预期结果为空或缺失

5. 测试设计方法多样性

• 9-10：使用了上述5类方法中的4种及以上
• 7-8：使用3种方法，覆盖良好
• 5-6：使用2种方法
• 3-4：主要依赖1种方法
• 0-2：未体现明显的设计方法

6. 正向/负向覆盖均衡性

• 9-10：正负向比例平衡（1:1 至 3:1），异常场景覆盖充分
• 7-8：比例为3:1 至 5:1，有一定异常覆盖
• 5-6：比例为5:1 至 10:1，异常覆盖有限
• 3-4：以正向用例为主，负向极少
• 0-2：几乎全部为正向用例

7. 优先级合理性

• 9-10：合理分布于 P0/P1/P2 或 高/中/低 优先级
• 7-8：整体合理，存在轻微失衡
• 5-6：明显失衡（例如某一级别占比超70%）
• 3-4：严重失衡（例如某一级别占比超90%）
• 0-2：所有用例优先级相同，无区分

8. 测试数据具体性

• 9-10：超过50%的用例包含具体输入值
• 7-8：30%-50%的用例包含具体值
• 5-6：10%-30%的用例包含具体值
• 3-4：少于10%的用例包含具体值
• 0-2：无具体测试数据，全部为模糊描述

评分公式

综合得分 = round(8个维度平均分, 1)

等级映射：

• 8.0-10.0：优秀（基准）
• 6.0-7.9：良好
• 4.0-5.9：需改进
• 0-3.9：较差

生成工作流

根据需求生成测试用例时，请遵循以下流程：

1. 询问用户偏好：

- 输出格式：仅 Markdown 或 Markdown + XMind？

- 导出维度：评审维度 或 执行维度？

1. 执行需求分析：

- 应用全部5种分析方法（逐句分析、业务流程、数据流、状态转换、用户场景）

- 提取：功能模块、业务规则、异常场景、测试数据

1. 设计测试用例：

- 从测试设计方法论部分选择合适的方法

- 默认采用 Level 2 细粒度

- 遵循命名规范和字段规则

1. 生成输出文件：

- 创建基于时间戳的文件名：{name}-v{MMdd_HHmmss}.md

- 若请求 XMind：同时生成 {name}-v{MMdd_HHmmss}.xmind

- 按选定维度（评审或执行）进行结构化组织

1. 自我审查：

- 运行编写检查清单

- 验证8维度质量标准

- 确保需求覆盖率 ≥ 95%

评估工作流

评估测试用例时，请按以下步骤操作：

1. 阅读测试用例文件并识别所有作者
2. 分析每位作者在8个维度上的表现，使用量化指标
3. 评分每个维度（0-10分），并附证据
4. 计算综合得分
5. 撰写评估报告，包含：

- 每位作者的得分表

- 每位作者的优势

- 每位作者的改进建议

- 团队共性问题

- 可操作的建议

用例模板

| 字段 | 值 |
|------|----|
| 用例ID | order_create_014 |
| 用例名称 | [订单管理][WEB] 订单创建 - 产品数量 - 边界值校验 |
| 项目 | 电商平台 |
| 版本 | V2.3.0 |
| 模块 | 订单处理 |
| 用例类型 | 功能测试用例 |
| 优先级 | P1 |
| 前置条件 | 1. 用户使用有效凭证登录<br>2. 库存中有可用商品 |
| 测试步骤 | 1. 进入订单管理 > 创建订单<br>2. 选择商品并输入数量为 0<br>3. 点击提交按钮<br>4. 输入数量为 999<br>5. 点击提交按钮 |
| 预期结果 | 1. 订单创建页面成功加载<br>2. 显示错误提示：“数量必须至少为1”<br>3. 显示错误提示：“单笔订单最大数量为100” |
| 后置条件 | 无 |

编写检查清单

提交测试用例前，请确认以下事项：

生成前确认项

• [ ] 与用户确认输出格式：仅 Markdown 或 Markdown + XMind？
• [ ] 与用户确认导出维度：评审维度 或 执行维度？
• [ ] 在设计用例前，已应用全部5种需求分析方法

基础完整性检查

• [ ] 命名符合 [模块][平台] 功能 - 条件 - 验证点 格式
• [ ] 用例ID符合 主模块_子模块_序号 格式
• [ ] 前置条件按需填写（不要盲目写“无”）
• [ ] 每步明确指定按钮/字段/菜单名称
• [ ] 每步均有对应的预期结果
• [ ] 预期结果具体且可验证（避免使用“正确”“正常”等模糊词）
• [ ] 优先级分布合理（不全为同一级别）
• [ ] 同时覆盖正向与负向用例
• [ ] 提供具体测试数据值
• [ ] 用例相互独立（执行顺序不影响结果）
• [ ] 默认采用 Level 2 细粒度（每条用例2-5步）
• [ ] 使用一致术语（创建/查询/编辑/删除/提交）

设计质量

• [ ] 至少应用了一种有意识的设计方法（等价类、边界值、场景等）
• [ ] 输入与输出映射为一对一关系（无模糊的预期结果）
• [ ] 数值型/长度型/日期型字段覆盖了边界值
• [ ] 文本字段测试了空值、null 值和空白字符输入
• [ ] 跨字段校验已覆盖（例如：开始日期 > 结束日期）
• [ ] 错误提示信息包含确切文本，而非仅“错误提示”类描述
• [ ] 状态变化已记录（前后状态明确）
• [ ] 数据持久性已验证（完成创建 → 查询 → 更新 → 删除 的完整流程）

分层与类型

• [ ] 设计时考虑了测试金字塔原则（并非所有用例均为端到端级别）
• [ ] API 用例覆盖所有参数组合及错误码
• [ ] UI 用例仅覆盖跨模块关键路径
• [ ] 冒烟用例标记为 P0，并覆盖主要业务流程

可维护性

• [ ] 用例可追溯至需求 ID
• [ ] 后置条件在适用时记录影响范围
• [ ] 测试数据可复现（不依赖随机的生产数据）
• [ ] 用例中不含随环境变化而改变的硬编码值

审查检查清单（用于同行评审）

评审者使用此清单验证用例质量：

审查项                                 通过  不通过  备注
─────────────────────────────────────────────────────────
命名符合标准格式                     □    □
ID 唯一且反映模块层级结构             □    □
前置条件描述充分                     □    □
步骤可执行（具体到 UI 元素）          □    □
预期结果可验证（具体明确）            □    □
优先级分配合理                       □    □
粒度适当（默认 Level 2）             □    □
正向/负向覆盖均衡                    □    □
测试数据具体明确                     □    □
设计方法可识别                       □    □
可追溯至需求                         □    □
─────────────────────────────────────────────────────────
审查结论：通过 / 需修改 / 失败
评审人：__________  日期：__________

额外资源

• 有关各维度详细评分标准，请参阅 [reference.md](reference.md)
• 有关真实测试用例的示例评估，请参阅 [examples.md](examples.md)
• 有关 XMind 格式规范及版本管理指南，请参阅 [reference.md](reference.md) 中的“XMind 格式规范”、“版本管理”章节
• 有关需求分析示例，请参阅 [reference.md](reference.md) 中的“深度需求分析示例”部分