一、用例设计概述：测试用例的定义、设计原则与常见误区

说实话，做了这么多年的测试，我觉得最容易被低估的，就是“写用例”这件事。

很多人以为用例就是列几条操作步骤。但说白了，它是你测试思路的载体。你的测试策略、覆盖深度、风险判断，全都压在那几行字里。我见过不少项目，开发说“修好了”，测试点几下发现没问题就过了，结果线上出大问题。为什么？因为用例没覆盖到。

1.1 什么是测试用例？

测试用例（Test Case），是一组输入条件、执行步骤和预期结果的组合。它的目标是：回答“这个功能到底能不能用”。

• 输入条件：数据、环境、前置状态
• 执行步骤：用户怎么操作
• 预期结果：系统应该反馈什么

举个例子。你要测一个登录功能。输入条件是“用户名admin，密码123456”，操作是“点登录按钮”，预期结果是“跳转到首页”。这就算一条用例。

但你别以为这就完了。真的用例远不止这么简单。我曾在项目中遇到一个极端情况：某个用户名的长度超过数据库字段限制，系统直接崩溃。你想想看，如果用例里只写了正常的admin，这种问题根本测不出来。

1.2 设计原则：覆盖什么、怎么覆盖

我个人的习惯是，先定目标，再定覆盖。目标不明确，用例一定散。

设计用例时，我通常会关注以下几个原则：

原则	说明	我踩过的坑
有效性	每条用例能发现潜在缺陷	曾经写了100条用例，执行完一个bug都没提——全是重复场景
可重复性	换一个人执行，结果一致	后来我规定了“环境+数据+步骤”三要素缺一不可
独立性	用例之间不互相依赖	有次A用例执行失败导致B无法执行，浪费半天排错
可追溯性	每条用例对应一个需求点	没有追溯的用例，评审时根本没法确认覆盖度

1.3 常见误区：这些坑我当年都踩过

初学者最容易犯的错误，我总结了一下，主要就三条。你对照看看自己有没有中招。

1. 只写“快乐路径”

   只测正常输入、正常操作。我当年做过一个OA系统，审批流程只测了“提交→审批→通过”，结果生产环境上有人提交后直接取消，系统的状态直接混乱了。

2. 预期结果写得太模糊

   比如“系统正常响应”、“页面无异常”。这种写法你执行一百遍也没人知道究竟对不对。我建议你把预期写得可以量化：比如“页面显示'提交成功'字样”、“状态码返回200”。

3. 用例颗粒度两极分化

   要么一条用例覆盖了七八个操作，要么一个点击就写一条。太粗的话，执行失败了根本不知道是哪一步引起的；太细的话，用例数量爆炸，维护成本极高。

我曾经接手过一个老项目的用例库，光一个订单模块就有3000条用例。但仔细一看，其中有500条都在测同一个“下单成功”的场景。说白了，这就是覆盖混乱。真正该测的——比如库存超卖、支付超时、并发扣款——反而一条都没有。

1.4 用例设计整体逻辑框架

下面这张图，是我在工作中提炼出来的。你画用例之前，先把这四层想清楚，再去写。就不会出现“东一榔头西一棒槌”的情况。

习惯上，我每次写用例前会问自己一句：

• 这个功能用户最常用的场景是什么？
• 最容易出错的地方在哪儿？
• 系统边界设在哪里？

把这些问题想清楚，用例覆盖的维度基本就确定了。

1.5 小结

这一章我们聊了测试用例到底是什么，设计时该遵守哪些原则，以及最容易掉进去的几个坑。嗯，这里有一个关键点我想再强调一下：

带着这个思路往下走，你后续学的每一种设计方法，都会离“有效覆盖”更近一步。