2、测试策略制定：基于风险的测试策略，测试范围界定，测试优先级划分，测试退出准则

好，咱们进入第二个实战环节。测试策略制定，说白了就是回答三个问题：测什么？先测谁？什么时候停？

我见过太多项目，一上来就铺开测，结果时间不够，该测的没测，不该测的浪费了人力。嗯，这其实是个管理问题，不是技术问题。我个人习惯，拿到一个项目，第一件事不是写测试用例，而是拉上开发、产品、运维，坐下来做一轮风险分析。

2.1 基于风险的测试策略

为什么要基于风险？因为资源永远不够。你想想看，一个工业自动化系统，可能有上千个功能点，但你的测试周期只有两周。怎么办？

我的做法是：把每个功能点按「故障发生概率」和「故障影响程度」两个维度打分。

风险等级	发生概率	影响程度	测试策略
高（H）	频繁出现	系统崩溃/数据丢失	全量覆盖 + 自动化回归
中（M）	偶尔出现	功能降级/性能下降	核心场景覆盖 + 抽样
低（L）	极少出现	界面问题/非核心功能	冒烟测试 + 用户反馈

我在项目中遇到过一件事：一个PLC通信模块，开发说「这个很稳定，不用测太细」。结果上线第一天，现场就出现了数据丢包。为什么？因为开发只测了理想网络环境，没考虑现场有强电磁干扰。从那以后，我对「稳定」这两个字特别敏感。

2.2 测试范围界定

测试范围怎么定？不是拍脑袋，也不是全测。我一般用「三圈法」来界定：

1. 内圈（必须测）：核心业务逻辑、安全相关功能、数据一致性校验。这些不测，项目就别上线。
2. 中圈（建议测）：性能指标、兼容性、异常处理。这些出问题会影响体验，但不至于崩盘。
3. 外圈（可选测）：界面美观度、非关键路径的辅助功能。这些可以放一放，或者交给用户验收。

举个例子。一个自动化产线的MES系统，内圈是「工单下发→设备执行→数据回传」这条链路。中圈是「报表生成速度」「多语言支持」。外圈是「按钮颜色」「字体大小」。你想想看，按钮颜色错了，产线会停吗？不会。但工单下发错了，整条线就废了。

2.3 测试优先级划分

优先级划分，我习惯用P0-P3四级制。注意，这不是拍脑袋，而是有依据的。

优先级	定义	示例	响应要求
P0	阻塞性缺陷，不修复无法继续	登录失败、核心流程中断	立即修复，24小时内
P1	严重缺陷，影响主要功能	数据计算错误、关键接口超时	下一个迭代修复
P2	一般缺陷，有替代方案	某个非核心按钮失效	本版本内修复
P3	轻微缺陷，不影响使用	文案错别字、样式偏移	下个版本修复

这里有个坑，我踩过。有一次，开发说「这个P2的bug不影响功能，先放着」。结果用户验收时，那个bug恰好是客户最在意的功能。嗯，所以优先级不是一成不变的，要结合客户视角动态调整。

2.4 测试退出准则

什么时候可以停止测试？这个问题，很多团队都搞不清楚。我见过两种极端：一种是「测到没bug为止」，另一种是「时间到了就停」。都不对。

我个人习惯，用「量化指标」来定义退出准则。比如：

• 功能覆盖率：所有P0/P1用例100%通过，P2通过率≥95%
• 缺陷收敛率：连续3天新增缺陷数≤2个，且无P0/P1缺陷
• 回归测试通过率：自动化回归用例通过率≥98%
• 性能指标：响应时间、吞吐量、CPU/内存使用率均在阈值内

举个例子。一个SCADA系统的测试，我们定了退出准则：

退出条件：
1. 所有P0用例通过（共12条）
2. P1用例通过率100%（共45条）
3. P2用例通过率≥95%（共120条）
4. 连续3天无新增P0/P1缺陷
5. 压力测试：500并发下，响应时间<2s，无内存泄漏
6. 安全测试：OWASP Top 10 全部覆盖，无高危漏洞

注意，退出准则不是一成不变的。我记得有个项目，客户要求特别严，我们就把P2通过率提到了98%。还有个项目，时间特别紧，我们只要求P0/P1全过，P2可以放一放。灵活一点，别死板。

好了，测试策略制定这块，核心就是这四步：风险分析定方向，三圈法界定范围，P0-P3排优先级，量化指标定退出。你想想看，是不是比「上来就测」靠谱多了？

下一章，咱们聊聊测试用例设计。嗯，那才是真正考验功力的地方。