企业官网建设流程全解析

Test Program 执行流程与状态机：从加载到收尾的完整生命周期

系列：Advantest V93000 SmarTest 8 核心概念解析｜第 8 篇（共 8 篇，终篇）
适合读者：理解 SmarTest 整体原理，准备调试生产部署问题的工程师

前言

前七篇把所有测试数据（Board、Spec、Pattern、Action、OS）和测试代码（Test Method）都讲清楚了。这一篇回答最后一个问题：点击"Run"之后，到底发生了什么？

理解执行流程对以下场景至关重要：

• 调试"为什么我的 PreBind 没有执行"
• 解决开发环境 OOM 但生产不 OOM 的问题
• 处理某个 site 停止后的清理顺序
• 设计高效的 multisite 测试策略

一、执行层级结构

SmarTest 的执行是三层嵌套的层级结构：

Test Program（定义范围与引用） ↓ Testflow（决定执行顺序和条件控制） ↓ Test Suite → Test Method（实际执行测量代码）

"运行测试程序"本质上就是：按照 testflow 指定的顺序，依次执行各个 test suite 中的 test method 的execute()方法。

二、六个执行状态

SmarTest 的测试程序执行过程通过一组明确定义的状态机来管理。

Idle ↓ (activate) Test Program Activated ↓ (load) Test Program Loaded ↓ (bind) Test Program Bound ↓ (run) Testflow Ready ↓ (Testflow::execute) Testflow Running ↓ (完成后自动回到) Testflow Ready（若还有 testflow 待执行） ↓ (最终完成或 stop) Test Program Bound

各状态详解

工程环境 vs 生产环境的差别

• 工程环境（UI 操作）：中间状态被自动跳过，点击"Run test program"直接从 Idle 穿过所有状态到 Testflow Running
• 生产环境（Test Cell API）：每个状态转换都可以单独控制（activate()→load()→bind()→run()→Testflow::execute()），提供更精细的控制粒度

三、完整执行序列（11 步）

这是一次完整测试程序执行的完整顺序：

第一阶段：加载（activated → loaded）

步骤 1：initialize()方法

所有 test method 的initialize()方法被执行。执行顺序不保证，不能依赖特定顺序。

典型用途：设置 test descriptor 的默认值（后续可被 test table 覆盖）。

步骤 2：PreBind testflow

从磁盘读取 test table（包含 limit、bin 设置等）。在生产环境中，每个 lot 开始前执行一次，而非每片 DUT 都执行。

步骤 3：setup()方法

所有 test method 的setup()方法被执行。执行顺序不保证。

典型用途：用 Device Setup API 程序化创建配置文件，覆盖磁盘上的配置。

步骤 4：update()方法

在 binding 完成后（loaded → bound）执行。

典型用途：用 Device Test API 修改内存中的测试数据（不改磁盘文件）。

第二阶段：运行（bound → running）

步骤 5：PreStart testflow

整个 lot 开始前执行一次，适合给 DUT board 上的有源电路供电。

步骤 6：PreRun testflow（每片 DUT）

每片 DUT 测试前执行，是修改测试程序变量的最后机会。若 PreRun 中修改了已 bound 的 setup 数据，仅被修改的那部分数据会被重新 bind（其他已 bound 的数据不受影响）。

步骤 7：PowerUp testflow（每片 DUT）

连接仪器、执行 continuity 测试、DUT 上电。如果未定义，SmarTest 根据仪器配置自动上电。

步骤 8：Main testflow（每片 DUT）

主测试流，所有正式测量在这里执行。包含所有 subflow 和 test suite 的execute()调用。

步骤 9：PowerDown testflow（每片 DUT）

DUT 下电、断开仪器连接。也可用于复杂 binning 算法。未定义时 SmarTest 自动执行。

步骤 10：PostRun testflow（每片 DUT，但在所有 site 的 PowerDown 完成后）

汇总 binning 结果等清理工作。

步骤 11：PreStop testflow（整个 lot 结束前一次）

切断 DUT board 电源。与 PreStart 对应。

SmarTest 在 PostRun 和 PreStop 之后自动断开所有仪器连接。

四、内存管理：为什么开发时 OOM 生产不会

这是一个很容易踩坑的问题。

根本原因

SmarTest 在 binding 时尽量优化内存使用。效果最好的情况是一次性 bind 整个测试程序（activate 后直接 bind 全部）。

在开发时，工程师经常单独执行某个 subflow 或 test suite 来快速测试某个功能，这导致只有该部分被 bind，其他部分还没进内存。此时测试机内存分配碎片化，可能出现 OOM。

而生产时，整个程序一次性 activate → bind → run，内存分配最优，不会出现 OOM。

判断方法

如果开发时出现内存不足（out-of-memory）错误，但怀疑在完整运行时不会出现，可以验证：

1. 重新 activate 测试程序
2. 立即 bind 整个程序（不执行任何 subflow）
3. 如果 OOM 消失 → 这是开发流程的产物，不是真实问题

五、并发执行与资源锁定

前台 vs 后台执行

Test Method 的execute()方法默认在前台执行，拥有测试机的独占访问权。一次只有一个 test method 可以在前台运行。

当一个 test method 完成对测试机的使用后，可以调用releaseTester()释放测试机控制权，自己转为后台执行（继续处理结果上传、数据记录等不需要测试机的任务）。此时 testflow 可以继续，下一个 test suite 开始前台执行。

这种设计允许数据处理（后台）与硬件测量（前台）并行，提升吞吐量。

Testflow ├─ Suite1.execute() [前台] → 测量完成 → releaseTester() → [转后台：上传/记录] │ ↓ ├─ Suite2.execute() [前台] → 测量完成（等 Suite1 释放测试机后才能测量） │ ... └─ waitForAllResults() ← 等待所有后台任务完成后再继续

同一 Test Suite 不能并行

同一个 test suite 不能并行执行两个实例——第二个实例必须等第一个execute()的后台处理完全结束后才能开始。

六、多 site 测试（Multisite Testing）

Site 的六种状态

重要：Inactive site（由分支逻辑排除）和 Stopped site（由 stop() 终止）是不同的——前者可以在后续重新激活，后者不可以。

Site 执行顺序的三种模式

SmarTest 根据仪器共享情况自动选择执行顺序：

① Parallel（并行）：所有 site 同时执行同一测量。适用于没有 site 间共享仪器（或共享但可以同时驱动所有 site）的情况。吞吐量最高。

② Site Sequencing（顺序执行）：每个 site 依次独立执行完整测量。适用于有只能被一个 site 使用的共享仪器（如 RF 仪器需要切换）的情况。

③ Site Interlacing（交织执行）：需要切换的动作（如 RF 切换）顺序执行，其余部分（如数字 pattern）并行执行。兼顾测试时间和精度。

Site Interlacing 的关键：在 spec 文件中对需要切换的仪器启用siteInterlacingOn选项，并在 OS 中将需要顺序执行的 action 和可以并行执行的 pattern 分放在不同的 parallel group 中。

多 site 中的 Testflow 分支

当 testflow 到达一个条件分支（if/else）时：

• 每个 site独立评估条件
• 某些 site 走 if 分支，另一些走 else 分支
• 如果两个分支都有 site，两个分支都会执行
• 在各自的分支执行期间，另一分支的 site 处于 inactive 状态

性能建议：尽量把通用代码放在分支外，减少需要分支的代码量，提升 multisite 效率（MSE）。

动态修改与 Site 作用域

在execute()方法中动态修改配置时，只对 active site 有效。如果某些 site 共享资源，需要确保所有 site 的修改一致，否则会出现 Dynamic Bind Error。

安全做法是使用context.operateOnAllSites()确保修改应用到所有可用 site：

@Overridepublicvoidexecute(){context.operateOnAllSites(()->{measurement.specVariables().setVariable("SPEC_variable",150e-9);});measurement.execute();}

七、异常处理与 Site 停止

异常发生时

当 testflow 中抛出异常时：

• 当前正在执行的 test suite 完成后停止（不强制中断）
• 不再启动新的 test suite（除 PowerDown 和 PostRun 外）
• 对所有site 生效（非仅发生异常的 site）

stop()调用时

在 test method 或 testflow 中调用stop()时：

• 只影响指定的 site（或当前所有 active site）
• 在下一个 test suite 执行完后停止（不是立即停止）
• 被停止的 site 执行 PowerDown，然后进入 inactive
• 其他 site 继续执行

被停止的 site 不可再次激活，而因分支逻辑暂时变为 inactive 的 site 可以重新激活。

八、告警系统（Alarm System）

SmarTest 的告警系统在测试执行期间捕获异常情况，分三类：

仪器告警（Instrument Alarms）

由硬件检测到的异常，与具体仪器类型相关，例如：

软件告警（Software Alarms）

由测试软件内部检测到的异常：

Test Cell 告警（Test Cell Alarms）

由测试机外部环境问题触发，通常需要 test cell controller 响应：

告警配置优先级

告警配置可以在多处设定，优先级从高到低：

1. execute()方法中的 IMeasurement 接口设置
2. update()方法中的 IMeasurement 接口设置
3. setup()方法中的 context 对象设置
4. PreBind testflow 中的 test table 读取（最常用）
5. test method 初始化代码

推荐方式：通过 test table 的Alarm_Config工作表配置告警，无需修改代码。

九、调试工具一览

SmarTest 提供了多种面向设备测试的调试工具，统一支持所有测试域（数字、DC、模拟、RF）：

断点（Breakpoint）调试流程：

1. 设置断点后执行 → 执行暂停于断点处
2. 在断点处修改配置 → 系统自动 rebind → 重新执行该测量
3. 调试视图（Measurement view、Timing Debug view）实时更新

总结：完整执行生命周期一图流

Idle │ ↓ activate() Test Program Activated │ (读取 .prog 文件，加载 DUT board，初始化变量) │ ↓ load() │ ├── 实例化所有 testflow 和 test method │ ├── 执行所有 initialize() │ ├── 执行 PreBind testflow（读 test table） │ └── 执行所有 setup() Test Program Loaded │ ↓ bind() │ ├── 解算所有配置方程 │ ├── 下载 setup 数据到硬件 │ └── 执行所有 update() Test Program Bound │ ↓ run() │ ├── 启动数据记录 │ ├── 写入测试开始事件 │ ├── 执行 PreStart testflow（lot 级别） │ ├── 执行 PreRun testflow（DUT 级别，修改变量的最后机会，被修改部分重新 bind） │ ├── 执行 PowerUp testflow（DUT 上电、continuity） │ ├── 执行 Main testflow（正式测量） │ ├── 执行 PowerDown testflow（DUT 下电） │ ├── 执行 PostRun testflow（binning 汇总） │ └── 执行 PreStop testflow（lot 级别电源关闭） Test Program Bound（自动回到此状态，等待下一轮）

系列总结

至此，《Advantest V93000 SmarTest 8 核心概念解析》系列全部完成，共 8 篇，覆盖了从开发环境到执行机制的完整知识体系：