内容摘要：测试培训内容 上周三下午，我坐在公司会议室最后一排，盯着投影仪上那张密密麻麻的思维导图，心里想的却是上午没改完的那个bug。培训师姓周，四十出头，说话带着点南方口音，开场第一句就是：“你们谁记得自己上

测试培训内容

上周三下午，测试我坐在公司会议室最后一排，培训盯着投影仪上那张密密麻麻的内容思维导图，心里想的测试却是上午没改完的那个bug。培训师姓周，培训四十出头，内容说话带着点南方口音，测试开场第一句就是培训：“你们谁记得自己上个月写的测试用例里，最蠢的内容那个错误？”

会议室安静了三秒，然后有人笑了。测试周老师没等回答，培训直接切到下一页幻灯片——上面是内容他自己十年前写的一段测试脚本，注释里写着“此步骤必挂，测试勿删”。培训他说这是内容当年为了赶上线故意留的定时炸弹，后来炸了，线上支付渠道堵了四十分钟。

这个开头比那些“大家好，今天我们来聊聊测试”的套话强太多。培训内容其实不复杂，核心就三块：测试思维不是找茬，是拆解风险；用例设计要像写侦探小说，每个步骤都有目的；回归测试不是点鼠标，是验证假设。

周老师讲了个具体案例。某次版本更新，开发改了个登录接口的返回码，从“200”改成“201”，测试用例里没更新断言，结果全量回归通过，但实际用户登录后页面空白。原因很简单——前端只认200。他说：“测试用例不是写给自己看的，是写给未来那个熬夜加班的你，让他别踩同一个坑。”

中间休息时，我翻了下培训材料，发现里面夹着几张手写笔记的扫描件，字迹潦草，还有咖啡渍。周老师说那是他第一份工作时的导师留下的，后来导师跳槽去了大厂，但这份笔记他留到现在。笔记里有一句话被红笔圈了三遍：“测不出bug不代表没bug，只代表你没测对。”

后半场是实操环节。周老师让我们分组给一个模拟的购物车功能写测试用例，限时二十分钟。我们组四个人，争论焦点是“优惠券叠加”这个场景要不要覆盖。有人觉得太边缘，有人觉得必须测。周老师走过来看了一眼，说：“你们先想想，这个功能上线后，最可能出问题的是哪类用户？”

答案其实很简单——用优惠券的人。他接着说：“测试不是做加法，是做减法。把最可能出事的路径先走通，比列一百条用例但每条都浅尝辄止强。”

培训结束时，周老师没做总结，只留了个邮箱，说“有问题的测试用例可以发给我，我帮你们看看”。我后来真发了一封，他回复得很快，附了一段代码片段，还加了个表情包。

说实话，这场培训没讲什么高深理论，但比那些讲“测试金字塔”“敏捷流程”的课有用。因为它让我记住了一个具体画面：那个晚上，周老师盯着屏幕，看到支付渠道堵了四十分钟时，他大概在想——要是当初多写一条断言就好了。

测试这行，说白了就是跟自己的侥幸心理较劲。培训内容可以忘，但那个“必挂勿删”的注释，我大概会记很久。