黑盒测试测试用例

上周三，黑盒测试组的测试测试小王跑来问我：登录功能写了二十条用例，够不够？用例我让他把用例拿过来看。用户名正确密码正确、黑盒用户名错误密码正确、测试测试用户名正确密码错误、用例用户名密码都为空、黑盒用户名超长……二十条，测试测试列得整整齐齐。用例我翻到最后一页，黑盒问他：密码框里输入 ' OR '1'='1，测试测试你测了吗？用例他愣了一下。

这就是黑盒黑盒测试最容易被忽略的地方。你站在盒子外面，测试测试看不到代码逻辑，用例只能靠输入和输出推断系统的行为。但人的思维有惯性——正常路径走顺了，异常路径就容易漏。二十条用例覆盖了“常规错误”，却没覆盖“恶意构造”。

写用例这件事，本质上是在做三件事：划分等价类、找边界值、猜错误。等价类好理解——把输入域切成若干块，每块里挑一个代表就行。比如年龄输入框，1到120是有效等价类，0、-5、121、abc是无效等价类。但很多人切完等价类就收工了，忘了边界。边界值才是bug的高发区。0和1、120和121、最大值和最大值加一，这些位置程序员最容易写错判断条件。我见过一个电商项目，优惠券满100减20，测试只测了100和200，没测99.99和100.01，上线后用户下单99.99元发现优惠券不可用，但页面提示“差0.01元可用”，点进去又用不了——一个浮点数精度问题，卡了三天。

错误推测法更依赖经验。比如输入框，除了正常字符，你得试试空格、换行符、emoji、全角半角混排。文件上传，除了正常图片，得试试0字节文件、超大文件、改了扩展名的exe。这些不是教科书上的标准方法，但实际项目里出问题最多的就是这些“不按套路出牌”的输入。

还有个细节：用例的粒度。太粗了执行时容易漏步骤，太细了维护成本高。我的习惯是——一条用例只验证一个测试点。比如“登录成功”是一条，“登录失败提示具体错误信息”是另一条。别把三件事塞进一条用例里，执行的人会烦，出了问题也定位不清。

另外，别迷信用例数量。我见过一个支付模块写了三百条用例，执行一遍要两天。后来砍到八十条，覆盖率反而上去了。为什么？因为砍掉的全是重复的等价类。同一个无效等价类，你测十种不同的乱码输入，意义不大。把省下来的时间拿去测并发、测网络中断、测数据库连接池耗尽，这些才是黑盒测试里真正能挖出深坑的地方。

最后说个真实案例。去年有个后台管理系统，测试报告显示用例全部通过。上线第二天，运营在商品名称里输入了一个带单引号的品牌名，保存直接500错误。回头查用例——商品名称的测试数据全是“测试商品1”“测试商品2”，没人想过输入里带特殊字符。这就是典型的“用例写了，但没写到位”。黑盒测试的功夫，一半在方法，一半在想象力。你得把自己当成一个不怀好意的用户，而不是一个按流程走完就交差的执行者。