📚 课程目录第3章测试用例设计基础

3、测试用例设计基础：测试用例要素、设计原则、覆盖准则（语句、分支、MC/DC）及在AUTOSAR中的特殊要求

AUTOSAR（AUTomotive Open System ARchitecture）作为全球主流的汽车软件架构标准，其分层解耦的设计思想（应用层、RTE、基础软件层）在提升代码复用性的同时，也带来了测试复杂度的显著增加。在AUTOSAR环境下，测试用例设计不再是简单的“输入-输出”映射，而是需要结合RTE事件触发机制、BSW模块状态机、以及多核/多分区并发特性进行系统性设计。本章将深入剖析测试用例的核心要素、设计原则与覆盖准则，并重点阐述AUTOSAR架构下特有的测试设计约束与实战方法。

3.1 测试用例的核心要素与设计原则

核心原理：测试用例的本质是将测试需求转化为可执行、可判定、可追溯的具体操作步骤。在AUTOSAR环境中，一个完整的测试用例必须包含八个关键要素：唯一标识（TC_ID）、需求追溯（Requirement Trace）、前置条件（Precondition）、测试输入（Test Input）、执行步骤（Procedure）、预期结果（Expected Result）、实际结果（Actual Result）以及测试环境（Environment）。其中，前置条件在AUTOSAR中尤为重要，因为BSW模块的状态（如ComM的COMM_NO_COMMUNICATION、COMM_FULL_COMMUNICATION）直接决定了测试路径的可行性。

判断方法：设计测试用例时，应遵循以下原则：可追溯性——每个用例必须能追溯到具体的SWS（Software Specification）章节或系统需求；最小化冗余——避免重复覆盖同一逻辑路径；可重复性——在相同环境下执行结果必须一致；可判定性——预期结果必须明确，不能出现“系统正常”这类模糊描述。在AUTOSAR中，还需额外关注时序敏感性，即测试用例必须明确指定RTE事件触发的周期、偏移量和优先级。

要素	说明	AUTOSAR示例
前置条件	ECU状态、通信状态、模式	ComM处于FULL_COMMUNICATION，CanSM处于STARTED
测试输入	信号值、报文、RTE事件	CAN报文ID=0x123，DLC=8，Data=0x01 0x02...
预期结果	返回值、状态迁移、事件触发	BswM模式请求切换至RUN，RTE事件E_OK
环境约束	OS核、分区、时钟频率	运行在Core0，Partition1，时钟40MHz

实战场景：以AUTOSAR的CanSM（CAN状态管理器）模块为例，设计“Bus-Off恢复”测试用例。前置条件需设置CanSM处于FULL_COMMUNICATION状态，且CAN控制器已进入Bus-Off状态。测试输入为等待Bus-Off恢复定时器超时（通常为128个总线空闲周期）。预期结果应验证CanSM状态机从BUSOFF状态迁移至PRE_FULL状态，并最终恢复至FULL_COMMUNICATION。该用例必须明确指定使用的CAN通道（Can_0）、波特率（500kbps）以及是否启用了错误帧注入。

常见误区：许多测试工程师在编写AUTOSAR用例时，忽略了模式管理（BswM）的影响。例如，在测试Dcm（诊断通信管理）时，如果BswM当前处于SLEEP模式，Dcm的请求将无法被处理。因此，用例的前置条件必须包含BswM的模式状态，否则测试结果将不可复现。

3.2 覆盖准则：从语句覆盖到MC/DC

核心原理：覆盖准则用于衡量测试用例对代码逻辑的覆盖程度。在AUTOSAR功能安全（ISO 26262）要求下，ASIL-D等级通常要求MC/DC覆盖。各准则的强度递增：语句覆盖（SC）要求每条可执行语句至少执行一次；分支覆盖（DC）要求每个判定的真/假分支至少执行一次；条件/判定覆盖（C/DC）要求每个条件的所有可能结果至少出现一次，且每个判定本身的所有可能结果也至少出现一次；MC/DC则进一步要求每个条件必须独立影响判定的结果。

操作流程：在AUTOSAR环境中实施MC/DC覆盖，需遵循以下步骤：
1. 使用工具（如VectorCAST、Parasoft）解析BSW模块的C代码，生成条件/判定列表。
2. 分析每个判定中的独立条件对，例如if (a && b)中，a和b均为独立条件。
3. 设计测试用例矩阵，确保每个条件都能独立翻转判定结果。例如，对于if (a && b)，需要设计(a=1,b=1)->真，(a=0,b=1)->假，(a=1,b=0)->假三组用例。
4. 在AUTOSAR的RTE环境中，通过注入信号或修改内部变量来满足条件组合。

覆盖准则	定义	AUTOSAR适用场景	工作量
语句覆盖	每条语句执行一次	单元测试冒烟	低
分支覆盖	每个判定的真/假分支	模块集成测试	中
MC/DC	每个条件独立影响判定	ASIL-C/D安全相关模块	高

案例拆解：以AUTOSAR的E2E（端到端保护）模块为例，其校验逻辑包含if (DataID == expectedID && CRC == calculatedCRC)。为达到MC/DC覆盖，需设计以下用例：
① DataID正确+CRC正确 → 通过（真）
② DataID错误+CRC正确 → 失败（假，由DataID独立影响）
③ DataID正确+CRC错误 → 失败（假，由CRC独立影响）
④ DataID错误+CRC错误 → 失败（假，组合验证）
在AUTOSAR测试环境中，可通过修改RTE的E2E_P01Protect函数的输入参数来模拟上述条件。实际执行时，需在CANoe中构造带错误CRC的报文，并监控E2E状态机的状态迁移。

经验提醒：在AUTOSAR中，由于RTE层对SWC（软件组件）的封装，直接进行MC/DC覆盖存在一定困难。建议采用“白盒+灰盒”混合策略：对BSW模块使用白盒工具进行代码级覆盖，对SWC使用RTE事件注入进行接口级覆盖。同时，利用AUTOSAR的#if defined(UNIT_TEST)编译选项，在测试版本中暴露内部变量，便于条件控制。

3.3 AUTOSAR架构下的特殊测试设计要求

核心原理：AUTOSAR的分层架构和标准化接口带来了三类特殊测试需求：RTE事件时序测试、BSW状态机全覆盖以及多核/分区并发测试。RTE作为SWC与BSW之间的通信中枢，其事件触发机制（周期性、事件型、混合型）直接影响测试用例的时序设计。BSW模块（如ComM、CanSM、BswM）的状态机迁移路径必须被完整覆盖，包括非法状态迁移的容错测试。多核架构下，跨核通信（IOC）的延迟和一致性成为测试重点。

判断方法：设计AUTOSAR特殊测试用例时，应遵循以下判断路径：
1. 识别被测对象属于SWC还是BSW，以及其依赖的RTE接口类型（CS接口、Sender-Receiver接口、Mode接口）。
2. 分析RTE事件触发条件，确定是周期触发（如10ms）还是事件触发（如信号变化）。
3. 检查是否涉及跨核通信，若涉及，需增加IOC延迟测试和缓存一致性测试。
4. 对于BSW模块，绘制完整的状态迁移图，确保每个迁移路径至少有一个测试用例。

特殊要求	测试重点	典型工具/方法
RTE时序	事件延迟、周期抖动、优先级反转	CANoe + RTE Instrumentation
BSW状态机	合法/非法迁移、超时处理、错误恢复	状态图覆盖矩阵
多核并发	IOC通信延迟、共享资源竞争、死锁	多核调试器 + 压力测试
模式管理	BswM模式切换、模式请求仲裁	模式切换序列测试

实战案例：某项目在测试AUTOSAR的BswM模块时，发现模式切换请求存在竞态条件。初始现象：当Dcm请求进入PROGRAMMING模式的同时，ComM请求进入FULL_COMMUNICATION模式，BswM出现模式冲突，导致ECU复位。分析过程：通过RTE日志发现，两个请求在同一个RTE周期内到达，BswM的仲裁逻辑未考虑并发场景。实际操作：设计并发测试用例，使用CANoe的CAPL脚本同时发送两个模式请求，并监控BswM的状态输出。结果对比：修复前，BswM随机选择模式，导致系统不稳定；修复后，BswM按照优先级（Dcm > ComM）进行仲裁，系统稳定。复盘经验：AUTOSAR测试必须覆盖并发事件，不能仅测试单一事件触发。

风险提示：在AUTOSAR多核测试中，若使用传统的单核调试器，可能无法捕获跨核通信的时序问题。建议使用支持多核同步断点的调试工具（如Lauterbach TRACE32），并配合硬件时间戳（DWT）来精确测量IOC延迟。此外，测试用例必须明确指定运行的核心和分区，否则在调度器配置变化时，测试结果将不可复现。

3.4 测试用例设计流程与质量评估

核心原理：一个完整的AUTOSAR测试用例设计流程包含五个阶段：需求分析、场景识别、覆盖策略制定、用例生成、评审与维护。需求分析阶段需提取SWS中的功能需求、时序需求和安全需求。场景识别阶段需结合系统用例（System Use Case）和时序图（Sequence Diagram）识别正常路径、异常路径和边界路径。覆盖策略制定阶段需根据ASIL等级确定目标覆盖准则。用例生成阶段需将场景转化为具体的测试步骤和预期结果。评审与维护阶段需确保用例的可追溯性和可维护性。

操作流程：质量评估可通过以下指标进行：用例密度（每千行代码对应的用例数）、需求覆盖率（已追溯需求/总需求）、缺陷检出率（用例发现的缺陷数/总缺陷数）。在AUTOSAR项目中，建议使用需求管理工具（如DOORS、Polarion）与测试管理工具（如TestWeaver、VectorCAST）进行集成，实现需求-用例-缺陷的双向追溯。

阶段	输入	输出	质量检查点
需求分析	SWS、系统需求	需求列表、优先级	需求可测试性
场景识别	时序图、用例图	场景清单	场景完整性
覆盖策略	ASIL等级、代码结构	覆盖目标	覆盖准则合理性
用例生成	场景、覆盖目标	测试用例集	用例可执行性
评审维护	用例集、缺陷报告	更新后的用例	追溯性、一致性

经验总结：在AUTOSAR项目中，建议采用“基于风险的测试设计”方法。对于安全关键模块（如E2E、Fls），采用MC/DC覆盖并增加故障注入测试；对于非安全模块（如Xcp），采用分支覆盖即可。同时，建立用例复用库，将常见的BSW模块测试用例（如CanSM的Bus-Off恢复、ComM的模式切换）标准化，可显著提高测试效率。最后，务必在每次软件迭代后更新用例，确保与代码变更同步。