【芯片测试】：SmarTest 8：Usage of Test Tables 运行机制总结

Meraki.Zhang2026-03-21 13:16

目录

  • [SmarTest 8：Usage of Test Tables 运行机制总结](#SmarTest 8：Usage of Test Tables 运行机制总结)
    • [1. 概述](#1. 概述)
    • [2. test table 在测试程序中的位置](#2. test table 在测试程序中的位置)
    • [3. test table 的文件形态](#3. test table 的文件形态)
    • [4. test table 是否强制使用](#4. test table 是否强制使用)
    • [5. test table 的接入机制](#5. test table 的接入机制)
      • [5.1 入口：PreBind auxiliary flow](#5.1 入口：PreBind auxiliary flow)
      • [5.2 运行触发时机](#5.2 运行触发时机)
      • [5.3 PreBind 在完整执行时序中的位置](#5.3 PreBind 在完整执行时序中的位置)
    • [6. PreBind 中真正执行读表的机制](#6. PreBind 中真正执行读表的机制)
    • `TestTableReader`
    • [7. TestTableReader 的关键参数与作用](#7. TestTableReader 的关键参数与作用)
      • [7.1 testTablePath](#7.1 testTablePath)
      • [7.2 limitCategory / loglevelCategory / variablesCategory](#7.2 limitCategory / loglevelCategory / variablesCategory)
      • [7.3 errorLogPath](#7.3 errorLogPath)
      • [7.4 forceImport](#7.4 forceImport)
      • [7.5 useCache](#7.5 useCache)
    • [8. TestTableReader 的检查机制](#8. TestTableReader 的检查机制)
    • [9. 检查失败后的处理机制](#9. 检查失败后的处理机制)
      • [9.1 控制台输出 warning](#9.1 控制台输出 warning)
      • [9.2 生成带注释的 test table](#9.2 生成带注释的 test table)
      • [9.3 将问题表保存到 errorLogPath](#9.3 将问题表保存到 errorLogPath)
      • [9.4 根据 forceImport 决定是否停止程序](#9.4 根据 forceImport 决定是否停止程序)
    • [10. 注释版 test table 的查看方式](#10. 注释版 test table 的查看方式)
    • [11. PreStart 的补充机制](#11. PreStart 的补充机制)
    • [12. test table 的生成机制：TestTableWriter](#12. test table 的生成机制：TestTableWriter)
    • `TestTableWriter`
      • [12.1 生成的内容特点](#12.1 生成的内容特点)
      • [12.2 outputFileName](#12.2 outputFileName)
      • [12.3 testsSheetByFlow](#12.3 testsSheetByFlow)
      • [12.4 版本限制](#12.4 版本限制)
    • [13. Usage of Test Tables 的整体运行机制](#13. Usage of Test Tables 的整体运行机制)
      • [场景 A：普通 test table 读取](#场景 A：普通 test table 读取)
      • [场景 B：test table 含 specification variables](#场景 B：test table 含 specification variables)
      • [场景 C：test table 检查失败](#场景 C：test table 检查失败)
      • [场景 D：生成初始 test table](#场景 D：生成初始 test table)
    • [14. 使用建议](#14. 使用建议)
      • [14.1 不要在 test method 中覆盖 test table 设置](#14.1 不要在 test method 中覆盖 test table 设置)
      • [14.2 将 test table 视为主配置源](#14.2 将 test table 视为主配置源)
      • [14.3 可自定义 reader 的扩展机制](#14.3 可自定义 reader 的扩展机制)
    • [15. 总结](#15. 总结)

SmarTest 8：Usage of Test Tables 运行机制总结

1. 概述

test table 的本质，是把测试程序中与 limits、binning、data logging 相关的设置，集中放到一个统一的表格文件中进行管理。

它不是执行测试的主体，而是测试程序运行前后用于配置装载、配置校验、配置映射的集中式配置载体。

在不使用 test table 的情况下，这些设置也可以分别写在 testflow、test method 或其他程序文件中，但这样会导致配置分散、难以维护、难以追踪，也容易在调试、量产和版本切换时产生不一致。

因此，test table 的核心价值不是"多了一张表"，而是实现了：

  • 配置集中化
  • 配置可视化
  • 配置可导入导出
  • 配置可校验
  • 配置与测试程序显式绑定

2. test table 在测试程序中的位置

当一个测试程序运行时，基本链路可以理解为：

text 复制代码 
testflow → test suite → measurement result → 判定 / data logging / binning

其中：

  • testflow 负责定义测试执行顺序
  • test suite 负责调用测试方法执行具体测量
  • 测量得到结果后，还需要：
    • 用 limit 判定 pass/fail
    • 决定是否记录数据
    • 决定进入哪个 bin

test table 就是在这后半段中，承担这些规则和配置的统一入口。

3. test table 的文件形态

test table 是一个 .ods 格式的电子表格文件（Open Document Spreadsheet），通常由多个 sheet 组成。

3.1 必需 sheet

Tests

这是 test table 的核心 sheet，用于保存 pass/fail 测试项的设置。

通常会包含类似信息：

  • test descriptor
  • test number
  • test text
  • low limit / high limit
  • unit
  • soft bin
  • 不同 category 下的配置列

3.2 可选 sheet

Master_File

用于引用其他 test table，支持模块化和分层组织。

Software_Bins / Hardware_Bins

用于定义 bin 表，集中管理 software bin 和 hardware bin 的编号、名称和映射。

Profile

用于设置 test suites 和 testflows 的参数。

Alarm_Config

用于报警相关配置。

STDF_Config

用于 STDF 数据记录相关配置。

TPVariables

用于测试程序变量配置。

Specs

用于在 PreStart flow 中设置 specification variables。

4. test table 是否强制使用

test table 不是强制必须 ，但推荐使用。

也就是说：

  • 可以不用 test table
  • 但如果使用，就必须在测试程序中显式实现接入机制
  • 系统不会因为目录里存在一个 .ods 文件，就自动把它应用到测试程序中

因此，test table 是一种需要主动接入的配置架构。

5. test table 的接入机制

5.1 入口：PreBind auxiliary flow

要让测试程序读取 test table，测试程序文件中必须定义一个类型为 PreBind 的 auxiliary flow。

PreBind 是测试程序的早期辅助流程，它的作用是：

  • 在主测试流程执行前读取 test table
  • 将表中的配置导入当前测试程序

这意味着：

  • test table 的装载是前置装载
  • 主测试执行前，limit、binning、data logging 等配置应该已经被导入

5.2 运行触发时机

只要触发：

  • 整个测试程序运行
  • 某个 subflow 运行
  • debug 调试运行

如果定义了 PreBind，SmarTest 都会在初始阶段执行它。

也就是说，PreBind 是一个统一的前置配置入口，不仅正式运行会走，调试也会走。

5.3 PreBind 在完整执行时序中的位置

从课件给出的执行顺序看，PreBind 所处的位置可以进一步细化为：

text 复制代码 
0. Load
1. Initialization
2. 执行 PreBind flow
3. setup()
4. Link
5. Bind
6. update()
7. execute()
   ├─ PreRun flow
   ├─ PowerUp flow
   ├─ Main flow
   └─ PowerDown flow
8. Binning

这说明 PreBind 的时序位置非常靠前，处于：

  • 程序加载和初始化之后
  • 正式 setup / link / bind / execute 之前

因此，从运行机制上看，PreBind 的作用就是在主测试真正展开前，先把 test table 中的配置装载进程序环境，为后续：

  • limit 判定
  • data logging
  • binning
  • 变量配置

提供统一的前置配置基础。

6. PreBind 中真正执行读表的机制

PreBind 只是入口，真正负责读取 test table 的，是其中一个调用专用 test method 的 test suite。

SmarTest 提供了专用 test method：

TestTableReader

标准结构可以理解为：

text 复制代码 
test program
  └─ PreBind flow
       └─ suite
            └─ TestTableReader
                 └─ 读取 .ods test table

也就是说：

  • PreBind 负责在合适时机执行
  • suite 负责承载调用动作
  • TestTableReader 负责真正读取、解析、检查并导入 test table

7. TestTableReader 的关键参数与作用

7.1 testTablePath

指定要读取的 test table 文件路径。

该路径通常是相对于 source folder 的相对路径。

作用：

  • 明确当前程序使用哪张 .ods 表
  • 便于工程迁移、版本管理和团队共享

7.2 limitCategory / loglevelCategory / variablesCategory

用于指定读取哪一组 category 配置。
test table 支持在同一张表中保存不同阶段的配置，例如：

  • 调试阶段
  • QA 阶段
  • characterization 阶段
  • 量产阶段

这些 category 决定当前程序装载哪一套：

  • limit 配置
  • logging 配置
  • variables 配置

因此，category 的本质是：

让同一张 test table 支持不同开发阶段的不同配置集。

7.3 errorLogPath

指定错误输出目录。

如果导入过程中发现问题，系统会将一个带注释的 test table 输出到该目录，方便定位问题。

7.4 forceImport

控制发现问题后，程序是否继续执行。

  • true：有问题也尽量继续执行
  • false：有问题则停止测试程序执行

适用理解：

  • 开发/调试阶段常用 true
  • 正式版本/严格验证阶段常用 false

7.5 useCache

表示将读取和解析后的 test table 数据放入缓存。

作用：

  • 减少重复解析开销
  • 提高重复运行效率
  • 在复杂工程中提升整体性能

8. TestTableReader 的检查机制

TestTableReader 不是简单读文件，它在导入时会做完整性和一致性检查。

8.1 检查项

1）是否覆盖测试程序中的每个 test descriptor

要求 test table 为测试程序中的每个测试项都提供对应设置。

如果某些测试项缺少配置，则说明表不完整。

2）是否存在重叠设置

要求不能有两个设置同时命中同一测试对象并产生歧义。

如果存在重叠配置，就会导致系统无法确定该采用哪一条规则。

3）是否都能映射到测试程序

要求 test table 中列出的配置项必须能与当前测试程序对应上。

不能存在表里有，但程序里没有的配置对象。

4）是否完整且一致

要求配置不仅存在，而且必须填写完整、逻辑一致、无缺失、无自相矛盾。

8.2 检查机制的意义

这些检查的目的，是帮助建立一张：

  • 正确
  • 完整
  • 可映射
  • 一致

的 test table。

因此，TestTableReader 不只是读取器，也是：

  • 校验器
  • 诊断器
  • 导入入口的质量把关点

9. 检查失败后的处理机制

如果任意检查失败，TestTableReader 会执行以下动作：

9.1 控制台输出 warning

将错误或警告信息输出到 console，供运行时观察。

9.2 生成带注释的 test table

系统会生成一个新的 test table，在有问题的位置增加注释和 warning 信息。

例如：

  • 哪些 test descriptor 缺少设置
  • 哪些配置无法映射
  • 哪些设置重叠
  • 哪些内容不完整

9.3 将问题表保存到 errorLogPath

该带注释的问题表会保存到 errorLogPath 指定的文件夹中。

9.4 根据 forceImport 决定是否停止程序

  • 如果 forceImport = false，测试程序停止执行
  • 如果 forceImport = true，尽量继续执行

10. 注释版 test table 的查看方式

当系统输出了注释版 test table 后，可以使用 LibreOffice 打开该 .ods 文件。

查看详细 warning 的方法：

  1. 按 F5 打开 Navigator
  2. 查看 Comments
  3. 双击某条 comment
  4. 系统会将焦点跳转到与该 warning 对应的单元格

这说明注释版 test table 不只是报错文件，而是一个实际可用于定位问题的排错工具。

11. PreStart 的补充机制

如果 test table 中还包含 specification variables 的设置，仅有 PreBind 还不够。

这时还需要定义 PreStart auxiliary flow。

原因是：

  • 某些 specification files 会在后续阶段加载
  • 与 specs 相关的变量配置，在 PreBind 阶段未必能完全正确应用
  • 因此，在 specification files 加载完成后，需要再次读取 test table

于是运行顺序会变成：

text 复制代码 
启动程序 → PreBind 读取一次 test table → 加载 specification files → PreStart 再读取一次 test table → 后续主测试执行

所以：

  • PreBind：负责前期通用配置导入
  • PreStart：负责 specs 环境就绪后的二次配置装载

12. test table 的生成机制：TestTableWriter

除了读取已有 test table，SmarTest 还支持从测试程序反向生成一个初始 test table。

这通过专用 test method 实现：

TestTableWriter

它的作用是：

  • 根据当前测试程序自动生成一份初始 .ods test table
  • 在 Tests sheet 中列出测试程序里所有 pass/fail 测试的 test descriptor

也就是说，TestTableWriter 的本质是：

从程序结构自动导出 test table 骨架。

12.1 生成的内容特点

自动生成的 Tests sheet 会列出：

  • 测试程序中识别到的 pass/fail 测试项
  • 对应的 test descriptor
  • 一些基本结构信息

这张表通常是一个初始模板，后续还需要人工补充：

  • limit
  • binning
  • data logging
  • profile
  • specs 等配置

12.2 outputFileName

指定导出 .ods 文件的路径和文件名。

12.3 testsSheetByFlow

控制 Tests sheet 的组织方式：

  • false：所有测试项放在一个 Tests sheet 中
  • true：按不同 testflow 分别生成独立的 Tests sheet

12.4 版本限制

在 SmarTest 8.2.0 中，TestTableWriter 只能在 PreStart auxiliary flow 中工作。

后续版本中，才支持 main flow 和其他 auxiliary flows。

13. Usage of Test Tables 的整体运行机制

综合起来，Usage of Test Tables 的运行机制可以总结为以下顺序：

场景 A：普通 test table 读取

text 复制代码 
1. 测试程序启动
2. 如果定义了 PreBind，则先执行 PreBind
3. PreBind 中的 suite 调用 TestTableReader
4. TestTableReader 根据 testTablePath 找到 .ods 文件
5. 按 limit/loglevel/variables category 选择当前阶段配置
6. 对 test table 做覆盖性、唯一性、可映射性、一致性检查
7. 若检查通过，则将配置导入程序
8. 后续 setup / bind / update / execute / binning 按导入后的配置运行

场景 B：test table 含 specification variables

text 复制代码 
1. 测试程序启动
2. PreBind 先读取一次 test table
3. 加载 specification files
4. PreStart 再读取一次 test table
5. 将 specs 相关变量正确应用到程序环境
6. 继续执行后续测试流程

场景 C：test table 检查失败

text 复制代码 
1. TestTableReader 在导入时发现问题
2. 向 console 输出 warning
3. 生成带注释的新 test table
4. 保存到 errorLogPath
5. 若 forceImport=false，则停止程序
6. 若 forceImport=true，则尽量继续执行

场景 D：生成初始 test table

text 复制代码 
1. 在 PreStart 中调用 TestTableWriter
2. 扫描测试程序中的 pass/fail 测试项
3. 自动生成一个初始 .ods test table
4. 在 Tests sheet 中写入 test descriptors
5. 工程师再补充 limits、bins、logging 等配置

14. 使用建议

14.1 不要在 test method 中覆盖 test table 设置

原因：

  • 会破坏配置集中化的设计
  • 会造成表中配置与程序实际行为不一致
  • 容易导致 pass/fail 判定理解错误
  • 容易造成 binning、logging、limit 使用错乱
  • 在量产环境中可能引发高成本问题

14.2 将 test table 视为主配置源

工程上更合理的做法是：

  • limit 从 test table 管理
  • binning 从 test table 管理
  • data logging 从 test table 管理
  • 程序代码尽量不再私自覆盖

这样才能保证：

  • 行为一致
  • 调试一致
  • 文档一致
  • 量产一致

14.3 可自定义 reader 的扩展机制

除了使用 SmarTest 官方提供的 TestTableReader 之外，也可以自行编写 test method，去读取一种自定义格式 的 test table。

这意味着：

  • 官方 .ods + TestTableReader 是标准方案
  • 但并不是唯一方案
  • 如果项目有特殊流程、特殊字段定义或内部规范，也可以自行实现读取逻辑

不过一旦采用自定义 reader，通常也意味着需要自行负责：

  • 配置解析
  • 配置与测试程序的映射
  • 完整性检查
  • 冲突检查
  • 一致性保障

因此，这一能力更适合有明确定制需求的工程场景。

15. 总结

Usage of Test Tables 的核心，不是简单"使用一张表"，而是一套完整的配置集中、显式接入、前置装载、自动校验、错误诊断、阶段化分类、支持导入导出的运行机制。

其核心链路可以概括为：

text 复制代码 
测试程序显式定义 PreBind
→ PreBind 中调用 TestTableReader
→ 读取并校验 .ods test table
→ 按 category 选择当前阶段配置
→ 导入 limits / binning / logging / variables
→ 后续测试流程按导入配置执行

如果涉及 specs，则：

text 复制代码 
PreBind 初次导入 → specification files 加载 → PreStart 二次导入

如果还没有 test table，则可以通过：

text 复制代码 
PreStart 中调用 TestTableWriter → 自动生成初始 test table 模板

因此，从运行机制角度看，test table 是 SmarTest 8 中用于统一管理测试配置的重要入口，也是连接测试程序结构与实际判定/记录行为之间的核心配置桥梁。

相关推荐
Meraki.Zhang9 天前
【芯片测试】：SmarTest 8 Binning 运行机制总结
芯片测试·bin·93k
Meraki.Zhang4 个月前
【芯片测试篇】：SmarTest 8 三温和三压测试程序的搭建
芯片测试·ate·93k
FORCREAT-苏州永创5 个月前
半导体静态电性测试系统如何实现对各类电子元器件的评估测试？
半导体·芯片测试·半导体功率器件·静态参数测试仪
FORCREAT-苏州永创5 个月前
从实验室到产线：苏州永创-STD2000X如何统一分立器件静态参数测试仪的“语言”？
半导体·芯片测试·测试系统·cmti·cmti测试系统·半导体功率器件·静态参数测试仪
FORCREAT-苏州永创5 个月前
探秘半导体“体检中心”：如何为一颗芯片做静态参数测试？
半导体·芯片测试·测试系统·cmti·cmti测试系统·半导体功率器件·静态参数测试仪
Meraki.Zhang8 个月前
【芯片测试篇】：93K测试机I2C的设置和调试
i2c·芯片测试·ate测试·93k
XINERTEL2 年前
如何利用仪表构造InfiniBand流量在数据中心测试中的应用
开发语言·php·数据中心·芯片测试·时延测试
北京锦正茂科技有限公司2 年前
晶圆测试是什么？为什么要进行晶圆测试？
半导体·芯片测试·晶圆测试·材料·探针台·测试系统
专业ATE提供商2 年前
加速科技ST2500 数模混合信号测试设备累计装机量突破500台！
fpga开发·芯片测试·半导体测试·国产ate
热门推荐
01GitHub 镜像站点02Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南03小黑课堂计算机二级WPSoffice题库软件下载安装教程（2026年3月最新版）04Labelme从安装到标注：零基础完整指南05OpenClaw 使用和管理 MCP 完全指南06AI 编程三剑客：Spec-Kit、OpenSpec、Superpowers 深度对比与实战指南07UV安装并设置国内源08班级宠物园部署指南09OpenClaw Control UI安全上下文访问配置10Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services