黑盒测试基本功：等价类划分法与边界值分析法实战

黑盒测试里有两个基本功等价类划分法和边界值分析法简单到很多新手觉得看一眼就会了可实际一到写测试用例的阶段反而最容易翻车。尤其是那个经典到不能再经典的三角形问题——输入三条边判断输出是什么三角形看起来三分钟的需求真正把用例设计完整却没那么容易。我这些年用三角形问题带过不少新人也拿它做过面试题。它范围不大、规则清晰但恰好同时包含了输入格式校验、取值范围边界、多条件组合判定三类典型测试场景等价类划分法和边界值分析法都能在它身上完整跑一遍。这篇文章适合刚入行的测试新人也适合准备面试但想系统整理一遍基础的人甚至做了几年功能测试但用例设计基本靠拍脑袋的老手也值得花十分钟把思路捋一捋。1. 先搞清楚套路黑盒测试为什么总拿三角形问题当案例1.1 黑盒测试到底测的是什么黑盒测试的核心是把被测对象当成一个不透明的盒子不关心内部代码怎么实现、算法怎么设计只关心输入和输出的对应关系。测试人员的工作就是设计各种输入观察输出拿实际结果和需求规格里的预期结果比对一致就通过不一致就记bug。举个例子你不需要知道一个计算器内部用什么代码实现sum函数只需要输入 22看它是不是返回 4。黑盒测试的本质就是“从使用者的角度验证功能是否符合需求”这也是它为什么总是和等价类划分法、边界值分析法绑在一起讲——这两种方法都纯粹从输入输出入手不涉及代码结构是天然的黑盒设计手段。很多人觉得黑盒测试门槛低就是点点点。这个说法只对了一半。门槛低是真的但要把黑盒测试用例设计得有质量、不重不漏远没有想象中容易。三角形问题之所以能成为软件测试教科书里的常客就是因为它把黑盒测试的几个难点浓缩到了一个极小的场景里。1.2 等价类划分法用最少的用例覆盖最多的输入等价类划分法听起来玄乎其实就是“分类测试”。把输入集合按照某些规则切分成若干个等价类每个等价类里选出一个代表值来设计用例。它的理论基础是同一等价类里的数据暴露缺陷的概率是相似的。如果一个代表值能测出bug这个类里其他值大概率也能测出来如果一个代表值通过了其他值大概率也能通过。这里必须强调两个概念有效等价类和无效等价类。有效等价类是符合需求规格的输入集合比如姓名输入框要求1到20个字符那长度在1到20之间的字符串就是有效等价类。无效等价类是不符合需求规格的输入集合比如空字符串、超过20个字符的字符串、包含特殊字符的字符串。大多数新手写用例时都只顾着覆盖“正确输入”把无效等价类忽略掉了。实际项目中无效等价类恰恰是缺陷的高发区。用户永远不会按照你预期的方式输入空值、超长、负数、特殊字符这些都是线上最容易出问题的场景。三角形问题的输入条件是“三个整数取值范围1到100”展开之后你会发现无效等价类的数量其实比有效等价类多得多。1.3 边界值分析法缺陷偏爱在边界处发生等价类划分法解决的是“覆盖面”的问题但它有个明显的盲区——边界。大量测试实践证明软件缺陷往往发生在输入的边界附近而不是在输入范围的正中间。原因也不难理解开发在写判断条件时最容易写错的就是“大于”和“大于等于”的区别、数组下标越界、循环边界条件这些位置。边界值分析法就是专门针对边界这个盲区设计的。它的做法是在每个等价类的边界附近取值精确打击最容易被写错的代码逻辑。三角形问题的边界有两个层面第一层是边长的取值范围取值边界是1和100第二层是三角形的构成条件任意两边之和必须大于第三边那“刚好等于第三边”的位置就是逻辑边界。这两个层面都需要用边界值分析法去覆盖。等价类划分法和边界值分析法的关系可以理解成“先画一个圈再检查圈的边缘”。等价类负责把输入域划分清楚保证每个区域都有代表用例边界值负责把每个区域的边缘位置检查到位。两者配合才算把输入域覆盖完整。2. 磨刀不误砍柴工先把三角形问题的需求定清楚2.1 需求版本不统一设计用例前必须确认规则三角形问题在网上有非常多版本有的是输入三条整数边有的允许实数有的范围是1到100有的范围是1到200。这里必须提醒一句不同需求版本推导出的测试用例是完全不同的写用例前第一件事就是把需求规格敲死。我用的版本是软件测试教材里最常见的那种输入三条整数边a、b、c取值范围1到100程序根据输入输出“等边三角形”“等腰三角形”“一般三角形”或“不能构成三角形”四种结果之一。输入不满足条件时如0、负数、超过100的整数、非整数按需求判定为“输入无效”。实际工作中需求不可能永远这么清晰。如果产品文档里没写“负数怎么处理”“0怎么处理”测试人员必须主动去找产品经理确认预期行为把规则固化成文字。否则你写出的用例没有预期输出没法断言评审时也过不了。三角形问题作为练习可以默认一套规则但真实项目的教训是需求不明确的用例设计得再漂亮也是废纸。2.2 把三角形判定规则拆开揉碎判定规则看起来人人都懂但写测试用例之前需要把逻辑拆到足够细致。三角形的判定需要经过两个步骤第一步验证输入合法性。a、b、c三个数都必须满足“1到100之间的整数”这个条件。注意这里是“且”的关系三个数都合法才算合法输入只要有一条不满足就归入“输入无效”的分支。第二步对合法输入做几何判定。先判断能否构成三角形条件就是任意两边之和大于第三边。这个条件等价于“最长边小于另外两边之和”两个判断方式等价测试时用哪个都不影响预期结果推导。能构成三角形之后再判断类型三边全部相等是等边只有两边相等是等腰三边都不相等是一般三角形。这里的顺序很重要。从需求角度讲等边三角形同时也满足“有两条边相等”这个条件所以如果程序先判断等腰再判断等边输入(5,5,5)时预期的输出就应该被明确。我在后面的章节里会专门讲这个坑这里先记住结论测试用例的预期输出必须建立在明确的判定顺序之上。2.3 三角形问题的测试难点到底在哪三角形问题看起来简单但它的测试设计有三个难点。第一个难点是输入约束有“合法与非法”两个方向无效等价类数量并不少。第二个难点是取值范围有边界而且这个边界既包括数值边界1和100还包括几何判定边界两边之和等于第三边。第三个难点是类型判定存在“等腰包含等边”的逻辑交叉容易产生预期输出不明确的情况。这三个维度一旦交叉起来就是测试用例最容易漏的地方。比如(100, 100, 100)三条边都在上边界能构成等边三角形但很多人写边界值用例时只想到了(100, 50, 50)这种等腰情况。又比如(1, 1, 2)虽然数值都合法但112恰好不满足“大于”的条件预期应该是“不能构成三角形”这个逻辑边界细分起来够写满一整张表。3. 实战走一遍用等价类划分法设计三角形问题的测试用例3.1 先列有效等价类和无效等价类按照等价类划分法第一步是把输入域切分清楚。对三角形问题切分逻辑分两层先按输入是否合法切出有效和无效两大类再在有效类内部按输出结果继续细分。有效等价类可以分成四类合法输入且构成一般三角形合法输入且构成等腰三角形合法输入且构成等边三角形合法输入但构不成三角形。这里特别要提醒很多新人会忘掉“合法输入但构不成三角形”这一类。它的输入本身是合法的三个数都在1到100之间但比如(1, 2, 3)这种几何上无法构成三角形。这类输入属于有效等价类因为输入格式没有违规只是结果是非三角形。无效等价类继续按“哪条边不合法”和“不合法的方式”细分。针对a来说无效情况至少有三种小于下边界0或负数、大于上边界超过100、不是整数小数、字符、空值。b和c同理。所以仅无效等价类就有九类每类至少要取一个代表值。3.2 设计等价类测试用例表按上述划分可以整理出一张完整的等价类用例表。每条用例的输入都标明覆盖的等价类方便评审和回溯。用例编号测试方法abc预期输出覆盖等价类EC-01等价类345一般三角形有效等价类-一般三角形EC-02等价类556等腰三角形有效等价类-等腰三角形EC-03等价类555等边三角形有效等价类-等边三角形EC-04等价类123不能构成三角形有效等价类-非三角形EC-05等价类055输入无效无效等价类-a小于下边界EC-06等价类10155输入无效无效等价类-a大于上边界EC-07等价类1.555输入无效无效等价类-a非整数EC-08等价类505输入无效无效等价类-b小于下边界EC-09等价类51015输入无效无效等价类-b大于上边界EC-10等价类51.55输入无效无效等价类-b非整数EC-11等价类550输入无效无效等价类-c小于下边界EC-12等价类55101输入无效无效等价类-c大于上边界EC-13等价类551.5输入无效无效等价类-c非整数如果你被测系统的输入框允许空值和字符串建议再补两条用例一条是三个输入里有空值一条是输入字符。这两种场景在实际测试中非常常见但需求文档里经常不会明说。3.3 为什么每个无效等价类要单独设计用例这张表里你可以看到一个设计原则每条无效等价类用例只包含一个无效条件其他输入保持合法。比如EC-05的a0但b和c都是5这样用例执行失败时你可以立刻定位到是a这个条件出了问题。如果你写一条用例是(a0, b101, c1.5)三个数同时非法用例失败时很难判断到底是谁触发的异常这个原则在测试领域叫“单缺陷假设”。另外还要注意执行顺序的习惯。有效等价类用例通常放在前面执行无效等价类放在后面。这不是硬性要求但实际操作中如果无效输入导致程序崩溃或者页面卡死后续用例就没法继续跑了。先把正常功能验证完再做异常测试执行效率会高很多。但等价类划分法到这里并没有结束。有效类的四组用例保证了每个输出分支都覆盖到了无效类的九组用例保证了输入约束的每种非法情况都覆盖到了但边界位置还是没有精确检查。比如EC-06用的是101能证明大于100不合法但100本身是否合法99和100之间的区别有没有被正确处理这些必须交给边界值分析法来检验。4. 再进一步用边界值分析法补上最容易出bug的边边角角4.1 确定边界点和离点边界值分析法的第一步是找出所有边界。对三角形问题数值边界是取值范围1到100几何边界是“两边之和等于第三边”的位置。对于闭区间[1, 100]需要取三类关键点上点就是边界值本身即1和100内点是边界内部紧贴边界的点取2和99离点是刚离开边界的点取0和101。标准取法是对每个输入变量分别取0、1、2、99、100、101这六个值再按一定的策略组合成测试用例。这里有一个非常容易踩的坑。很多初学者以为边界值分析就是拿0、101这种越界值测一遍就完事了忽略了1、100本身以及内点2、99。实际上边界值的核心不只是测“越界时系统会不会报错”更要测“边界上系统能不能正确工作”。如果只测0和101等于漏掉了边界本身这块逻辑大概率是测试盲区。几何边界是普通边界值分析经常忽略的部分。对三角形问题来说任意两边之和等于第三边时恰好处于“构成”和“不构成”的临界位置。比如(1, 2, 3)和(2, 2, 4)这两组输入数值都合法但几何上刚好不满足“任意两边之和大于第三边”。如果开发在代码里把条件写成“大于等于”这种用例在需求定义正确的情况下会直接暴露缺陷。4.2 边界值用例表按照单变量边界取的策略可以整理出下面的边界值用例表。表中正常输入值取50它是范围1到100的中间值能在其他变量取边界时保证数据的合法性。用例编号测试方法abc预期输出覆盖说明BV-01边界值123不能构成三角形a取下边界上点1且123触发逻辑边界BV-02边界值224不能构成三角形224触发逻辑边界BV-03边界值15050等腰三角形a取下边界上点1BV-04边界值1005050等腰三角形a取上边界上点100BV-05边界值50150等腰三角形b取下边界上点1BV-06边界值5010050等腰三角形b取上边界上点100BV-07边界值50501等腰三角形c取下边界上点1BV-08边界值5050100等腰三角形c取上边界上点100BV-09边界值05050输入无效a下边界外离点0BV-10边界值1015050输入无效a上边界外离点101BV-11边界值50050输入无效b下边界外离点0BV-12边界值5010150输入无效b上边界外离点101BV-13边界值50500输入无效c下边界外离点0BV-14边界值5050101输入无效c上边界外离点101BV-15边界值25050等腰三角形a取下边界内点2BV-16边界值995050等腰三角形a取上边界内点99BV-17边界值1100100等腰三角形上下边界同时出现BV-18边界值100100100等边三角形全上边界组合这张表已经能覆盖绝大部分边界缺陷了。BV-01到BV-02是几何边界BV-03到BV-08是取值范围的上下边界点BV-09到BV-14是边界外离点BV-15到BV-16是内点BV-17到BV-18是跨边界的组合。你看边界值分析法并不是简单地测“越界”而是把“边界上”“边界内”“边界外”三个方向全部覆盖到。4.3 边界值分析中容易被忽视的组合问题如果你按标准策略一次只让一个变量取边界值另一个变量固定取正常值你会发现有一个盲区多个变量同时处于边界状态的情况没有覆盖到。比如(1, 1, 1)这种全下边界组合(100, 100, 100)这种全上边界组合以及(a0, b0, c5)这种多变量同时越界的组合。实际项目里多变量同时越界并不罕见尤其是在表单提交场景中用户很可能在多个输入框里都填了非法数据。如果系统只做了单个字段的校验没有做整体逻辑的校验多变量越界就可能绕过某些检查。所以我的建议是先按标准单变量边界值跑一遍覆盖绝大多数边界缺陷再补充几条多边界组合的用例。表里我也特意加上了(1, 100, 100)和(100, 100, 100)就是为了验证多个边界同时出现时程序的判定逻辑是否仍然正确。另外三角形问题的几何边界同样存在组合问题。三条边里任何两条边的和“刚好等于”第三边都有可能触发逻辑缺陷所以(1, 2, 3)、(2, 2, 4)、(3, 3, 6)这类用例不能只测一条三组边都至少覆盖一次。之前我带新人时发现他们往往会测(1, 2, 3)这一条但很少再想 acb 和 bca 的另外两个方向这样就会漏掉只有部分比较条件写错的bug。5. 真实测试中的坑三角形问题从用例到执行5.1 预期输出不明会导致用例废掉三角形问题最常见的坑不在设计阶段而在断言阶段。需求里写了a、b、c是三个整数取值范围1到100但没说“0怎么处理”“负数怎么处理”“小数怎么处理”。如果你碰到一个实际开发的三角形判断程序输入0时它可能提示“输入无效”可能弹一个错误框也可能直接把0当作合法值继续算结果算出个“等腰三角形”。测试用例必须有明确的预期输出没有预期输出的用例等于没写。遇到需求没覆盖的场景正式的做法是先和产品经理确认并补充需求再写用例。如果是练习场景就要在用例中明确假设输入0或负数预期输出“输入无效”。我在带新人时经常看到他们把预期输出写成“报错”或“提示”这种模糊表述在评审时一定会被打回因为你没法判断程序行为到底是否正确。5.2 等价类和边界值是重叠而非重复有同学会问等价类用例里已经包含了(0, 5, 5)和(101, 5, 5)边界值用例里又有(0, 50, 50)和(101, 50, 50)这不是写重了吗表面看有两条用例重复了但这两条用例服务的目的完全不同。等价类用例的目的是验证“小于下边界的值属于无效输入”这一类行为0只是这个类的代表边界值用例的目的是验证“离点0”这个具体位置上的行为0本身才是测试焦点。同样的输入在设计矩阵里承担的角色不一样。实际执行时可以根据需要合并但在用例设计文档里我建议分开写清楚标注好使用的是哪种方法这样测试报告能体现两种方法的覆盖率也方便他人评审。5.3 等腰和等边的判定顺序坑从需求语义上看等边三角形满足“有两条边相等”的条件因此存在一个经典争议程序输出(5, 5, 5)时到底该判“等边三角形”还是“等腰三角形”很多新手写三角形判断代码时逻辑是先判断是否有两条边相等输出“等腰”再判断三条边是否相等输出“等边”。这种顺序写出来的程序等边三角形会先落入等腰分支最终输出的结果取决于代码的先后顺序。从测试角度讲需求如果没有明确优先级输入(5,5,5)时你到底该期望“等边三角形”还是“等腰三角形”我的经验是如果需求里同时存在“等腰三角形”和“等边三角形”两个输出默认的判定优先级应当是先判断等边再判断等腰。也就是说(5,5,5)的预期输出是“等边三角形”。这个优先级一定要在用例里写明否则开发按另一个顺序实现测试用例就没法判定通过还是失败。更稳妥的方式是直接和开发对齐规则把判定优先级写进需求文档。5.4 从三角形问题延伸到真实项目三角形问题不止是教学案例。电商下单的数量限制、优惠券满减金额、会员等级积分区间这些场景本质上都是同一个套路先定输入范围再划分等价类再抠边界值。拿商城购物车数量来举例需求一般是“单次购买数量1到9999超出限制提示错误”。用等价类划分有效类是1到9999的整数无效类是0、负数、超过9999的整数、小数、空值。再用边界值分析取1、2、9998、9999、10000、0这套逻辑和三角形问题完全同构。只要在三角形问题上把方法练扎实切换到任何真实需求的输入域设计你脑子里自然就会形成这套流程。提示判断一个测试人员是不是真懂边界值不用问概念就看他能不能说出“上点、内点、离点”在程度范围里的具体取值以及他会不会主动去找需求里的隐藏边界。三角形问题恰好是练习这个思维的最佳工具。我做测试这些年一个特别深的感受是三角形问题这类“玩具场景”恰恰是检验基本功最好的试金石。它没有复杂的业务上下文没有环境依赖纯粹考验你面对一个输入模型时能不能把分类做全、把边界找齐。每次我在面试里让候选人现场写下三角形问题的用例那些能把无效等价类列全、能主动补上逻辑边界用例的人处理真实项目时几乎不会把用例设计得七零八落。最后再分享一个小技巧。写测试用例时用例编号里最好带方法标记比如EC代表等价类BV代表边界值。这样用例一多你能一眼看出哪些区域覆盖密、哪些区域覆盖稀。排查测试报告时这种方法标记能帮你快速复盘如果边界值用例全过了但等价类用例挂了问题大概率在业务逻辑分支而非边界判断反过来也一样。这套习惯用到真实项目里比临时翻需求文档高效得多。