简介这份资源面向软件测试初学者与需要系统梳理用例设计方法的从业者聚焦测试用例编写这一核心技能通过经典实例帮助读者理解如何把测试理论落到具体场景中。压缩包内共1个doc文档约329KB内容围绕黑盒测试展开涵盖等价类划分、边界值分析、错误推测、因果图与判定表驱动等常用方法并配有登录功能、三角形判定、NextDate函数、自动售货机等典型示例同时整理了优秀测试用例应包含的要素清单。已有4779人学习下载说明其在测试入门与面试复习场景中具有一定参考价值。读者可从中获得可直接借鉴的用例模板、设计思路与场景拆解方式用于对照练习、查漏补缺提升用例覆盖度与编写效率。1. 从一份登录用例说起为什么“经典实例”比框架文档更值得先啃很多同学做软件测试课设第一反应是去搭一套自动化框架结果用例本身写得漏洞百出脚本跑得再顺也只是把错误固化下来。真正卡住交付的往往不是工具而是“这条用例到底该覆盖什么”。这份《软件测试用例的经典实例》把黑盒测试里最常用的五类设计方法——等价类划分、边界值分析、错误推测、因果图、判定表驱动——全部落到具体例子上登录功能、三角形判定、NextDate 日期函数、自动售货机、设备维修优先级。它适合两类人一是要交测试用例设计作业、需要一套能直接对照改写的模板的学生二是要出一份可评审的测试方案、需要把用例设计讲清楚的从业者。下面按“需求怎么立、用例怎么设计、怎么落地、怎么验收”的顺序拆开讲。2. 需求与用例规格先把一条用例该有的字段立住2.1 一条合格用例的十二个字段原文列了十二条我按实际写用例时的填写顺序重新排一下并补上每条为什么不能省字段是否必填说明软件/项目名称必填定位用例归属跨项目复用时靠它区分版本号内部必填同一功能不同版本预期结果可能不同缺了就无法追溯功能模块名必填决定用例归档目录评审时按模块抽查用例简单描述必填一句话说清这条用例验证什么目的参考信息选填需求文档章节号、设计稿链接便于回溯依赖关系条件必填如“依赖 TC2 已录入用户 test”串行用例必须写前置条件必填数据库权限、已登录状态、初始数据等用例编号 ID必填建议“项目简写-模块简写-NO.”如 LOGIN-AUTH-001步骤号/操作描述/测试数据必填三者成组出现一步一行预期结果必填最重要没有预期结果的用例等于没写实际结果执行时填有 BUG 管理工具可省略由工具记录开发人员/测试人员/执行日期开发必填出问题能第一时间找到责任人这里有个血泪经验预期结果写“登录成功”是无效的必须写到可观测的层面比如“跳转至首页页面顶部显示当前用户名 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~7a 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、min1、max-1、max、max1。原文表格里 Test1~Test3 测 year 下边界1911、1912、1913Test4~Test7 测 year 上边界1975、2049、2050、2051Test8~Test13 测 day 的 -1、1、2、30、31、32Test14 测 mouth 的 -1Test15~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×28。列出初始判定表后做化简把相似规则合并最终压到 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、min1、max-1、max、max1 六点跨月跨年再补进位用例。4.4 用例依赖没写导致执行顺序错乱现象单独跑某条用例失败按顺序跑却通过。原因依赖了前一条用例造的数据如已注册用户 test但依赖关系字段空着。解决依赖字段必填并在前置条件里写清数据来源。4.5 判定表化简后漏覆盖现象某组合条件在测试中从未被执行。原因化简时把不该合并的规则并了。解决化简后逐条反查原始规则是否被命中必要时保留冗余规则。5. 验收与答辩用一张覆盖矩阵把用例讲清楚交作业或答辩时评审最想看的不是用例数量而是“你的用例凭什么说覆盖够了”。我一般会做一张方法-场景覆盖矩阵把五类方法和被测功能交叉打勾缺哪格一目了然被测功能等价类边界值错误推测因果图判定表登录有有长度上限有三次锁定无无三角形判定有有有退化边无无NextDate有有有月末进位无无自动售货机无无无有有维修优先级无无无无有答辩时按这个矩阵讲先说每个功能为什么选这几类方法登录偏输入校验所以等价类边界值售货机偏组合逻辑所以因果图判定表再挑一条用例现场走一遍“前置条件→步骤→预期结果”最后展示无效等价类和边界邻点的用例证明不是只测了 happy path。评审常追问的两个点提前准备好一是“你的预期结果依据是什么”答需求文档章节号二是“连续三次失败锁定这条怎么验证”答用循环执行 TC6 三次并检查提示文案与 IE 关闭行为。从那以后我每次带测试用例的课设或方案评审都强制先过一遍覆盖矩阵再让人讲用例细节——矩阵缺格的地方后面讲得再花哨也是虚的。希望帮到你。本文还有配套的精品资源点击获取
