3、需求分析与测试策略：需求可测试性分析、测试策略文档编写、测试优先级与风险评估
说实话，很多车载项目翻车，根源不在测试执行，而在需求阶段就埋了雷。我见过太多团队拿到需求文档直接开写用例，结果测到一半发现需求根本没法测——要么描述模糊，要么逻辑矛盾。今天咱们就聊聊怎么在需求阶段就把这些坑填上。
3.1 需求可测试性分析
什么叫可测试性？说白了就是：你拿到一条需求，能不能设计出明确的通过/不通过标准。如果一条需求写成“系统响应要快”，那测试就没法做——多快算快？2秒？200毫秒？
可测试性三要素
- 可观测：测试结果能被明确感知（屏幕亮了/灭了）
- 可量化：有具体数值或阈值（≤500ms）
- 可复现：相同输入总能得到相同输出
我在项目中遇到过一条经典的反面案例：“导航系统在复杂路况下应提供合理路线”。什么叫“合理”？谁来定义？后来我们跟产品经理吵了三轮，最终改成：“在连续3个路口拥堵时，自动切换至备选路线，切换时间≤2秒，备选路线预计到达时间不超过原路线的1.3倍”。这才算能测。
3.1.1 常见不可测需求类型
| 类型 | 典型描述 | 问题所在 |
|---|---|---|
| 模糊形容词 | “界面应美观大方” | 没有客观标准 |
| 隐含条件 | “在恶劣天气下正常工作” | 未定义“恶劣”的量化指标 |
| 逻辑矛盾 | “同时支持A和B，但A与B互斥” | 设计冲突 |
| 依赖未定义 | “根据用户偏好调整” | 偏好数据来源未说明 |
我的习惯：拿到需求文档后，先花30分钟做一轮“可测试性评审”。每一条需求都问自己三个问题：
- 我能设计出通过/不通过的判定条件吗？
- 这个判定条件需要什么测试环境？
- 如果测不过，我能明确指出哪里不符合吗？
三个问题只要有一个答不上来，这条需求就得打回去重写。
3.2 测试策略文档编写
测试策略文档不是写给别人看的，是给自己团队用的作战地图。我见过最糟糕的测试策略——洋洋洒洒50页，全是模板套话，真正干活的人翻两页就困了。
我个人习惯把测试策略文档控制在5-8页，核心就四块内容：
3.2.1 测试策略文档结构
| 章节 | 内容要点 | 篇幅建议 |
|---|---|---|
| 测试范围 | 明确测什么、不测什么 | 1页 |
| 测试层级 | 单元/集成/系统/验收的分配比例 | 1页 |
| 环境与工具 | HIL台架、仿真环境、实车配置 | 1-2页 |
| 风险与优先级 | 高风险项、核心功能、回归策略 | 2-3页 |
避坑指南：我曾经在某个项目中把测试策略写得过于详细，连每条用例的预期结果都列进去了。结果需求一变更，整个文档作废，团队白干两周。后来我学乖了——策略文档只定方向，不定细节。具体用例交给测试用例库去管。
3.2.2 测试层级分配原则
车载系统测试有个经典的比例模型，我称之为“金字塔+冰淇淋”：
- 底层（单元测试）：占40%。MCU驱动、算法模块、通信协议栈。这些跑得快、成本低。
- 中层（集成测试）：占35%。模块间交互、CAN/LIN信号、SOA服务调用。
- 顶层（系统测试）：占25%。全链路场景、实车路试、OTA升级。
为什么不是传统金字塔？因为车载系统对集成测试的要求远高于普通软件。你想想看，一个刹车信号从传感器到执行器，中间经过3个ECU、2条总线、1个网关——任何一个环节出问题都是人命关天。
3.3 测试优先级与风险评估
资源永远不够，时间永远紧张。这是测试的常态。所以我们必须学会做减法——哪些功能必须测透，哪些可以放一放。
3.3.1 风险矩阵
我常用的方法是“影响程度 × 发生概率”二维矩阵：
| 影响程度 | 高概率 | 中概率 | 低概率 |
|---|---|---|---|
| 致命 | P0（必须测） | P0（必须测） | P1（重点测） |
| 严重 | P0（必须测） | P1（重点测） | P2（常规测） |
| 轻微 | P2（常规测） | P3（可选测） | P4（不测） |
优先级定义
- P0：影响安全或法规合规，必须100%覆盖，不可跳过
- P1：核心功能或高频场景，覆盖率≥90%，可接受少量遗漏
- P2：常规功能，覆盖率≥70%，可基于风险抽样
- P3：边缘功能或低频场景，覆盖率≥30%，仅做冒烟测试
- P4：不测，记录在案，后续迭代再补
3.3.2 风险评估的实战经验
嗯，这里要注意——风险评估不是一次性的。需求变了、架构改了、甚至供应商换了，风险等级都得重新评估。我习惯在每个迭代开始前做一次15分钟的风险快评，只问三个问题：
- 这次改动涉及哪些模块？
- 这些模块之前出过什么bug？
- 如果出问题，最坏后果是什么？
有一次，一个看似无害的UI文案修改，我按流程做了风险快评，发现改的是仪表盘的“续航里程”显示——而这块代码跟电池管理系统的底层算法有耦合。结果一测，果然把续航计算逻辑带偏了。要是没做这个快评，直接上线，车主看到续航里程忽高忽低，投诉电话得被打爆。
我的小技巧：在测试策略文档里专门留一页“已知风险清单”，用表格列出：
- 风险描述
- 影响范围
- 当前缓解措施
- 责任人
- 状态（开放/关闭）
这个清单每周更新一次，项目复盘时它就是最好的素材——哪些风险我们预判到了，哪些漏了，为什么漏。
3.4 本章知识结构图
下面这张图把需求分析到测试策略的完整链路串起来了，你可以把它贴在工位旁边：
这张图的核心逻辑就一句话：需求不可测，后面全是白干。先做可测试性分析，把模糊需求挡在门外；再写测试策略，定好方向和资源分配；最后用风险矩阵排优先级，确保有限资源用在刀刃上。
你想想看，如果每个项目都能把这三步走扎实，测试返工至少能减少40%。我亲身验证过——一个原本计划3个月的项目，因为前期需求分析到位，测试策略清晰，最后提前2周交付，而且线上bug率比同期项目低了60%。