凌晨2:17，生产环境挂了。没有告警，没有预警，只有一片死寂后的混乱。
20个人挤在桥接电话里，各说各话。根因查清后，所有人哑火——有人跳过回归测试，理由是"就是个UI小改动"。
那通电话之后，我对测试的理解彻底变了。不是理论，不是定义，是生存。
冒烟测试：你的第一道防线
如果构建版本连启动都做不到，其他一切免谈。
冒烟测试就是这么简单粗暴：应用能启动吗？能登录吗？核心流程还活着吗？
想象你发动汽车。引擎响了？好，继续。没响？停下来检查，别浪费时间规划路线。
我见过新手测试人员在这上面犯浑。他们试图做得"全面"，把冒烟测成了迷你回归。5分钟能做完的事，硬拖成40分钟。
错了。冒烟测试的价值恰恰在于快和狠。我见过有人5分钟内拒掉一个构建，毫无心理负担。因为烂构建下游浪费的，是几十个人的几个小时。
回归测试：那个被跳过的夜晚
回到凌晨那场事故。改动确实小——登录按钮的样式调整。开发者本地看了眼，没问题，直接合并。
但那个按钮的点击事件绑定在一段复用组件上。样式改动触发了组件重渲染，重渲染打断了异步登录状态检查。结果：用户点击登录，页面刷新，状态丢失，无限循环。
回归测试的存在，就是捕捉这种"我以为没关系"的连锁反应。它不是质疑你的代码，是质疑整个系统的耦合复杂度。
那天的桥接电话里，有个声音特别刺耳："要是跑了那套15分钟的自动化回归，我们现在都在睡觉。"
15分钟对6小时。这笔账，很多人到出事才算明白。
测试金字塔：别在错误楼层堆人
行业里爱画三角形：底层单元测试海量，中间服务测试适中，顶层端到端（End-to-End，即模拟完整用户路径的测试）精简。
道理都懂，执行稀烂。
我见过团队倒过来搞。端到测试写了800个，跑一次4小时，失败率30%。每次失败都要人工排查，是环境问题？数据问题？还是真bug？没人说得清。
单元测试反而没人写。"赶进度"三个字，把金字塔建成了倒三角。
结果？发布周期从两周拖到两个月。因为没人敢合代码，合了就炸，炸了就得查那800个端到端里的哪个在抽风。
测试金字塔不是教条，是成本公式。越底层的测试，定位越快、维护越便宜、反馈越及时。顶层测试必须有，但要像特种部队——精准、昂贵、用在刀刃上。
探索性测试：人比脚本聪明的地方
自动化能跑赢重复，但跑不赢意外。
探索性测试是带着脑子乱点——有计划地乱点。你熟悉用户路径，然后故意走歪：如果在这里双击呢？如果网络突然断了再恢复呢？如果输入框里塞个emoji再删除呢？
最好的探索性测试人员，都有一种偏执。他们不相信"正常用户不会这么干"，他们相信"只要有1%的用户会这么干，乘以日活就是灾难"。
有个经典案例：某支付页面的金额输入框，限制只能输数字。脚本测试通过了。但探索性测试人员发现，复制粘贴可以绕过限制，塞进去一串字母。提交后，后端解析失败，返回了完整的堆栈信息——包括数据库连接字符串。
自动化脚本不会想到复制粘贴。但人会。
生产监控：测试的延长线
凌晨2:17那场事故，最痛的不是bug本身，是"没有告警"。
测试的终点不是上线，是上线后的可观测性。日志、指标、链路追踪——这三件套是你在黑暗里的手电筒。
但太多团队把监控当成运维的事。测试人员写完用例就撤，从不问"如果这功能真挂了，我们多久能知道"。
理想的测试闭环是：设计用例时，同步设计告警规则。这个接口超时了？阈值多少？触发什么动作？谁on-call（值班待命）？
把监控当成测试的验收标准，你会发现很多"测过了"的功能，其实从未被真正保护。
那通凌晨电话的最后，有人问了个问题：如果当时有告警，我们能挽回多少？
没人回答。因为大家都知道，答案不是时间，是信任——用户对产品的信任，团队对流程的信任，以及你对自己工作的信任。
现在你的团队，从代码提交到生产告警，这条链路上 weakest link（最薄弱环节）在哪？
热门跟贴