第2章测试策略制定

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

测试策略这东西，说白了就是回答三个问题：测什么？怎么测？测到什么程度算完？

我见过太多团队，一上来就闷头写测试用例，结果到项目后期才发现——关键模块没覆盖到，低风险的地方反而测了一大堆。嗯，这就是典型的「没有策略」。

今天咱们就聊聊，怎么用风险来驱动测试策略。这套方法我在好几个嵌入式项目里验证过，效果还不错。

为什么要基于风险？道理很简单：资源永远不够用。你想想看，一个嵌入式项目，硬件成本、开发周期、测试人力，哪个不是紧巴巴的？

基于风险的测试策略，核心就一句话：把测试资源集中在风险最高的地方。

风险 = 故障发生的概率 × 故障造成的损失

我们不是要消除所有缺陷，而是要把缺陷控制在可接受的风险范围内。

我在一个车载项目中遇到过这种情况：某个传感器接口的通信协议，理论上很简单，但一旦出错会导致车辆误判。我们评估下来，概率虽然低，但损失极高。最后我们给这个接口安排了3轮交叉测试，外加一次硬件在环仿真。结果真就抓到了一个时序问题。

具体怎么评估风险？我习惯用这个四象限法：

我的经验：风险矩阵不是一次定死的。项目中期，随着硬件改版、需求变更，风险等级会变。我建议每两周重新审视一次风险矩阵。

有了风险等级，优先级就好定了。但这里有个坑——很多人把「风险高」和「优先级高」直接划等号。其实不完全对。

优先级还要考虑一个因素：测试的依赖关系。

举个例子：某个底层驱动模块风险很高，但它的测试依赖硬件板卡，而板卡要两周后才到。这时候你把它排在最前面，反而浪费时间。

我一般按这个顺序排优先级：

注意：P0的测试必须安排专人负责，而且要有「熔断机制」——如果P0测试发现严重问题，整个项目要停下来评估。

我曾经在一个物联网网关项目里，把通信协议栈排成了P0。结果测试第一天就发现，在弱网环境下，协议栈的重传机制有死循环。幸亏发现得早，不然等整机联调时再暴露，那代价就大了。

测试范围，说白了就是「哪些要测，哪些不测」。很多新手项目经理喜欢说「全测」，但这是不负责任的。

为什么？因为嵌入式系统里，有些东西根本测不完。比如一个RTOS的任务调度，理论上所有任务组合都要测，但实际项目里你只能选典型场景。

我界定测试范围时，会考虑这几个维度：

一个实用的原则：测试范围 = 需求覆盖 × 风险覆盖 × 变更覆盖。三个维度取交集，而不是并集。

嗯，这里要注意。测试范围不是越窄越好。我见过一个团队，为了赶进度，把测试范围砍到只剩核心功能。结果上线后，一个配置参数的边界值没测，导致设备在特定温度下死机。这个教训挺深刻的。

准入准出标准，是测试阶段的「门禁」。没有这个门禁，测试过程就容易失控。

测试准入标准（什么时候可以开始测）：

测试准出标准（什么时候可以结束测试）：

我的习惯：准入准出标准不是一成不变的。项目初期可以严格一些，到了后期如果时间紧张，可以适当放宽——但必须经过风险评审，而且要有书面记录。

我曾经在一个医疗设备项目里，因为准出标准没定好，测试团队和开发团队吵了一个星期。开发说「测完了」，测试说「还没达标」。后来我们坐下来，把准出标准一条条列清楚，签了字，后面就顺畅多了。

测试策略制定，说到底就是做选择题。资源有限，风险无限，怎么选？

这套方法我用了好几年，不能说万无一失，但至少能保证：该测的没漏，不该测的没浪费。

下一章咱们聊聊测试用例设计，那又是另一门手艺了。