一、测试用例设计基础:从“随便点点”到“心中有数”
说实话,我刚入行那会儿,对测试用例的理解特别肤浅。觉得不就是“打开页面,点个按钮,看看结果对不对”嘛。直到有一次,我负责一个支付模块的回归测试,漏写了一个边界条件——金额为0的场景。结果上线当天,用户用0元买走了价值几千块的商品。嗯,从那以后,我再也不敢小看测试用例了。
这一章,我们就来聊聊测试用例的那些“基本功”。别觉得基础就简单,你想想看,高楼大厦的地基要是没打好,后面全是坑。
1.1 什么是测试用例?
测试用例,说白了就是一份“操作说明书”。它告诉测试人员:你要测什么、怎么测、期望看到什么结果。
我个人的理解更直白一些——测试用例就是你和被测系统之间的一份“契约”。你按照约定的步骤操作,系统就应该返回约定的结果。如果系统不按契约来,那就是bug。
核心定义:测试用例(Test Case)是为特定目标(如验证某个功能、检查某个性能指标)而设计的一组输入条件、执行步骤和预期结果的集合。
1.2 为什么测试用例这么重要?
你可能听过一句话:“没有测试用例的测试,叫随机探索。” 这话虽然有点绝对,但道理不假。
我在项目中遇到过好几次这样的情况:团队赶进度,大家说“先不写用例了,直接上手测”。结果呢?测了两天,谁也不知道自己测了哪些功能,哪些还没测。最后上线前,产品经理问“支付流程测了吗?” 三个人同时说“我以为你测了”。
测试用例的重要性,我总结为三点:
- 可重复: 这次测了,下次还能按同样的方式测。回归测试全靠它。
- 可衡量: 写了100条用例,通过了95条,测试进度一目了然。
- 可交接: 新人来了,看用例就知道怎么测。不用每次都找老人“口传心授”。
我的习惯: 哪怕时间再紧,我也会先写一个“冒烟测试用例清单”,至少保证核心流程有据可查。这招帮我挡了好几次“上线前甩锅”。
1.3 测试用例的生命周期
测试用例不是写完了就完事的。它有自己的“一生”。我习惯把它分成五个阶段:
| 阶段 | 说明 | 常见动作 |
|---|---|---|
| 创建 | 根据需求文档或设计文档,编写用例初稿 | 编写、自审 |
| 评审 | 产品、开发、测试一起过一遍,查漏补缺 | 会议评审、在线评论 |
| 执行 | 按照用例步骤进行测试,记录结果 | 手工执行、自动化执行 |
| 维护 | 需求变更或发现遗漏时,更新用例 | 增、删、改、版本管理 |
| 归档 | 项目结束后,将用例存入知识库 | 标记状态、备份 |
这里我想特别强调一下维护阶段。我曾经接手过一个项目,用例库里有3000多条用例,但仔细一看,三分之一都是针对已经下线的功能写的。这种“僵尸用例”不仅没用,还会拖慢自动化执行的速度。所以,我建议每轮迭代结束后,花15分钟清理一下用例库。
1.4 优秀测试用例的8大要素
好,接下来是本章的重头戏。一个优秀的测试用例,到底长什么样?我总结了8个核心要素,缺一不可。
你可能会问:“为什么是8个?少一个不行吗?” 我个人觉得,这8个要素就像一个人的“身份证信息”,少了任何一个,别人都没法准确理解你要测什么。
8大要素速览: ID、标题、前置条件、测试步骤、预期结果、优先级、模块、创建人。
下面我一个一个说。
1.4.1 ID(编号)
每个用例的唯一标识。我习惯用“模块缩写-序号”的格式,比如 LOGIN-001、PAY-042。这样一看编号就知道是哪个模块的用例。
1.4.2 标题
标题要让人一眼看懂“测什么”。我见过最差的标题就是“测试登录功能”——这等于什么都没说。好的标题应该是“登录-输入正确用户名和密码,验证跳转到首页”。
1.4.3 前置条件
执行用例前,系统必须处于什么状态。比如“用户已注册且账号状态正常”、“数据库中有3条测试订单数据”。前置条件写不清楚,执行的时候就会卡住。
我曾经踩过的坑: 写前置条件时写了“用户已登录”,但没说明用什么账号登录。结果自动化脚本跑的时候,用的账号已经被封了,整个用例集全部失败。排查了半天才发现是前置条件没写清楚。
1.4.4 测试步骤
一步一步的操作指引。注意,步骤要可执行、无歧义。不要写“输入一些内容”,要写“在用户名输入框输入‘admin’”。
1.4.5 预期结果
这是用例的“灵魂”。没有预期结果,测试就变成了“看看会发生什么”。预期结果要具体、可验证。比如“页面右上角显示用户昵称‘admin’”、“数据库订单状态字段更新为‘已支付’”。
1.4.6 优先级
我一般分P0、P1、P2、P3四级:
- P0: 核心流程,不通过就不能上线(比如登录、支付)
- P1: 重要功能,影响用户体验(比如搜索、列表展示)
- P2: 次要功能,偶尔使用(比如个人资料修改)
- P3: 边缘场景,低概率触发(比如特殊字符输入)
1.4.7 模块
标明这个用例属于哪个功能模块。方便后期统计和筛选。比如“登录模块”、“购物车模块”。
1.4.8 创建人
谁写的这个用例。出了问题好找人确认,也方便统计每个人的工作量。
下面是一个完整的用例示例,你可以参考一下:
ID: LOGIN-003
标题: 登录-输入错误密码3次后,账号被锁定
前置条件: 用户'zhangsan'已注册,账号状态正常,当前登录失败次数为0
测试步骤:
1. 打开登录页面
2. 输入用户名 'zhangsan'
3. 输入错误密码 'wrong123'
4. 点击【登录】按钮
5. 重复步骤2-4,共3次
6. 第4次输入正确密码 'correct456'
7. 点击【登录】按钮
预期结果:
1. 前3次登录均提示“用户名或密码错误”
2. 第4次登录提示“账号已被锁定,请30分钟后重试”
3. 数据库中该账号的 locked 字段更新为 true
优先级: P1
模块: 登录模块
创建人: 张三
1.5 本章知识体系总览
为了让你更直观地理解这一章的内容结构,我画了一张图。你可以把它当作一个“知识地图”,学完之后回头看看,思路会更清晰。
给你一个小建议: 刚开始写用例的时候,别追求“一步到位”。先保证8大要素齐全,再慢慢优化细节。写得多了,自然就熟练了。我刚开始写的时候,一条登录用例要改三遍才能过评审,现在基本一遍过。