内容摘要：测试工作流程？说穿了就一句话：在错误的时间发现错误，成本最低。这话我干了八年测试才真正嚼出味道来。 刚入行那年，我负责一个电商系统的回归测试。开发改了个促销模块的代码，我按老用例跑了一遍，全绿。结果上

测试工作流程？测试说穿了就一句话：在错误的时间发现错误，成本最低。工作这话我干了八年测试才真正嚼出味道来。流程

刚入行那年，测试我负责一个电商系统的工作回归测试。开发改了个促销模块的流程代码，我按老用例跑了一遍，测试全绿。工作结果上线当晚，流程用户下单时优惠券叠加出负数金额，测试一晚上损失六位数。工作后来查原因，流程开发改了个底层公共函数，测试影响面远超促销模块——而我的工作用例根本没覆盖到那条调用链。

那次事故后，流程我重新梳理了流程，发现真正有效的测试工作，从来不是从“写用例”开始的。

第一步是需求评审。别急着点头说“明白”，你得追问：这个功能给谁用？在什么场景下触发？数据异常时系统该有什么反应？很多bug在需求阶段就埋下了——比如“用户可修改手机号”这句话，没说明是否需要验证旧手机号，开发按自己的理解做了，测试也按自己的理解验了，结果上线后用户账号被盗改。

第二步是测试计划。这里我不谈那些模板化的排期表，只说一件事：你得先搞清楚“哪些地方改了”。代码diff、接口文档变更、数据库表结构调整，这三样东西比任何测试工具都重要。我习惯拿到需求后先问开发要变更点清单，然后基于变更点去设计用例，而不是把整个系统从头到尾点一遍——那是给新人练手用的，不是给项目保命用的。

第三步才是用例设计。但我的做法可能和教科书不太一样：我会先写“反向用例”。比如登录功能，正向就是输对账号密码能进去，但真正容易出问题的是——密码连续错五次会不会锁定？锁定后多久解锁？解锁后是否需要重新验证？这些边界情况才是线上事故的高发区。正向用例是保底，反向用例才是护城河。

执行阶段有个反直觉的经验：别按用例顺序跑。我习惯先跑那些“影响面最大”的用例——比如支付流程、数据导出、权限校验。因为这些模块一旦出问题，后面所有用例都白跑。先跑高风险，再跑中低风险，最后用随机探索测试去“碰运气”——有时候你随手乱点反而能点出开发都想不到的bug。

至于缺陷管理，我只坚持一条：写bug报告时，把复现步骤写到“一个实习生照着做也能复现”的程度。别写“点击按钮后页面报错”，要写“在Chrome 120版本下，登录后点击右上角‘设置’，选择‘账号管理’，再点‘解绑手机’，页面弹出500错误，控制台报错信息为XXX”。信息越具体，开发修得越快，扯皮越少。

最后说回归测试。别迷信自动化，很多团队把自动化覆盖率当成KPI，结果用例跑得飞快，但线上照样出问题——因为自动化用例本身就是按老逻辑写的，代码一重构，用例也跟着失效了。我现在的做法是：每个迭代留出20%的时间做手工探索测试，专门找那些自动化覆盖不到的角落，比如不同浏览器下的样式错乱、弱网环境下的超时处理、快速点击时的并发请求。

测试这行干久了你会发现，流程不是束缚你的锁链，而是帮你兜底的网。网眼可以调大调小，但你不能没有网就下水。那些觉得“测试就是点点点”的人，大概率没经历过线上事故的深夜——电话响起，老板在群里@你，用户数据一片混乱，而你翻遍用例库，找不到一条能解释当前现象的记录。

那时候你才会明白，真正靠谱的流程，不是让你按部就班地走完每个步骤，而是让你在每一个环节都多问一句“如果这里出问题，后果是什么”。问得多了，网就织密了。