😂 IT段子

缺陷的严重程度取决于发现者的职级。我不知道该说什么，就笑了笑。我把这个 case 的日志全部拉下来，一行行对时间线。从此我多了一条团队规约

测试提的 bug 标题叫"偶现"，复现步骤写着：多试几次。我把手上的资料翻出来又读了两遍。我把这个接口的压力测试跑了一遍，瓶颈在数据库。同事说这波操作可以写进新人培训教材

这个环境的测试数据三个月没清，已经不可信了。我笑了笑，决定不解释。我把这个功能的测试报告整理了出来，附了截图。世界瞬间清净了

测试用例的价值在于它证明的东西比它跑的次数多。我发现自己居然没法反驳。我在心里把这次的测试结论写成了三句话。我把这条经验写进了团队 wiki

测试环境最大的特点是它和线上不一样。我叹了口气，然后打开了编辑器。我把这个问题定义成了 P3，然后它上线后变成了 P0。果然现实比段子更精彩

测试用例写了三百条，线上 bug 出在没写的那一条。我在心里给这次的测试结果总结了一句，风险可控。世界瞬间清净了

这条用例依赖另一个用例的数据，顺序一变就红。我发现自己居然没法反驳。我发现这个测试在本地一直是绿的，流水线上一直是红的

我把用例的数据造得和线上一样，问题终于现形。我拉了个小群，把相关同学都叫了进来。我在这个用例上加了个断言，它立刻红了。我把它写进了组内的避坑文档第一章

缺陷的严重程度取决于发现者的职级。我想反驳，但发现他说得对。我加了三道自动化检查，希望下次能早点发现。这大概就是程序员的人生吧

我把这个接口的异常分支补了用例，果然有问题。我在心里给这次的测试时间估了个数，实际用了两倍。第二天这个方案就变成了团队标准做法