8. 需求评审阶段测试人员到底要做什么？
很多新手以为测试工作从开发提测才开始。
其实真正成熟的测试，应该从需求评审阶段就介入。越早发现问题，修复成本越低。
一、需求评审不是旁听会议
测试参加需求评审，不是为了听产品念文档。
测试要做的是：
- 理解业务目标；
- 确认业务规则；
- 发现需求遗漏；
- 提出异常场景；
- 评估测试范围和风险；
- 判断需求是否可测试。
如果需求阶段没有问清楚，后面写用例和执行测试都会很被动。
二、先确认业务流程是否闭环
一个需求必须有完整流程。
比如优惠券需求，要问：
- 优惠券从哪里创建；
- 用户如何领取；
- 哪些商品可用；
- 满足什么条件可用；
- 使用后状态如何变化；
- 订单取消后是否退回；
- 退款后优惠券如何处理；
- 过期后是否自动失效。
这就是从生命周期角度看需求。
三、重点追问异常场景
需求文档通常写正常流程多，异常流程少。
测试要主动补充：
- 数据为空怎么办；
- 重复提交怎么办；
- 网络超时怎么办；
- 权限不足怎么办；
- 状态不允许怎么办；
- 第三方接口失败怎么办；
- 并发操作怎么办。
很多线上问题都是异常场景没定义清楚导致的。
四、权限和角色必须提前确认
企业系统里，权限问题非常常见。
需求评审时要问：
- 哪些角色能看到这个功能；
- 哪些角色能新增、编辑、删除；
- 数据权限按部门还是个人；
- 管理员和普通用户有什么区别；
- 通过接口访问是否也要校验权限；
- 离职、禁用用户的数据如何处理。
权限如果评审阶段不明确，后面很容易返工。
五、数据规则要问细
测试要关注数据从哪里来、到哪里去。
比如订单需求，要确认：
- 订单号如何生成；
- 金额如何计算；
- 状态如何流转；
- 库存何时扣减；
- 支付流水如何关联；
- 取消后数据如何恢复；
- 历史数据是否兼容。
如果数据规则不清楚，用例很难写完整。
六、可测试性也要评估
不是所有需求都天然可测试。
测试要确认：
- 是否有测试环境；
- 是否有测试账号；
- 是否需要造数据；
- 是否依赖第三方服务；
- 是否有日志可查；
- 是否有后台配置入口；
- 是否能模拟异常场景。
如果第三方支付、短信、风控无法模拟，要提前沟通测试方案。
七、评审后要输出测试关注点
需求评审结束后，测试最好整理：
- 测试范围；
- 不测范围；
- 核心流程；
- 高风险点；
- 需要确认的问题；
- 测试数据和环境依赖。
这能避免后续出现“我以为你会测”“我以为这个不用测”。
八、面试回答模板
可以这样回答：
需求评审阶段我不会只听产品讲功能，而是会从业务流程、异常场景、权限角色、数据规则、兼容影响和可测试性几个方面确认需求。比如订单类需求，我会重点问订单状态如何流转、库存什么时候扣减、支付失败或超时怎么处理、取消后优惠券和库存是否恢复、不同角色能否操作。评审后我会整理测试范围、高风险点、疑问点和测试数据依赖，为后续用例设计做准备。
这个回答能体现你有前置质量意识。
九、下一步建议
需求评审能力是业务测试进阶的关键。
建议你每次看需求都问五类问题：
- 主流程是否完整；
- 异常场景是否明确；
- 权限角色是否清楚；
- 数据状态是否闭环；
- 是否具备测试条件。
配套刷题：
