2. TestStand数据库架构与数据模型

TestStand 的结果记录能力并不是“把测试结果写进一个文件”这么简单。它内置了一套关系型数据库架构,把一次测试任务拆解成若干层级的实体:一次测试会话、一个被测单元、一个测试步骤、一次测量值,以及伴随产生的各种属性。理解这套架构,是后续做结果追溯、报表定制和数据库查询的基础。本节先讲清楚 TestStand 内置数据库的表结构、主外键关系,以及数据从测试执行到落库的完整流向。

一、内置数据库架构的四个核心层级

TestStand 默认提供的数据库架构(Schema)围绕四个核心表展开,它们之间存在明确的父子关系:

  • UUT(被测单元)表:记录一次被测对象的身份信息,例如序列号、批次号、工位号、测试开始与结束时间、整体判定结果(Pass/Fail)。一个 UUT 对应一次完整的测试流程。
  • STEP(步骤)表:记录 UUT 内部每一个测试步骤的执行情况,包括步骤名称、所属序列文件、执行顺序、步骤判定结果、耗时等。一个 UUT 下会有多个 STEP 记录。
  • MEASUREMENT(测量)表:记录步骤中产生的具体测量数据,例如测量名称、测量值、单位、上下限、判定结果。一个 STEP 可能产生零个、一个或多个 MEASUREMENT。
  • PROPERTY(属性)表:以键值对形式存储 UUT、STEP 或 MEASUREMENT 上的附加属性,用于扩展字段,避免频繁修改表结构。

这四张表通过主外键串联:UUT 是根节点,STEP 通过 UUT_ID 关联到 UUT,MEASUREMENT 通过 STEP_ID 关联到 STEP,PROPERTY 则通过所属对象的 ID 和类型进行关联。这种设计使得任意一条测量值都可以向上追溯到具体的步骤和被测单元,这正是“结果追溯”的数据基础。

TestStand 内置数据库关系模型与追溯数据流 UUT 表 UUT_ID (PK) SerialNumber / Batch StartTime / EndTime UUTStatus (Pass/Fail) STEP 表 STEP_ID (PK) UUT_ID (FK) StepName / Order StepStatus / ElapsedTime MEASUREMENT 表 Meas_ID (PK) STEP_ID (FK) MeasName / Value / Unit LowLimit / HighLimit / Status 1 : N 1 : N PROPERTY 表 Prop_ID (PK) OwnerID / OwnerType PropName / PropValue 扩展属性 追溯数据流:测试执行 → 结果对象 → 数据库写入 → 查询追溯 Sequence 执行 RunState / ResultList Database Logger SQL 查询 / 报表

二、表结构与关键字段的实际含义

以一次典型的电源模块测试为例。假设序列文件依次执行“上电检查”“输出电压测量”“纹波测量”“过流保护”四个步骤。执行完成后,数据库中的记录大致如下:

表关键字段示例值说明
UUTSerialNumberPWR-2024-00187被测电源模块序列号
UUTUUTStatusFailed整体判定失败
STEPStepName输出电压测量步骤名称
STEPStepStatusPassed该步骤通过
MEASUREMENTMeasNameVout_5V测量项名称
MEASUREMENTValue / Unit5.12 / V实测值
MEASUREMENTLowLimit / HighLimit4.75 / 5.25规格上下限
MEASUREMENTStatusPassed该测量项判定

注意 UUT 整体为 Failed,但“输出电压测量”步骤和其测量值都是 Passed。这说明失败发生在其他步骤(例如“纹波测量”超限)。追溯时,只需从 UUT 记录出发,向下查询所有 STEP,再找到 Status 为 Failed 的步骤及其 MEASUREMENT,就能快速定位问题。这正是关系模型的价值:失败点可以被精确定位到某一步骤的某一项测量。

三、数据从执行到落库的流向

TestStand 在运行时会在内存中维护一个结果对象树(ResultList)。每个步骤执行后,其状态、测量值和属性都会被写入这棵树。数据库记录并不是逐步实时写入的,而是由 Database Logger 在特定时机(通常是 UUT 测试完成或序列结束时)批量提交。理解这一点很关键:如果测试过程中程序崩溃,尚未提交的结果可能不会出现在数据库中。

Database Logger 的工作方式由“数据库选项”和“Schema”共同决定。Schema 文件(通常是 .ini 或 .xml)定义了表名、字段映射和插入语句。TestStand 默认提供的 Schema 已经覆盖了 UUT、STEP、MEASUREMENT、PROPERTY 四张表,但实际项目中经常需要扩展字段,例如增加“工位号”“操作员”“温度”等。扩展方式有两种:一是直接修改 Schema 增加列,二是在 PROPERTY 表中以键值对形式存储。前者查询效率高但改动大,后者灵活但查询时需要做行转列处理。

实践建议:如果某个字段需要频繁用于筛选或报表分组(如工位号、产品型号),建议直接扩展 UUT 表字段;如果只是偶尔查看的附加信息(如环境温度、操作员备注),放在 PROPERTY 表中更合适。

四、追溯查询的典型路径

假设需要回答“序列号 PWR-2024-00187 的纹波测量值是多少,是否超限”。查询路径如下:

  1. 在 UUT 表中按 SerialNumber 找到 UUT_ID。
  2. 用 UUT_ID 在 STEP 表中找到 StepName 为“纹波测量”的 STEP_ID。
  3. 用 STEP_ID 在 MEASUREMENT 表中找到 MeasName 为“Ripple_mV”的记录,读取 Value、LowLimit、HighLimit 和 Status。

对应的 SQL 示意如下:

SELECT m.MeasName, m.Value, m.Unit, m.LowLimit, m.HighLimit, m.Status
FROM UUT u
JOIN STEP s ON s.UUT_ID = u.UUT_ID
JOIN MEASUREMENT m ON m.STEP_ID = s.STEP_ID
WHERE u.SerialNumber = 'PWR-2024-00187'
  AND s.StepName = '纹波测量';

如果查询结果中 Status 为 Failed,且 Value 超出 HighLimit,就可以确认失败原因。若还需要知道该步骤的耗时或执行顺序,可以一并从 STEP 表中取出 ElapsedTime 和 Order 字段。

五、关系模型对结果追溯的意义

TestStand 的数据库架构本质上是一个以 UUT 为根、STEP 为中间层、MEASUREMENT 为叶子的树形关系模型。这种分层设计带来三个直接好处:

  • 定位精确:任何一条测量值都能向上追溯到步骤和被测单元,不会丢失上下文。
  • 统计灵活:可以按 UUT 统计整体合格率,也可以按 STEP 统计某一步骤的失败率,还可以按 MEASUREMENT 统计某项参数的分布。
  • 扩展方便:PROPERTY 表提供了不修改主表结构就能附加信息的通道,适合快速迭代的测试项目。

需要特别注意的是,TestStand 默认 Schema 中的表名和字段名是固定的,但不同版本之间可能存在细微差异。在实际项目中,建议先用数据库工具打开默认 Schema,确认表结构和字段类型,再决定是直接使用还是扩展。如果使用自定义 Schema,必须保证 Database Logger 的映射配置与 Schema 一致,否则会出现“测试通过但数据库无记录”或“字段写入错位”的问题。

常见误区:把 MEASUREMENT 表当成“所有测量值的大表”直接查询,而忽略 STEP 和 UUT 的关联。这样虽然能拿到数值,但无法知道它属于哪个序列号、哪个步骤,追溯链就断了。正确的做法始终是从 UUT 出发,沿外键向下关联。