★ FEATURED ARTICLE 简介这是一份软件测试用例设计方法的经典实例文档面向软件测试工程师、测试初学者及备考人员系统梳理了测试用例的基本编写要点以及黑盒测试、等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法等常用设计方法。资源包含1个doc文档压缩包大小329KB内容以文字和表格形式呈现案例覆盖登录界面的黑盒测试含初始页面显示、用户名录入、密码校验、多次登录失败安全校验等多个场景、三角形判定的等价类划分、NextDate函数的边界值分析、数组排序程序的错误推测以及自动售货机因果图设计等每个实例都配有完整的用例步骤与预期结果可直接参考对照编写。截至目前已有4773人学习下载适合需要快速上手编写规范测试用例、提升测试设计能力的测试人员参考学习。1. 测试用例不靠灵感经典实例为什么至今还能直接搬很多新人写测试用例时第一反应是找模板觉得用例是靠灵感堆出来的。等到评审被开发问一句“这条用例为什么这样设计”就答不上来。真正可靠的做法是用经典设计方法把场景拆出来而不是靠临时脑补。这份经典实例把五类高频考点放到了一起B/S登录功能的黑盒用例、三角形问题的等价类划分、NextDate函数的边界值分析、自动售货机的因果图与判定表、排序程序的错误推测法基本覆盖了手工用例设计里最容易漏但又总被面试问到的角落。适合刚入行的功能测试同学照着抄字段结构也适合写用例总被说“覆盖不全”的工程师把五类方法逐个落地。把这几个例子亲手推一遍比看十篇讲“什么是等价类”的科普文有用得多。2. 合格用例的十二个字段从B/S登录实例看如何组织2.1 一份用例的信息要素哪些字段不能省一份能直接用的测试用例不是把操作步骤堆上去就完事。项目正文里列出了十二项信息拆开看可以归成四类定位信息、执行条件、结果判定、追溯信息。定位信息包括软件名称、版本号、功能模块名、用例编号、用例描述解决的是“这条用例测的是哪个系统哪个模块”执行条件包括前置条件、入口、依赖关系、操作步骤和测试数据解决的是“这条用例在什么状态下才能跑”结果判定是预期结果和实际结果这是用例的灵魂追溯信息包括参考信息、开发人员、测试人员和执行日期方便出问题时回头找源头。实际写用例时最容易漏的是前置条件和依赖关系。前置条件不等于操作步骤它描述的是执行之前的初始状态比如“系统已存在用户名 test”“数据库可访问”“浏览器版本为 IE6.0 SP4”。依赖关系则说明这条用例是不是建立在其他用例执行成功的基础上回归时看到依赖关系才知道谁先跑谁后跑。2.2 登录功能的黑盒用例TC1到TC10怎么搭原文以一个 B/S 结构登录功能为被测对象假设浏览器是 IE6.0 SP4黑盒用例从页面显示一路覆盖到安全锁定。我把核心用例整理成下面的表字段顺序按日常写用例的习惯做了统一用例ID场景测试步骤预期结果备注TC1初始页面显示打开 IE在地址栏输入地址进入登录页面页面元素完整显示与详细设计一致无TC2用户名录入-验证输入已存在的用户 test输入成功TC5 的前置步骤TC3用户名容错性输入 aaaaabbbbbcccccdddddeeeee输入到蓝色显示的字符时系统拒绝输入验证长度上限TC4密码录入输入与用户名相关联的数据 test输入成功TC5 的前置步骤TC5系统登录成功按 TC2、TC4 输入后单击登录按钮登录系统成功依赖 TC2 和 TC4TC6用户名、密码校验不输入用户名和密码直接单击登录按钮提示“请检查用户名和密码的输入是否正确”双空校验TC7密码校验输入用户名不输入密码单击登录提示“需要输入密码”密码必填校验TC8密码有效性校验输入用户名 test密码与用户名不一致提示“错误的密码”密码正确性校验TC9输入有效性校验输入不存在的用户名和密码提示“用户名不存在”用户存在性校验TC10安全校验连续 3 次未成功提示“您没有使用该系统的权限请与管理员联系”并自动关闭 IE锁定策略这套用例的巧妙之处在于它把“正常流”和“异常流”分得很清楚。TC1 到 TC5 走正常路径先证明页面、输入框、登录主流程能跑通TC6 到 TC10 走异常路径逐个拆校验规则。黑盒测试看不到代码逻辑只能靠这种“输入组合 预期输出”的矩阵把可能性压到有限的组合里。TC3 里提到“输入到蓝色显示的字符时系统拒绝输入”这是当年 IE 下用字符宽度限制输入长度的表现。现在写用例不一定要写“蓝色”但要写明最大长度和拒绝行为比如“超过 20 个字符时输入框不接受第 21 个字符”。描述越具体开发和测试之间越不容易扯皮。2.3 用例ID、入口条件与依赖关系让用例可追踪原文给出的用例编号格式是“软件名称简写-功能块简写-NO”例如 LOGIN-01-001。这种格式在测试管理工具里非常常见好处是看编号就能知道归属模块排序和过滤都方便。入口条件要写明“打开 IE输入相应地址进入登录页面”这看起来像废话但在实际回归时非常重要。如果入口页面有多个比如直接输 URL、点菜单跳转、从外部系统单点登录用例必须注明走哪个入口否则同一个操作可能得到不同结果。依赖关系在 TC5 上表现得很直观它复用了 TC2 和 TC4 的输入结果。如果 TC2 跑不通TC5 的执行就失去意义测试执行时应该先把 TC2、TC4 跑完再跑 TC5。这种依赖还会影响缺陷定位TC5 失败不一定是登录按钮的问题可能是前置步骤留下的脏数据导致。3. 等价类划分法三角形问题的有效与无效用例设计3.1 等价类划分的核心思想与适用场景等价类划分的思路是把程序的输入域按照“程序处理方式是否相同”切成若干个类从每个类里挑一个代表值做测试。这样可以把无限输入压缩成有限集合同时保证覆盖率。它非常适用于这类场景输入条件能被明确拆解成规则且每条规则之间相对独立。三角形问题就是典型题目要求输入三个整数 a、b、c 构成三角形程序根据三边关系输出“非三角形”“一般三角形”“等腰三角形”“等边三角形”。输入条件看着是三个整数实际上隐含了“整数”“三个数”“非零”“正数”“两边之和大于第三边”“等腰”“等边”七条规则。有效等价类验证程序能不能正确处理合法输入无效等价类验证程序能不能合理拒绝非法输入。很多测试新手只做了有效等价类无效等价类一栏全空评审时就会被追问“输入 0 会怎样”“输入小数会怎样”。这两类必须同时覆盖。3.2 三角形问题的七条约束与等价类编号把题目中给出和隐含的条件列出来应该是下面这七条输入三个整数必须是三个数不能多也不能少三个数都不能为 0三个数都必须是正数任意两边之和大于第三边有两条边相等构成等腰三条边相等构成等边满足 1 到 4 的前提下程序再根据 5、6、7 判断输出类型。如果不满足第 5 条直接输出“非三角形”满足第 5 条且三条边相等输出“等边三角形”满足第 5 条且有两条边相等输出“等腰三角形”否则输出“一般三角形”。等价类编号可以这样排基本输入条件整数、三个数、非零、正数和构成条件两边之和大于第三边作为前五条等腰的三种排列位置作为第 8、9、10 类等边作为第 11 类。为什么等腰要拆三种因为程序里判断 ab、bc、ac 通常是三个独立条件a 和 b 相等、b 和 c 相等、a 和 c 相等对应不同的执行路径只测一种排列会漏掉另外两条分支。3.3 覆盖有效和无效等价类的用例表有效等价类的代表性用例可以这样选abc覆盖情况预期输出345一般三角形覆盖基本输入条件和构成条件一般三角形445ab 相等覆盖等腰的一种排列等腰三角形455bc 相等覆盖等腰的另一种排列等腰三角形545ac 相等覆盖等腰的第三种排列等腰三角形444三边均相等覆盖等边条件等边三角形无效等价类也要单独成表常见做法是每个前四条约束各挑一个反例abc覆盖的无效等价类预期输出2.534非整数应给出错误提示或“非三角形”034含 0应给出错误提示或“非三角形”-134负数应给出错误提示或“非三角形”123两边之和等于第三边非三角形125两边之和小于第三边非三角形一个输入缺失34只有两个数应给出错误提示最后一类往往被忽略程序声明输入三个整数如果少传一个参数很多实现会直接报异常。这类无效输入在接口测试里经常出现等价类里应该单独留一条。写用例时不要把预期结果写成“报错”要写具体错误文案或异常类型否则执行人无法判断系统行为是否符合预期。4. 边界值分析法NextDate函数的边界用例与常见误区4.1 为什么缺陷集中在边界边界值分析的理论基础其实很朴素开发人员在写判断条件时最容易在“恰好相等”和“恰好超过”的地方出错比如把 写成 把最小值判断漏掉。缺陷密度在输入域的边界处明显高于中间区域。等价类划分选出的是一个等价类里的代表值边界值分析则在等价类的边界上多取几个点通常是边界值本身、边界值的前一个值和后一个值。对闭区间取边界值、边界值减 1、边界值加 1对开区间取边界值两侧紧邻的值。NextDate 函数是教科书级别的边界值案例因为它同时有 month、day、year 三个输入范围而且 day 和 month 之间还有联动。原文隐含设定是 month 取值范围 1 到 12day 取值范围 1 到 31year 取值范围 1912 到 2050。4.2 NextDate函数的边界值用例展开测试时采用“单变量法”即每次只让一个变量取边界附近的值其他变量固定在有效范围内的常规值。下面把边界用例整理成一张表边界类型固定参数被测参数取值预期输出说明year 下边界month6, day1519111911.6.16下边界外一年非法year 下边界内month6, day1519121912.6.16最小值有效year 下边界内month6, day1519131913.6.16边界正常值year 上边界内month6, day1520492049.6.16边界正常值year 上边界month6, day1520502050.6.16最大值有效year 上边界外month6, day152051输入日期超界上边界外一年非法day 下边界外month6, year20010day 超出 [1…31]非法day 下边界内month6, year200112001.6.2最小值有效day 上边界内month6, year2001302001.7.16 月只有 30 天加一天跨月day 上边界外month6, year200131输入日期超界6 月不存在 31 日month 下边界外day15, year20010month 超出 [1…12]非法month 下边界内day15, year200112001.1.16最小值有效month 上边界内day15, year2001122001.12.16最大值有效month 上边界外day15, year200113month 超出 [1…12]非法这张表里最值得研究的是 day 的上边界。6 月只有 30 天所以 day30 的预期输出不是 2001.6.31而是直接跳到 2001.7.1day31 反而成了非法日期。如果写用例时只按“1 到 31”的取值域机械取数就会把 30 日和 31 日的规则写错。边界值分析的隐藏要求是必须结合业务规则理解每个边界背后的真实含义不能只看取值范围数字。month 的边界测试同样有坑。1 月和 12 月的下一条日期都涉及跨年2 月还要处理闰年逻辑。原文没有覆盖闰年场景实际执行时我会补一组 2 月 28 日、2 月 29 日、3 月 1 日的用例其中闰年和非闰年各一套才算真正封住日期函数的边界。4.3 边界值分析法的局限与组合爆增边界值分析看着简单实际容易陷入组合爆炸。month、day、year 三个变量每个变量取 6 个边界附近的值全组合就是 216 条用例页面操作型测试根本跑不完。常见做法是单变量法每次只让一个变量动其余变量固定在常规值用三次小规模测试替代一次全组合。这里要注意这种方法的代价它只保证单个变量边界被覆盖不保证变量之间的组合边界被覆盖。比如 day 和 month 的联动单变量法在 month2、day28 这类组合上会失效。更稳妥的做法是以单变量法为主体再针对已知的高风险联动点补几条组合用例比如 2 月 28 日、2 月 29 日、12 月 31 日、1 月 1 日。5. 因果图与判定表从售货机到维修规则的化简与避坑5.1 因果图把容易漏的组合变成显式关系等价类和边界值都假设输入条件相对独立但很多业务规则的输入之间存在“与”“或”“非”的关系这时候因果图比前两种方法更合适。原案例是一个处理单价 5 角钱的自动售货机规格说明片段包含两个核心场景有零钱找时投入 5 角或 1 元硬币并押下橙汁或啤酒按钮送出饮料没有零钱找时投入 1 元硬币并押下按钮饮料不送出且退还 1 元硬币。原因列出来有五个售货机有零钱找、投入 1 元硬币、投入 5 角硬币、押下橙汁按钮、押下啤酒按钮。结果有四个主要输出售货机“零钱找完”灯亮、退还 1 元硬币、退还 5 角硬币、送出饮料。直接连原因和结果会画出很多交叉线所以引入中间结点比如“投入 1 元硬币且押下饮料按钮”“押下橙汁或啤酒按钮”“应当找 5 角零钱并且售货机有零钱找”“钱已付清”。写用例时不一定真的画一张标准因果图但要在表格里把这种“组合条件”显式列出来。常见做法是先把原因和结果编号再写一列中间状态最后把条件组合转换成判定表。这样至少保证每个条件组合都被考虑过而不是靠直觉猜几个场景。5.2 判定表条件桩、动作桩与8到5规则的化简判定表是因果图的下游产物适合处理复杂的条件组合。原案例的维修规则是功率大于 50 马力的机器、维修记录不全或已运行 10 年以上的机器应给予优先的维修处理。这里有三个条件每个条件两种取值规则数应该是 2×2×28。初始判定表如下条件/动作规则1规则2规则3规则4规则5规则6规则7规则8功率大于50马力YYYYNNNN维修记录不全YYNNYYNN运行超过10年YNYNYNYN优先维修处理XXXXXXXX作其他处理-------X按“或”逻辑理解只有规则 8 是三个条件全不满足走“作其他处理”其余七条规则都应该优先处理。画成表后会发现能合并的规则很多原文化简后留下 5 条规则条件/动作化简1化简2化简3化简4化简5功率大于50马力YYYNN维修记录不全YNN--运行超过10年-YNYN优先维修处理XXXXX作其他处理--X-X注意这个化简过程最容易出问题。表面上可以把“维修记录不全”在两行里合并成“-”但如果严格按真值表回查会发现问题功率小于 50 且运行未超过 10 年但维修记录不全的机器仍然应该优先处理而化简表的第 5 条把这种情况判成了“作其他处理”。所以化简后必须逐条对照原始真值表做验证不能为了图省事把规则合并到语义丢失。5.3 避坑记录四条踩坑经验现象一判定表化简完成后回归测试漏掉了“维修记录不全但功率和年限都不满足”的场景。原因把“-”当成了“该条件绝对不影响结果”实际上“-”只代表在本条已化简规则范围内不影响不代表在所有场景下都不影响。解决化简后用原始 8 条规则逐条对照确认每条原始规则都能落到化简后的某条规则里。现象二因果图画出来密密麻麻中间结点连到结果时反而理不清。原因中间结点建得太随意把“结果”直接当成“中间状态”。解决中间结点只保留能对应一个明确条件的组合状态比如“投入 1 元硬币且押下饮料按钮”不要把任何输入或输出直接塞进中间层。现象三预期结果写成“系统提示错误”这种抽象描述执行时两个人有四种判断。原因用例作者想偷懒用功能描述代替了具体输出。解决把提示文案写进用例比如 TC6 的预期结果直接写“请检查用户名和密码的输入是否正确”提示框的文案来自需求文档不允许执行人自行发挥。现象四边界值分析只盯着输入框长度忘了业务规则本身也有边界。原因把“边界”理解成了数据类型边界忽略了业务边界。解决像 TC10 的“连续 3 次未通过自动关闭 IE”这类规则3 就是业务边界要把第 2 次、第 3 次、第 4 次分别写成用例确认第 3 次触发锁定而第 2 次不触发。6. 错误推测法与一个可执行的覆盖自查习惯错误推测法看起来最“玄学”实际上是用经验换覆盖率。它不依赖形式化方法而是把“这个程序最容易坏在哪”变成检查清单。原案例里有一个非常经典的示例测试一个对线性表进行排序的程序需要特别检查空表、只含一个元素、元素已排好序、元素逆序、部分或全部元素相同这五类输入。这五条看着简单实际覆盖了排序实现里最容易出问题的分支空表会让很多循环直接越界单元素考验边界处理已排序和逆序考验比较次数元素相同则考验排序算法是否稳定。这五类输入完全可以固化成一段自动化冒烟脚本每次换排序实现或改算法时先跑一遍# 排序程序错误推测法回归基线 def smoke_check_sort(sort_funcsorted): cases { 空表: [], 单元素: [1], 已排好序: [1, 2, 3, 4, 5], 完全逆序: [5, 4, 3, 2, 1], 全部相同: [2, 2, 2, 2], } for name, arr in cases.items(): out sort_func(arr) assert out sorted(out), f{name} 输出不是升序: {out} print(f[通过] {name}: {arr} - {out})这段脚本里cases 字典的每个 key 对应一种错误推测场景value 是输入数据排序函数执行后用断言确认输出仍然是升序。注意这里的 sorted(out) 只是用来校验输出是否有序并不等价于功能正确性判断如果要验证稳定性还要对比排序前后相同元素的相对位置。实际业务中我会把错误推测场景扩展成 8 到 10 条比如“输入包含最大最小值”“输入长度超过缓冲区”“输入包含重复对象”等每一条都来自对这个模块代码和历史的了解。从那以后我每次给模块设计用例都强制把“等价类分析、边界值选取、错误推测清单”三件事走一遍排序这类通用逻辑还会顺手把五个基线场景加进回归用例。这个方法看着笨但能接住大多数“换了个边界值就翻车”的线上问题。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
