软件测试中什么是测试用例？初学者必读_千锋教育

01 测试用例到底是什么？别被“用例”两个字骗了

很多人第一次接触“测试用例”这个词，脑子里蹦出来的画面是：一张表格，几行字，填几个操作步骤，完事。然后他们就开始照着模板填，填完就觉得自己会了。结果一到面试，一问测试用例设计，哑口无言。一上项目，一跑测试，漏洞百出。

测试用例不是填空题，是攻防战的地图。

测试用例（Test Case）的定义，教科书上写得很清楚：为某个特定目标而编制的一组测试输入、执行条件、预期结果。但这句话太官方，翻译成人话：测试用例就是你提前想好，要怎么搞坏这个功能，以及搞坏之后它应该是什么反应。

核心三要素：

1. 输入数据：你喂给程序什么？

2. 执行步骤：你按什么顺序操作？

3. 预期结果：程序应该吐出什么？

举个例子。你测试一个登录框，输入“admin”，密码“123456”，点登录，预期跳转到首页。这就是一条测试用例。但如果你只写这一条，你的测试覆盖率是0%。因为真正的bug，藏在“admin”输成“ad min”、“密码输错3次”、“密码框粘贴”、“验证码过期”这些边界里。

测试用例的价值，不是证明软件能用，而是证明软件在什么情况下会崩。一条好的测试用例，能替你挡住一次线上事故。

02 为什么90%的测试新手写不好测试用例？三个致命错误

我见过太多人，写了3个月测试用例，水平还停留在第一天。为什么？因为他们犯了三个致命错误。

错误一：把测试用例当成“操作说明书”

他们写“点击按钮A，页面弹出B”，然后结束。这叫记录，不叫测试。真正的测试用例，必须包含预期结果和实际结果的对比。没有预期结果，你测完了也不知道对错。没有实际结果，你测了等于没测。

没有预期结果的测试用例，等于没有靶心的箭。

错误二：只写“快乐路径”

快乐路径就是用户正常操作时走的流程。比如注册：输入合法信息，点提交，注册成功。99%的新手只写这种。但软件崩溃，从来不是因为快乐路径。崩溃是因为用户乱点、网络断开、数据超长、并发操作。测试用例的核心，是覆盖那些不快乐、不正常的路径。

错误三：用例粒度要么太粗，要么太细

太粗：一条用例覆盖10个步骤，出了问题你根本不知道哪一步挂了。

太细：点击一个按钮写5条用例，导致用例数量爆炸，维护成本飙升。

正确的粒度：一条用例只验证一个行为或一个结果。 比如“输入错误密码3次，账号锁定”是一条。“输入正确密码登录成功”是另一条。不要混在一起。

数据不会骗人：一个中型Web项目，测试用例数量通常在2000-5000条。如果每条用例都包含“操作步骤+预期结果+前置条件”，覆盖率能做到80%以上。如果只写快乐路径，覆盖率不到20%。

03 写好测试用例的黄金法则：等价类+边界值

别被理论词汇吓到。等价类划分和边界值分析，是所有测试用例设计的基石。掌握了这两个，你就能从“瞎蒙”进化到“系统化设计”。

等价类划分：把无穷多的输入，归类为有限的几类。

比如输入年龄，要求1-100。理论上你可以输入1、2、3...100，但没必要。你只需要测试三类：

• ►有效等价类：1到100之间的任意一个数字（比如50）
• ►无效等价类1：小于1的数字（比如0、-1）
• ►无效等价类2：大于100的数字（比如101、200）
• ►无效等价类3：非数字（比如“abc”、空、特殊字符）

边界值分析：bug就爱藏在边界上。

还是年龄输入框，1-100。边界值就是1和100。测试时，必须覆盖：

• ►边界点：1、100
• ►边界内一点：2、99
• ►边界外一点：0、101

组合起来，一个输入框，只需要测试7个值：0、1、2、50、99、100、101。而不是100个。效率提升94%。

等价类让你不遗漏，边界值让你不放过。

代码示例（Python，用于生成边界值测试数据）：

def generate_boundary_tests(min_val, max_val):
    tests = []
    tests.append(min_val - 1)  # 边界外
    tests.append(min_val)      # 边界点
    tests.append(min_val + 1)  # 边界内
    tests.append(max_val - 1)  # 边界内
    tests.append(max_val)      # 边界点
    tests.append(max_val + 1)  # 边界外
    return sorted(set(tests))

# 测试年龄输入1-100
print(generate_boundary_tests(1, 100))
# 输出：[0, 1, 2, 99, 100, 101]

04 实战：从需求到测试用例，三步走

光说不练假把式。我们拿一个真实需求来拆解。

需求描述：用户注册功能。输入手机号、密码、确认密码。点击注册按钮后，系统发送验证码到手机，验证通过后注册成功。

第一步：拆解需求，列出所有测试点

• ►手机号：格式验证（11位数字，以1开头）、空值、非数字、超长、重复注册
• ►密码：长度6-16位、包含数字和字母、空值、纯数字、纯字母、特殊字符
• ►确认密码：与密码一致、不一致、空值
• ►验证码：正确、错误、过期、为空、重复发送
• ►注册按钮：点击一次、快速点击多次、网络断开时点击

第二步：用等价类和边界值设计具体用例

手机号测试用例示例：

密码测试用例示例（边界值）：

第三步：补充异常场景和组合场景

• ►场景1：输入正确手机号和密码，但验证码错误 → 注册失败
• ►场景2：输入正确信息，点击注册按钮后断网 → 提示网络异常
• ►场景3：快速点击注册按钮10次 → 只发送一次请求
• ►场景4：用已注册手机号再次注册 → 提示“手机号已注册”

一条用例覆盖一个错误，十条用例覆盖一个功能。

05 测试用例的维护：写出来不是终点，用起来才是

很多团队陷入一个误区：花2周写2000条测试用例，然后扔进Excel里吃灰。半年后项目迭代，用例没人更新，新功能没覆盖，旧用例全失效。

测试用例的生命周期不是“写完就结束”，而是“持续更新”。每一次代码变更、每一次需求变更、每一次线上bug修复，都是更新测试用例的信号。

三个维护原则：

1. 用例与代码同版本：每次发版前，必须更新对应模块的测试用例。不要等到版本都上线了才想起来补。

2. 删除无用用例：功能下线了，用例立刻删除。留着只会增加维护成本，让新人困惑。

3. 定期评审：每月一次用例评审，拉上开发和产品，一起过一遍。你会发现很多用例已经不符合当前业务逻辑了。

数据对比：不维护的用例，半年后有效覆盖率从80%掉到30%。维护的用例，覆盖率稳定在85%以上。用例不更新，等于白写。

---

测试用例不是写给领导看的，是写给明天出bug的自己看的。 今天少写一条边界值，明天线上多一次事故。开始写，系统化写，持续更新写。你的测试生涯，从写好第一条用例开始。