📚 课程目录第1章课程导入与TestStand异常处理全景

1. 课程导入与TestStand异常处理全景

在自动化测试系统中，被测对象（DUT）本身、测试仪器、线缆夹具、驱动软件乃至测试序列逻辑，任何一环都可能出现非预期行为。如果测试程序只按“理想路径”编写，一旦某一步骤返回失败、仪器通信超时或断言不成立，整个测试站就可能停在半途：DUT 未断电、继电器未复位、测试报告缺失，甚至影响后续工位。异常处理与测试恢复机制，正是让测试程序在偏离理想路径时仍能“可控地继续或安全地停止”的核心能力。

在 NI TestStand 中，异常处理不是附加功能，而是与序列执行引擎深度耦合的内建机制。理解它的第一步，是分清 TestStand 中“异常”到底指什么。TestStand 并不只把程序崩溃当作异常，它把测试执行过程中一切“偏离预期结果”的情况都纳入统一的状态与处理模型，主要包括以下几类：

步骤失败（Step Failure）：某个步骤执行后返回的状态为 Failed。例如 Numeric Limit Test 测得电压 3.62 V，而上下限为 3.30～3.50 V，该步骤即判为失败。这是最常见、粒度最细的异常。
序列失败（Sequence Failure）：当序列中某步骤失败且未被处理时，失败状态会沿调用栈向上传播，导致整个序列被标记为失败。它往往是步骤失败的“聚合结果”。
硬件错误（Hardware Error）：仪器返回错误码、VISA 通信中断、DMM 无法初始化等。这类错误通常由驱动层抛出，TestStand 通过错误簇（error cluster）捕获。
超时（Timeout）：等待仪器响应、等待 DUT 上电稳定或等待某个条件成立超过设定时限。超时本质上是“未在预期时间内得到预期结果”。
断言失败（Assertion Failure）：程序主动检查某个前提条件，若不满足则判定失败。例如断言“电源电流应小于 50 mA”，实测 120 mA 即触发断言失败。

这五类异常在 TestStand 中并非彼此孤立。硬件错误和超时通常以错误簇形式出现，会直接中断当前步骤；步骤失败和断言失败则更多体现为“结果不符合预期”，是否中断取决于步骤的流程控制设置。理解它们的区别与联系，是设计恢复策略的前提。

关键区分：步骤失败是“结果不对”，硬件错误是“根本没法测”，超时是“等不到结果”，断言失败是“前提不成立”。四者的处理策略往往不同——结果不对可以记录并继续，硬件错误通常需要重试或中止，超时可能需要复位仪器，断言失败则要检查测试条件是否被破坏。

那么，恢复机制的目标是什么？可以概括为三点：第一，保证测试资源安全，无论测试是否成功，DUT 电源、继电器、气路都应回到安全状态；第二，保证测试数据完整，失败步骤的测量值、错误码、时间戳都应被记录，便于追溯；第三，保证测试流程可控，是重试、跳过、继续下一项，还是中止整个测试，应由预设策略决定，而不是让程序“卡死”或“带病运行”。

TestStand 实现这些目标的整体架构，可以理解为一条“异常产生—传播—捕获—处理—恢复”的链路。步骤执行时产生状态或错误，执行引擎按序列调用栈向上传播；开发者通过 SequenceFilePostStep、Step Failure 回调、On-The-Fly 报告以及 Try/Catch 结构等入口捕获异常；捕获后根据异常类型选择重试、清理、记录或中止；最后由清理步骤（Cleanup）和恢复序列把系统带回确定状态。下面的 SVG 展示了这一全景架构。

从图中可以看到，异常处理并不是一个孤立的“错误处理函数”，而是贯穿步骤执行、状态传播、回调捕获、策略决策和恢复清理的完整链路。对于初学者而言，最容易忽略的是“恢复”环节：很多测试程序在捕获错误后只是弹窗提示，却没有把电源关掉、继电器复位，导致下一次测试在错误状态下开始，产生连锁误判。因此，在设计任何测试序列时，都应把 Cleanup 和恢复逻辑当作与测试步骤同等重要的组成部分。

学习建议：在后续章节中，我们会逐一展开回调机制、Try/Catch 结构、重试策略、清理步骤和恢复序列的具体实现。本节只需建立整体认知：异常分类决定处理策略，捕获入口决定处理位置，恢复目标决定处理终点。三者对齐，异常处理才不会变成“到处打补丁”。

最后需要强调，TestStand 的异常处理能力是分层的。步骤级可以设置“失败后是否继续”，序列级可以通过回调统一拦截，文件级可以通过 SequenceFilePostStep 做全局记录，而测试站级还可以结合 StationGlobal 和部署配置实现统一策略。这种分层设计让开发者既能精细控制单个步骤，又能保持整体一致性。理解这一全景，是后续深入掌握 TestStand 异常处理与测试恢复机制的基础。