第四章 一致性验证范围：必测项、选测项、测试用例分级、通过准则
做1AS一致性验证，第一个要搞明白的问题就是：“我到底要测什么？”
这个问题听起来简单，但实际项目中踩坑的比比皆是。我见过不少团队，把验证范围定得太宽，结果测试周期拉长、成本爆炸；也见过定得太窄，最后交付物被客户怼回来重做。
说白了，验证范围的划定，直接决定了你的工作量、项目周期和交付质量。这章我就把必测项、选测项、测试用例分级和通过准则这四块内容，掰开揉碎了讲清楚。
4.1 必测项 vs 选测项
先区分两个核心概念：必测项和选测项。
| 对比维度 | 必测项 | 选测项 |
|---|---|---|
| 定义 | 标准中明确要求的、不可省略的验证内容 | 标准中推荐但对特定场景可选的验证内容 |
| 来源 | 1AS 规范中的“Shall”条款 | 1AS 规范中的“Should”或“May”条款 |
| 优先级 | 最高，必须全部覆盖 | 中/低，根据风险评估决定 |
| 后果 | 未覆盖或不通过 → 验证失败 | 未覆盖需提供合理理由，不通过可谈判 |
| 典型例子 | 协议数据单元格式、帧ID分配、时间同步精度 | 冗余校验方式、特定异常恢复流程 |
我个人的习惯是，在项目启动阶段就拉一张表，把标准中所有条款过一遍，明确标注出每一个条款是“必测”还是“选测”。这一步做扎实了，后面测试用例设计就不会跑偏。
4.2 测试用例分级
光区分必测和选测还不够。同一个必测项下面的测试用例，重要程度也有差异。所以我一般把测试用例分成三个等级：P0、P1、P2。
- P0（关键级）：直接影响系统安全或主要功能的用例。比如ECU休眠唤醒时的状态迁移、总线仲裁逻辑。P0用例只要有一个不过，验证结论直接判“不通过”。
- P1（重要级）：影响系统性能或兼容性的用例。比如网络负载波动下的响应时间、异常帧过滤。P1用例可以接受小比例的失败，但必须说明原因并评估风险。
- P2（一般级）：边界条件或非主流场景的用例。比如极端温度下的时序抖动、不常见的故障码注入。P2用例主要用于完善验证覆盖，不强制100%通过。
我举个例子你就懂了。记得我之前做过一个车载网关项目，标准要求验证“连续发送1000帧无丢包”。这个用例按说应该归P0，因为丢包直接影响通信可靠性。但当时因为时间紧，测试组把它降成了P2。结果呢？跑了几百帧就发现间歇性丢帧，还好被早发现了，不然项目交付出大问题。
4.3 通过准则
有了用例分级，怎么判断最终“过没过”？这就是通过准则要解决的问题。
我个人习惯把它拆成两个层面：单个用例的通过准则和整体验证的通过准则。
4.3.1 单个用例的通过准则
每个测试用例都需要写清楚：什么样的行为算通过，什么样的行为算失败。不是简单地“帧能发出去就行”。
标准格式一般是这样的：
- 前置条件：ECU上电完成，总线处于空闲状态
- 测试步骤：发送ID为0x123的数据帧，长度8字节
- 预期结果：在5ms内收到ACK确认，且无错误帧出现
- 通过条件：连续100次测试，成功次数≥98次
你想想看，如果预期结果只写“收到ACK”，那偶尔丢一次ACK算不算失败？所以一定要把通过条件量化。
4.3.2 整体验证的通过准则
这个就涉及到项目级别的“绿灯”究竟是什么。我常用的判定逻辑是：
- 所有P0用例必须100%通过，一个都不能少。
- P1用例通过率≥90%，且未通过项必须有明确的风险评估和客户确认。
- P2用例通过率≥70%，未通过项可在内部评审中裁决。
- 所有必测项必须有测试报告，选测项如果放弃了，必须书面说明理由。
| 等级 | 通过率要求 | 未通过处理方式 |
|---|---|---|
| P0 | 100% | 必须修复后重新测试 |
| P1 | ≥90% | 需风险评估 + 客户确认 |
| P2 | ≥70% | 内部评审裁决 |
嗯，这里要注意一点：通过率不是唯一的度量标准。我遇到过一种情况，P0用例全过了，但P1用例里有一个“总线负载超过80%时的帧丢失率”没通过。最后发现这个场景在实车中几乎不可能出现，所以通过风险评估后，客户同意豁免。这很正常，关键是流程要留痕。
4.4 整体验证范围框架
到这里，我把必测项、选测项、用例分级、通过准则串联一下。下面这张图，基本就是我用来指导项目验证范围设计的框架。
你可以按照这个框架，一步步梳理你的项目。从标准条款出发，先分出必测和选测；然后把必测项按P0、P1、P2分级；选测项单独做风险评估；最后套用通过准则来判断验收条件。
好了，验证范围这块的核心我基本讲完了。你下次接到新项目，不妨先花半天时间，把标准条款过一遍，画出你自己的验证范围矩阵。这步做好了，后面的测试执行效率和交付质量，都会轻松很多。