OpenTAP

OpenTAP 中断链路剖析：Break Conditions 如何从步骤传到计划

背景

在做自动化测试时，最常见的诉求是“某一步失败就别再往下跑”。OpenTAP 提供了 Break Conditions，但它并不是简单的 if/else，而是一条从单步运行、父子步骤到 TestPlan 级别的中断链路。理解这条链路后，才能解释为什么有时只跳过同级步骤，有时会提前结束整份计划。

框架分析

OpenTAP 把中断条件抽象成 BreakCondition 枚举（如 BreakOnError、BreakOnFail），并通过 BreakConditionProperty 作为附加属性挂到步骤或计划上。执行时每个 TestStepRun 会先计算自己的有效中断配置：如果当前步骤是 Inherit，就继承父级 BreakCondition；否则使用本地配置。随后由 BreakConditionsSatisfied() 按当前 Verdict 判断是否触发中断。触发后不直接“杀进程”，而是抛 TestStepBreakException，由上层执行器决定停止范围。

实现过程

可用下面命令快速复现关键调用链：

1
2
cd /home/ops/clawd/repos/opentap
grep -RIn "BreakConditionsSatisfied\|ThrowDueToBreakConditions\|TestStepBreakException" Engine --include='*.cs'

一次典型流程是：

  1. TestStepRun.calculateBreakCondition() 计算当前步有效中断策略；
  2. 步骤完成后调用 BreakConditionsSatisfied()；
  3. 若命中条件，记录日志并抛出 TestStepBreakException；
  4. TestStep 与 TestPlanExecution 分层捕获该异常，写入 BreakIssuedFrom，并停止后续同级或计划级执行。

注意事项

  • Inherit 会叠加父级行为，排查“为何提前中断”时先看父节点和 TestPlan 设置。
  • BreakOnPass 虽然合法，但在回归场景容易造成“通过即停”的误用。
  • 子步骤手动运行（如 RunChildStep）时，throwOnBreak 参数会影响异常是否继续向外传播。
  • 观察日志时重点看 Break issued from ... 与 BreakIssuedFrom 参数，两者结合最容易定位真正触发点。

小结

Break Conditions 的价值不在“能停”，而在“可控地停”。OpenTAP 通过“附加属性 + 继承计算 + 异常传播 + 计划级汇总”把中断机制做成了可追踪、可复盘的执行语义，这比单点判断更适合复杂测试计划。

关键源码路径：

  • Engine/BreakCondition.cs
  • Engine/TestStepRun.cs
  • Engine/TestStep.cs
  • Engine/TestPlanExecution.cs
  • Engine/EngineSettings.cs