4. 测试资产分类与编码规范

在 MicroAutoBox 项目验收过程中，测试资产往往散落在不同工程师的本地目录、不同版本的模型仓库和不同批次的标定数据中。如果没有统一的分类与编码规范，验收时最常出现的问题不是“测不出来”，而是“找不到、对不上、说不清”。测试资产治理的第一步，就是让每一类资产都有明确的类别归属、可解析的命名和可追溯的版本标识。

一、先分类：六类资产，六种生命周期

MicroAutoBox 项目中的测试资产通常可归为六类，它们的产生者、变更频率和验收关注点各不相同：

• 测试用例：描述“测什么、预期什么”，以需求条目为源头，变更相对稳定，验收关注覆盖率与需求追溯。
• 测试脚本：描述“怎么测”，包括自动化脚本、CAPL 脚本、Python 测试序列等，随接口和信号定义变化而频繁修改。
• 标定数据：包括 A2L、DCM、PAR、CDFX 等，与具体软件版本强绑定，验收关注与 HEX/S19 版本的一致性。
• 模型：Simulink 模型、被控对象模型、接口模型，关注版本、变体与代码生成配置。
• 报告：测试报告、标定报告、验收记录，是结果证据，关注可复现性与签署状态。
• 缺陷记录：问题单、偏差单、回归记录，关注状态流转与关联的用例、脚本和版本。

分类不是给文件夹起名字，而是决定“谁可以改、改完影响谁、验收时查什么”。例如标定数据一旦与软件版本脱钩，即使测试全部通过，也无法证明该标定适用于当前交付的控制器软件。

二、再编码：让文件名自己说清身份

推荐采用分段式编码，各段用短横线或下划线分隔，顺序固定，便于脚本解析和人工识别。一个可落地的结构如下：

项目_资产类型_被测对象_功能域_序号_版本_状态.扩展名

示例：
MABX_TC_ESC_Brake_0012_v1.3.0_Released.xlsx
MABX_TS_ESC_Brake_0012_v1.3.0_Draft.py
MABX_CAL_ESC_Brake_20240612_v2.1.0_Released.a2l
MABX_MDL_Vehicle_Plant_0007_v0.9.2_Review.slx
MABX_RPT_ESC_Brake_0012_v1.3.0_Approved.pdf
MABX_DEF_ESC_Brake_0031_v1.0.0_Open.xlsx

各段含义需要团队内统一约定，不能各自解释：

版本标识必须与状态联动。Draft 表示仍在编辑，Review 表示待评审，Released 表示可用于集成测试，Approved 表示已通过验收签署。验收时只允许引用 Released 或 Approved 状态的资产，Draft 和 Review 只能作为过程记录，不能作为验收证据。

三、版本标识：区分“文件版本”与“内容版本”

很多团队只靠文件名中的日期区分版本，例如 Brake_20240612.xlsx，这会导致两个问题：同一天多次修改无法区分，跨天修改又看不出内容是否兼容。更稳妥的做法是同时保留语义化版本和内容指纹。

语义化版本 v主.次.修订 的约定建议为：主版本变更表示接口、信号定义或测试判定准则发生不兼容修改；次版本变更表示新增用例、新增标定量或新增测试步骤；修订版本变更表示文字修正、注释补充或参数微调，不影响测试结论。内容指纹可用文件哈希前八位表示，例如 v1.3.0-a3f91c2e，写入报告和缺陷记录中，用于确认“验收时用的到底是哪一份文件”。

四、分类、编码与版本的关系

下图展示了六类测试资产如何通过统一编码汇聚到验收证据链中。分类决定资产类型缩写，编码决定文件身份，版本与状态决定该资产能否被验收引用。

五、落地检查：编码规范是否真的可用

规范写完不等于落地。建议在验收前做一次“编码体检”，用脚本扫描资产目录，检查以下项目：文件名是否符合分段结构、类型缩写是否在允许集合内、序号是否重复、版本号是否与状态匹配、Released 资产是否都有对应的报告和缺陷记录。对于不符合的文件，不直接重命名，而是登记到缺陷记录中，由责任人修正后重新提交。

当六类资产都按统一编码命名，并且版本与状态联动受控时，验收工作会从“翻目录找文件”变成“按编号查证据”。测试用例能追溯到需求，脚本能追溯到用例，标定数据能追溯到软件版本，报告能追溯到具体执行批次，缺陷记录能追溯到受影响的资产版本。这才是测试资产治理真正要达成的状态。