测试人员不看需求文档，项目出事谁背锅？高危岗位必须养成的7个专业习惯

上周有个项目经理来问我们：测试没看需求文档就开测了，上线出了事故，这锅该谁背？

说实话，这种问题我们一年要听几十遍。但每次我都得先泼盆冷水：追责这件事，从来不是按“谁更错”来分的，是按“谁手里有证据”来分的。

需求文档上没人签字，评审会没留纪要，测试用例跟需求对不上号，这三条里中一条，最后背锅的大概率就是测试。不是因为他最该背，而是因为只有他的工作产物是拿不出手的。开发可以说“我按理解做的”，产品可以说“我口头讲过”，只有测试，交出来的是一份跟原始需求对不上的报告。在验收会上，这就叫失职。

软件测试报告

反过来，如果用例每条都挂着需求编号，需求变更有记录、有评估、有回归范围确认，那出事就不是测试的锅，是变更没被管住的锅。这两件事的性质完全不一样，一个赔钱，一个改流程。

所以别纠结“谁背锅”。真正该关心的是，测试这个岗位怎么让自己永远不在“拿不出手”那一栏里。下面这7个习惯，是我们看了几百份报告、参与过几十次事故复盘之后总结出来的。不优雅，但真能保命。

习惯一：没拿到可验证的需求，不开工

“可验证”三个字是关键。写的是“系统运行流畅”“界面友好”，这不叫需求，这叫愿望。测试接到的第一件活，其实是把愿望翻译成能判定的句子，响应时间多少秒算流畅、几步之内完成操作算友好。翻译不了，就写进报告的不确定项里，别自己硬扛。

习惯二：用例必须挂需求编号，一条都不能悬空

这是最土也最有效的一招。用例上没有需求编号的，一律视为无效用例。听起来死板，但它解决了一个真实问题：当有人问你“这个场景你凭什么测”时，你能在三秒内指给他看。 三秒内指不出来，你在会上就已经输了，后面的技术细节没人听。

习惯三：需求变更必须有痕迹，哪怕只是一封邮件

微信语音不算，口头沟通不算。最少最少，也得有一封带日期的邮件，或者一份改了版本号的文档。很多项目的事故源头都不是变更本身，而是变更发生了，但只有两个人知道。测试是最晚知道的那个人，却往往是第一个被问“你怎么没测到”的人。

习惯四：明确写下“本次不测什么”

这一条大部分人不敢做，因为怕显得不专业。恰恰相反，敢写排除项的人，才真的控得住范围。 不覆盖的机型、不压的生产环境极限、不扫的模块，白纸黑字列出来。这不是推脱，这是给未来的自己留一条退路。真出事了，这份清单比任何解释都管用。

习惯五：结论只下在测过的地方，不 extrapolate（外推）

测了Chrome就说Chrome，别顺手写一句“主流浏览器均兼容”。测了500并发就说500并发，别加一句“系统可支撑大规模用户”。多写的这一句，将来就是别人拿来打你的原话。报告的每一句多余的话，都是给对方递的刀子。

习惯六：版本号、系统名称逐字对齐

看着像小事，但它是所有低级错误里最救不回来的那种。“XX系统V2.0”和“XX平台V2.0”，在逐字比对那一关，谁的解释都没用，只能重做。花十秒钟核对一下，省的是两周工期。

版本号对齐系统名称

习惯七：留一份自己能翻出来的原始记录

用例执行记录、扫描原始结果、环境配置截图、监控数据导出。这些东西平时没用，一旦要用，就是救命的那根绳子。体系要求原始记录至少保存六年，这不是官僚主义，是给三年后的某场会准备的。

说句实在的，这7条里没有一条能提高测试的技术水平。它们提高的是另一样东西：可追溯性。而可追溯性，才是测试这个岗位真正的护城河。技术会过时，工具会换，但“我说过的每句话都有出处”这件事，永远不会贬值。

最后补一句可能不太讨喜的：如果你现在的流程里，需求没人签字、变更全靠口头、用例不编号，那出事的时候别急着找背锅的人。先看看这个流程，是不是从一开始就在等一个人来背锅。

标签：软件测试、测试需求