📚 课程目录第2章 AutomationDesk工程结构与工作空间

2. AutomationDesk工程结构与工作空间

AutomationDesk 的工程并不是一个单独的文件，而是一个由工程文件、测试序列文件、测试步骤库、参数集、报告模板以及若干辅助资源共同组成的目录体系。理解这套结构，是后续能够独立搭建自动化测试项目、复用测试逻辑、定位运行结果的前提。本节从“工程里到底有什么”出发，逐层拆解项目、测试序列、测试步骤、测试用例与测试报告之间的关系，并说明 IDE 界面各区域与磁盘目录的对应方式。

一、从工程到测试用例的层级关系

AutomationDesk 采用典型的树形层级组织测试资产，自上而下依次为：工程（Project）→ 测试序列（Test Sequence）→ 测试步骤（Test Step）→ 测试用例（Test Case）。需要特别注意的是，测试用例并不是一个独立的文件类型，而是对“一组测试步骤 + 参数集 + 期望结果”的逻辑封装，通常以测试序列中的某个分支或某个被标记的步骤组来体现。

工程是最高层容器，对应磁盘上的一个工程目录，其中包含一个主工程文件（扩展名通常为 .aap 或与具体版本相关的工程描述文件）。测试序列是工程下的可执行单元，每个序列保存为独立文件，扩展名一般为 .adts。测试步骤是序列内部的最小执行单元，它可以是赋值、等待、条件判断、调用外部工具、读写 dSPACE 变量、执行 Measurement 或 ControlDesk 操作等。测试用例则是在序列内部通过步骤组合与参数化形成的、具有明确通过/失败判据的测试逻辑。

这种层级带来的直接好处是：同一套测试步骤可以在不同参数集下反复执行，从而用少量序列覆盖大量测试用例；而测试报告则按执行批次自动生成，把每个用例的实际结果、时间戳、失败原因汇总成可追溯的记录。

二、IDE 界面布局与工作空间

打开 AutomationDesk 后，主界面通常由以下几个区域构成，理解它们的分工可以显著减少操作时的来回切换：

工程浏览器（Project Explorer）：以树形展示工程下的所有序列、参数集、报告模板和外部资源。右键菜单是新建序列、导入步骤库、设置活动参数集的主要入口。
序列编辑器（Sequence Editor）：中央主工作区，以表格或图形化方式展示当前序列的步骤列表。每一行是一个测试步骤，列通常包括步骤类型、名称、参数、超时、使能状态等。
步骤库/工具箱（Step Library / Toolbox）：按类别列出可插入的步骤模板，例如通用步骤、dSPACE 专用步骤、信号处理步骤、文件与报告步骤。拖拽或双击即可插入到序列中。
属性/参数面板（Properties / Parameters）：显示当前选中步骤或序列的详细属性，是填写变量名、期望值、容差、超时时间的地方。
输出与报告视图（Output / Report View）：运行过程中显示日志、警告和错误；运行结束后可直接打开生成的测试报告。

这些面板的位置和显隐状态共同构成“工作空间（Workspace）”。AutomationDesk 允许保存不同的工作空间布局，例如“编辑布局”和“调试布局”，方便在编写序列和排查失败之间快速切换。对于初学者，建议先保持默认布局，待熟悉各面板职责后再自定义。

三、工程目录组织与文件类型

一个典型的 AutomationDesk 工程目录大致如下（目录名可自定义，此处为示例）：

MyProject/
├── MyProject.aap              # 工程描述文件
├── Sequences/
│   ├── SmokeTest.adts         # 冒烟测试序列
│   ├── BrakeTest.adts         # 制动功能测试序列
│   └── Regression/
│       └── FullRegression.adts
├── ParameterSets/
│   ├── Nominal.par            # 标称参数集
│   └── Boundary.par           # 边界参数集
├── Reports/
│   └── ReportTemplate.rpt     # 报告模板
├── Resources/
│   ├── Variables.map          # 变量映射
│   └── Tools/                 # 外部脚本或可执行文件
└── Logs/
    └── 2025-06-01_Run01/      # 按批次存放运行日志与报告

其中 .adts 是测试序列文件，.par 是参数集文件，.rpt 是报告模板。变量映射文件用于把 AutomationDesk 中的符号名与 dSPACE 实时系统中的变量路径对应起来，是连接测试逻辑与被测对象的桥梁。运行日志和报告通常按时间批次分目录存放，便于回归对比。

建议在工程建立初期就约定目录命名规范，例如序列按功能模块分目录、参数集按工况命名、报告按“日期_批次”归档。这样在序列数量增长到几十个之后，仍然能快速定位目标文件。

四、一个最小可运行示例

下面以一个“电机转速阶跃响应检查”为例，说明各层级如何落地。假设被测对象是一个电机控制模型，目标是在 0.5 s 时把目标转速从 1000 rpm 阶跃到 2000 rpm，并检查 1.5 s 后实际转速是否进入 2000±50 rpm 范围。

在工程下新建序列 MotorStepTest.adts。
插入步骤：设置目标转速变量 TargetSpeed = 1000，等待 0.5 s。
插入步骤：设置 TargetSpeed = 2000，等待 1.5 s。
插入步骤：读取实际转速 ActualSpeed，判断是否满足 1950 ≤ ActualSpeed ≤ 2050。
若满足则标记该用例通过，否则标记失败并记录实际值。
选择参数集 Nominal.par 运行序列，运行结束后在报告视图中查看结果。

这里，TargetSpeed 和 ActualSpeed 是变量映射中定义的符号名，具体路径由 dSPACE 工程决定。判断条件中的 1950 和 2050 是示例容差，实际项目中应根据控制精度和测量噪声调整。运行报告会记录该用例的名称、执行时间、实际转速值和判定结果，形成可追溯的测试证据。

测试用例的通过/失败判据必须明确写在步骤中，不能只靠人工观察。否则报告只能记录“执行过”，无法证明“通过”。容差设置过紧会导致误报，过松则失去检测意义，建议结合被测对象的稳态误差和传感器精度确定。

五、常见混淆点

初学者容易把“测试序列”和“测试用例”混为一谈。简单区分：序列是文件，用例是逻辑。一个序列可以包含多个用例，也可以只包含一个；一个用例也可以跨多个序列通过调用关系组合。另一个常见问题是把参数集写死在步骤里，导致同一序列无法复用于不同工况。正确做法是把可变数值提取到参数集，步骤中只引用参数名，这样切换参数集即可覆盖标称、边界、故障等多种场景。

掌握以上结构后，后续无论是编写复杂序列、调试失败用例，还是整理测试报告，都能在清晰的层级框架下进行，而不是面对一堆零散文件无从下手。