📚 课程目录第1章课程导入与全景认知

1. 课程导入与全景认知

在基于 dSPACE MicroAutoBox（下文简称 MAB）的快速控制原型（RCP）项目中，硬件到货、模型下载成功、台架上跑通一次，并不等于项目可以交付。真正决定项目能否被复现、被审计、被交接的，是验收与测试资产治理这两件事。本课程讨论的正是围绕 MAB 项目形成的这套工程秩序：如何定义"做完了"，如何证明"做对了"，以及如何让证据在三个月后、换一个人、换一台机器时依然成立。

一、两个核心概念：验收与测试资产治理

项目验收指依据事先约定的验收准则，对 MAB 项目的交付物逐项核对并给出结论的过程。它的对象不是"代码写完了没有"，而是可验证的交付证据：硬件配置与接线、实时模型与 I/O 映射、标定参数集、测试用例与测试报告、版本与变更记录。验收的典型判据包括：模型在 MAB 上以指定采样周期稳定运行、关键信号在预期范围内、故障注入后系统进入预期安全状态、以及所有交付物版本一致可追溯。

测试资产治理指对测试过程中产生的可复用资产进行统一管理，使其具备可发现、可追溯、可复现、可演进的属性。测试资产不只是"测试用例"，它至少包含五类：

测试用例与测试序列：激励条件、判据、前置状态、预期结果；
测试数据：原始测量数据、标定数据、故障注入记录；
测试环境描述：MAB 型号与固件版本、RTI 版本、被控对象台架配置、线束定义；
测试脚本与自动化配置：如 AutomationDesk 工程、Python/MATLAB 驱动脚本；
报告与结论：测试报告、缺陷记录、验收签署记录。

二者关系可以概括为：验收是"一次性判定"，治理是"长期可复现"。没有治理，验收只能靠人回忆；没有验收，治理就失去目标与出口。

二、目标与范围

本课程的整体目标可归纳为四条：一是建立统一的验收准则与判定口径，避免"各人各标准"；二是让测试资产从"散落在个人电脑里"变为"有唯一标识、有归属、有版本"；三是使关键测试可被第三方在无原作者参与的情况下复现；四是形成可审计的变更与签署链路。

范围上需要明确边界。纳入治理的对象包括：MAB 相关的实时模型、I/O 配置、标定文件、测试用例、测试数据、测试环境清单、报告与签署记录。通常不纳入本课程范围的是：被控对象（如发动机、电机、整车）本身的机械与电气设计文件、量产 ECU 的软件基线、以及企业级 PLM/ALM 平台的选型与部署——这些只作为接口与依赖被引用。

范围界定的实用判据：如果某个文件在"换一台 MAB、换一个工程师"后仍需要被找到并用于复现测试，它就应当纳入测试资产治理范围。

三、角色分工

MAB 项目通常涉及四类角色，职责必须清晰分离，否则验收会退化为"自己验自己"：

角色	核心职责	关键产出
测试执行工程师	搭建台架、编写并运行测试用例、采集数据	测试用例、原始数据、初版报告
模型/标定负责人	维护实时模型与 I/O 映射、发布标定参数集	模型版本、A2L/参数集、变更说明
资产管理员	维护资产库结构、命名与版本规则、权限	资产清单、版本台账、归档记录
验收评审人	依据准则独立核对证据、给出通过/有条件通过/不通过结论	验收记录、遗留问题清单

需要强调的是，验收评审人不应是测试执行工程师本人。在资源紧张的小团队中，至少应做到"交叉评审"：由未参与该用例编写的成员执行复核，并保留复核痕迹。

四、整体流程框架

下图给出 MAB 项目从资产产生到验收归档的整体关系。注意它不是一条单向流水线，而是"资产库"作为中心枢纽，测试执行与验收评审分别向它写入和读取证据。

流程上可以按五个阶段推进：资产产生 → 入库登记 → 测试执行与数据采集 → 验收评审 → 归档与基线冻结。其中"入库登记"是最容易被跳过、也最致命的一步：如果测试用例在运行前没有登记唯一标识，那么它产生的数据在两周后就无法与任何用例对应，验收时只能凭文件名猜测。

五、一个可落地的资产命名与登记示例

为了让治理不停留在口号，下面给出一套可直接采用的命名与登记规则示例（示例参数，非实测结果）。命名采用"项目-对象-类型-版本-日期"五段式：

MAB_TC_MotorSpeedStep_TC-014_v1.2_20240612
 │    │        │          │      │      │
 │    │        │          │      │      └─ 生成日期 YYYYMMDD
 │    │        │          │      └──────── 版本号 v主.次
 │    │        │          └─────────────── 用例编号
 │    │        └────────────────────────── 测试对象/场景
 │    └─────────────────────────────────── 资产类型：TC=测试用例
 └──────────────────────────────────────── 项目代号：MAB

配套的登记字段至少应包含：资产ID、类型、负责人、关联模型版本、关联标定版本、MAB固件与RTI版本、台架配置编号、状态（草稿/已评审/已冻结）、存放路径、校验值（如SHA-256）。其中"关联模型版本 + 标定版本 + 固件版本"三者构成复现的最小环境三元组，缺一不可。

常见误区：只记录"模型版本"而忽略标定参数集与固件版本。同一模型在不同标定下可能表现出完全不同的响应，验收结论会因此失效。

六、本课程的学习路径

后续章节将沿着上述框架逐层展开：先讲清验收准则如何从需求推导为可判定的条目，再讲测试资产库的目录结构与命名规则如何设计，然后进入测试用例编写、数据采集与报告生成的具体操作，最后落到验收评审、遗留问题闭环与基线冻结。每一节都会给出可直接套用的字段、规则或检查项，而不是停留在概念描述。

在开始之前，建议先做一次现状盘点：打开你当前的 MAB 项目目录，尝试回答三个问题——最近一次测试用的是哪个模型版本？对应的标定文件在哪里？如果明天换人复现，他能否在十分钟内找到这两样东西？如果答案是否定的，那么本课程要解决的问题，正是你项目里真实存在的风险。