测试策略制定：基于风险的测试策略、测试范围界定、测试优先级划分
测试策略这东西，说白了就是回答三个问题：测什么、测多少、先测谁。很多团队一上来就铺用例，结果核心模块漏了，边缘功能反而测得很细。我见过不止一个项目，因为测试策略没想清楚，最后交付前通宵补测，还出了线上事故。
这一章，咱们就聊聊怎么用风险来驱动测试决策。不是拍脑袋，而是有章法地做取舍。
为什么一定是基于风险？
嵌入式项目的资源永远是有限的。人力、时间、硬件环境，哪样都不够用。你想想看，一个产品可能有几百个功能点，但能跑完所有组合的团队，我干了十几年也没见过几个。
所以必须做减法。那减谁？留谁？
答案很简单：风险高的优先测，风险低的少测或不测。这不是偷懒，是工程理性。
核心原则：测试投入 = 风险等级 × 影响范围。风险越高，测试越深；影响越大，覆盖越全。
第一步：风险识别与评估
我个人习惯把风险来源分成三类：
- 功能风险——逻辑复杂、状态多、边界模糊的功能。比如通信协议栈的状态机，一个状态跳错就可能死锁。
- 变更风险——新代码、重构代码、修复过的代码。改过的地方最容易出问题，这是铁律。
- 环境风险——硬件不稳定、驱动不成熟、外设兼容性差。嵌入式里，硬件坑比软件坑多。
评估的时候，我常用一个简单的二维矩阵：
| 风险维度 | 低 (1分) | 中 (2分) | 高 (3分) |
|---|---|---|---|
| 发生概率 | 几乎不会触发 | 特定条件下出现 | 正常操作就会触发 |
| 影响严重度 | 功能降级，可恢复 | 功能丧失，需重启 | 系统崩溃、数据丢失、安全风险 |
| 可检测性 | 日志明显，容易复现 | 需要特定手段才能捕获 | 偶发、难以复现、无日志 |
风险总分 = 概率 × 严重度 × 可检测性系数。分数越高，越要优先投入测试资源。
我的经验：可检测性这个维度经常被忽略。有些bug虽然严重，但一测就现形，反而不那么可怕。真正要命的是那些偶尔出现、又抓不住日志的幽灵bug。我在一个车载项目中遇到过，CAN总线丢帧每周只出现一次，查了两个月才定位到是中断优先级配置问题。这种风险，测试策略里必须给最高优先级。
第二步：测试范围界定
风险评完了，接下来就是划边界。哪些功能必须测？哪些可以放一放？
我一般用「三层过滤法」来界定范围：
- 第一层：强制覆盖——安全相关、法规要求、核心业务流程。这些没得商量，必须测。
- 第二层：风险驱动覆盖——风险评分高于阈值的功能模块。阈值可以动态调整，项目初期设低一点，后期收紧。
- 第三层：抽样覆盖——低风险、稳定模块。按比例抽测，比如每个模块抽20%的用例，确保基本功能正常。
举个例子，我之前做的一个工业控制器项目：
- 强制覆盖：看门狗复位逻辑、安全停机流程、固件升级失败回滚
- 风险驱动覆盖：Modbus TCP 协议栈（历史bug多）、多任务调度（竞态条件风险高）
- 抽样覆盖：LED指示灯逻辑、蜂鸣器控制（简单、稳定、几乎没改过）
这样一划，测试范围从原来的300个功能点压缩到了120个，但核心风险一个没漏。
注意：抽样覆盖不是不测，而是用更少的用例覆盖基本路径。如果抽样测试发现了问题，就要把整个模块提升到风险驱动覆盖层级，重新评估。
第三步：测试优先级划分
范围定了，但执行顺序呢？总不能同时跑120个测试吧？
优先级划分，我遵循一个简单的规则：先测风险最高的，再测最容易测的。
具体来说，我把测试用例分成四个象限：
| 优先级 | 特征 | 执行策略 |
|---|---|---|
| P0 | 高风险 + 高影响 | 每次构建必须通过，阻塞后续测试 |
| P1 | 高风险 + 低影响 / 低风险 + 高影响 | 每日回归测试，失败需24小时内修复 |
| P2 | 低风险 + 低影响 | 每周回归，或集成测试阶段执行 |
| P3 | 边缘场景、非功能性 | 有时间就测，没时间就跳过 |
为什么把「容易测的」也放前面？因为快速反馈能建立信心。你想想看，如果跑了一晚上测试，早上发现全是P3用例失败，而P0还没跑完，那这反馈就毫无意义。
我的习惯：每天早上第一件事，先看P0用例的通过率。如果P0全绿，这一天心里就有底。如果P0有失败，不管P1-P3多漂亮，我都不会发布版本。这个习惯救过我很多次。
风险策略的动态调整
测试策略不是写一次就完事的。项目在变，风险也在变。
我一般每两周做一次风险重评，主要看三点：
- 新引入了哪些代码变更？——变更风险上升
- 最近发现了哪些bug？——对应模块的风险等级要调高
- 硬件版本有没有换？——环境风险可能变化
举个例子，有一次项目中期换了MCU型号，我立刻把外设驱动和中断相关的测试全部提升到P0。果然，新MCU的GPIO中断响应时序和旧版不一样，差点踩坑。
本章知识结构图
下面这张图总结了基于风险的测试策略制定流程，从风险识别到优先级划分，再到动态调整，形成一个闭环。
避坑指南
最后分享几个我踩过的坑，希望能帮你少走弯路。
我曾经犯过的错：
- 过度依赖历史数据。有一次我完全根据上一版本的bug分布来定测试重点，结果新版本的核心改动恰恰在历史低风险区域，上线就出了大问题。历史数据只能参考，不能替代当前版本的风险评估。
- 忽略非功能性风险。性能、稳定性、安全性这些非功能需求，在风险矩阵里经常被低估。我见过一个设备，功能测试全过，但连续运行72小时后内存泄漏导致死机。非功能性风险，建议单独建一个评估维度。
- 优先级一成不变。项目中期发现了一个严重bug，修复后我忘了把对应模块的优先级调回来，结果后续回归测试覆盖不足，同类问题再次出现。优先级要动态调整，别偷懒。
基于风险的测试策略，核心就是一句话：把有限的测试资源，投入到最可能出问题的地方。这不是理论，是每个嵌入式测试工程师每天都要做的决策。希望这一章的内容，能帮你把这个决策做得更理性、更有章法。