测试项目经历

测试项目经历

我接手那个叫“北极星”的测试支付系统测试时，离上线只剩三周。项目代码库里躺着两千多个待验证的经历用例，而前任测试只留下一句“环境跑不起来”。测试第一天下午我就在测试环境里复现了那个著名的项目bug——金额为0的订单居然能支付成功，数据库里躺着一笔笔“免费”交易。经历开发组长挠着头说：“这逻辑我写了三年，测试一直以为前端拦住了。项目”

那次经历让我明白，经历测试的测试第一课不是学工具，是项目学会怀疑。怀疑文档、经历怀疑代码注释、测试怀疑“应该没问题”这句话。项目后来我养成个习惯：每接到一个新模块，经历先不看用例，自己把核心流程走一遍。往往走完第三遍，就能撞见两三个需求文档里没写的边界情况——比如用户连续点击“提交”按钮五次，或者网络断线重连时请求被重复发送。

但真正让我对测试改观的，是一次性能压测。我们模拟了五百个用户同时抢购秒杀商品，系统直接雪崩，数据库连接池被榨干，页面白屏了七八秒。开发第一反应是“测试脚本写得有问题”，我当场调出监控图谱：线程数飙到峰值后直线坠落，GC日志里Full GC间隔从正常的十秒缩短到两百毫秒。那种感觉挺奇妙的——你手里没有代码，却能通过数据曲线说出系统“哪里在流血”。

后来我学会把bug报告写得像侦探小说。不写“点击按钮后页面报错”，而是写“在Chrome 120版本下，从购物车进入结算页，快速切换优惠券三次，第四次点击结算时，接口返回502，但前端未捕获异常，页面卡在loading态”。开发拿到这种描述，往往十分钟就能定位问题。有次一个资深后端私下跟我说：“你写的bug单比我自己的代码注释还清楚。”

当然也有翻车的时候。有一回我自信满满地标了个“严重”级别的bug，说用户头像上传后变形。结果产品经理拿来设计稿一比，人家故意做成了16:9的裁切效果。那天我学会一件事：测试不能只盯着功能对不对，还得搞明白产品“为什么这么设计”。从那以后，我每次提bug前会多问一句：“这是不是有意为之？”

现在回头看，那段测试经历教会我的不是怎么找bug，而是怎么跟不确定性共处。系统永远有测不完的路径，需求永远在变，但你可以通过分层策略——先跑通主流程，再攻边界值，最后做随机探索——把风险控制在可接受范围内。就像那个北极星项目，最后上线时我们砍掉了三分之一“理论上存在”的测试用例，把时间花在了支付金额、并发冲突、幂等性这些真正会咬人的地方。

上线当晚我盯着监控大屏，看着交易曲线平稳爬升，没有一条报错警报。那一刻我突然觉得，测试这活儿有点像守夜人——大部分时间安静得让人犯困，但你知道，黑暗里总藏着几只随时可能扑出来的野兽。而你的价值，就是让它们永远没有机会扑出来。