选课系统崩了。学生选课系统周一早上九点，黑盒教务处的测试服务器准时卡死，两万多人同时点“提交”，学生选课系统页面转圈转到让人想砸键盘。黑盒这不是测试什么新鲜事，每年选课季都要来这么一出。学生选课系统我后来去查了后台日志，黑盒发现大部分请求其实根本没到数据库那层，测试全堵在负载均衡前面。学生选课系统也就是黑盒说，系统还没开始干活，测试就已经被自己的学生选课系统入口给憋死了。

黑盒测试要做的黑盒，就是测试不管它里面怎么搭的，只看外面表现。你给它什么输入，它回你什么输出。选课系统最核心的输入就三类：学生身份、课程容量、时间冲突。输出也简单——选上了，或者没选上，外加一句提示。但就是这三进两出的事，能测出不少毛病。

我拿一个测试账号登进去，先试了正常流程。选一门还有余量的课，点提交，页面刷新，课程出现在已选列表里。没问题。然后我开始折腾。

第一刀砍在并发上。用脚本模拟五十个请求同时抢同一门只剩一个名额的课。理论上应该只有一个成功，其余返回“容量已满”。实际结果是：三个请求都显示选课成功。数据库里那条课程记录的已选人数变成了三，但容量上限是一。超卖了。这是典型的竞态条件——系统先查余量，再写入，两步之间没有锁。修起来不难，加个行级锁或者用原子操作就行。但黑盒测试不管你怎么修，它只告诉你：这里漏了。

第二刀试边界。课程容量设为0，提交选课请求。系统返回“选课成功”，然后课程列表里出现了一门容量为0的课，已选人数显示1。这就有意思了。容量为0在业务上应该直接拒绝，但系统只判断了“当前人数 < 容量”，0 < 0 为假，按理说该拒绝。可它没拒。我去翻接口返回，发现前端传过来的容量字段是字符串“0”，后端做比较时隐式转换成了数字，但比较逻辑写的是“<=”。小于等于零，0 <= 0 为真，放行了。一个等号的事。

第三刀切时间冲突。选了两门时间完全重叠的课，系统没拦。课表上两门课叠在一起，红字提示“时间冲突”，但选课状态已经是“已选”。提示归提示，数据归数据，两套逻辑各走各的。学生要是只看提示不查课表，期末就得撞车。

还有更离谱的。我试了在选课请求里把学生ID改成别人的。系统没校验，直接按传入的ID写入了选课记录。也就是说，只要知道别人的学号，就能替别人选课，或者把别人已经选上的课顶掉。这是权限漏洞，黑盒测试里属于安全用例没覆盖到。

测完这些，我列了个单子给开发。他们看了半天，说有些问题他们自己也没想到。比如那个容量为0的边界，代码里确实写了校验，但被一个类型转换给绕过去了。再比如并发超卖，他们一直以为数据库的唯一索引能兜住，但索引建在了（学生ID，课程ID）上，不是课程ID上，同一门课不同学生同时插入，索引拦不住。

黑盒测试的好处就在这。你不去管它代码写得漂不漂亮，架构合不合理，你只从外面捅。捅对了地方，它就露馅。选课系统这种高并发、强一致性的场景，光靠功能测试走一遍正常流程根本不够。你得把它往死里逼——并发、边界、越权、异常输入，一个都不能少。

后来系统修了一版。我又跑了一遍同样的用例。并发超卖没了，容量为0拒了，时间冲突直接拦截，学生ID也做了会话绑定。但新问题又来了：并发请求下，失败的那几个返回的提示是“系统繁忙，请稍后重试”，而不是“容量已满”。学生看到这个提示会一直重试，反而加重服务器负担。这算不算bug？算，但优先级不高。先保证数据对，再优化提示文案。

选课系统每年都要被骂。骂的人不知道背后是并发控制没做好，还是边界条件漏了，他们只知道页面卡了、课没了、系统烂。黑盒测试就是替他们把这些“烂”翻译成开发能看懂的东西。翻译得越准，修得越快。