一个登录框，黑盒你输入用户名和密码，测试点“登录”。发现页面跳转了，黑盒说明登录成功。测试页面没跳，发现提示“密码错误”，黑盒说明登录失败。测试整个过程你只关心输入和输出，发现中间发生了什么，黑盒你不管——这就是测试黑盒测试。

但有些东西，发现它永远看不到。黑盒

去年我参与过一个电商项目。测试测试团队把购物车功能翻来覆去测了三天，发现加商品、删商品、改数量、算总价，所有用例全部通过。上线第二天，有用户反馈：购物车里加了两件商品，总价显示正确，但结算时扣款金额比页面显示多了三毛钱。

问题出在哪？优惠券的折扣计算在结算接口里被重复执行了一次。页面展示用的是前端算出来的价格，结算用的是后端重新算的价格。两个价格在大部分情况下碰巧一致，但在某个特定的优惠券叠加场景下，差了0.3元。黑盒测试只验证了“页面显示的总价对不对”，没验证“实际扣款和显示是否一致”，因为测试用例里压根没写这条。

这不是测试人员粗心。这是黑盒测试的盲区——你只能测你想到的东西。

代码里有一个 if (user.getAge() > 18)，写成了 if (user.getAge() > 18 && user.getAge() < 60)。60岁以上的用户全部被拦截。黑盒测试如果只准备了25岁、30岁、45岁的测试账号，这个bug就永远发现不了。你不可能穷举所有年龄，你只能抽样。抽样就有漏网之鱼。

更隐蔽的是那些“不报错但行为异常”的情况。比如一个排序算法，黑盒测试输入十组数据，输出都是有序的，通过。但代码里用了一个不稳定的排序实现，当两个元素比较值相等时，它们的相对顺序被打乱了。这个bug在测试数据里没触发，因为测试数据恰好没有重复值。上线后用户发现，同样价格的商品，每次刷新页面顺序都不一样。用户觉得“这网站怎么怪怪的”，但说不出来哪里怪。

还有一类问题，黑盒测试连“输入”都摸不到。内存泄漏。一个后台服务每隔一小时处理一批任务，每次处理完释放了90%的内存，剩下10%没释放。跑一天没事，跑一周没事，跑一个月服务器崩了。黑盒测试跑一轮最多几小时，根本碰不到这个阈值。你测的是功能，不是资源。

并发也是。两个用户同时抢最后一件库存，黑盒测试单线程跑一遍，库存减一，正确。再跑一遍，库存减一，正确。但两个请求同时到达，代码里没有加锁，库存减了两次，变成-1。这个bug在单用户测试里永远不会出现。你得用压测工具模拟并发，但那已经超出常规黑盒测试的范围了。

我见过最离谱的一个案例：某个接口在黑盒测试里返回了正确的JSON，字段名、字段值、嵌套结构全对。但代码里那个字段是从缓存里读的，缓存每24小时刷新一次。测试当天缓存是热的，数据正确。第二天缓存过期，接口返回了空值。黑盒测试只验证了“当下这一刻”的正确性，没验证“数据来源的可靠性”。

说白了，黑盒测试是在验证“行为”，不是在验证“实现”。行为对了，实现可能千疮百孔。你看到的是冰山露出水面的那一角，水面下的代码逻辑、资源管理、并发控制、边界条件，黑盒测试一概不知。

那怎么办？白盒测试、代码审查、静态分析、压力测试、混沌工程——这些手段各管一摊。黑盒测试只是其中一层滤网，它滤不掉所有杂质。指望黑盒测试发现所有问题，就像指望用体温计量血压，工具本身就没那个能力。

所以下次有人跟你说“测试都通过了”，你可以问一句：测的是什么？怎么测的？没测什么？