第三讲：AutomationDesk入门——工作流、测试序列创建与基础测试用例编写
好，咱们今天正式进入AutomationDesk。说实话，很多刚接触HIL测试的工程师，第一眼看到这个工具会觉得有点懵——界面密密麻麻的，不知道从哪下手。我当年第一次打开它的时候，盯着屏幕看了五分钟，心想：这玩意儿跟LabVIEW长得也不像啊？
别急，今天这一讲，我带你把它拆开揉碎了讲清楚。你只要跟着我的节奏走，一节课下来，你就能自己搭一个简单的测试序列出来。
3.1 AutomationDesk的工作流——先搞清楚它想干嘛
AutomationDesk说白了，就是一个测试脚本的编排工具。它不是用来写底层驱动代码的，也不是用来画UI界面的。它的核心任务就一个：把测试步骤串起来，自动执行，然后出报告。
我个人习惯把它的工作流分成三步：
- 建项目——告诉工具你要测什么，用什么硬件，连哪个模型。
- 写脚本——用图形化或者文本的方式，把测试步骤写清楚。
- 跑并出报告——一键执行，然后看结果。
你想想看，这跟咱们平时手动测试的流程是不是一样的？只不过AutomationDesk帮你把第二步和第三步自动化了。
核心要点： AutomationDesk的工作流是“配置-编写-执行-报告”的闭环。不要一上来就想着写多复杂的脚本，先把项目结构搭对，后面的事就顺了。
3.2 创建你的第一个测试序列
好，咱们打开AutomationDesk。新建一个项目，你会看到左侧有个叫“Test Sequences”的文件夹。右键，新建一个Sequence。
嗯，这里要注意：Sequence是AutomationDesk里最基本的执行单元。一个Sequence里可以包含多个测试步骤，也可以嵌套子Sequence。我刚开始做项目的时候，经常犯一个错误——把所有测试步骤全塞到一个Sequence里，结果一个Sequence几百行，调试起来想死的心都有。
后来我学乖了：一个Sequence只做一件事。比如“上电测试”一个Sequence，“CAN通信测试”另一个Sequence。这样出了问题，定位起来快得多。
创建Sequence之后，你会看到一个类似流程图的工作区。左侧是工具箱，里面有很多现成的模块：
| 模块类别 | 常用模块 | 说明 |
|---|---|---|
| 控制流 | If、While、For | 控制测试的执行逻辑 |
| 动作 | SetValue、GetValue | 读写信号或变量 |
| 检查 | Check、Assert | 判断测试是否通过 |
| 报告 | ReportComment、ReportStep | 在报告中添加注释或步骤 |
拖一个“SetValue”模块到工作区，双击它。你会看到右侧的属性面板。这里要填三个东西：变量名、值、执行时间。比如我想让某个模拟量输出5V，就填上对应的变量名，值填5，时间填1000毫秒。
小技巧： 我个人习惯在变量名前加一个前缀，比如“Sim_”表示仿真模型的变量，“Hw_”表示硬件IO。这样一眼就能看出来这个变量是来自模型还是来自板卡。这个习惯帮我避免过好几次搞混变量的低级错误。
3.3 基础测试用例编写——从“点亮一个灯”开始
咱们来写一个最基础的测试用例。假设我们要测试一个ECU的数字输出引脚，看它能不能在收到CAN报文后拉高。
测试步骤很简单：
- 发送一个CAN报文，让ECU输出高电平。
- 等待200毫秒。
- 读取ECU的输出引脚，判断是否为高电平。
在AutomationDesk里，我会这样搭：
// 伪代码逻辑，实际是图形化拖拽
Step 1: CAN_Send("Msg_EnableOutput", 0x123, 8, [0x01]);
Step 2: Wait(200);
Step 3: result = DI_Read("DigOut_Pin1");
Step 4: Check(result == 1, "输出引脚应为高电平");你可能会问：为什么要在发送报文后等200毫秒？
这个问题问得好。我在项目中遇到过好几次，ECU收到报文后不是瞬间响应的，它内部有处理时间。如果你不等一下直接去读，大概率读到的是旧状态，然后测试就误判失败了。这个等待时间，我一般会根据ECU的响应规格书来定，如果没有规格书，就先试个200毫秒，不行再加。
避坑指南： 我曾经因为等待时间设得太短，导致一个测试用例在实验室跑了一百遍都不过。后来发现是ECU的响应时间比我想象的长了50毫秒。从那以后，我养成了一个习惯：所有等待时间都留出20%的余量。比如规格书说最大响应时间100毫秒，我就设120毫秒。
3.4 测试用例的“骨架”——前置条件、执行、检查、后处理
一个规范的测试用例，我建议至少包含四个部分：
- 前置条件（Precondition）：测试开始前，系统应该处于什么状态。比如“ECU已上电”、“CAN总线正常”。
- 执行（Action）：你要做什么操作。比如发送报文、设置电压。
- 检查（Check）：期望的结果是什么。比如“输出引脚为高电平”。
- 后处理（Postcondition）：测试结束后，把系统恢复到安全状态。比如“关闭输出”、“断开电源”。
很多新手容易忽略后处理。我见过一个案例，测试完没关输出，结果下一个测试用例一上来就读到高电平，以为是自己的测试通过了，实际上那是上一个测试残留的状态。嗯，这种问题排查起来特别费时间。
在AutomationDesk里，我通常会在Sequence的最后加一个“Cleanup”区域，专门放后处理的步骤。不管测试通过还是失败，Cleanup都会执行。这个机制叫“Finally”块，跟编程里的try-catch-finally是一个道理。
3.5 让测试用例“会说话”——添加报告注释
测试跑完了，报告里只有一堆Pass/Fail，领导看不懂，客户更看不懂。怎么办？
加注释。AutomationDesk里有个“ReportComment”模块，你可以在每个关键步骤后面加一句人话。比如：
- “发送使能报文，ID=0x123，数据=0x01”
- “等待ECU响应，200ms”
- “读取数字输出引脚1，期望值为1”
这样生成的报告，哪怕是不懂技术的人，也能看明白你测了什么、怎么测的、结果是什么。我个人的习惯是：每个Check前面，一定跟一个ReportComment。这样报告里既有判断结果，又有操作说明，一目了然。
总结一下今天的内容：
- AutomationDesk的工作流是“建项目-写脚本-跑并出报告”。
- 一个Sequence只做一件事，别贪多。
- 基础测试用例的骨架：前置条件→执行→检查→后处理。
- 别忘了加注释，报告是给别人看的。
下一讲，咱们会深入讲AutomationDesk的变量管理和数据连接。到时候我会分享一个我踩过的坑——关于全局变量和局部变量搞混导致测试结果全乱套的故事。嗯，那个故事挺有意思的，咱们下次聊。