4. 测试计划制定：范围、策略、资源、进度、风险

测试计划这东西，说白了就是整个测试团队的作战地图。我见过太多项目，一上来就闷头写用例、跑脚本，结果跑到一半发现资源不够、环境冲突、需求还变了。嗯，最后锅全甩给测试。

所以我的习惯是——不管项目多急，先花半天把 Test Plan 敲定。你想想看，方向错了，跑得再快也没用。

4.1 测试范围：什么该测，什么不该测

范围界定是第一步，也是最容易扯皮的一步。我记得有一次做智能家居网关项目，产品经理说“所有功能都要测”，开发说“只测改动的模块”，最后我夹在中间……后来我学乖了，直接用一张表把范围锁死。

4.2 测试策略：怎么测，用什么手段

策略部分，我习惯按测试金字塔来分层。但嵌入式测试跟纯软件不一样——硬件依赖、环境干扰、实时性要求，这些都得单独拎出来说。

具体到每个层级，我会在策略里写明：

• 单元测试：用 Cmock + Unity 做驱动层打桩，每个模块独立编译运行。我习惯在 CI 里配一个“提交即跑”的流水线，10 分钟内出结果。
• 集成测试：重点测中断优先级、DMA 传输、RTOS 任务调度。曾经有一次，两个任务共享一个全局变量没加锁，跑单测全过，一集成就随机死机……后来我规定：所有共享资源必须用信号量保护。
• 系统测试：用真实硬件 + 自动化脚本。比如用 Python 控制继电器模拟上电掉电，用串口抓日志做关键字校验。
• 验收测试：这部分我一般交给产品经理和 QA 一起做，测试团队提供环境和数据支持。

4.3 资源：人、设备、环境、工具

资源计划最容易出问题的是“设备冲突”。一个项目 5 个人，只有 3 块开发板，怎么排？我的做法是提前拉一张资源表，按周分配。

4.4 进度：里程碑 + 迭代节奏

进度计划我一般分两层：里程碑层（给管理层看）和迭代层（给团队用）。

里程碑层长这样：

• M1（第 2 周）：测试计划评审通过，环境搭建完成
• M2（第 4 周）：单元测试完成，覆盖率报告输出
• M3（第 6 周）：集成测试完成，关键问题清零
• M4（第 8 周）：系统测试完成，发布候选版本
• M5（第 9 周）：验收测试通过，发布签字

迭代层我按周排，每周末做一次“测试进展看板”。举个例子：

4.5 风险：提前识别，提前应对

风险这东西，你不管它，它就会来管你。我一般把风险分成三类：技术风险、资源风险、管理风险。

4.6 完整的 Test Plan 模板

说了这么多，最后给一个我一直在用的模板结构。你直接拿去改项目名就能用。

# 嵌入式测试计划模板

## 1. 文档信息
- 项目名称：
- 版本号：
- 编写人：
- 评审人：
- 批准人：

## 2. 测试范围
- In Scope（功能/平台/协议/性能）
- Out of Scope（明确不测的内容）
- 测试通过/失败标准

## 3. 测试策略
- 单元测试（工具、覆盖率目标、责任人）
- 集成测试（重点模块、接口、时序）
- 系统测试（场景、压力、稳定性）
- 验收测试（用户场景、认证标准）

## 4. 资源计划
- 人员（角色、姓名、时间投入）
- 硬件（开发板、仪器、数量）
- 环境（实验室、工具链、CI 配置）

## 5. 进度计划
- 里程碑（M1-M5，含日期）
- 迭代计划（按周排，含交付物）
- 缓冲期安排

## 6. 风险管理
- 风险清单（类别、描述、概率、影响、应对）
- 风险跟踪机制（周更新、责任人）

## 7. 交付物清单
- 测试计划文档
- 测试用例集
- 测试报告（阶段/最终）
- 缺陷报告
- 覆盖率报告

## 8. 审批签字
- 测试经理：
- 项目经理：
- 产品经理：