软件测试用例设计：五类经典方法实战与避坑指南

简介：这份资源面向软件测试初学者与需要系统梳理用例设计方法的从业者，聚焦测试用例编写这一核心技能，通过经典实例帮助读者理解如何把测试理论落到具体场景中。压缩包内共1个doc文档，约329KB，内容围绕黑盒测试展开，涵盖等价类划分、边界值分析、错误推测、因果图与判定表驱动等常用方法，并配有登录功能、三角形判定、NextDate函数、自动售货机等典型示例，同时整理了优秀测试用例应包含的要素清单。已有4779人学习下载，说明其在测试入门与面试复习场景中具有一定参考价值。读者可从中获得可直接借鉴的用例模板、设计思路与场景拆解方式，用于对照练习、查漏补缺，提升用例覆盖度与编写效率。

1. 从一份登录用例说起：为什么“经典实例”比框架文档更值得先啃

很多同学做软件测试课设，第一反应是去搭一套自动化框架，结果用例本身写得漏洞百出，脚本跑得再顺也只是把错误固化下来。真正卡住交付的，往往不是工具，而是“这条用例到底该覆盖什么”。这份《软件测试用例的经典实例》把黑盒测试里最常用的五类设计方法——等价类划分、边界值分析、错误推测、因果图、判定表驱动——全部落到具体例子上：登录功能、三角形判定、NextDate 日期函数、自动售货机、设备维修优先级。它适合两类人：一是要交测试用例设计作业、需要一套能直接对照改写的模板的学生；二是要出一份可评审的测试方案、需要把用例设计讲清楚的从业者。下面按“需求怎么立、用例怎么设计、怎么落地、怎么验收”的顺序拆开讲。

2. 需求与用例规格：先把一条用例该有的字段立住

2.1 一条合格用例的十二个字段

原文列了十二条，我按实际写用例时的填写顺序重新排一下，并补上每条为什么不能省：

这里有个血泪经验：预期结果写“登录成功”是无效的，必须写到可观测的层面，比如“跳转至首页，页面顶部显示当前用户名 test”。预期结果越具体，后面判定通过与否就越没有扯皮空间。

2.2 用登录功能把字段填满

原文给了一个 B/S 结构登录功能的黑盒用例，被测对象是登录页，假设浏览器为 IE6.0 SP4。功能描述四条：地址栏输入地址显示登录界面；输入用户名密码后系统校验并提示；任一信息未输入给出提示；连续 3 次未通过自动关闭 IE。把它整理成可执行的用例表，核心几条如下：

用例ID: LOGIN-AUTH-001 用例名称: 系统登录-成功路径 前置条件: 已存在用户 test/test，浏览器已打开登录页 步骤1: 用户名输入 test 预期: 输入框正常回显 步骤2: 密码输入 test 预期: 密码以掩码显示 步骤3: 单击登录按钮 预期: 进入系统首页，顶部显示 test 依赖: 无

用例ID: LOGIN-AUTH-006 用例名称: 系统登录-用户名密码均未输入 前置条件: 登录页已打开 步骤1: 不输入任何内容，单击登录按钮 预期: 登录失败，提示“请检查用户名和密码的输入是否正确”

原文那张表里 TC1 到 TC10 覆盖了初始页面显示、用户名录入、用户名容错（超长输入被拒绝）、密码录入、成功登录、双空校验、仅缺密码、密码错误、用户名不存在、连续三次失败锁定。这套划分的价值在于：它把“登录”这个看似简单的功能拆成了输入合法性、组合校验、安全策略三层，每层都有独立用例，评审时一眼能看出哪层没覆盖。

提示：TC3 那条“输入到蓝色显示的字符时系统拒绝输入”，本质是输入长度上限的边界验证，写用例时要把上限值明确成数字，别只写“超长”。

3. 五类设计方法的落地：从等价类到判定表怎么选、怎么写

3.1 等价类划分：三角形判定的有效类与无效类

三角形判定是等价类的经典题：输入三个整数 a、b、c 作为边长，判定一般三角形、等腰三角形、等边三角形。原文先列出输入条件要求：整数、三个数、非零、正数、两边之和大于第三边、等腰、等边，然后分有效类和无效类。

有效等价类用例（覆盖条件 1~7）：

a b c 覆盖等价类 预期输出 3 4 5 (1)-(7) 一般三角形 4 4 5 (1)-(7),(8) 等腰三角形 4 5 5 (1)-(7),(9) 等腰三角形 5 4 5 (1)-(7),(10) 等腰三角形 4 4 4 (1)-(7),(11) 等边三角形

无效等价类则要逐条打破：非整数、只给两个数、含零、含负数、两边之和不大于第三边。设计说明：有效类用最少用例覆盖全部有效条件，无效类每条只违反一个条件、其余保持有效，这样一旦失败能立刻定位是哪个约束没实现。这是等价类最容易翻车的地方——很多同学一条无效用例同时塞进负数和零，失败了根本分不清是哪个校验缺失。

3.2 边界值分析：NextDate 函数的三个变量

NextDate 函数隐含 mouth 取 1~12、day 取 1~31、year 取 1912~2050。边界值就是取每个范围的 min-1、min、min+1、max-1、max、max+1。原文表格里 Test1~Test3 测 year 下边界（1911、1912、1913），Test4~Test7 测 year 上边界（1975、2049、2050、2051），Test8~Test13 测 day 的 -1、1、2、30、31、32，Test14 测 mouth 的 -1，Test15~Test19 测 mouth 的 11、12、13 等。

用例 mouth day year 预期输出 Test1 6 15 1911 年份超出[1912…2050] Test2 6 15 1912 1912.6.16 Test3 6 15 1913 1913.6.16 Test8 6 -1 2001 day 超出[1…31] Test10 6 31 2001 2001.7.1 Test14 -1 15 2001 mouth 超出[1…12]

设计说明：边界值不是只测边界本身，而是测“边界内、边界上、边界外”三点，因为绝大多数 off-by-one 错误就藏在这三点之间。NextDate 还有个隐藏坑——月份天数不同，2 月 28/29、4 月 30 这些跨月进位要单独补用例，原文表格没展开，实际交付时我一般会额外加一组“月末+1”的用例。

3.3 错误推测与因果图：靠经验补盲区

错误推测法针对排序程序，原文列了五类特别情况：空表、单元素、已排好序、逆序、部分或全部元素相同。这类方法没有公式，靠的是对“哪里容易出错”的直觉，比如空表和单元素是循环边界，逆序是性能最坏情况，重复元素是稳定性问题。

因果图用在自动售货机上：投 5 角或 1 元硬币，按橙汁或啤酒按钮出饮料；无零钱时红灯亮，投 1 元按按钮则退币不出货；有零钱时退 5 角并出货。原文把原因（有零钱、投 1 元、投 5 角、按橙汁、按啤酒）和结果（红灯亮、退 1 元、退 5 角、出橙汁、出啤酒）列出来，再引入中间结点（投 1 元且按按钮、按了饮料按钮、应找 5 角且有零钱、钱已付清），最后转判定表。因果图的价值是把“组合条件”可视化，避免漏掉“投 1 元+无零钱+按按钮”这种交叉场景。

3.4 判定表驱动：设备维修优先级的化简

原文的维修判定题：功率大于 50 马力、维修记录不全、运行超 10 年，满足任一即优先维修。三个条件各两取值，规则数 2×2×2=8。列出初始判定表后做化简，把相似规则合并，最终压到 5 条：

规则 1 2 3 4 5 功率>50? Y Y Y N N 记录不全? Y N N - - 运行>10年? - Y N Y N 优先处理 x x x - - 其他处理 - - - x x

设计说明：判定表的化简原则是“无关项用 - 表示，能合并的规则合并”，合并后规则数从 8 降到 5，用例量直接少三成。这里最容易踩的坑是化简过头——把本不该合并的规则并了，导致某个组合没被覆盖。我的习惯是化简后反向验算一遍：每条原始规则是否都能被某条化简后规则命中。

4. 避坑与常见问题：用例设计里最容易翻车的五处

4.1 预期结果写成“功能正常”

现象：用例执行时测试人员和开发对“是否通过”各执一词。原因：预期结果停留在功能层面，没有落到可观测的界面元素、返回值或日志。解决：预期结果必须包含具体文案、跳转目标、数据变化，比如“提示‘错误的密码’且停留在登录页”。

4.2 无效等价类一条塞多个错误

现象：用例失败后无法定位是哪个校验缺失。原因：一条无效用例同时违反多个输入约束。解决：每条无效用例只违反一个条件，其余保持有效，这是等价类的基本纪律。

4.3 边界值只测边界不测邻点

现象：上线后出现“第 32 天”这类 off-by-one 缺陷。原因：只测了 31 和 1，没测 0、32、-1。解决：每个边界取 min-1、min、min+1、max-1、max、max+1 六点，跨月跨年再补进位用例。

4.4 用例依赖没写导致执行顺序错乱

现象：单独跑某条用例失败，按顺序跑却通过。原因：依赖了前一条用例造的数据（如已注册用户 test），但依赖关系字段空着。解决：依赖字段必填，并在前置条件里写清数据来源。

4.5 判定表化简后漏覆盖

现象：某组合条件在测试中从未被执行。原因：化简时把不该合并的规则并了。解决：化简后逐条反查原始规则是否被命中，必要时保留冗余规则。

5. 验收与答辩：用一张覆盖矩阵把用例讲清楚

交作业或答辩时，评审最想看的不是用例数量，而是“你的用例凭什么说覆盖够了”。我一般会做一张方法-场景覆盖矩阵，把五类方法和被测功能交叉打勾，缺哪格一目了然：

答辩时按这个矩阵讲：先说每个功能为什么选这几类方法（登录偏输入校验所以等价类+边界值，售货机偏组合逻辑所以因果图+判定表），再挑一条用例现场走一遍“前置条件→步骤→预期结果”，最后展示无效等价类和边界邻点的用例，证明不是只测了 happy path。评审常追问的两个点提前准备好：一是“你的预期结果依据是什么”，答需求文档章节号；二是“连续三次失败锁定这条怎么验证”，答用循环执行 TC6 三次并检查提示文案与 IE 关闭行为。

从那以后我每次带测试用例的课设或方案评审，都强制先过一遍覆盖矩阵再让人讲用例细节——矩阵缺格的地方，后面讲得再花哨也是虚的。希望帮到你。

本文还有配套的精品资源，点击获取