黑盒测试用例设计

写测试用例这事，黑盒很多人一上来就对着需求文档逐条翻译，测试结果写了一百多条，用例跑一遍发现一半在测同一个逻辑。设计黑盒测试用例设计的黑盒核心不是“覆盖需求”，而是测试“用最少的用例戳中最多的风险点”。

我见过一个登录模块，用例有人写了27条用例：空用户名、设计空密码、黑盒都为空、测试用户名超长、用例密码超长、设计特殊字符……看起来很全对吧？黑盒但漏了一个关键场景——用户名正确、密码错误时，测试系统返回的用例提示信息是否暴露了“该用户不存在”还是“密码错误”。这个细节直接关系到撞库攻击的难易程度。用例数量从来不是衡量质量的指标。

等价类划分：别把边界当普通值

等价类划分是老生常谈，但实际操作中容易犯一个错误：把有效等价类和无效等价类当成同等重要的东西。一个输入框允许1-100的整数，无效等价类可以拆出“小于1”“大于100”“非整数”“空值”“特殊字符”五类，但真正需要重点设计的是边界值——0、1、100、101。这四个值比中间那98个值加起来都容易出bug。

个人经验：边界值附近最容易暴露开发人员的“差一错误”。比如分页功能，每页10条，总共100条数据。测试25条数据时分几页？第10页有没有数据？第11页请求会返回什么？这些才是黑盒测试该盯的地方。等价类划分帮你减少用例数量，边界值分析帮你找到真正的缺陷。

判定表：条件组合的照妖镜

业务规则复杂的时候，判定表比拍脑袋想用例靠谱得多。举个例子，一个电商优惠券系统：用户类型（新/老）、订单金额（满100/不满100）、优惠券类型（满减/折扣），三个条件组合起来有8种情况。如果不画判定表，很容易漏掉“老用户+不满100+折扣券”这种边角场景。

判定表的好处是强迫你把每个条件的所有取值都列出来，然后逐行检查动作是否合理。我习惯在画完判定表后，把每一行当成一个用例的骨架，再补充具体的输入数据。这样出来的用例集，逻辑覆盖度比凭直觉写的高出一截。

场景法：用户不会按你的剧本走

基本流和备选流的概念大家都懂，但实际写的时候，很多人只写基本流——用户正常操作、系统正常响应。备选流才是bug的重灾区。比如一个转账功能，基本流是“输入账号→输入金额→确认→转账成功”。备选流呢？转账中途网络断了、余额刚好等于转账金额、收款账号被冻结、同一笔转账重复提交……

我的做法是：先写一条“happy path”用例，然后针对每一个可能出错的环节，各写一条异常用例。不是穷举所有异常，而是挑那些“开发容易忽略、用户可能触发”的场景。比如重复提交，前端加个防抖就完事了？后端有没有做幂等？这才是黑盒测试要验证的。

错误推测：经验比方法论更直接

错误推测法听起来很玄，其实就是“我赌这里会出问题”。比如看到日期输入框，就猜开发可能没处理闰年；看到金额字段，就猜可能用了浮点数导致精度丢失；看到文件上传，就猜可能没限制文件类型。这些猜测来自之前踩过的坑。

我个人的错误推测清单里排第一的是“空值和null的区别”。很多系统对空字符串做了校验，但传null进去直接500。排第二的是“并发操作”，两个请求同时修改同一条记录，后写的会不会覆盖先写的？这些用例不需要复杂的设计方法，靠的是对系统薄弱环节的直觉。

黑盒测试用例设计没有标准答案。等价类、边界值、判定表、场景法、错误推测，这些方法不是让你按顺序套一遍，而是根据具体模块的特点挑着用。一个查询功能，边界值加等价类就够了；一个审批流程，判定表和场景法更合适。别为了“方法完整”而写用例，那样只会产出大量冗余。