1. 测试用例设计基础

什么是测试用例

测试用例，说白了就是一份「操作说明书」。

你想想看，我们拿到一个功能，总不能凭感觉乱点吧？测试用例就是告诉你：先做什么、再做什么、期望看到什么结果。

我个人习惯这样定义：测试用例是一组输入条件、执行步骤和预期结果的集合，用来验证某个功能是否正常工作。

举个例子，测一个登录框：

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

我在项目中遇到过不少新人，上来就写「测试登录功能」——这哪叫用例？这连方向都没有。用例必须具体到每一步操作，不然别人没法执行，你自己过两周也忘了。

测试用例的核心要素

一个合格的测试用例，必须包含以下要素。少了任何一个，这个用例就是「残废」的。

要素	说明	我的经验
用例编号	唯一标识，方便追溯	我习惯用「模块-功能-序号」的格式
测试标题	一句话描述测什么	别写太长，20字以内搞定
前置条件	测试前必须满足的状态	这个最容易漏，我吃过亏
测试步骤	具体的操作序列	步骤要细，别跳步
预期结果	系统应该表现出的行为	要可观察、可验证
实际结果	执行后真实看到的结果	执行时填写，用于对比
状态	通过/失败/阻塞等	建议用统一的状态词

测试用例的生命周期

测试用例不是写出来就完事了。它有自己的「一生」，我把它分成五个阶段。

第一阶段：设计

拿到需求文档，开始分析。这时候别急着写用例，先搞清楚：这个功能到底要解决什么问题？

我一般会先画个思维导图，把功能点拆开。比如一个搜索功能，我会拆成：搜索框、搜索按钮、搜索结果、搜索历史、空搜索、特殊字符搜索……

第二阶段：评审

写好的用例一定要过评审。不是走过场，是真的找产品、开发一起看。

我记得有一次评审，开发看了一眼我的用例说：「这个场景根本不会出现，因为后端做了限制。」好家伙，要不是评审，我白写20条用例。

第三阶段：执行

用例评审通过后，就可以执行了。执行的时候要注意：

• 严格按照步骤来，别跳步
• 实际结果要如实记录
• 发现bug及时提，别攒着

第四阶段：维护

需求变了怎么办？用例也得跟着变。很多团队用例写完后就不管了，这是大忌。

我建议每个迭代结束后，花半小时过一遍用例。该删的删，该改的改，该补的补。不然用例库会越来越「脏」，最后没人敢用。

第五阶段：归档

项目上线后，用例要不要删？别删！

归档的意思是：标记为「已执行」，保存到用例库中。下次回归测试或者类似项目，可以直接复用。我手头有个项目做了三年，用例库积累了2000多条用例，每次回归直接挑着跑，效率翻倍。

小结

测试用例不是什么高深的东西，它就是一份「操作指南」。但写好它，需要你理解业务、熟悉系统、有经验积累。

嗯，这里要注意：别把用例写成「流水账」。好的用例，别人照着做一遍就能发现问题。差的用例，写的人自己都看不懂。

我个人习惯，写完用例后问自己三个问题：

1. 这个用例能发现bug吗？
2. 别人能看懂并执行吗？
3. 如果需求变了，这个用例好改吗？

三个问题都回答「是」，那这个用例就合格了。