风险驱动测试：不要把所有需求测成同一个深度

风险驱动测试的核心，是让测试深度和业务风险匹配。

测试资源永远不够。需求多、时间短、环境不稳定、研发还在改代码，这些都是常态。如果每个功能都按同样深度测试，团队看起来很公平，实际上很低效。风险驱动测试要解决的就是这个问题：把更多时间用在更可能影响用户和业务的地方。

先给模块分层

我通常会从四个维度判断风险：

• 用户影响：出问题后影响多少用户，是否影响核心链路。
• 变化频率：最近是否频繁改动，是否有大重构。
• 依赖复杂度：是否依赖支付、权限、消息、第三方服务。
• 历史缺陷：过去是否经常出同类问题。

这四个维度不需要做成复杂模型，一张简单表格就够了。重要的是团队一起讨论，研发、产品、测试都能解释为什么某个模块被标成高风险。

测试深度要不同

高风险模块要有更完整的测试策略：需求评审提前介入、接口和数据校验、异常路径、兼容性、灰度观察、线上监控都要覆盖。低风险模块可以更轻，只做核心路径和必要回归。

风险要持续更新

风险不是一次评审后就固定。一个本来低风险的模块，如果临时加了紧急需求，或者研发为了修 bug 改了公共组件，它就应该被重新评估。测试计划需要跟着风险变化，而不是跟着最早那版排期僵住。

写在最后

风险驱动测试不是少测，而是让测试更诚实。测试经理要帮助团队承认资源限制，并且把限制转化成清晰的取舍。把所有地方都测得一样深，听起来稳，实际会让真正危险的地方拿不到足够注意力。