📚 课程目录第4章量产测试软件框架设计

4. 量产测试软件框架设计

当测试需求从实验室验证转向产线量产，软件框架的设计目标会发生根本变化：不再是“跑通一次”，而是“在有限节拍内稳定跑通成千上万次”。TI Sitara 这类 SoC 的产线测试通常同时涉及 DDR、eMMC、以太网、USB、串口、ADC、电源域等多类资源，测试程序必须把“测试序列编排、资源管理、日志与结果上报、多工位并行”四件事组织成可维护、可扩展的架构，而不是把测试代码堆在一个 main 函数里。

一、分层架构：把测试逻辑与硬件操作解耦

推荐采用四层结构。最底层是硬件抽象层（HAL），封装对 /dev、sysfs、GPIO、I2C、SPI 等接口的读写，例如把“读取 DDR 训练状态”封装成 hal_ddr_get_train_status()，上层不直接操作寄存器。第二层是资源管理层，负责串口、网口、电源、夹具继电器的申请、占用与释放，避免两个工位争抢同一物理资源。第三层是测试项层，每个测试项是一个独立可执行单元，输入是资源句柄与参数，输出是结构化结果。最上层是序列编排与调度层，决定测试项的执行顺序、并行度、超时与重试策略。

在 Linux 侧，测试程序通常以多进程或多线程方式运行，HAL 与资源管理放在主控进程，测试项以动态库或独立进程加载；在 RTOS 侧（如 Sitara 的 Cortex-M4 核），则更强调确定性时序，测试项以任务形式注册到调度器，通过消息队列与主控通信。两种形态共享同一套测试项描述与结果格式，便于统一上报。

二、测试序列编排：用数据描述流程，而不是硬编码

序列编排的核心思想是“流程即数据”。每个测试项用一条记录描述：项 ID、名称、依赖资源、超时、重试次数、失败是否阻断、参数。例如：

{
  "id": "DDR_TRAIN",
  "name": "DDR 训练与容量校验",
  "resource": ["ddr"],
  "timeout_ms": 8000,
  "retry": 1,
  "block_on_fail": true,
  "params": {"size_mb": 512, "pattern": "0x5A5A"}
}

编排器读取该列表后，按依赖关系生成执行顺序。对于无依赖的项（如 USB 枚举、以太网 PHY 自检），可并行执行；对于有依赖的项（如先上电再测 DDR），必须串行。编排器还需处理“阻断”语义：若 DDR 训练失败且 block_on_fail=true，后续依赖 DDR 的项直接标记为 SKIP，而不是继续执行导致误判。

三、资源管理：句柄化与生命周期

资源管理的目标是“谁申请、谁释放、谁负责”。每个物理资源（如工位 1 的串口 /dev/ttyS2、夹具继电器 GPIO 45）在启动时注册为资源对象，测试项通过 res_acquire("uart1") 获取句柄，使用完毕后 res_release()。资源管理器维护引用计数与超时回收：若某测试项异常退出未释放，管理器在超时后强制回收并记录告警，防止工位卡死。

对于多工位并行，资源命名必须带工位前缀，例如 ws01.uart1、ws02.uart1，避免跨工位误用。电源资源尤其关键：每个工位的 DUT 电源应独立可控，测试项通过 power_on(ws_id) 上电，测试结束后 power_off(ws_id)，确保不会因一个工位失败而影响其他工位。

四、日志与结果上报：结构化优先

产线日志的价值在于可追溯与可统计。建议每条测试记录包含：时间戳、工位号、DUT 序列号、测试项 ID、结果（PASS/FAIL/SKIP）、耗时、失败码、关键测量值。日志以 JSON Lines 格式写入本地文件，同时通过 MQTT 或 TCP 上报到 MES。失败码应预先定义，例如 E_DDR_TRAIN=1001、E_ETH_LINK=2003，便于产线快速分类。

结果上报要区分“测试结果”与“过程日志”。测试结果只保留最终判定与关键测量值，过程日志可保留详细调试信息，但需按级别过滤，避免产线网络拥塞。

五、多工位并行测试的软件设计模式

多工位并行的常见模式有三种：进程池模式、线程池模式和事件驱动模式。进程池模式为每个工位启动独立进程，隔离性最好，适合 Linux 侧；线程池模式共享内存，通信开销小，但需注意资源竞争；事件驱动模式基于 epoll 或 RTOS 消息队列，适合高并发、低延迟场景。

无论哪种模式，调度器都应维护一个工位状态机：IDLE → LOADING → TESTING → REPORTING → IDLE。当某工位进入 TESTING，调度器为其分配测试序列；测试完成后进入 REPORTING，上报结果并释放资源。若某工位超时，调度器将其标记为 ERROR，并触发告警，同时不影响其他工位继续测试。

六、一个可参考的测试序列示例

以某 Sitara AM62x 工位为例，测试序列可组织为：上电自检（POWER_ON_SELF）→ DDR 训练与容量校验（DDR_TRAIN）→ eMMC 读写校验（EMMC_RW）→ 以太网 PHY 自检与环回（ETH_LOOPBACK）→ USB 枚举与读写（USB_ENUM）→ 串口回环（UART_LOOP）→ ADC 基准测量（ADC_REF）→ 下电（POWER_OFF）。其中 DDR_TRAIN 与 EMMC_RW 为阻断项，失败则后续 SKIP；ETH_LOOPBACK 与 USB_ENUM 可并行执行，以缩短节拍。

假设 DDR_TRAIN 超时设为 8000 ms，实测耗时约 5200 ms；EMMC_RW 超时 6000 ms，实测约 3100 ms；ETH_LOOPBACK 超时 4000 ms，实测约 1800 ms。若四个工位并行，单工位节拍约 12～15 s，四工位总产能约 960～1200 件/小时（示例估算，实际取决于 DUT 与夹具）。

多工位并行时，务必确保电源与夹具资源按工位隔离。若多个工位共用同一电源通道，一个工位的短路或过流会拖垮其他工位，导致批量误判。

综上，量产测试软件框架的设计重点不在于代码量，而在于把“序列、资源、日志、并行”四个维度用清晰的数据结构和状态机组织起来。Linux 侧侧重进程隔离与网络上报，RTOS 侧侧重确定性时序与消息通信，两者共享测试项描述与结果格式，才能让产线测试既稳定又易于扩展。