3. 测试项目结构设计

在 vTESTstudio 中，一个测试项目并不是把若干测试用例简单堆在一起，而是由测试配置（Test Configuration）→ 测试单元（Test Unit）→ 测试用例（Test Case）→ 测试步骤（Test Step）构成的四级层次结构。理解这四级之间的“谁包含谁、谁引用谁、谁决定谁”的关系，是后续编写 CAPL 测试代码、组织工程目录、以及让测试可维护、可复用的前提。

一、四级层次各自承担什么职责

测试配置是工程中最上层的可执行单元，它决定“这次测试跑什么、按什么顺序跑、在什么环境下跑”。一个测试配置通常绑定一个或多个测试单元，并关联目标总线/网络环境（如 CAN、CAN FD、LIN、以太网）、仿真节点、诊断描述文件（CDD/ODX）以及硬件通道映射。测试配置本身不写测试逻辑，它更像一份“执行清单 + 环境声明”。

测试单元是逻辑分组单位，通常按被测对象或功能域划分，例如“车门控制单元”“电池管理系统 BMS”“诊断服务 UDS”。测试单元内部可以包含多个测试用例，也可以嵌套子测试单元。测试单元是复用和并行执行的基本粒度：同一测试单元可以被多个测试配置引用，从而在不同环境（如台架、HIL、实车）下重复使用。

测试用例是最小的“可判定单元”，它必须能给出明确的通过/失败结论。一个测试用例通常对应一条需求或一个测试点，例如“验证车速超过 20 km/h 时车门自动上锁”。测试用例内部由若干测试步骤组成，并带有前置条件、后置处理、判定逻辑和报告输出。

测试步骤是测试用例内部的原子操作，例如“设置信号 VehicleSpeed = 25”“等待 200 ms”“读取信号 DoorLockState”“断言 DoorLockState == Locked”。测试步骤是真正与总线、信号、诊断服务交互的地方，也是 CAPL 代码最密集的层级。

二、层级之间的引用关系与设计原则

这四级不是简单的“文件夹嵌套”，而是引用关系。测试配置通过引用测试单元来组装执行集，测试单元通过包含测试用例来组织逻辑，测试用例通过调用测试步骤来执行操作。这意味着同一个测试单元可以出现在多个测试配置中，同一个测试用例也可以被多个测试单元引用。设计时应遵循三条原则：

• 高内聚：一个测试单元只负责一个功能域，一个测试用例只验证一个测试点，避免“大而全”的用例。
• 低耦合：测试步骤之间尽量独立，通过参数传递数据，而不是依赖全局变量或执行顺序。
• 可追溯：每个测试用例应能映射到具体需求编号，便于生成需求覆盖报告。

三、工程目录组织规范

vTESTstudio 工程在磁盘上以目录和文件的形式存在，合理的目录结构直接影响团队协作效率。推荐按“配置—单元—用例—资源”四个维度组织：

MyProject/
├── Configurations/          # 测试配置
│   ├── Bench_Config.vtconfig
│   └── HIL_Config.vtconfig
├── TestUnits/               # 测试单元
│   ├── BMS/
│   │   ├── BMS_Unit.vtunit
│   │   └── TestCases/
│   │       ├── TC_OverVoltage.vtcase
│   │       └── TC_UnderVoltage.vtcase
│   └── DoorControl/
│       ├── Door_Unit.vtunit
│       └── TestCases/
│           └── TC_AutoLock.vtcase
├── Steps/                   # 可复用测试步骤库
│   ├── CommonSteps.can
│   └── DiagSteps.can
├── Resources/               # 环境与描述文件
│   ├── DBC/
│   ├── CDD/
│   └── Panels/
└── Reports/                 # 测试报告输出

其中 Steps/ 目录存放可复用的 CAPL 函数库，供多个测试用例调用；Resources/ 集中管理 DBC、CDD、面板等环境文件，避免路径散落。测试配置和测试单元文件建议使用有意义的英文命名，测试用例文件以 TC_ 前缀标识，便于在 vTESTstudio 的 Test Tree 中快速定位。

四、一个具体示例：车门自动上锁测试

以“车速超过 20 km/h 时车门自动上锁”为例，四级层次落地如下：

对应的测试步骤 CAPL 片段示意：

testcase TC_AutoLock()
{
  // 前置条件
  setSignal("DoorStatus", 0);      // 车门关闭
  setSignal("Ignition", 1);        // 点火 ON

  // 测试步骤
  setSignal("VehicleSpeed", 25);   // 车速 25 km/h
  testWaitForTimeout(200);         // 等待 200 ms
  int lockState = getSignal("DoorLockState");

  // 判定
  if (lockState == 1) {
    testStepPass("车门已自动上锁");
  } else {
    testStepFail("车门未上锁，实际值: %d", lockState);
  }
}

五、常见设计误区

• 把测试配置当测试用例用：在配置层写判定逻辑，导致无法复用和追溯。
• 测试单元粒度过粗：一个单元塞进几十个用例，执行失败时难以定位。
• 测试步骤依赖全局变量：步骤之间通过全局变量传值，顺序一变就失败。
• 目录与逻辑结构不一致：磁盘目录随意堆放，Test Tree 中却按功能分组，导致维护困难。

掌握这四级层次和目录规范后，后续编写 CAPL 测试代码、配置测试环境、生成测试报告时，就能做到“结构清晰、职责分明、复用高效”。