自动化测试用例设计与批量执行 - 第1节

一、什么是测试用例

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

你想想看，我们测试一个功能，总不能每次都凭感觉乱点吧？测试用例就是把你「怎么测、测什么、期望什么结果」这些步骤，清清楚楚写下来。我刚开始做测试那会儿，觉得写用例太麻烦，直接上手就测。结果呢？测完自己都忘了测过哪些场景，上线后出了bug，领导一问「这个场景你测了吗？」——我哑口无言。

从那以后，我养成了一个习惯：先写用例，再动手测。

测试用例的定义其实很简单：一组输入条件、执行步骤和预期结果的集合，用来验证某个功能是否满足需求。

二、测试用例的核心要素

一个完整的测试用例，到底该包含哪些东西？我见过很多新手写的用例，就一句话「测试登录功能」——这哪叫用例？这连提纲都算不上。

我个人习惯，把核心要素分成两类：基础信息和执行信息。

2.1 基础信息

要素	说明	示例
用例编号	唯一标识，方便追溯	TC-LOGIN-001
用例标题	一句话描述测试点	验证正确用户名密码可登录
所属模块	功能模块名称	登录模块
优先级	P0/P1/P2/P3	P0（核心功能，必须通过）
前置条件	执行前需要满足的条件	用户已注册，账号状态正常

2.2 执行信息

要素	说明	示例
测试数据	输入的具体值	用户名：admin，密码：123456
操作步骤	一步步怎么做	1. 打开登录页 2. 输入用户名 3. 输入密码 4. 点击登录
预期结果	系统应该表现为什么样	页面跳转到首页，右上角显示用户名
实际结果	执行后实际表现（执行时填写）	与预期一致 / 页面报错500
测试状态	通过/失败/阻塞/跳过	通过

三、测试用例的生命周期

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

3.1 创建阶段

根据需求文档、原型图、设计稿，把测试点梳理出来。这个阶段我建议先列功能点，再细化成用例。比如登录功能，先列「正常登录」「错误密码」「空输入」「账号锁定」这些大方向，再一个个展开。

3.2 评审阶段

写好的用例，拉上产品和开发一起过一遍。我曾经有一次没评审就直接开测，结果测了三天才发现有个核心流程理解错了——全部白干。嗯，这个坑我踩过，你们别踩。

3.3 执行阶段

按照用例一步步执行，记录实际结果。这里要注意：不要跳步骤。我见过有人觉得「这步肯定没问题」，直接跳过，结果偏偏就是那步出了bug。

3.4 维护阶段

需求变了，用例也得跟着变。我习惯每次版本迭代后，花半小时过一遍存量用例，该删的删，该改的改。不然用例库会越来越臃肿，最后变成没人看的「僵尸用例」。

3.5 归档阶段

项目结束后，把用例归档。别急着删，说不定下个版本还能复用。我手头有个用例库，已经积累了三四年，新项目来了直接复用80%，效率提升很明显。

四、知识体系总览

下面这张图，把测试用例的核心内容串起来了。你可以把它当成一张「地图」，随时回来看看。

五、写在最后

测试用例这东西，看着简单，但真正写好、用好，需要时间积累。我刚开始写用例的时候，也犯过各种错：漏场景、预期结果写得太模糊、用例维护不及时……

但没关系，慢慢来。记住一句话：好的测试用例，是项目质量的基石。你花在用例上的每一分钟，都会在后续的测试执行中加倍还给你。