测试用例篇：用例要素、设计方法与完整案例

你有没有遇到过这种情况：开发说"功能我测过了，没问题"，结果上线第二天一崩，产品经理第一时间不是找开发，而是找你——"测试是干什么吃的？"这道锅，很多测试新手都被迫背过。但要我说，这口锅大概率不是你的责任，而是你根本没写测试用例，或者写得不全。

是的，问题就出在"用例"这两个字上。你可能会想：我对着页面点一点、把功能跑一遍不就行了，干嘛还要写什么用例？这篇文章就是要给你把这个"不写用例也能测"的幻想彻底打碎，然后把写用例这件事从头到脚掰开揉碎讲清楚。

我会从测试用例到底是什么讲起，然后给你一套设计测试用例的万能公式（保证你面对任何一个需求都不至于脑子空白），接着进入本课的重头戏——六种具体的设计方法：等价类、边界值、正交法、判定表、场景法、错误猜测法。每一种我都会配上真实可操作的例子，最后还会给你一张可以拿来就用的表格式用例模板，以及面试/笔试里最常被问到的登录功能用例设计。

在正式开始之前，先给没接触过的人做个知识准备。如果你是零基础，下面这几句话足够你跟上节奏：

• 测试用例（Test Case）：为了一次测试准备的一组"输入 + 操作 + 预期结果"的集合。它是测试的第一等公民。
• 黑盒测试：把被测程序当成一个"黑箱子"，不关心内部怎么实现，只关心"我给了什么输入、程序给了我什么结果"。本课讲的用例设计方法，几乎都属黑盒测试的范畴。
• 回归测试：改了一个功能之后，把跟它相关的旧功能再完整重测一遍，防止"改一处、坏一片"。后面你会看到，没有用例，回归测试根本没法做。

好了，带上这些，我们开始。

测试用例的概念

一句话定义：测试用例（Test Case）是为了实施测试而向被测系统提供的一组集合，这组集合包含测试环境、操作步骤、测试数据、预期结果等要素。

这里有两个关键词值得你停下来品一品。

第一个是"集合"。意思是，一个用例不是一句话，而是一个"完整的包裹"——它要把"我在什么环境下、准备用什么数据、按什么顺序操作、最后应该看到什么"全部装进去。少了一项，这个用例就是不完整的，别人执行不了，你自己回头也看不懂。

第二个是"预期结果"。设计测试用例的原则一：一个用例里最不可或缺的部分，是定义"预期输出/结果"。 这听起来像废话，但恰恰是新手最容易犯的错。常见场景是：写用例时只写"输入手机号，点击登录"，然后没了——后面该弹出什么、跳转到哪、提示什么文案，一个字都没有。那这个用例到底能不能算通过？没法判断。没有预期结果的用例，不是一个合格的用例，它更像一句"我想点一下试试"。

那我们为什么要费劲写用例？直接对着软件点不就行了吗？我们来数一数"不写用例直接测试"会遇到哪些问题：

• 不知道是否测全了：靠感觉点，今天点了这三个按钮，明天可能只点了两个，到底覆盖了多少功能，自己心里没数。
• 覆盖率无法衡量：想跟领导汇报"测试覆盖到 80% 了"，你拿什么数据说话？手点上没有，没有量化依据。
• 回归测试无法实施：版本 2.0 要上线了，版本 1.0 的旧功能你还得保证能用。没有用例清单，你靠脑子回忆"上次是怎么测的"？一个人测三天三夜也回归不完。
• 存在大量冗余测试：今天测的状态和三天前测的重叠了，白白浪费时间。

这四点加起来，就是测试用例存在的根本理由：让测试可量化、可复用、可回归、不冗余。 另外还有一层现实意义——避免测试人员被迫背锅。产品出问题，第一责任人首先想到的是"测试为啥没测到"。这时候你掏出用例记录，指给他说"这条规则当时需求文档里就这么写的，我按文档测了，是需求本身有矛盾"，这就是你的护身符。所以认真写用例，既是对产品负责，也是对你自己负责。

用例的要素：一张模板先看全貌

要素是什么？就是我们写每一个用例时，必须给出的那些信息项。传统手工测试的用例，通常会包含下面这些格子，我直接给你一张可用的模板：

这张表就是传统手写用例的标准姿势，笔试时要求"完整写出测试用例及必要要素"时，你要能把它默写出来。但要注意——如今大多数企业做敏捷/迭代开发，已经很少用这么重的表格逐条写了，更多是用思维导图（脑图）来组织用例，把"模块 → 测试点 → 具体用例"一层层展开。这样做的好处是直观、层级清晰、方便评审时快速浏览全貌。

不过话说回来，表格有表格的严谨，脑图有脑图的直观。考试看表格，工作看脑图——两种情况你都应该会。本课后面大部分练习我都会用"脑图思路 + 表格落地"结合的方式给你演示。

思维先摆正：常规思维 + 逆向思维 + 发散思维

在设计用例之前，有一个思维层面的东西必须先纠正，否则再多方法也用不出来。

先看你第一直觉会怎么设计。假如让我给"门锁"设计测试用例，新手往往会这样做：门锁能开、能关、钥匙能插进去、锁坏了会怎样……然后呢？没有了。这样零散地靠脑子蹦出来的用例，少得可怜，而且你根本不知道自己漏了什么。

设计测试用例的正确思想，是"常规思维 + 逆向思维 + 发散性思维"三者叠加。 展开说就是设计测试用例的原则二：

1. 用例不但要根据有效且预料到的输入来写，更要根据无效且未预料到的输入来写。
2. 检查程序"没做它该做的"只是成功一半；测试的另一半，是检查程序是否做了它不该做的。
3. 计划测试工作时，不要默许假定"这里不会出错"就跳过。

把这三条翻译成人话：不要只测"正常流程"，更要去测"异常和边界"。 用户不会永远规规矩矩输入合法数据，他可能敲错、可能乱敲、可能连续点提交、可能中途断网。这些"不该发生却总会发生"的场景，恰恰是 bug 的高发区，也是测试价值的最大体现处。

记住了这个思维，我们再来学"有思路的设计"——光是靠头脑风暴去碰用例是碰不出来的，我们需要一套能落地执行的框架。这就是下一节的万能公式。

设计测试用例的万能公式

如果你在面试里被问"给某个东西设计测试用例"，大多数人第一反应是懵。但如果你脑子里装了一套公式，你就能"套路化"地往下拆，永远不会冷场。这套公式就是：

功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试

无论被测对象是软件、网站、命令行工具，还是一个"水杯"，你都可以从这个六个维度往里填，填完再用前面讲的逆向/发散思维去补充边界和异常。下面逐个讲。

功能测试

功能测试，是试图发现"程序与其外部规格说明之间存在不一致"的过程。所谓外部规格说明，简单说就是从最终用户角度对程序行为的精确描述，也就是"用户应该得到什么"。功能测试通常是一项黑盒操作——我们不关心程序内部怎么算，只看输入输出对不对。

工作或面试里，常会遇到"需求不明确"的情况。这时候别慌，有这几条路可以走：查找相关文档来理解产品目标；多参加需求讨论、设计讨论、计划讨论会议加深理解；把自己整理的测试点召集相关人员评审，评审通过后就能作为设计用例的依据；如果产品已上线，多亲自用一用，不懂就问产品经理；还可以翻历史 bug，bug 集中的地方往往是薄弱点。

界面测试

软件界面上所有的内容都要测。要求大致分两层：一是整体界面的实现要与设计图一致（布局、配色、文案对得上）；二是界面元素的控件操作验证（按钮能不能点、输入框能不能聚焦、下拉能不能展开、点击有没有反馈）。

性能测试

性能测试和功能测试的区别一句话说清：功能测试检查软件"做没做"，性能测试检查软件"做得好不好"。功能上按钮能点，性能上要看点了多久才响应；功能上数据能加载，性能上看是 0.1 秒还是 3 秒、并发 1000 人会不会崩。

兼容性测试

软件是跑在五花八门的硬件和软件环境上的。比如 QQ 既能 PC 端用又能移动端用；移动端又分 iOS 和 Android；市面上又有各种品牌、机型、系统版本。软件能不能在不同环境里正确运行，就是兼容性要验证的。

有人会问：机型那么多，难道每台都要测？当然不是，要有选取标准——优先选当前产品排名 top 级别的机型；选择主流的浏览器和机型。实际企业里，后台一般能统计到用户使用的机型并生成报表，测试人员就按报表里的主流机型去测，既覆盖到位又不浪费资源。

易用性测试

易用性的标准是产品"简单易上手"。假如一个从没装过、没用过的新用户，他能否快速适应产品的使用流程？新手能不能不看说明书就用起来？测易用性，你可以站在"第一次见它的人"的视角去过一遍流程。

安全测试

安全测试和性能测试一样，都是很大的领域。常见的安全问题有：隐私数据明文显示（密码、手机号直接暴露）；参数未强校验导致 SQL 注入；越权（普通用户能执行管理员权限的操作）。测安全，就是去故意触发这些危险场景。

有了这个公式还够吗？对大多数 Web 项目来说，还有两种高频测试类型经常被提到，值得一提：

弱网测试

目的是尽可能保证用户体验。关注点包括：页面响应时间是否可接受（热启动、冷启动、页面切换、前后台切换、首字时间、首屏时间等）；页面呈现是否一致完整；超时文案是否符合定义、异常信息显示是否正常；是否有超时重连；安全角度是否会 DNS 劫持、登录 IP 频繁更换、单点登录异常；大流量事件风险（弱网下是否会去更新 apk、下载大文件）。

构造弱网需要借助工具，这里推荐 Fiddler：一是用 Fiddler 配置代理，二是用 Fiddler 抓包（桌面端/移动端都能抓），三是在 Fiddler 里设置网速模拟来构造弱网条件。三步就能把"3G 弱网"这种环境造出来。

安装卸载测试

对需要部署到用户机器上的软件，除了功能，还要关注它能不能成功安装、能不能干净卸载，以及安装/升级过程对原有数据、配置的影响。

好，公式讲完了。现在拿它练手。还记得前面的"门锁"吗？现在用"水杯"来完整走一遍，这也是课件里的经典作业——对水杯设计测试用例。别看它是个日用品，它能完美帮你训练万能公式：

功能测试：能装水；能保温/隔热（如果是保温杯）；容量大小与标识一致；有水嘴/杯盖的，开合、倒水是否正常；密封是否漏不漏水。

界面测试：颜色、形状、图案是否符合设计；杯身有无异味、毛刺；logo 印刷是否清晰、不会一擦就掉。

性能测试：装 95°C 热水后，杯外壁温度是否在安全范围；从 1 米高处落下是否摔碎；反复开关杯盖几千次是否仍密封。

兼容性测试：能装水、热水、冷饮；能放入车载杯架、是否能被多种杯套容纳；能不能放微波炉加热（取决于材质说明）。

易用性测试：单手能不能轻松开盖；杯口大小是否方便饮用；装满水后拿着是否顺手不累；儿童会不会轻易打翻。

安全测试：材质是否符合食品级安全标准（不含双酚A/BPA）；高温下是否会释放有害物质；杯盖上的密封圈是否啃咬安全。

你发现没有，用公式一拆，一个水杯就能拆出二十多个测试点，而且井井有条，完全不靠运气去碰。这就是万能公式的价值。它的本质是给你一个"分类的篮子"，让你潜意识里的零星想法都有个去处。

思考题（带答案）： 题目：用万能公式，给"一台 ATM 自动取款机"初步整理测试点，至少覆盖功能、界面、安全、性能四个维度。

参考答案（示意，不必穷尽）：功能——插卡是否能识别账户、正确输入密码能否进入、取款金额是否正确扣除、余额不足是否拒绝并提示、退卡是否正常；界面——屏幕提示文案是否清晰、按钮布局是否合理、数字键盘按键是否有反馈；安全——密码输入是否用"**"掩码显示、连续输错 3 次是否锁卡/吞卡、是否有防窥挡板、余额凭条会不会打印出完整账号；性能——多人同时操作时单笔交易响应时间是否可接受、故障时是否及时停机并提示。这只是答案的骨架，你按公式继续往里填即可。

基于需求的设计方法

刚才的公式是"总纲"，那具体到一个功能点时怎么落地？这就要用到基于需求的设计方法。它其实不是某一招，而是所有具体方法的总出入口——测试人员拿到需求文档/产品规格说明书后，围绕需求来设计用例。

基于需求的设计流程可以归纳为三步：

1. 明确需求中的功能点。先把一段需求文字"翻译"成一个个可测试的功能。以邮箱注册为例，功能点就是"账号注册、账号登录"。
2. 结合万能公式设计测试点。再把每个功能点套进功能/界面/性能/兼容/易用/安全的篮子里，扩展出测试点。
3. 用具体设计方法细化。对每个测试点，再用后面要讲的等价类、边界值等方法去填充具体的数据和步骤。

我们可以拿一份"注册邮箱账号"的需求，把这一步走一遍：

需求：用户可以注册网易邮箱账号，提供姓名、电子邮箱地址、密码（6~15 位字符）、确认密码、验证码输入框，点击"注册"按钮完成注册，注册后可用该账号登录邮箱。

功能点：注册、登录。 针对注册，结合万能公式扩展：

• 功能：必填项校验（哪些必填）、格式校验（邮箱格式、密码位数）、密码与确认密码一致性、验证码正确性、重复注册提示、注册成功后跳转。
• 界面：各输入框、按钮样式与设计图一致，错误提示文案是否清晰、位置是否正确。
• 性能：点击注册到返回结果页的响应时间是否可接受。
• 安全：密码传输/存储是否加密、密码是否明文回显。
• 易用性：必填项是否有星号/提示，输入错误是否有即时反馈。
• 兼容性：在不同浏览器、不同设备上注册流程是否正常。

你看，把"功能点 × 万能公式"一交叉，测试点就铺开了。但这一步只解决了"测什么"，还没解决**"具体用什么数据"**。比如"密码 6~15 位字符"，到底该试哪些值？总不能从 0 位试到 150 位吧？这就引出了真正精细化的方法。

下面开始逐个讲六种具体设计方法。每一种我都会说清"它解决什么问题 → 具体怎么做 → 一个完整例子 → 有什么坑"。

等价类划分法

先回到"密码 615 位字符"这个点。如果用穷举法，你要试 6 位、7 位、8 位……一直到 15 位，这还不算 15 位和 15 位以上这些非法情况。假设范围再改成"6~150 位"，你要试到猴年马月？穷举在软件测试里是不可能完成的，因为输入的集合几乎是无穷的。

等价类划分法（Equivalence Partitioning） 就是为解决穷举问题而生的。它的核心思想是：依据需求，把输入（特殊情况下也考虑输出）划分成若干个"等价"的类，从每个类中选出一个代表作为用例。如果这个代表测试通过了，就认为这一类都通过了。 这样就可以用较少的用例，达到尽量多的功能覆盖。

生活里到处是等价类的例子。老师给学生"因材施教"，但学生太多教不过来，只能先分组：优等生扩展知识面与综合能力，中等生夯实基础、查缺补漏，后进生优先掌握重点、暂时跳过难点。这里的"分组"，背后就是一种等价类思想——不是对每个学生单独定方案，而是把学生按水平划成几类，每类用一种策略。

等价类分为两种：

• 有效等价类：对于程序的规格说明书是合理、有意义的输入数据构成的集合。用它来验证程序是否实现了规格说明规定的功能。
• 无效等价类：根据需求说明书，不满足需求的输入集合。用它来验证程序对非法输入的处理是否正确。

这里我要特别强调一个新手误区：很多人只想着有效等价类，把无效等价类漏了。 记住前面万能公式里"设计用例要基于无效和未预料到的输入"这条原则——无效等价类恰恰是测试里最容易发现 bug 的地方，比如你随便输一串乱码邮箱，程序到底会不会崩、会不会给出友好提示，这才是考验程序健壮性的关键。

根据等价类设计用例的方法：

1. 划分有效等价类和无效等价类（把每一种合法区段和每一种非法区段都列出来）；
2. 针对每个等价类编写用例，设计具体测试数据——一般一个有效等价类一个用例，一个无效等价类一个用例（因为无效类的用例更适合一条条分开验证，避免一次输入多个无效值掩盖了程序的真实判断逻辑）。

以"密码 6~15 位字符"为例，我们来划分：

有效等价类：字符长度为 6 位的合法密码；字符长度为 714 位之间任意一个合法密码；字符长度为 15 位的合法密码。可以合并成"长度 615 位的任意字符"这一个有效类，也可以拆成三个分别测端点以配合边界值（下一节）。

无效等价类：长度小于 6 位（如 0~5 位）的密码；长度大于 15 位的密码；空密码（什么都不填，特殊的一种无效等价类，因为很多系统会把"必填"单独校验）。

注意事项：划分等价类时，还要考虑输入数据的"类型边界"。比如"邮箱地址"这个字段，合法数据得是符合邮箱格式的字符串（如 x@qq.com），无效数据包括：不带 @ 的字符串、带空格、纯数字、只有后缀、内容超过长度限制等。每一个"不合规的格式"理论上都可以是一个独立的无效等价类。

等价类的一个明显缺点是：它只考虑了输入域的"分类"，没有考虑输入域之间的"组合"。多个输入字段之间如何互相影响（比如"邮箱合法但密码非法"系统该怎么反应），等价类覆盖不了——这正是后面正交法和判定表要补的活。

思考题（带答案）： 题目：请为"手机号"字段（需求：11 位、以 1 开头、纯数字）划分有效等价类和无效等价类。

参考答案：有效等价类——11 位、以 1 开头的纯数字（如 13812345678）。无效等价类——长度为非 11 位（少于 11 位或多于 11 位）；不以 1 开头；包含非数字字符（含字母、空格、符号）；空值（不填）。需要说明：以上每个无效等价类建议各成一个用例，让系统"每错一次都能被精准抓到"，避免一次输多个错值导致系统报哪个错都说不清。

边界值分析法

边界值是等价类最好的搭档，通常作为等价类的补充，它的用例大多来自等价类的边界上。

什么是边界问题？先讲个段子。考完试老师布置寒假作业：超过 60 分的把题目抄 1 遍，低于 60 分的抄 3 遍。于是小明没写作业——因为他刚好考了 60 分。老师"超过 60 与"低于 60"的规则，没有规定"等于 60"怎么处理，这就是典型的边界漏洞："含不含端点"没说清，bug 就钻空子。

边界值分析法（Boundary Value Analysis） 就是对输入或输出的边界值进行测试的一种黑盒方法。为什么边界值得我们重点测？因为大量 bug 恰恰产生在"边界处"——程序员判断条件多用 >、>=、<、<=，符号写串一位、等于的情况漏写，一段范围就会在端点出错。所以边界是错误高发地带。

边界值往往包含"边界值本身"和"次边界值"（紧挨着边界的值）。 通常的取值习惯是：取 最小值-1、最小值、最大值、最大值+1（统称为 min-1、min、max、max+1）。看课件里的三个例子你就明白了：

1. 输入框长度要求 1~11，取边界值：0（min-1）、1（min）、11（max）、12（max+1）。
2. 运动员参赛项目 1~3 项，取边界值：0 项、1 项、3 项、4 项。
3. 查询页面共 999 行、每 50 行一页，取边界值：输出 0 行、1 行、50 行、51 行、999 行。

接下来有一个特别容易晕的坑，我必须单独拎出来讲清楚，也是面试爱问的点——开区间与闭区间的取法：

• 闭区间（包含端点，用方括号 [min, max] 表示）时，合法边界是 min 和 max 本身，边界用例取 min-1、min、max、max+1。比如"1~11 位"，合法的是 1 和 11，要额外测 0 和 12（它们属于非法的一侧，但紧贴边界）。
• 开区间（不含端点，用圆括号 (min, max) 表示，或写成"大于 x、小于 y"）时，比如"成绩要大于 60 分才算及格"，那么 60 本身就不是合法值，边界用例要取 59、60、61，其中只有 61 及以上合法，60 和 59 都应该触发"不及格"。

所以拿到需求时，第一件事是判断这个边界到底是开区间还是闭区间——"615 位"到底含不含 6 和 15，从""字面上看通常视为闭区间，即包含两端，那么边界测试用例就是 5、6、15、16。把这个判断做对，你才不会被"到底取几个值"这种问题卡住。

注意：边界值和预期结果要成对校验。 比如测"6 位密码"，预期是注册成功；测"5 位密码"，预期是提示"密码不得少于 6 位"。边界用例的价值正在于"刚好合法"和"刚好非法"这两个节点的行为是否都正确。

实操层面，我们常把边界值和等价类配合起来用，形成一套组合拳：

• 用等价类确定"在该测哪些区间"（合法区间、非法区间各是什么）；
• 用边界值确定"每个区间端点附近具体测哪几个数"。

这样既覆盖了代表值，又覆盖了最容易出错的值点。

思考题（带答案）： 题目：需求是"年龄 18~60（含），且为整数"，请用边界值法列出应测的年龄，并说出每组数值对应的是哪一方。

参考答案：取 17（min-1，非法/偏小一侧）、18（min，合法下界）、60（max，合法上界）、61（max+1，非法/偏大一侧）。另外可补一个"范围中间的典型值"，如 30，作为合法代表。核心是四剑客 min-1/min/max/max+1 都要测到，同时确认 18 和 60 恰为闭区间内包含的合法端点。

正交实验法

走到这一步，我们用等价类和边界值已经能把"单个字段"测得很细了。但前面说过，等价类的短板是不考虑字段之间的组合。

回想邮箱注册的 5 个选项：姓名、电子邮箱、密码、确认密码、验证码。每个都只有两种状态——"填写"、"不填写"。要是用排列组合去测，2 的 5 次方等于 32 个用例。这还没算其他字段，组合数会爆炸成天文数字。而实际工作中，我们并不想为"只填了部分选项"这种场景把 32 个用例全跑一遍——我们想知道的是：用尽量少的用例，尽量多地覆盖字段之间的两两组合。

这就是正交实验法（Orthogonal Experimental Design）。正交试验设计是研究多因素多水平的一种设计方法，它根据正交性，从全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析，来了解全面试验的情况——它是一种基于正交表的、高效率、快速、经济的设计。

先解释三个正交表里的词，这是理解的正交的前提：

• 因素（Factor）：对试验结果有影响的条件，通常对应正交表中的一列。在注册例子里，姓名、邮箱、密码、确认密码、验证码就是 5 个因素。
• 水平（Level）：每个因素对应的可选项。这里每个因素都有"填写、不填写"两个水平。
• 行数：要做多少次试验（也就是生成多少个用例）。

正交表用 L 数字(……) 表示，比如最简单的正交表 L4(2(3))，含义是：L 代表正交表；右下标数字 4 表示有 4 横行，也就是做 4 次试验；括号内的指数 3 表示有 3 纵列，即最多允许安排 3 个因素；括号内的数字 2 表示表的主要部分只有 2 种数字，即每个因素有 2 个水平。

正交表有两个重要性质：（1）每一列中，不同的数字出现的次数相等；（2）任意两列中数字的排列方式齐全且均衡。 正因为有这两条性质，一般人是很难徒手设计出正交表的，实际中我们靠工具。

用正交法设计测试用例的步骤：

1. 找到因素和水平；
2. 用工具（如 allpairs 论文和资料里常提到的 pairwise 算法工具，课件的例子用的是 allpairs.exe）生成正交表；
3. 根据正交表编写测试用例；
4. 补充遗漏的重要测试用例（工具生成的可能和"标准正交表"略有出入，但不影响用来设计用例）。

以邮箱注册为例，走一遍步骤：

1. 找因素和水平：因素 = 姓名、电子邮箱、密码、确认密码、验证码；水平 = 填写、不填写。
2. 生成正交表：把所有"因素/水平"写进 Excel；在命令行工具目录下建一个文本文件（如 new.txt），把因素和水平粘贴进去保存；执行类似 allpairs.exe new.txt > zhengjiao.txt 的命令，把生成的正交表输出到文件。
3. 根据正交表写用例。5 个二水平因素选用 L8 正交表，砍到 8 个用例即可覆盖所有的两两组合。这里我给出一个 L8(2^7) 标准表的示意（正式以 allpairs 输出为准），前 5 列分别对应姓名、邮箱、密码、确认密码、验证码，水平 1=填写、水平 2=不填写：

（注：这张示意表把 32 个全组合压缩到 8 个代表行，同一行内任何两列的组合，在整张表里都出现且均衡覆盖，这正是正交的思想。）

4. 补充遗漏的重要用例：正交表只保证两两组合覆盖，一些"全都不填"、"全部填写"这种极端或逻辑关键的组合，可能不在表里，需要手动补上，例如补"5 项全都不填写"这一条，确认系统能否正确提示必填项。

正交法定量的意义在于：用局部代表试验来近似覆盖全面试验，在用例数量与覆盖率之间取得平衡。 它非常擅长处理"字段多、各自独立、组合爆炸"的场景。

思考题（带答案）： 题目：假设某表单有 3 个下拉框 A、B、C，每个下拉框有 2 个取值（1 和 2），用排列组合会有 8 个用例。请说明为什么用正交法可以减少用例，并指出正交法主要保证了什么覆盖。

参考答案：当面做全组合要 2×2×2 = 8 个用例，但很多组合对测试结果没有独特的区分价值。正交法从全组合中挑出"代表点"，用 4 个左右的用例（如 L4 型正交表）就能保证任意两个因素之间的两两组合都被覆盖到。它的覆盖重点是"两两组合"，而不是"全部组合"——这正是它省用例的原因，也是它覆盖不全面的边界（极端全组合若在图中缺失需手动补）。

判定表法

等价类和边界值把单个字段测透了，正交法把"互不影响"的多字段两两覆盖做了。但现实中有另一类需求：输入组合不同，结果就不同，而且存在明确的逻辑关系。 这种场景正交法就无能为力了，需要判定表来登场。

我们先看一个经典需求：

用户输入的账号中包含 admin 字符，或者通过内部链接进入注册页面，并且提交注册按钮，就成为管理员身份；反之无管理员身份。

注意这里的"并且"和"或者"——结果不再是一对一的，而是由条件的组合决定，不同组合对应不同结果。正交法能处理"需要考虑组合"的场景，但处理不了"组合背后还有逻辑关系"的场景，这种就要用判定表。

判定表（Decision Table） 是一种表达逻辑判断的工具，它能清晰地把"所有条件 → 所有结果"的关系列成一张表。根据判定表法设计测试用例的步骤：

1. 确认需求中的输入条件和输出条件；
2. 找出输入条件和输出条件之间的关系（用逻辑表达式表达）；
3. 画判定表（条件桩、条件项、动作桩、动作项）；
4. 根据判定表编写测试用例。

拿上面的需求走一遍：

第一步，确认输入条件和输出条件。

• 输入条件 a：账号包含 admin 字符
• 输入条件 b：通过内部注册链接进入
• 输入条件 c：点击注册按钮
• 输出条件：管理员（1）、无管理员（2）

第二步，找出输入输出之间的关系。 成为管理员的逻辑是：(a 或 b) 且 c，即 (a OR b) AND c，缺一不可。用逻辑表展开所有 2³=8 种组合：

（逐行核对：只有"点击注册"这一条件必须为"是"，同时 a 或 b 至少一个为"是"时，结果才是管理员，其余都是无管理员。）

第三步，画判定表（把上表规整成条件项/动作项的矩阵，这就是判定表的标准形态）。

第四步，根据判定表编写测试用例。 从上面 8 个组合翻译成可执行用例：

• 账号包含 admin、非内部注册链接、点击注册按钮 → 应为管理员身份。
• 账号包含 admin、内部注册链接、不点击注册按钮 → 应为非管理员身份。
• 账号不包含 admin、内部注册链接、点击注册按钮 → 应为管理员身份。
• 账号包含 admin、内部注册链接、点击注册按钮 → 应为管理员身份。
• 账号包含 admin、非内部注册链接、不点击注册按钮 → 应为非管理员身份。
• 账号不包含 admin、非内部注册链接、点击注册按钮 → 应为非管理员身份。
• 账号不包含 admin、内部注册链接、不点击注册按钮 → 应为非管理员身份。
• 账号不包含 admin、非内部注册链接、不点击注册按钮 → 应为非管理员身份。

看到没有，判定表把"条件组合 → 动作结果"的每一个分支都推演清楚了，一个不多、一个不少。它的价值在于：强制你覆盖所有组合，并且把逻辑关系显性化，避免靠直觉漏测某个分支。

这里补一个易混点：判定表和正交法到底区别在哪？

• 正交法：字段之间没有明确的逻辑后果差异，只想"两两组合都试到"，用于减少用例数量。
• 判定表：字段组合决定不同的结果，必须逐个组合给出预期结果，用于覆盖多条件逻辑判断。

使用范围：判定表适合"条件多、每个条件取值有限、条件之间有组合逻辑、且一个条件的判断要参考另一个条件"的场景（比如登录鉴权、订单状态流转、优惠券叠加规则）。当条件多到排列组合爆炸（比如 8 个条件），判定表也会膨胀，此时往往配合正交法先降低用例量。

思考题（带答案）： 题目：需求"当会员等级为 VIP 或消费金额满 500 元，且勾选了'使用积分'时，可以使用积分抵扣；其余情况不可使用积分抵扣"，请列出判定表的所有组合与结果。

参考答案：设条件 A=VIP 会员、B=消费满 500、C=勾选使用积分。可使用积分的条件是 (A 或 B) 且 C。组合：A是B否C是→可用；A是B否C否→不可用；A否B是C是→可用；A否B是C否→不可用；A是B是C是→可用；A是B是C否→不可用；A否B否C是→不可用；A否B否C否→不可用。可见"是否可用"只取决于 C 是否为"是"且 A/B 是否至少一个"是"。

场景法

场景法解决的是另一类大问题。前面所有方法都在"功能点"这个粒度上打转，但一个完整的功能流程往往是多个功能点串起来的，比如"注册 → 验证邮箱 → 登录"这是一整条业务流。如果只盯着单个输入框测，容易陷进功能细节、忽视业务流程要点。场景法就是用来测整条业务流程的。

场景法（Scenario-based Testing）：现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景就形成了场景，同一事件不同的触发顺序和处理结果就形成事件流。简单直白地说——你设计的用例要以"一条完整业务流程"为单位，模拟用户真实的使用路径。

场景法一般包含基本流和备选流：从一个流程开始，通过描述经过的路径来确定过程，遍历所有基本流和备选流来完成整个场景。这里快速定义两个词，生活化理解最好：

• 基本流（基本路径）：一条顺利走到底的"常规流程"，没有任何意外。
• 备选流（备选路径）：流程中某一阶段出现了"意想不到的情况"时走的分支。

场景主要包括四种类型：正常的用例场景、备选的用例场景、异常的用例场景、假定推测的场景。

课件里用"逛街买衣服"的例子讲得特别形象，我复述给你听：

基本流：逛街 → 去服装店 → 选衣服 → 买衣服。

各阶段可能出现的备选流：

• 逛街阶段：临时有事，出现导致不逛街了 → 备选流：重新规划逛街时间。
• 去服装店阶段：遇到意外去不了 → 备选流：寻找其他去服装店的机会。
• 选衣服阶段：选了但一直没合适的 → 备选流：继续寻找满意的衣服。
• 买衣服阶段：价格或其他方面不满意 → 备选流：重新寻找满意的价位。

你看，一条"逛街买衣服"的主线，被拆出了四条备选流。等把这些基本流和备选流全部走完，整套逛街业务的测试场景才算覆盖完整。这个方法最能体现发散思维——你能不能在每个阶段都想到"可能会出什么岔子"。

场景法设计测试用例的步骤：

1. 确定基本流；
2. 确定备选流；
3. 根据备选流补充测试用例；
4. 编写测试用例。

（照旧）用邮箱注册案例走一遍：

确定基本流：输入账号密码 → 点击注册 → 系统发送确认邮件 → 确认邮件 → 注册成功。

确定备选流：

• 账号密码输入异常（全部不输入、只输入部分、账号已注册）→ 重新输入；
• 网络异常；
• 发送邮件失败；
• 邮件接收失败（客户端未收到）；
• 服务端发送失败；
• 收到邮件但未在 24 小时内确认；
• 确认的不是最新发送的那封邮件。

根据备选流编写测试用例：

1. 输入正确的账号密码，点击注册后系统发出确认邮件，并在 24 小时内确认 → 注册成功。
2. 不输入账号密码就点击注册 → 提示重新输入。
3. 只输入账号、不输入密码就点击注册 → 提示重新输入。
4. 输入已注册的账号 → 提示账号已存在。
5. 网络异常时点击注册 → 有友好报错，且不产生脏数据。
6. 邮件服务端发送失败 → 提示稍后重试或支持重发。
7. 用户在 24 小时之外才确认邮件 → 确认链接失效，需重新触发。
8. 客户端收到邮件但系统仍未置为"已确认"状态 → 状态不一致时要能同步/纠正。

你发现了吗，场景法的产出不是一个个孤立输入框的用例，而是一条条带前后因果的完整故事线。正因为如此，能用"业务流"把各个孤立的点串起来，为测试人员建立整体业务感觉，避免"捡芝麻丢西瓜"。

思考题（带答案）： 题目：为一个"网上订餐流程：浏览菜单 → 加购物车 → 下单支付 → 商家接单 → 配送 → 确认收货"设计基本的场景分析和备选流。

参考答案：基本流——浏览菜单→加购物车→下单支付→商家接单→配送→确认收货。备选流示例——①浏览菜单时商品已售罄/下架；②加购物车后长时间未支付被清空；③支付失败（余额不足、网络断开、重复支付）；④商家接单前用户申请取消订单；⑤配送超时/骑手联系不上；⑥用户误点确认收货。每一支备选流都可以各写一条或数条用例（如"支付失败→可重试→不可重复扣款"）。

错误猜测法

最后一个方法最"玄学"也最实用——错误猜测法。

错误猜测法（Error Guessing） 是基于对被测试软件设计的理解、过往经验以及个人直觉，推测软件可能存在的缺陷，从而针对性设计测试用例的方法。它强调的是对需求的理解、对设计实现细节的把握，以及个人的经验和直觉。

错误猜测法和现在流行的"探索式测试"基本思想一致，在敏捷开发模式下投入产出比很高，被广泛用于测试。说它"玄学"是因为它依赖个人功力，说它"实用"是因为它的用例往往一击命中真实 bug。

用一句话体会它的感觉：当你一提到某个很熟悉的名字，脑海会立刻浮现对他的评价——提到"武大郎"你会想到憨厚老实，提到"潘金莲"你会想到美丽精明。测试老手看到一段功能，脑子里会自动蹦出"这里大概率会出什么错"，这就是错误猜测法。

课件里"张三要去卖瓜"的例子特别生动：

• 用例 1：张三这人不实诚，小心他缺斤少两——（对应：数值校验可能不严）；
• 用例 2：张三这人粗心，小心他的瓜被压坏了——（对应：异常输入处理可能疏忽）；
• 用例 3：张三这人小气，小心不要把他惹哭了——（对应：边界/极端情况的容错）。

这个方法的缺点是难以系统化，并且过度依赖个人能力。 所以实际项目中，它通常不是独立使用，而是作为等价类、边界值、判定表等系统化方法用完之后的"查漏补缺"层。

以注册功能为例，错误猜测法能猜出这些典型坑：

1. 校验中特殊字符、空格的处理（用户名里带空格、前后空白会不会被误判）；
2. 密码校验中的大小写（"Abc123" 和 "abc123" 是否算同一个密码，规则是否说清）；
3. 姓名中的特殊字符（emoji、生僻字、超长姓名能否正常保存显示）；
4. 密码发送是否明文（网络抓包或日志里是否泄漏密码）。

这一节想传达的最重要观念是：等你经验攒多了，你的"直觉"其实都是有规律可循的——无非还是"没做它该做的、做了它不该做的、边界没处理好、异常没兜住"。所以错误猜测法不是让你凭空碰运气，而是把前面所有方法的"潜意识化"。

思考题（带答案）： 题目：对"登录输入密码的输入框"，请用错误猜测法预测 3 个它可能存在的缺陷，并说明对应的用例方向。

参考答案（示例，不必唯一）：①按下 Enter 键能否提交——若只实现了点击按钮的提交事件，键盘回车可能无效，用例为"输入密码后按回车看能否登录"；②密码是否明文回显——若输入时显示明文，则泄漏隐私，用例为"输入时观察密码是否用掩码掩盖"；③连续多次输错是否有限制与倒计时——若无限重试会被暴力破解，用例为"连续输错 5 次后是否锁定或出现验证码"；④复制粘贴过来的超长 / 含空格密码是否被正确处理。

更多用例练习：命令行程序与接口

纸上谈兵到此为止，这部分我们做两组"跨题型"的实战练习——因为不同技术形态的被测对象，用例设计的落地点完全不一样。

命令行程序：给 zip/unzip 设计用例

有些功能没有图形界面，只有命令行，比如用 zip/unzip 命令对文件压缩解压。这种"无界面程序"主要靠功能、性能、兼容、可用性、安全维度去拆，界面维度退化为"命令行提示是否友好"。

功能测试：

1. 普通 txt 文件能够生成 zip 文件；
2. 图片/视频/zip 文件能够生成 zip 文件；
3. 多个文件能够生成 zip 文件（混合文件）；
4. 空文件夹可以生成 zip 文件；
5. 错误命令是否会报错（如 zip zip 后没写压缩包文件名称、没有源文件等）；
6. 其他参数（如压缩级别、递归 -r、覆盖 -f 等）的测试。

界面测试（命令行提示）：

1. 文件压缩成功时命令行提示是否美观、明确；
2. 文件压缩报错时命令行提示是否友好（把"哪里错了、怎么改"说清楚）。

性能测试：

1. 文件大小超过 1G 时是否能够压缩成功；
2. 超过 1G 时压缩耗时是否在合理范围内。

兼容性测试：

1. zip 工具能否在 Windows、Linux、Mac 等多系统上使用；压缩出的 zip 在不同系统间能否互相解压。

易用性测试：

1. 命令是否有使用帮助（如 zip --help 能展示用法）。

安全测试：

1. 使用 zip 命令压缩不会意外泄漏文件内容（权限、加密选项是否正确）。

你看，命令行工具也照万能公式拆得明明白白，这就是框架的威力。

Web 接口：给博客详情接口设计用例

现在很多测试是接口级测试。以"博客系统"的博客详情接口为例，接口形如：

http://192.168.47.135:8080/blog_system/blog?blogId=10

对这种接口，用 curl 在命令行上也能测，但实际工作中常用接口测试工具（最出名的就是 Postman）来提升效率。给它设计用例，重点看这些维度：

不同的请求方式：

1. 用 GET 方式请求，接口是否能返回预期响应数据；
2. 用 POST 方式请求接口，是否也能返回合理的数据或合理地被拒绝。

参数组合（若接口需要拼参数）：

1. 空参数；
2. 多参数（多传了没要求的参数）；
3. 少参数（少了必填参数）；
4. 参数对应的值为空/过长/特殊字符等。

不同的参数格式：

1. URL 拼参；
2. form-data 格式；
3. raw 格式等等。

接口性能：

1. 大量请求同时发起（如并发 1000 个），是否都能返回响应；
2. 并发情况下响应时间是否在大众可接受范围内。

Postman 的使用要点（若你还不熟，快速铺垫）：Postman 里主要是"请求类型（GET/POST）+ 请求 URL + 发送按钮 + 请求参数 + 请求头 + 请求体"。添加一个请求有两种方式：手动填写；或者打开浏览器开发者工具复制接口 URL，再到 Postman 里点击 Import——选择 "Raw text" 方式导入，粘贴复制好的 URL，continue，再 Import，接口就被导入成功了。经常用的接口还可以保存到 Collection 文件夹里，下次直接在对应文件夹下选它即可，不用重复填写。

到这里，我们把六种方法 + 万能公式 + 两套跨题型实战都过完了。你有没有一种感觉：所谓"会设计用例"，不是靠灵光一现，而是有一套可以按顺序执行的"脚手架"。下面我们聊聊最后一块拼图——怎么保证你写的这套东西本身是靠谱的。

用例评审：用例好不好，得有人把关

字写完了，是不是就完了？远远没有。一个高质量的用例集，需要一个关键环节来把关，那就是用例评审。

为什么需要评审？因为测试用例是团队协作的产物，不是测试一个人闷头写就完事。你基于自己的理解写的用例，可能：

• 对需求理解有偏差（你以为要这么测，产品说根本不是这个逻辑）；
• 覆盖不全（漏了某个重要模块或边界）；
• 步骤不可执行（别人照着你写的步骤根本没法复现）。

用例评审就是召集相关角色（产品经理、开发、测试，必要时加运维/UI）一起，把用例集过一遍的制度化流程。它的价值有三点：一是纠正理解偏差，让用例和真实需求对齐；二是查漏补缺，靠评审者不同的视角补足你遗漏的测试点；三是提高可执行性，确保每一条用例步骤清晰、预期明确、别人能照着跑。

评审时重点关注这几类问题：

• 需求符合性：这条用例测的需求点是不是真实存在、是否对应已确认的需求；
• 覆盖完整性：每个功能点是否都有对应用例，边界、异常、无效输入是否考虑了（这正好呼应了全课反复强调"至少一例无效等价类"和"边界值齐全"的原则）；
• 用例间一致性：编号是否唯一、命名是否规整、是否存在可合并的冗余用例；
• 可执行性：前置条件、测试数据是否写清，步骤是否可复现，预期结果是否可判定。

值得提醒的是：评审不是测试的"走形式"，而是质量保障的一环。 养成"写用例 → 自查 → 提交评审 → 按意见修订"的闭环习惯，你的用例质量才能真正稳定在及格线以上。评审中提出的问题也要做记录和闭环追踪，别评审完就翻篇。

经过评审定稿的用例，还要注意维护：需求一旦变更，用例要同步更新，否则用例和实际功能脱节，那套用例就失效甚至误导人了。

完整实战：给登录功能设计一套用例

最后，我们来一道"综合大作业"——给最经典的登录功能设计测试用例。这道题面试笔试都高频出现，我会把它从头走完，作为本课所有方法的一次汇总演练。刚才课件里的课堂练习也是它：明确需求 → 用万能公式 + 用例方法设计用例 → 按用例测试 → 记录结果。

第一步，明确需求。 登录功能需求一般约定：用户输入账号、密码，点击登录；账号为 11 位手机号；密码为字母和数字组合；校验通过则进入首页，校验失败提示错误并可重试，连续失败有次数限制。

第二步，用万能公式 + 具体方法拆测试点。

功能测试（这里集中用到等价类 + 边界值 + 场景法）：

• 正确的账号密码登录成功（有效等价类）；
• 错误的账号/错误的密码登录失败并提示（无效等价类）；
• 账号为空、密码为空分别提示（无效等价类 + 边界）；
• 账号位数非 11 位、不以 1 开头（边界值 + 无效等价类：10 位、12 位、0 位）；
• 密码不含数字、不含字母、长度超限（边界值）；
• 密码与账号格式同时非法时系统的判断优先级（判定表/组合）；
• 正确账号 + 错误密码、错误账号 + 正确密码的组合（判定表分支）；
• 连续输错 3 次后是否锁定/出现验证码（错误猜测法 + 边界）；
• 登录成功后跳转首页、记住登录态（场景法基本流）；网络异常登录、token 过期再登录（场景法备选流）。

界面测试：

• 登录表单布局与设计图一致，提示文案清晰无错别字；密码输入框用掩码显示。

性能测试：

• 点击登录到进入首页的响应时间；高并发下登录接口是否稳定。

兼容性测试：

• 主流浏览器（Chrome/Edge/Firefox/Safari）、主流手机机型与系统版本下登录是否正常。

易用性测试：

• 首次使用者能否快速找到账号密码框和登录按钮；键盘回车能否直接提交；输错后有清晰正确的纠错指引。

安全测试：

• 密码传输是否走 HTTPS/加密；是否明文回显密码；防暴力破解（次数/频率限制）；是否有越权（测出别人的登录态）；SQL 注入防护（账号密码里塞注入语句）。

第三步，落成表格式用例（节选几条，展示格式）：

（这只是示例节选，实际你要按前面的测试点把十来个甚至更多用例都列出来。）

第四步，按用例执行并记录。 每执行一条，记录实际结果与预期是否一致，不一致的就是 bug，录入缺陷管理并跟踪。

到这，你要能独立完成对任何一个功能的用例设计了。方法就这么多，剩下的全是反复练习练出的"手感"。

写到这里，我们把测试用例这件事从头到尾走了一遍：从"用例是什么、要素有哪些"到"设计用例的万能公式（功能/界面/性能/兼容/易用/安全）"，再到六种具体的设计方法——等价类去解决"输入太多测不完"、边界值专门盯最容易出错的端点（并说清了开闭区间的取法）、正交法用少量用例覆盖多字段两两组合、判定表把多条件的逻辑关系显性化、场景法把你的视野从单个点拉回到整条业务流、错误猜测法靠经验和直觉查漏补缺；之后我们用命令行程序和接口做了一组跨题型实战，最后用用例评审收住"质量把关"这一环，并以登录功能为模板做了一次全流程演练。

回看整篇文章，有一条主线贯穿始终：好的用例设计不是靠运气碰出来的，而是靠一套能按步骤执行的思维工具拆出来的。 万能公式保证你不抓瞎，等价类和边界值保证你单点测得深，判定表和正交法保证你组合测得全，场景法保证你流程测得顺，错误猜测法保证你兜得住漏网之鱼。把这套"脚手架"练进肌肉记忆，你面对任何陌生需求都不会再无从下手。

方法本身你已经都拿到了。接下来真正拉开差距的，只剩一件事——拿起你手边任何一个真实需求，照着这篇文章的步骤，把它从头拆到尾，把每条用例写出来再去执行。写用例时多问一句"这里有没有无效输入？边界值取齐没有？逻辑组合覆盖了吗？流程走通了吗？"，等你把这些问句变成直觉，你离"资深测试"就真的不远了。

对了，课件最后留了一个作业：给 Linux 的 "cd" 命令设计一套用例。这里也给你留一道类似的自测题，做完之后，你就把命令行类程序也从头到尾练过一遍了。

思考题（带答案）： 题目：请为 Linux 命令 cd（切换目录）设计测试用例（提示：考虑参数有效/无效、目标存在/不存在、权限、路径类型、错误提示等）。

参考答案（示例）：功能——①cd /root 切到存在的绝对路径成功，pwd 显示正确；②cd dir 切到当前目录下存在的相对路径成功；③cd .. 回到上一级成功；④cd ~ 切到用户主目录成功；⑤cd 不存在的路径 报 "No such file or directory" 且目录不变；⑥cd 文件路径（目标是文件而非目录）报错；⑦cd 无参数 恢复到用户主目录；⑧对无权访问的目录切不进去并有权限提示。异常/边界——空字符串、含空格/中文/特殊字符的路径、超长路径。界面（提示）——错误提示是否清晰贴切。兼容性——在 bash、sh 等常见 shell 下行为一致。易用性——帮助 help cd 是否可用。学习完可与命令行作业互相对照。