夜雨聆风小陈是我们组上个月新来的测试，校招，简历好看，主管满意，说科班出身带一带就能上手。
第二周给他分了活儿，一个用户中心模块，注册、登录、改密码，不算复杂。
出事就在周三下午。
我在工位写脚本，听见主管在会议室声音越来越大。一开始以为正常对需求，后来不对了，主管嗓门上来了："你这个用例到底跑没跑？"
安静几秒，小陈说了句什么，声音很小。
主管又来："那你告诉我，预期结果和实际结果都填的'一致'，截图呢？日志呢？"
这个味儿不对。
事情后来拼全了，是这样的——
小陈拿到的测试用例是一个老测试写的，很详细，每条都有操作步骤、预期结果、实际结果。正常应该照着步骤一条条执行，有问题提bug，没问题填实际结果，附截图。
但小陈没跑。
他把用例对着需求文档过了一遍，觉得“应该没问题”，回到系统里把所有用例的实际结果全填了“与预期一致”。一百二十六条，没有一个截图，没有一条日志，零 bug。
零bug。一个涉及注册登录改密码的模块，零bug。
主管扫了一眼报告就觉出不对——这种基础模块，表单边界值、异常提示文案、弱网重试逻辑，总有几个小问题，不可能干干净净。他把小陈叫进会议室，打开测试环境，随机挑三条，现场跑。
第一条，注册时密码输入空格。用例写"前端应拦截并提示"。小陈点进去——系统直接提交，空格密码注册成功。
第二条，连续输错五次密码。用例写"第五次后账号应锁定30分钟"。小陈试了——第六次还能继续输。
第三条，修改密码时新密码与旧密码相同。用例写"应提示不能相同"。小陈试了——改成功了，没提示。
三条现场跑，三条全挂。报告上写的全是“与预期一致"。
会议室安静了好一会儿。
主管问："你到底有没有在系统里跑过这些用例？"
小陈说："我看了需求文档，逻辑上应该没问题的，我觉得……"
"我问你有没有跑过。"
不说话了。
主管站起来，说了句话我到现在都记得："测试这个岗位，最底线就一条——你说测了，就是真的测了。你可以能力不行慢慢学，可以漏 bug 我给你时间。但没测说测了，这个一旦没了，你后面交的每一个'已验证'我都得怀疑。那团队没法转了。"
当天让他收拾东西走人，HR走流程。
小陈从会议室出来的时候脸是白的，抱着工牌和水杯从我们工位旁边过去。没人说话，整个办公区特别安静。
后来吃饭有人聊起这事，说是不是太狠了，刚毕业的小孩第一次犯错就开除。我没吭声，但心里站主管这边。
不是小陈能力不行，能力可以教。是他犯的错在测试岗上是致命的——不是技术层面的致命，是信任层面的。
测试这个岗位的产出不是代码，不是设计图，是一句话："这个功能我测了，没问题，可以上线。"这句话后面跟着的是整个产品的质量风险，是几十万用户的使用体验。开发写的代码有bug，测试是最后一道防线，你这道防线是假的，前面全白搭。
假的防线比没有防线更可怕。没有防线大家会小心，会自己测。假的防线让人放心往前冲，然后摔得更狠。
小陈那个模块，如果不是主管发现，按流程就上线了，那三个问题就到了用户面前。注册能输空格密码，登录错五次不锁定——最基本的安全漏洞。到时候追责查记录，全是"与预期一致"，谁背锅？
小陈未必是故意骗人。他可能真觉得看一遍需求就能判断对错，觉得这种简单功能不会有问题，觉得先把报告交了后面再补。这种心态在刚入行的人里不少见，学校学的是理论，没真正在项目里跑过用例，不理解“执行”这件事的重量，觉得那些步骤是多余的。
但逻辑清楚和实际跑过之间，隔着一整个真实世界的复杂性。你以为密码框会拦截空格，但前端可能忘加校验了；你以为错五次会锁定，但后端计数逻辑可能写在了错误的分支里。这些事你看需求文档看一辈子也看不出来，只有真正去操作、去输入、去点击，才能发现。
这就是测试用例存在的意义——把“我以为"变成"我确认了"。
后来带新人，每次第一天来我都讲小陈这个故事。不为吓唬谁，就一句话：在咱们这个岗位上，诚实比聪明重要，执行比理解重要。
你的每一个"已验证"，都得是真的。
