3. AUTOSAR基础软件测试需求分析

在AUTOSAR量产测试体系中，BSW（基础软件）测试需求分析是承上启下的关键环节。上游是OEM或Tier1提供的ECU提取规范（Extract Specification），下游是可直接驱动测试用例设计的BSW测试需求。很多团队在这一步容易走偏：要么把ECU提取规范原样搬进测试需求，导致需求颗粒度过粗、无法验证；要么凭经验直接写用例，跳过了需求分解，导致覆盖度无法追溯。本节围绕通信、诊断、存储、模式管理四个典型BSW模块，说明如何把ECU提取规范中的配置与行为描述，系统性地分解为可测试、可追溯的BSW测试需求。

一、先理解输入：ECU提取规范里有什么

ECU提取规范通常由系统配置工具（如DaVinci Configurator、EB tresos）从整车网络设计导出，核心内容包括：ECU通信矩阵（报文ID、周期、信号布局、发送类型）、诊断描述（诊断服务、DID、DTC、会话与安全等级）、NvM块配置（块ID、大小、CRC、写策略、默认值）、模式管理配置（EcuM状态、ComM通道、BswM规则）。这些内容本质上是“配置数据+行为约束”，而不是测试需求。测试需求分析的任务，就是把这些配置数据翻译成“在什么条件下、对什么对象、观察什么、期望什么”的可验证陈述。

二、通信模块：从报文矩阵到收发与超时需求

以CAN通信为例，ECU提取规范中会给出报文周期、发送类型（周期/事件）、信号初值和更新方式。分解到ComM/CanIf/Com模块的测试需求时，至少要覆盖三类：

• 发送行为：周期报文在ComM通道进入Full Communication后，是否按配置周期稳定发送；事件报文在信号更新后是否在指定时间内触发发送。
• 接收与超时：对配置了接收超时监控的报文，当连续多个周期未收到时，Com模块是否上报超时，超时阈值是否与配置一致。
• 信号网关与更新位：若存在信号路由，更新位（Update Bit）是否按配置置位和清除，接收端能否正确识别新数据。

这里的关键是把“周期20ms、超时3倍周期”这类配置参数，转成“在通道进入Full Communication后，连续60ms未收到ID 0x123，Com应上报超时”这样的可判定需求。参数值来自提取规范，判定条件来自BSW行为规范。

三、诊断模块：从诊断描述到服务与会话需求

诊断部分通常包含UDS服务列表、DID读写权限、DTC状态位和会话/安全等级。分解时建议按“服务—会话—安全—响应”四层展开：

• 服务可用性：在默认会话下，0x22（ReadDataByIdentifier）对指定DID是否返回正响应；在编程会话下，0x2E（WriteDataByIdentifier）是否被允许。
• 会话切换：0x10服务切换会话后，Dcm是否在P2时间内返回响应，且会话超时后是否自动回默认会话。
• 安全访问：0x27服务在错误密钥下是否返回NRC 0x35，连续错误是否触发延迟。
• DTC处理：故障发生时，DTC状态位是否按配置置位，0x19服务读取的DTC数量与状态是否与Dem配置一致。

诊断需求的难点在于“条件组合多”。建议用判定表把会话、安全等级、服务、DID权限四个维度组合起来，每一行对应一条测试需求，避免遗漏边界组合。

四、存储与模式管理：从块配置到读写与状态迁移

NvM模块的测试需求围绕“块”展开：块ID、长度、CRC类型、写策略（立即写/延迟写）、默认值。分解时要覆盖：上电时NvM_ReadAll是否按配置读取所有块；写请求后是否按写策略在指定时机写入；CRC校验失败时是否回退到默认值并上报错误。模式管理则围绕EcuM、ComM、BswM的状态迁移：例如EcuM从RUN到POST_RUN的迁移条件是否满足，ComM通道是否随EcuM状态进入No Communication，BswM规则是否按配置触发动作。

五、需求分解的实操要点

在实际项目中，建议为每条BSW测试需求分配唯一ID，并记录其来源配置项。例如需求“COM-TX-001：ComM通道进入Full Communication后，ID 0x123周期报文发送周期为20ms±2ms”，其来源是通信矩阵中的周期配置。这样在后续测试执行和缺陷回溯时，可以快速定位是配置问题还是实现问题。

另一个常见问题是“需求不可判定”。比如“诊断服务应正确响应”就无法验证，必须细化为“在默认会话下，对DID 0xF190发送0x22请求，Dcm应在P2时间内返回正响应，数据长度与配置一致”。判定的三要素是：触发条件、观察对象、期望结果，缺一不可。

六、从需求到测试用例的衔接

BSW测试需求分解完成后，下一步是设计测试用例。此时需要注意：一条测试需求可能对应多条用例（正常、边界、异常），也可能多条需求合并到一条用例中验证。关键是保持追溯关系清晰，确保每个配置项都有对应的测试需求，每条测试需求都有对应的用例覆盖。对于通信、诊断、存储、模式管理这四个模块，建议分别建立需求清单，并在需求评审时邀请配置工程师参与，确认分解结果与ECU提取规范一致。

总结来说，从ECU提取规范到BSW测试需求，核心动作是“参数提取—行为识别—可判定陈述—追溯建立—覆盖检查”。掌握这条路径，就能把分散的配置数据转化为结构化、可验证的测试需求，为后续测试用例设计和自动化执行打下基础。