测试工作流程图

测试工作流程图挂在墙上已经三个月了，测试A3纸打印的工作，边角微微卷起。流程没人主动去换，测试也没人觉得它过时——它就像办公室里的工作绿萝，活着，流程但没人在意。测试

那张图是工作测试组长老周画的。方框、流程菱形、测试箭头，工作标准的流程UML活动图。从需求评审开始，测试到测试计划、工作用例设计、流程执行、缺陷跟踪、回归、上线，最后是个圆角矩形写着“结束”。流程清晰得像高速公路的指示牌，但实际跑起来，没人按指示牌走。

上个月有个版本，开发提前两天提测。老周按流程图该走“提测准入检查”，结果发现代码连编译都没过。他愣了三秒，把流程图从墙上撕下来，揉成一团扔进垃圾桶。第二天又打印了一张新的，用红笔在“提测”旁边加了个小字：“先跑冒烟”。

这事挺典型。流程图画的是理想状态，真实世界是泥潭。你按流程走，第一步就卡住——需求文档里写着“支持多端”，开发说“先做Web，App下个迭代”。测试用例写到一半，产品经理跑来说“这个按钮文案改了”，你回头一看，需求文档还没更新。流程告诉你“需求变更要走评审”，但评审会排到三天后，线上bug等不了三天。

所以那张图真正的价值不在流程本身，而在它旁边贴的便利贴。黄色的是“提测前记得问开发要自测报告”，蓝色的是“线上问题先复现再提单”，粉色的是“周五下午别发版”。这些是流程图上没有的，全是踩坑踩出来的。

我见过最离谱的一次，测试环境数据库被人清了。按流程图，环境问题该找运维，运维说“我们没动”。查了半天，是隔壁项目组的同事连错了库，drop table跑得飞快。从那以后，流程图旁边多了张便签：“连库前先看host”。

测试这行干久了你会发现，流程图是骨架，人是血肉。骨架保证你不会散架，但真正让你跑起来的是那些不成文的规矩。老周有句话糙理不糙：“流程是给新人看的，老人看的是异常。”新人照着流程图走，至少不会犯大错；老人早把流程内化了，遇到问题直接跳步，跳完再补流程。

现在那张新流程图又贴了两个月，边角又开始卷。这次没人打算撕它。红笔加的那句“先跑冒烟”已经成了团队默认动作，流程图反而成了记录我们怎么变通的历史文件。哪天要是流程真跑顺了，那张图可能就撤了——但估计那天不会来。测试这行，永远有意外，永远有新的便利贴要往上贴。