第4章需求阶段的测试左移

第4章：需求阶段的测试左移——需求评审中的测试视角

大家好，我是老赵。今天我们来聊聊需求阶段的测试左移。

说实话，很多团队把测试左移理解成「早点提测」，这其实是个误区。真正的左移，是从需求评审就开始介入。我个人习惯把需求评审叫做「第一道防线」——你想想看，如果需求本身就有问题，后面再怎么测也是白搭。

测试人员参加需求评审，不是去当听众的。我见过太多测试同学坐在角落里，全程不说话，最后问一句「这个需求什么时候提测？」——嗯，这其实是在浪费机会。

测试视角的核心是什么？说白了就三个字：可验证。

需求文档里写「系统响应要快」，这能验证吗？不能。什么叫快？1秒算快还是0.1秒算快？我曾经在一个项目中，产品经理写「用户登录体验流畅」，结果上线后用户投诉登录慢，一查发现「流畅」的定义根本没对齐。

测试视角的三大关注点：

我记得有一次评审支付模块的需求，文档里写「支付失败时提示用户」。我问了一句：「支付失败的原因有哪些？每种原因提示什么内容？」产品经理愣住了。后来我们梳理出12种失败场景，每种都需要不同的提示文案和后续处理逻辑。这就是测试视角的价值。

可测试性分析，说白了就是判断一个需求能不能被「测明白」。我总结了一个简单的检查清单，分享给大家：

检查项	说明	示例（有问题）	示例（改进后）
输入是否明确	输入数据的格式、范围、类型是否定义清楚	「用户输入年龄」	「用户输入年龄，范围0-150，整数」
输出是否可观测	系统行为是否有明确的输出结果	「系统进行优化处理」	「系统返回优化后的结果，响应时间<200ms」
状态是否可控制	测试时能否方便地设置前置条件	「当用户处于特殊状态时」	「当用户账户被冻结时（可通过后台设置）」
异常是否可触发	错误场景能否被构造	「系统在异常情况下自动恢复」	「系统在网络中断30秒后自动重连，重连次数≤3次」

我的小技巧： 拿到需求后，先试着写一个测试用例。如果写不出来，或者写出来全是「待确认」，那这个需求的可测试性就有问题。我曾经用这个方法，在需求阶段就堵住了至少30%的返工风险。

传统流程是：需求→设计→编码→测试用例设计。但左移的做法是：需求评审的同时，就开始设计测试用例。

为什么？因为用例设计的过程，本身就是对需求的二次验证。你想想看，如果你在设计用例时发现某个场景不知道怎么测，那大概率是需求没写清楚。

我习惯的做法是这样的：

避坑指南： 我曾经犯过一个错误——在需求评审时直接抛出完整的测试用例。结果产品经理觉得我在「找茬」，开发也觉得测试管得太宽。后来我学乖了，只提「测试要点」和「风险点」，用提问的方式引导大家思考。效果好了很多。

举个例子，假设需求是「用户可修改个人资料」。测试视角下，我会问：

这些问题看似简单，但很多团队就是在这些「简单」的地方翻车。我记得有个项目，上线后发现用户修改手机号后收不到验证码，一查才发现需求里根本没提「修改手机号需要验证原手机号」——这就是需求用例设计前置能避免的问题。

最后分享一个我实际经历过的案例。某次我们要做一个「优惠券发放」功能，需求文档只有两页纸。我按照左移的思路，做了以下事情：

结果呢？这个功能从需求到上线只用了两周，测试阶段只发现了3个低级bug。而同期另一个没有做左移的功能，测试阶段改了4次需求，延期了一周。

所以我的建议是：别等到提测了才开始想怎么测。从需求评审开始，用测试的视角去审视每一个字。你会发现，很多问题在源头就能解决。

下一章，我们会聊聊设计阶段的测试左移——如何通过设计评审和接口契约，进一步降低风险。到时候见。