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各状态详解状态描述进入条件Idle未加载任何测试程序启动 SmarTest 后的初始状态Test Program Activated测试程序文件被读入内存DUT board 文件和 license 文件加载完成执行 activate() 或在 UI 选择ActivateTest Program Loaded所有 testflow 实例化initialize()、PreBind、setup()已执行执行 load()Test Program Bound所有配置方程已解算setup 数据已下载到测试硬件update()已执行执行 bind()Testflow Ready数据记录data logging已启动等待执行下一个 testflow执行 run()Testflow Running当前有 testflow 正在运行调用 Testflow::execute()工程环境 vs 生产环境的差别工程环境UI 操作中间状态被自动跳过点击Run test program直接从 Idle 穿过所有状态到 Testflow Running生产环境Test Cell API每个状态转换都可以单独控制activate()→load()→bind()→run()→Testflow::execute()提供更精细的控制粒度三、完整执行序列11 步这是一次完整测试程序执行的完整顺序第一阶段加载activated → loaded步骤 1initialize()方法所有 test method 的initialize()方法被执行。执行顺序不保证不能依赖特定顺序。典型用途设置 test descriptor 的默认值后续可被 test table 覆盖。步骤 2PreBind testflow从磁盘读取 test table包含 limit、bin 设置等。在生产环境中每个 lot 开始前执行一次而非每片 DUT 都执行。步骤 3setup()方法所有 test method 的setup()方法被执行。执行顺序不保证。典型用途用 Device Setup API 程序化创建配置文件覆盖磁盘上的配置。步骤 4update()方法在 binding 完成后loaded → bound执行。典型用途用 Device Test API 修改内存中的测试数据不改磁盘文件。第二阶段运行bound → running步骤 5PreStart testflow整个 lot 开始前执行一次适合给 DUT board 上的有源电路供电。步骤 6PreRun testflow每片 DUT每片 DUT 测试前执行是修改测试程序变量的最后机会。若 PreRun 中修改了已 bound 的 setup 数据仅被修改的那部分数据会被重新 bind其他已 bound 的数据不受影响。步骤 7PowerUp testflow每片 DUT连接仪器、执行 continuity 测试、DUT 上电。如果未定义SmarTest 根据仪器配置自动上电。步骤 8Main testflow每片 DUT主测试流所有正式测量在这里执行。包含所有 subflow 和 test suite 的execute()调用。步骤 9PowerDown testflow每片 DUTDUT 下电、断开仪器连接。也可用于复杂 binning 算法。未定义时 SmarTest 自动执行。步骤 10PostRun testflow每片 DUT但在所有 site 的 PowerDown 完成后汇总 binning 结果等清理工作。步骤 11PreStop 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错误但怀疑在完整运行时不会出现可以验证重新 activate 测试程序立即 bind 整个程序不执行任何 subflow如果 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 TestingSite 的六种状态状态定义ConfiguredDUT board 中定义的 siteAvailableConfigured 且有足够硬件资源的 siteIgnored在测试程序中声明为忽略的 siteEnabledAvailable 且未被禁用的 site当前执行会用到Active当前执行中正在被测试的 siteInactiveActive site 被分支条件排除后的状态可以重新变回 activeStopped被stop()调用后停止的 site不可再 active重要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()确保修改应用到所有可用 siteOverridepublicvoidexecute(){context.operateOnAllSites(()-{measurement.specVariables().setVariable(SPEC_variable,150e-9);});measurement.execute();}七、异常处理与 Site 停止异常发生时当 testflow 中抛出异常时当前正在执行的 test suite 完成后停止不强制中断不再启动新的 test suite除 PowerDown 和 PostRun 外对所有site 生效非仅发生异常的 sitestop()调用时在 test method 或 testflow 中调用stop()时只影响指定的 site或当前所有 active site在下一个 test suite 执行完后停止不是立即停止被停止的 site 执行 PowerDown然后进入 inactive其他 site 继续执行被停止的 site 不可再次激活而因分支逻辑暂时变为 inactive 的 site 可以重新激活。八、告警系统Alarm SystemSmarTest 的告警系统在测试执行期间捕获异常情况分三类仪器告警Instrument Alarms由硬件检测到的异常与具体仪器类型相关例如告警触发条件CURRENT_CLAMP电流超过设定钳位值VOLTAGE_CLAMP电压超过设定钳位值OVERRANGE测量值超出仪器量程LIMIT_EXCEEDED超过 DUT board 中设定的电压/电流限制PROTECTION过压/过流保护触发TIMEOUTMatchLoop 计数溢出或 TMU 事件不足DUT_BOARD_UNDOCKED测试中 DUT board 被移除软件告警Software Alarms由测试软件内部检测到的异常告警触发条件DYNAMIC_BIND程序动态修改配置后 bind 失败会中止当前 test suiteTEST_METHODTest method 抛出未处理的异常SOFTWARE_DEFECTSmarTest 内部执行进程崩溃Test Cell 告警Test Cell Alarms由测试机外部环境问题触发通常需要 test cell controller 响应告警触发条件DISK_SPACE_EXCEEDS_THRESHOLD可用磁盘空间不足FORMATTER_DEFECT数据记录格式化器崩溃或磁盘写入失败PH_COMMUNICATION与 prober/handler 通信中断LICENSE_SERVERLicense 服务器不可达告警配置优先级告警配置可以在多处设定优先级从高到低execute()方法中的 IMeasurement 接口设置update()方法中的 IMeasurement 接口设置setup()方法中的 context 对象设置PreBind testflow 中的 test table 读取最常用test method 初始化代码推荐方式通过 test table 的Alarm_Config工作表配置告警无需修改代码。九、调试工具一览SmarTest 提供了多种面向设备测试的调试工具统一支持所有测试域数字、DC、模拟、RF工具 / 视图用途Testflow view主调试控制台选择并执行 testflow/test suitePattern Editor按 device cycle 显示向量和测量结果Timing Debug view查看时序波形、Action 生命周期时间戳Operating Sequence view可视化 Pattern/Action 的时序关系Measurement view查看当前测量的信号和结果Instrument view查看仪器配置和实际 bound 值Shmoo view执行和分析 shmoo 测试参数扫描Signal Analyzer Tool分析信号波形断点Breakpoint调试流程设置断点后执行 → 执行暂停于断点处在断点处修改配置 → 系统自动 rebind → 重新执行该测量调试视图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 testflowlot 级别 │ ├── 执行 PreRun testflowDUT 级别修改变量的最后机会被修改部分重新 bind │ ├── 执行 PowerUp testflowDUT 上电、continuity │ ├── 执行 Main testflow正式测量 │ ├── 执行 PowerDown testflowDUT 下电 │ ├── 执行 PostRun testflowbinning 汇总 │ └── 执行 PreStop testflowlot 级别电源关闭 Test Program Bound自动回到此状态等待下一轮系列总结至此《Advantest V93000 SmarTest 8 核心概念解析》系列全部完成共 8 篇覆盖了从开发环境到执行机制的完整知识体系篇号主题核心内容1Eclipse IDE 与工作区Workspace、Work Center、Project 结构2测试程序架构总览四层层级、6 种配置文件、覆盖规则3DUT Board Measurement SpecSignal 抽象、仪器层、模块化设计4时序与 X-ModeWavetable、Timing Set、X-Mode、Break Cycle5数字 IO 硬件原理Driver、Comparator、PMU、Active Load、Clamping6Pattern 与 HSIOVector、Signal Group、Memory Pooling、Virtual Pattern、Link Scale7Action 与 Operating SequenceAction 生命周期、OS 编排、Test Method 四方法8执行流程与状态机6 状态机、11 步序列、Multisite、Alarm、调试工具