1. 测试用例基础：什么是测试用例、核心要素、为什么需要测试用例

大家好，我是这门课的主讲人。今天咱们聊聊最基础、也最容易被忽视的东西——测试用例。

你可能觉得，写测试用例谁不会啊？不就是把操作步骤列一列吗？嗯，我以前也这么想。直到有一次，我负责一个支付模块的回归测试，因为用例写得不够细，漏掉了一个边界条件，结果线上出了个不大不小的故障。从那以后，我对测试用例的态度就彻底变了。

说白了，测试用例就是你的“作战地图”。没有它，你就是在黑灯瞎火里乱撞。

测试用例，英文叫 Test Case。它是一组输入、执行条件、预期结果的集合。目的是验证某个功能点是否满足需求。

我个人的理解更简单：测试用例就是“怎么测、测什么、结果应该是什么”的说明书。

举个例子，你要测一个登录功能。测试用例会告诉你：

你想想看，如果没有这个说明书，你测的时候可能就随便输几个值，点一下，看到能登录就觉得完事了。但边界情况呢？密码错误呢？账号被锁定呢？这些都会被漏掉。

  核心观点：测试用例是测试工作的最小执行单元。它把“测试”这件事从“凭感觉”变成了“有据可依”。

一个完整的测试用例，应该包含哪些东西？我把它总结为“六要素”。

要素	说明	我的经验
用例编号	唯一标识，方便管理和追溯	我习惯用“模块_功能_序号”的格式，比如 LOGIN_001
测试标题	一句话描述测什么	要让人一看就知道测哪个场景
前置条件	执行前需要满足的状态	这个最容易漏，我曾经因为没写“用户已登录”导致用例执行失败
测试步骤	具体的操作流程	步骤要清晰，新人照着做也能跑通
预期结果	系统应该表现出的行为	这是用例的灵魂，写不清楚等于没写
实际结果	执行后真实看到的结果	用于对比，判断用例是否通过

除了这六要素，有些团队还会加上优先级、所属模块、创建人、创建日期等字段。但我觉得，上面这六个是底线，缺一个都不行。

小技巧：写预期结果时，尽量用“可验证”的描述。比如“页面显示‘登录成功’字样”，而不是“登录成功”。前者能明确判断，后者太模糊。

这个问题我问过不少新人。有人回答“因为领导要求写”，有人回答“为了记录”。这些都对，但不够本质。

我个人认为，测试用例存在的理由有三个：

没有用例，你测着测着就容易跑偏。可能某个功能点你测了十遍，另一个功能点一次都没碰。用例就像购物清单，让你知道哪些买了，哪些还没买。

我记得有一次做电商项目的测试，功能点特别多。如果没有用例，我根本记不住哪些优惠券组合已经测过，哪些还没测。最后靠用例矩阵，才把覆盖做到位。

测试不是一次性的事。回归测试、冒烟测试，都需要反复执行。没有用例，每次都得重新想步骤，效率低不说，还容易出错。

你想想看，一个版本迭代下来，回归测试可能要跑几百条用例。如果每条用例都写得清清楚楚，执行起来就很快。反之，如果用例写得稀里糊涂，执行的人就得猜，一猜就出问题。

测试不是一个人的战斗。新人来了，老员工离职了，项目交接了——这些场景下，测试用例就是最好的“交接文档”。

我曾经接手过一个遗留项目，原来的测试人员已经走了。幸好他留下了详细的测试用例，我照着用例跑了一遍，很快就摸清了系统的功能边界。如果没有这些用例，我估计得花一个月才能上手。

避坑指南：我曾经见过一个团队，用例写得特别详细，但没人维护。三个月后，用例和实际系统对不上了，反而成了误导。所以，用例一定要跟着版本走，每次迭代都要更新。

为了让你更直观地理解，我画了一张图，把本章的核心逻辑串起来。

这张图把本章的三个核心问题串在了一起。你从中心出发，先搞清楚“是什么”，再掌握“有什么要素”，最后理解“为什么需要”。这三步走完，测试用例的基础就算打牢了。

好了，这一章就到这里。记住一句话：好的测试用例，是测试质量的基石。下一章咱们聊聊怎么写好一个测试用例，到时候我会分享一些我踩过的坑和总结的技巧。