功能测试用例编写模板

功能测试用例编写模板

适用范围

HIS 系统功能测试用例（页面操作类为主），统一格式，便于执行与回归。对齐现有「号源池功能测试用例」风格。

文件组织

• 一个功能模块一个 md 文件，命名 <模块>功能测试用例.md，如 号源池功能测试用例.md、门诊收费功能测试用例.md。
• 存放于 HIS测试/<模块>/ 下。

文档结构

# <模块名>功能测试用例（含页面操作）

## 一、<子功能1>
### 1.1 <子场景>
##### 【<优先级>】<序号>、<用例标题>

- **前置条件**：<必须满足的前提，如权限、数据、页面状态>
- **操作步骤**：
  1. <具体到点击/输入哪一项，菜单路径写全>
  2. ...
  3. ...

**预期结果**：

- <可判定的客观结果，每条一行>
- ...

##### 【<优先级>】<序号+1>、<下一用例标题>
...

优先级标记（写在标题前）

• 【P0】：核心主流程，必须通过，阻塞发布。
• 【P1】：重要功能/主要异常分支，应通过。
• 【P2】：次要功能、边界、体验类。
• 【P3】：建议项、极端边界。

编写要求

操作步骤

• 写到可执行的粒度：具体点哪个菜单、输入什么值、点哪个按钮，不要写成"测试一下新增"。
• 菜单路径完整：系统菜单 → 号源管理 → 号类管理。
• 输入值明确：用具体的测试数据（如号类名称"特需专家"），不要写"输入一个名称"。

预期结果

• 可判定：客观、可核对（如"列表显示 N 条""提示保存成功"），避免主观描述（如"显示正常"）。
• 多个结果用列表分行，逐条可勾选核对。
• 涉及数据的，说明在何处可验证（列表刷新、数据库、其他页面）。

前置条件

• 列出权限、基础数据、依赖页面状态。
• 涉及特定机构/角色的，注明（与多机构构建 orgName 对应）。

覆盖维度（每模块至少覆盖）

• 正向：标准业务主流程走通。
• 异常：必填校验、格式校验、权限不足、重复提交、网络失败。
• 边界：空、超长、特殊字符、0/负数、跨年跨月、并发。
• 多机构：不同 orgName 下差异点（如有）。
• 权限：有/无权限分别验证。

敏感数据

• 测试用的身份证、医保卡、手机号使用测试假数据，不得使用真实病人信息（见 security-anti-leak.md）。