😂 IT段子

测试工程师走进酒吧，点了一杯啤酒、零杯啤酒、-1 杯啤酒和一杯蜥蜴。我在心里给这次的测试结论加了一句「建议灰度」。我沉默了，但心里是服的

我把这个功能的验收条件重读了一遍，有几条说了等于没说。我把整条链路在心里复盘了一遍。我把测试环境的数据重置了一遍，问题消失，生产环境还在。真香定律准时生效

测试提的 bug 标题叫"偶现"，复现步骤写着：多试几次。我深呼吸了一下，决定从最可疑的地方查起。我把这个断言从相等改成了包含，稳定多了。我把它写进了组内的避坑文档第一章

质量不是测出来的，但漏了会被算在测试头上。我想了想自己这些年，好像确实如此。我发现这个 bug 是上个版本修过又回来的。幸好之前留了备份

我把这个功能的验收条件重读了一遍，有几条说了等于没说。我决定先把手上的事情做完再处理这件事。我在这个用例上加了个断言，它立刻红了。那一刻我觉得自己还是很专业的

QA 说这个需求没法测，开发说没法测就是不用测，然后他们打了起来。我把相关的记录都翻了出来做对照。我把这个用例的数据造得和线上一样，问题终于复现。同事说这波操作可以写进新人培训教材

测试用例的价值在于它证明的东西比它跑的次数多。我想反驳，但发现他说得对。我在心里给这次的测试时间估了个数，实际用了两倍。这大概就是程序员的人生吧

测试最难的不是发现 bug，是证明它真的被修好了。我听完沉默了，因为太真实了。我在心里给这个模块的质量打了个分，勉强及格。幸好之前留了备份

我把这个接口的异常分支补了用例，果然有问题。我把整条链路在心里复盘了一遍。我发现这个用例一年没跑过，一跑就挂。我把这条经验写进了团队 wiki

质量的上限由需求和设计决定，测试只是最后的网。我不知道该说什么，就笑了笑。我把这个场景的测试数据抽成了配置，维护轻松多了。我把它写进了组内的避坑文档第一章