一、测试设计概述：从“点点点”到“有章法”
大家好，我是这门课的主讲人。做了十几年测试，从最初的手工“点点点”，到后来负责整个平台的测试架构，我最大的感触就是：测试用例，是测试工程师的“灵魂”。
很多人觉得写用例就是走个过场，应付一下评审。其实不然。你想想看，一个没有经过精心设计的用例，就像没有地图的探险，能不能找到 Bug 全靠运气。我个人习惯，在开始任何测试活动前，第一件事就是问自己：“我的测试用例，到底要验证什么？”
1.1 什么是测试用例？
说白了，测试用例就是一份“操作说明书”。它告诉执行者：
- 测什么：具体的功能点或场景
- 怎么测：前置条件、操作步骤
- 期望是什么：预期的正确结果
它不是一个简单的“输入A，看结果B”的脚本。我见过很多新手写的用例，步骤写得很详细，但就是抓不住重点。比如测试登录功能，他写了“输入正确用户名和密码，点击登录，跳转首页”。这没错，但太“教科书”了。
真正的测试用例，应该包含对业务逻辑的深刻理解。我记得有一次测试一个支付系统，用例里只写了“支付成功”和“余额不足”。结果上线后，用户发现“支付成功但订单状态没更新”。为什么？因为用例没覆盖到“支付回调超时”这个场景。这就是典型的用例设计缺失。
1.2 测试用例的核心价值
你可能觉得，用例就是给新人看的，老手直接凭经验测就行。我年轻时也这么想，直到有一次吃了大亏。
那是一个大版本迭代，我自认为对业务了如指掌，就没怎么写用例，直接上手测。结果呢？测了三天，感觉都跑通了。上线后，用户反馈了一个极其低级的 Bug——某个按钮在特定权限下消失了。我复盘时发现，这个场景我在测试时完全忽略了。
从那以后，我深刻理解了测试用例的四个核心价值：
| 价值维度 | 具体说明 | 我的经验 |
|---|---|---|
| 质量基线 | 定义了“什么是测过了”的标准 | 没有用例，你无法向项目经理证明测试完成了 |
| 知识传承 | 新人接手时，看用例就能快速理解业务 | 我曾经靠一份优秀的用例库，三天带熟了一个新人 |
| 效率保障 | 避免重复劳动和遗漏，让测试可重复 | 回归测试时，直接跑用例集，比人肉记忆靠谱100倍 |
| 过程度量 | 通过用例覆盖率、通过率评估测试进度 | 老板问“测了多少了？”你直接甩数据，比说“差不多了”有说服力 |
1.3 测试设计在软件生命周期中的位置
测试设计不是孤立存在的。它就像一座桥梁，连接着需求分析和测试执行。很多团队把测试设计当成“编码完成后的附属品”，这是大错特错的。
我个人习惯，在需求评审阶段就开始构思测试点。为什么？因为这时候发现问题，修改成本最低。你想想看，如果等到代码写完了，你才发现需求有逻辑漏洞，那改起来多痛苦？
下面这张图，是我自己总结的测试设计在软件生命周期中的位置：
从图中你可以看到，测试设计处于系统设计之后、编码实现之前。这是一个黄金窗口期。在这个阶段，你手里有详细的设计文档，但代码还没开始写。这时候设计用例，你可以：
- 反推需求的合理性：如果某个场景你设计不出用例，那很可能需求本身就有问题。
- 提前准备测试数据：比如需要构造一些特殊状态的数据，可以提前跟开发沟通。
- 规划测试策略：哪些用自动化，哪些用手工，哪些需要探索性测试。
嗯，这里要注意一点。很多测试同学觉得“测试设计”是测试经理或者架构师的事，自己只管执行。其实不是的。哪怕你只负责一个模块，你也是这个模块的“测试架构师”。你设计的用例质量，直接决定了这个模块的质量。
我曾经带过一个团队，有个同学负责一个非常边缘的模块。他觉得自己不重要，用例写得马马虎虎。结果那个模块上线后，成了线上故障最多的模块。后来我跟他一起复盘，重新设计了用例，把边界条件、异常流程都补全了。从那以后，那个模块再也没出过问题。
所以，不要小看任何一条用例。它可能是你职业生涯中，避免一次重大事故的关键。