第三章 测试计划制定：从需求到文档的完整链路
测试计划这东西，说白了就是整个台架测试的「施工图纸」。我刚入行那会儿，总觉得写计划是浪费时间，撸起袖子直接干多痛快。结果呢？测到一半发现漏了关键工况，设备借调冲突，报告格式五花八门……嗯，后来我学乖了。一份靠谱的计划，能帮你省下至少 30% 的返工时间。
3.1 需求分析：搞清楚你到底要测什么
需求分析是第一步，也是最容易被忽视的一步。很多人拿到测试任务就开始列条目，其实这是个大坑。
核心问题就三个：
- 测什么？——被测对象的功能、性能、边界
- 为什么测？——验证设计指标？排查故障？还是法规认证？
- 测到什么程度算够？——通过/失败判据是什么
我个人习惯的做法：
拿到需求文档后，先画一张「需求-功能-测试项」映射表。把客户或研发说的每一句话，拆解成可验证的测试点。比如客户说「电机响应要快」，那就要量化成「从 0 到 1000rpm 的上升时间 ≤ 200ms」。
我在项目中遇到过最典型的翻车案例：研发说「系统在高温下要稳定」，测试组直接上了 85°C 环境箱。结果测完发现，客户真正关心的是 85°C 下连续运行 1000 小时的寿命，而不是短时功能。你看，需求没对齐，方向全跑偏。
3.2 测试范围界定：学会做减法
测试范围不是越全越好。资源有限，时间有限，你得学会取舍。
范围界定三要素：
- 包含项：明确哪些功能、模块、工况必须测
- 排除项：明确哪些不测（比如已由供应商验证过的子部件）
- 优先级：按风险等级排先后顺序
| 优先级 | 定义 | 举例 |
|---|---|---|
| P0 | 安全相关，必须通过 | 急停功能、过流保护 |
| P1 | 核心功能，影响用户体验 | 响应时间、精度 |
| P2 | 边缘场景，可接受降级 | 极端温度下的性能衰减 |
| P3 | 非功能性，可延期 | 日志格式优化 |
我曾经踩过的坑：有一次为了追求「全覆盖」，把 P3 级别的测试项塞满了计划表。结果 P0 的测试因为设备排期冲突被压缩，最后交付时出了安全事故。从那以后，我定范围时一定先砍掉低优先级，把资源留给高风险项。
3.3 测试策略选择：用什么方法打这场仗
策略决定了你的测试效率。选对了，事半功倍；选错了，天天加班。
常见的策略组合：
- 基于风险的测试：优先测故障后果严重的场景
- 等价类划分：用少量典型值覆盖大量输入空间
- 边界值分析：专门测临界点（比如 0%、100%、110% 负载）
- 正交试验法：多因素组合时，用最少的用例覆盖主要交互
你想想看，一个台架测试可能有几十个参数，每个参数又有多个档位。全组合测试？不现实。我一般先用正交表筛选出 20-30 组关键组合，再补上边界值和典型工况。这样既保证覆盖率，又控制用例数量。
我的经验：对于台架测试，我强烈推荐「风险优先 + 边界覆盖」的组合策略。80% 的严重缺陷都出现在边界或异常工况下，而不是正常工况。
3.4 测试计划文档编写：把思路变成可执行的文字
文档不是写给领导看的，是写给执行者看的。好的计划文档，应该让一个新人照着做也能跑通。
标准文档结构：
- 概述：测试背景、目标、范围
- 测试环境：台架配置、仪器仪表、软件版本
- 测试用例清单：用例编号、描述、前置条件、步骤、预期结果
- 资源与排期：人员分工、设备分配、时间节点
- 风险与预案：可能遇到的问题及应对措施
- 交付物：测试报告、数据记录、问题清单
# 示例：测试用例条目格式
用例编号：TC-HIL-001
测试名称：急停按钮功能验证
前置条件：台架处于运行状态，转速 3000rpm
测试步骤：
1. 按下急停按钮
2. 观察电机是否在 500ms 内停止
3. 检查故障码是否记录
预期结果：电机停止 ≤ 500ms，故障码 E001 记录
实际结果：（留空，执行时填写）
写文档的三个原则：
- 可复现：每一步都要精确，别写「适当调整」这种模糊词
- 可追溯：每个用例都要能追溯到原始需求
- 可量化：预期结果必须有具体数值或判据
3.5 知识体系总览：一张图看懂测试计划
下面这张图，是我自己总结的测试计划制定流程。每次做新项目前，我都会对着它过一遍，确保没有遗漏。
这张图的核心逻辑是：需求驱动范围，范围决定策略，策略指导文档，文档经过评审才能发布。而且整个过程不是线性的——评审发现问题，要回退到前面环节修正。
3.6 避坑指南：我踩过的那些雷
雷区一：计划写得太细，反而没人看
我曾经写过一份 50 页的计划文档，每个步骤都配了截图。结果执行团队根本不想翻，直接问我「重点在哪几页？」。后来我改成 10 页核心 + 附录，核心部分控制在 3 页以内，阅读率反而高了。
雷区二：忽略设备校准状态
有一次计划里写了「使用高精度扭矩传感器」，但没确认传感器是否在校准有效期内。结果测出来的数据偏差 5%，整批测试作废。现在我的计划里一定会加一行「设备校准状态确认」作为前置条件。
我的习惯：计划文档发布前，我会找执行工程师和研发各做一次 15 分钟的快速评审。执行工程师看可操作性，研发看测试覆盖是否合理。两轮下来，文档质量能提升一大截。