一、测试用例基础

说实话，我见过不少测试新人，一上来就闷头写用例。写了一大堆，结果评审时被问得哑口无言。为什么？因为连测试用例到底是什么都没搞清楚。

今天咱们就把这个基础打扎实。你想想看，盖房子要图纸，做菜要菜谱，那测试呢？当然需要测试用例。它就是我们测试工作的「施工图」。

1.1 什么是测试用例

测试用例，说白了就是一组操作步骤和预期结果的集合。它的目的很简单——验证软件功能是否符合需求。

我习惯把测试用例比作「剧本」。开发写的是代码，测试写的就是用例。演员照着剧本演，测试照着用例测。剧本写得好，戏才演得顺；用例写得好，测试才测得透。

举个例子：你要测试一个登录功能。

用例编号：TC-LOGIN-001
测试标题：验证正确用户名和密码可以登录成功
前置条件：用户已注册，账号状态正常
测试步骤：
  1. 打开登录页面
  2. 输入正确用户名
  3. 输入正确密码
  4. 点击登录按钮
预期结果：页面跳转至首页，显示用户昵称

这就是一个最基础的测试用例。嗯，看起来简单吧？但实际工作中，很多人连这个都写不完整。

1.2 测试用例的核心要素

我刚开始带团队时，发现大家写的用例五花八门。有人只写步骤，有人只写预期，还有人把用例写成了一篇小作文。后来我定了个规矩：测试用例必须包含以下五个要素，缺一不可。

要素	说明	我踩过的坑
用例编号	唯一标识，方便追溯和管理	曾经有人用「1、2、3」编号，结果新增用例时全乱了
测试标题	一句话描述测试目的	「测试登录」这种标题等于没写，要写「验证错误密码登录失败」
前置条件	执行测试前必须满足的状态	漏写前置条件，测试执行到一半才发现环境不对
测试步骤	清晰、可执行的操作序列	步骤写得太笼统，新人根本看不懂怎么操作
预期结果	执行后应该看到的现象	只写「成功」两个字，到底什么是成功？

咱们一个一个说。

用例编号

我习惯用「模块-功能-序号」的格式。比如 TC-LOGIN-001，一看就知道是登录模块的第1条用例。千万别用纯数字，项目大了根本找不到。

测试标题

标题要能「望文生义」。你想想看，评审会上几十条用例，别人扫一眼标题就知道测什么。我见过最差的标题是「测试功能」，这跟没写有什么区别？

前置条件

这个最容易漏。我曾经接手过一个项目，用例里写着「点击删除按钮」。结果呢？数据都没创建，点哪门子删除？前置条件就是测试的「起跑线」，没到起跑线，测试没法跑。

测试步骤

步骤要细，细到新人照着做都不会出错。我见过有人写「输入用户名」，然后没了。输入什么用户名？正确的还是错误的？长度多少？这些都要写清楚。

预期结果

这是测试用例的灵魂。没有预期结果，测试就是盲测。预期结果要具体、可验证。别写「系统正常」，要写「页面显示'登录成功'，3秒后跳转至首页」。

1.3 测试用例的生命周期

测试用例不是写出来就完事了。它有自己的生命周期，就像人一样，从出生到消亡。

我习惯把生命周期分成五个阶段：

1. 创建期——根据需求文档编写用例
2. 评审期——团队评审，查漏补缺
3. 执行期——按照用例执行测试
4. 维护期——需求变更时更新用例
5. 归档期——项目结束后归档保存

这里我要重点说说维护期。很多团队用例写出来就再也不管了。需求变了，用例还是老的。结果呢？执行时发现用例和实际对不上，测试人员只能凭感觉测。这叫什么？这叫「僵尸用例」——看着有，实际没用。

我曾经在一个项目中吃过这个亏。需求改了三次，用例一次没更新。最后上线前发现，用例里测的功能早就被砍掉了。从那以后，我定了个规矩：需求变更时，用例必须同步更新，否则不允许提测。

知识体系总览

说了这么多，咱们用一张图把测试用例的基础知识串起来。这张图我画了很多遍，每次带新人都会拿出来讲。

这张图把咱们今天讲的内容都串起来了。中心是测试用例，往外延伸出定义、核心要素和生命周期。你想想看，掌握了这三个维度，写用例是不是就有章可循了？

我个人习惯，每次写用例前都会先画这么一张图。不是为了好看，是为了理清思路。思路清楚了，写出来的用例才不会跑偏。