测试用例详解

一、定义与核心价值

1. 什么是测试用例？

定义：为验证被测对象（系统/接口/组件/单元）功能是否符合预期，所设计的一组输入数据、操作步骤和预期结果的集合。
本质：测试工程师的执行指南（含环境准备、测试数据、操作流程、结果验证）。

类比：像菜谱一样清晰明确，任何测试人员按步骤执行都能得出确定结论。

2. 为什么需要测试用例？

价值点	说明	项目案例
防遗漏	明确测试范围，避免功能点遗漏	电商支付流程未测退款接口导致线上故障
防重复	减少无效测试，提升效率	避免多人在不同模块重复测试登录功能
需求验证	编写时发现需求文档缺陷	需求中“折扣计算规则”描述模糊
进度可控	通过用例量估算工作量和排期	依据500条用例评估2周测试周期
知识传承	新人快速接手，降低人员变动风险	离职交接后新员工3天熟悉测试流程

---

二、测试用例设计规范（八大要素）

原则：根据实际项目需求对要素剪裁，保持与需求的双向追溯

要素	说明	示例
1. 用例编号	唯一标识符，体现层级关系	ECOM-ST-FUNC-Login-001（电商项目-系统测试-功能-登录模块-001号用例）
2. 测试项	用例分类/功能模块名	“用户登录验证”、“购物车价格计算”
3. 用例标题	用一句话概括测试目的（在测试项下唯一）	“使用已注册手机号+正确密码登录成功”
4. 优先级	P0核心功能（如支付） P1高频功能（如搜索） P2边缘功能（如界面文案）	支付失败流程验证 → P0
5. 预置条件	执行前的环境/数据准备（非必需）	“用户账户余额≥100元”、“商品库存=10”
6. 输入数据	精准明确的测试数据	手机号：13800138000 密码：Test@123
7. 操作步骤	无歧义的步骤描述（禁用模糊词汇）	1. 打开APP首页 2. 在用户名栏输入13800138000 3. 在密码栏输入Test@123 4. 点击“登录”按钮
8. 预期结果	可验证的具体结果（非主观描述）	1. 跳转至用户主页 2. 顶部显示用户名“测试用户” 3. 数据库login_log表新增记录

避坑指南：

• 操作步骤中禁用：“尝试”、“检查”等模糊动词 → 改用“点击XX按钮”、“输入XX数据”
• 预期结果中禁用：“正常工作” → 改用“弹出成功Toast”、“订单状态变更为已支付”

---

测试用例编号

一、编号系统核心原则

1. 唯一性原则：每个用例有全局唯一ID
2. 可读性原则：通过ID可知用例归属
3. 可扩展原则：适应业务增长和变更
4. 追溯性原则：支持需求->用例->缺陷的追溯
5. 分类原则：体现测试类型和层级
6. 简洁性原则：避免过长冗余
7. 一致性原则：全团队统一规范
8. 版本控制原则：支持用例迭代
9. 自动化友好原则：便于工具解析

二、四层编号结构体系

[产品/项目]-[模块]-[测试类型]-[序列号]{-版本标识}

结构详解：

层级	长度	编码规则	示例	说明
产品/项目	3-5字符	项目缩写	EC	电商(E-Commerce)
模块	2-4字符	模块代码	OMS	订单管理(Order Management System)
测试类型	2字符	类型代码	FT	功能测试(Functional Test)
序列号	4数字	0001开始	0103	模块内唯一序号
版本标识 (可选)	1字符	版本标记	R	修订版(Revision)

完整示例：EC-OMS-FT-0103-R2

三、编码字典设计

1. 测试类型编码表

测试类型	代码	说明
功能测试	FT	Functional Test
集成测试	IT	Integration Test
系统测试	ST	System Test
性能测试	PT	Performance Test
安全测试	SC	Security Test
兼容测试	CT	Compatibility Test
探索测试	ET	Exploratory Test
回归测试	RT	Regression Test
用户验收	UA	User Acceptance

2. 序列号分配规则

• 基础序列：0001-0999 核心业务流程
• 边界值：1000-1999 边界/异常测试
• 配置相关：2000-2999 配置/参数测试
• 性能专用：3000-3999 性能测试用例
• 安全专用：4000-4999 安全测试用例

四、版本控制方案

EC-OMS-FT-0103-R2
                └── 第二次修订

标识	含义	使用场景
(无)	初始版本	新创建用例
R1	第一次修订	需求变更导致更新
R2	第二次修订	测试策略调整
V1	大版本变更	产品架构调整
T	临时版本	临时测试需求

测试用例标题设计指南

一、顶级标题的黄金标准

1. 精确到可执行 - 仅看标题就知测试内容
2. 业务导向 - 使用业务语言而非技术术语
3. 原子性 - 每标题仅验证一个核心点
4. 可搜索 - 包含关键过滤字段
5. 可追溯 - 嵌入需求标识符

二、结构化标题模板（5种场景）

1. 功能测试 - 三层结构

[模块].[子模块]: [条件]下验证[行为]的[预期结果]

示例：
订单.支付: 使用过期信用卡时验证支付失败提示REQ-3.2.5
用户管理.注册: 输入无效手机号时验证实时错误提示

2. 异常测试 - 故障注入模式

[模块]在[异常条件]时应[系统响应]

示例：
库存服务在DB连接超时时应返回503状态码
支付接口收到乱码数据时应丢弃请求并记录异常

3. 性能测试 - 量化表达

[场景]在[负载]下[指标]应满足[SLA]

示例：
结算页面在500并发用户下P95响应时间≤2s SLA-PERF-4.3
数据导出10万记录时内存占用<1GB

4. 兼容性测试 - 矩阵表达

[功能]在[平台/配置]组合下的[验证点]

示例：
视频播放器在iOS16/Safari下的全屏切换功能
报表打印在Win11+惠普LaserJet M404dn的布局保真

5. 安全测试 - 攻击模式

通过[攻击手法]尝试[漏洞类型]时应触发[防护机制]

示例：
通过SQL注入尝试获取用户表时应触发WAF拦截
使用XSS脚本尝试DOM操纵时应被内容安全策略阻止

三、动词使用规范（精度分级）

场景	推荐动词	禁止动词
正向验证	验证、确认、检查	测试、做
异常验证	确保、拒绝、防止	看看、试试
性能测量	测量、监控、验证	检查、观察
安全防护	阻止、拦截、加密	避免、预防
兼容检查	呈现、支持、保持	显示、运行

| 评估维度       | 优秀标题特征                  | 检查项                  |
|----------------|-----------------------------|-------------------------|
| **精确性**     | 明确具体验证点                | 是否避免模糊词汇？       |
| **原子性**     | 仅包含单一验证目标            | 是否可拆分为多个用例？   |
| **可追溯性**   | 包含需求ID/标准编号           | 能否定位到需求文档？     |
| **可执行性**   | 工程师无需看步骤即懂          | 新手能否理解测试目标？   |
| **可过滤性**   | 含模块/类型等关键元数据       | 能否在系统中快速检索？   |
| **业务价值**   | 体现业务场景而非技术实现      | 产品经理是否看得懂？     |

---

测试用例预置条件设计指南

一、预置条件设计黄金法则

1. 精确到可执行（5W2H原则）

• What：明确具体对象（数据库、文件、用户）
• Where：指定位置（URL、文件路径、DB表）
• When：时间条件（交易时段、有效期）
• Who：执行身份（角色、权限）
• Why：必要性说明（关键依赖）
• How：实现方法（脚本、工具）
• How many：量化数据（记录数、并发量）

2. 环境无侵入原则

• 禁止修改生产配置
• 使用沙箱/容器隔离
• 自动化清理机制

二、分层设计框架（四层金字塔）

层级	内容	示例	技术实现
基础设施	硬件/网络/OS	Kubernetes集群 v1.25	Terraform脚本
中间件	服务/数据库	MySQL 8.0.32	Docker Compose
业务数据	实体/状态	用户ID=1001 余额=5000	Factory Bot
运行时状态	会话/令牌	JWT有效令牌	API自动化生成

案例:

预置条件：

1. 清算窗口开启（交易日 9:00-15:00 UTC+8）
2. 测试账户配置：
   • 账户A：ID=1001，余额=100000.00，状态=激活
   • 账户B：ID=1002，余额=500.00，状态=冻结
3. 风控参数： risk_threshold=50000（DB表：sys_config）
4. 身份凭证：
   • 有效数字证书：/certs/user1001.p12
   • API令牌：Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…
5. 验证方法： ```bash curl -k --cert-type P12 --cert user1001.p12 $API_URL/health

终极建议：将预置条件视为可执行的文档，建立与自动化测试同等的维护标准。每项条件都应具备：

• 独立可验证性
• 环境自描述能力
• 业务语义明确性
• 自动化兼容能力

记住：优秀的预置条件能让测试用例在5年后仍可精确复现！