第四章：测试策略与计划：制定符合ASPICE要求的测试策略，编写测试计划
好，我们进入第四章。这一章，说白了就是整个测试工作的“总指挥图”。
很多团队一上来就写测试用例，结果测到一半发现资源不够、环境没有、需求变了。嗯，这就是典型的“没有策略，只有蛮干”。
ASPICE 对测试策略和计划的要求，其实就一句话：你得想清楚再动手，而且要把怎么想的写下来。
4.1 测试策略：你的“作战地图”
测试策略不是一张表格，而是一套决策逻辑。它回答三个问题：
- 测什么？（范围）
- 怎么测？（方法）
- 测到什么程度算够？（退出准则）
我个人习惯，在项目启动的第一周，就把测试策略文档的骨架搭好。哪怕内容先空着，框架必须立住。
4.1.1 测试层次的划分
ASPICE 明确要求测试要分层。我见过最典型的错误，就是“单元测试当集成测试做，集成测试当系统测试做”。
| 测试层次 | 测试对象 | 典型方法 | ASPICE 关联过程 |
|---|---|---|---|
| 单元测试 | 单个函数/模块 | 白盒测试、MC/DC覆盖 | SWE.6 |
| 集成测试 | 模块间接口 | 接口测试、桩/驱动 | SWE.7 |
| 系统测试 | 完整ECU/系统 | 黑盒测试、功能测试 | SWE.8 |
| 验收测试 | 客户需求 | 场景测试、实车测试 | VAL.1 |
这里有个坑。我曾经在一个项目中，客户要求“所有单元测试必须达到100%语句覆盖”。听起来很严格对吧？但实际上一测才发现，很多底层驱动代码根本没法做MC/DC覆盖——因为硬件寄存器读操作是“读一次变一次”。
4.1.2 测试方法的选型
测试方法不是越高级越好，而是越匹配越好。我一般按这个优先级来选：
- 基于需求的测试（必须做，ASPICE 硬性要求）
- 等价类划分 + 边界值分析（对付数值型输入，效率最高）
- 状态转换测试（对付有状态机的模块，比如CAN协议栈）
- 决策表测试（对付多条件组合逻辑）
你想想看，如果一个模块有5个布尔输入，用穷举法要测32种组合。但用决策表，可能只需要8-12条用例。这就是策略的价值。
4.2 测试计划：把策略变成可执行的“日程表”
测试计划不是写给别人看的，是给自己用的。ASPICE 要求测试计划至少包含：
- 测试范围与不测范围
- 测试环境与工具链
- 资源分配（谁、什么时候、做什么）
- 风险与缓解措施
- 里程碑与交付物
4.2.1 测试环境规划——最容易翻车的地方
我见过最惨的一次，项目都到Sprint 3了，测试环境还没搭好。为什么？因为硬件采购周期是12周，而项目经理只给了4周准备时间。
所以我的建议是：测试计划里，环境准备必须单独列一个风险项。
✅ 环境规划清单（我自己的模板）：
- 硬件：开发板/ECU数量、调试器、负载箱
- 软件：编译器版本、调试工具、覆盖率工具
- 自动化：测试框架（如Vector CAST、Tessy）、持续集成服务器
- 数据：测试用例库、基线版本、缺陷跟踪系统
4.2.2 测试用例的优先级排序
资源永远不够，所以必须排序。我一般用“风险优先级”来排：
| 优先级 | 定义 | 示例 |
|---|---|---|
| P0 | 安全关键功能，不通过则不能发布 | 刹车灯控制、安全气囊触发 |
| P1 | 核心业务功能，不通过则影响用户体验 | 车窗升降、空调温度调节 |
| P2 | 次要功能，可延迟修复 | 氛围灯颜色切换、仪表盘主题 |
| P3 | 边缘场景，低概率发生 | 极端温度下的显示刷新率 |
嗯，这里要注意：P0的用例必须100%执行，P3的用例可以抽样执行。但抽样比例必须在测试计划里写清楚，否则审计时会被挑战。
4.3 测试策略文档的“避坑指南”
我曾经在一个ASPICE CL2的预审中，被审核员问了一个问题：“你的测试策略里写了‘使用等价类划分’，但你能证明你确实用了这个方法吗？”
我当时一愣。后来才明白，光写“用什么方法”不够，还得写“怎么用”。
💡 我的改进方法：
在测试策略文档里，对每个测试方法都附一个“应用示例”。比如：
方法：等价类划分
应用对象：车速传感器输入（0-300 km/h）
有效等价类：0-300（正常范围）
无效等价类：<0（负值）、>300（超范围）
边界值：0、1、299、300这样审核员一看就明白，你不是在“抄模板”，而是真的在应用。
4.4 测试计划的“动态调整”机制
测试计划不是一成不变的。ASPICE 允许你调整，但要求你记录调整的原因。
我个人的做法是：每周五下午花30分钟，检查测试计划的执行偏差。如果发现某个模块的缺陷率异常高，就临时增加一轮“回归测试”。这个决策必须记录在测试计划变更日志里。
举个例子：
变更记录 V1.2
日期：2025-03-15
变更内容：增加CAN通信模块的集成测试轮次（从2轮增至3轮）
原因：前两轮发现3个接口时序问题，风险等级高
影响：测试周期延长2天，但可避免系统测试阶段返工你看，这样写，既满足了ASPICE的“可追溯性”，又保护了自己——万一项目延期，你能拿出证据说“这是为了质量做的理性决策”。
4.5 小结：测试策略与计划的“黄金三要素”
最后，我总结一下。一个能过ASPICE审核的测试策略与计划，必须包含这三样东西：
- 清晰的层次划分——单元、集成、系统、验收，各司其职
- 可验证的方法说明——不光写“用什么”，还要写“怎么用”
- 动态调整的机制——计划是活的，变更要有记录
说实话，很多团队把测试计划写成了“流水账”，结果审核时被问得哑口无言。你想想看，如果你自己都说不清楚“为什么这么测”，那审核员凭什么相信你测对了？
下一章，我们会深入测试用例的设计——怎么写出“一个顶十个”的高效用例。到时候我会分享一个我压箱底的“测试用例模板”，保证让你少走弯路。
公众号:蓝海资料掘金营，微信deep3321