4. 步骤级异常处理

在 TestStand 中，序列（Sequence）由若干步骤（Step）顺序执行，而每个步骤自身都携带一组决定“异常如何被处理”的属性。这些属性集中在 Step Properties 对话框的多个选项卡中，包括 Run Mode、Loop Settings、Post Actions、Run-Time Errors（含 Step Failure Causes、Ignore Run-Time Errors、Break on Step Failure）等。它们共同决定了：当步骤执行失败、超时、被跳过或循环出错时，TestStand 引擎会做什么、序列会走向哪里、结果如何记录。理解这些属性的作用范围与优先级，是构建可靠测试流程的基础。

Run Mode：步骤是否执行、以何种方式执行

Run Mode 决定步骤在序列中的执行方式，常见取值包括 Normal、Skip、Force Pass、Force Fail。Normal 表示按步骤定义正常执行；Skip 表示跳过该步骤，不执行其代码，但仍会在结果中记录为 Skipped；Force Pass 表示无论步骤实际执行结果如何，都强制标记为 Passed；Force Fail 则强制标记为 Failed。Force Pass 与 Force Fail 常用于调试或临时屏蔽某个不稳定步骤，但在正式测试流程中应谨慎使用，因为它们会掩盖真实的执行结果。需要注意的是，Run Mode 影响的是“结果状态”，而不是“是否执行代码”——Skip 不执行代码，而 Force Pass/Force Fail 仍会执行代码，只是覆盖结果判定。

Loop Settings：循环体内的异常传播

当步骤配置为循环执行（如 For 循环、While 循环或遍历数组）时，Loop Settings 中的选项会显著改变异常行为。关键配置包括：Loop Type（循环类型）、Number of Loops（循环次数）、以及“On Loop Failure”相关行为。若循环体内某一次迭代失败，TestStand 默认会记录该次迭代的失败，并继续执行后续迭代，除非显式配置为“在失败时终止循环”。此外，Loop Settings 还允许设置循环间的延迟（Loop Delay）和是否在每次迭代后检查“Break”条件。循环内的失败会累积到步骤的最终结果中：只要有一次迭代失败，整个步骤通常会被标记为 Failed，除非使用 Ignore Run-Time Errors 或 Post Actions 进行干预。

Post Actions：失败后的下一步走向

Post Actions 是步骤级异常处理中最直接的“路由”配置。它定义当步骤执行完成后（无论成功或失败），序列应如何继续。常见选项包括：

• Use Default：使用序列或步骤类型的默认行为，通常为“继续执行下一步”。
• Goto Step：跳转到指定步骤，常用于失败后进入清理或恢复流程。
• Goto Cleanup：跳转到序列的 Cleanup 步骤组，执行资源释放。
• Terminate Execution：终止整个执行，通常用于严重错误。
• Break：暂停执行并进入调试器，便于现场排查。

Post Actions 可以分别针对“Passed”和“Failed”两种结果设置。例如，可以配置为“失败时 Goto Cleanup，成功时继续下一步”。这种分离配置使得异常恢复路径与正常路径可以清晰分离，而不必在步骤代码中写大量条件判断。

Step Failure Causes：什么算“失败”

Step Failure Causes 定义了哪些运行期事件会导致步骤被判定为失败。常见选项包括：

• Run-Time Error：步骤代码抛出错误或返回错误码。
• Timeout：步骤执行超过指定时间。
• Step Failure：步骤内部调用的子步骤失败。
• Custom Condition：用户自定义的失败条件，例如某个测量值超出上下限。

通过勾选或取消这些选项，可以精细控制“失败”的判定边界。例如，若某个步骤的超时并不影响整体测试结论，可以取消 Timeout 作为失败原因，从而避免误判。需要注意的是，Step Failure Causes 只影响“是否标记为失败”，不直接改变执行流向；执行流向仍由 Post Actions 决定。

Ignore Run-Time Errors：忽略错误但保留记录

Ignore Run-Time Errors 是一个布尔属性。当设置为 True 时，即使步骤代码抛出运行期错误，TestStand 也不会将步骤标记为 Failed，而是继续执行后续步骤。该属性常用于“非关键步骤”或“探测性步骤”，例如读取一个可选传感器、尝试连接一个可能不存在的设备。但必须注意：忽略错误并不等于错误消失，错误信息仍会记录在结果中，只是不触发失败判定。若后续步骤依赖该步骤的输出，忽略错误可能导致更隐蔽的连锁问题，因此应配合日志审查使用。

Break on Step Failure：失败时暂停调试

Break on Step Failure 用于在步骤失败时自动触发调试断点。当该属性为 True 且步骤失败时，TestStand 会暂停执行并打开调试器，定位到失败步骤。这在开发阶段非常有用，可以立即检查变量、调用栈和步骤属性。但在自动化产线或无人值守测试中，应关闭该属性，否则一次失败会导致整个测试流程挂起。通常建议在开发序列中启用，在部署序列中禁用，或通过序列级配置统一覆盖。

属性之间的优先级与交互

这些属性并非孤立生效，而是存在明确的优先级关系。一个典型的判断顺序是：首先检查 Run Mode（Skip 直接跳过，Force Pass/Fail 覆盖结果）；若正常执行，则根据 Step Failure Causes 判断是否构成失败；若构成失败，再检查 Ignore Run-Time Errors 是否忽略；若未忽略，则根据 Post Actions 决定下一步走向；若 Break on Step Failure 为 True，则在失败时暂停。Loop Settings 则在循环体内重复上述判断，并决定是否继续下一次迭代。理解这一顺序，可以避免“配置了 Post Actions 却没有生效”这类常见困惑——例如，若 Ignore Run-Time Errors 为 True，步骤不会被标记为失败，Post Actions 中的 Failed 分支自然也不会触发。

配置示例与结果判读

假设有一个“读取电压”步骤，配置如下：Run Mode = Normal；Step Failure Causes 勾选 Run-Time Error 和 Timeout；Ignore Run-Time Errors = False；Post Actions 的 Failed 分支设为 Goto Cleanup；Break on Step Failure = False。若该步骤因设备无响应而超时，TestStand 会将其标记为 Failed，记录超时错误，然后跳转到 Cleanup 步骤组执行资源释放，最后终止序列。若将 Ignore Run-Time Errors 改为 True，则超时仍会记录，但步骤不会标记 Failed，Post Actions 的 Failed 分支不会触发，序列继续执行下一步。若再将 Break on Step Failure 改为 True，则超时发生时执行会暂停并打开调试器，便于现场检查设备连接状态。

总结来说，Step Properties 中的这些属性构成了一个分层的异常处理机制：Run Mode 决定“是否执行与结果覆盖”，Step Failure Causes 决定“什么算失败”，Ignore Run-Time Errors 决定“失败是否被忽略”，Post Actions 决定“失败后去哪里”，Break on Step Failure 决定“失败时是否暂停”，Loop Settings 则决定“循环体内异常如何传播”。只有理解它们之间的优先级与交互，才能在实际测试序列中精确控制异常行为，既保证测试的严谨性，又保留必要的容错与恢复能力。