3. 测试架构概述

量产测试架构不是“把仪器连起来、把脚本跑通”这么简单。它决定了测试程序能否在数十台机台、数百个工位、数年内持续稳定运行，也决定了新芯片导入、测试项增删、机台换代时，团队要付出多少返工成本。本节从分层架构、模块化设计、可扩展性与可维护性四个维度，建立量产测试架构的整体认知。

一、核心原理：为什么量产测试必须“分层”

量产测试的本质，是把“芯片规格”翻译成“可重复执行的测量与判定”。这个过程涉及硬件连接、仪器控制、测试算法、数据判定、数据记录与追溯等多个关注点。如果把它们混写在一个脚本里，任何一处变更都会牵动全局。分层架构的核心思想是按变化频率与职责边界切分：越底层越稳定，越上层越贴近产品与业务。

典型的分层自下而上为：

• 硬件与驱动层：测试机、探针台/分选机、DUT板、继电器矩阵、电源与仪表驱动。关注点是通道映射、时序、量程与校准。
• 仪器抽象层：把不同厂商、不同型号的仪器统一为同一组接口，如 set_voltage()、measure_current()，屏蔽 SCPI 或私有命令差异。
• 测试方法层：实现具体测试项，如开短路、漏电、阈值电压、频率、ADC 线性度。它只调用抽象接口，不关心仪器型号。
• 测试流程层：组织测试项顺序、条件分支、重测策略、站点并行与资源调度。
• 数据与判定层：规格限、单位换算、Bin 分类、数据落库、追溯与报表。

分层的价值在于：更换机台时只改驱动与抽象层；新增测试项时只改方法层与流程层；调整规格时只改数据判定层。每一层都有清晰的输入输出契约，团队可以并行开发与验证。

二、模块化设计：把“测试项”做成可插拔单元

模块化是分层落地的具体手段。一个合格的测试模块应具备四个特征：单一职责、明确接口、独立可测、无隐式全局状态。以漏电测试为例，模块只负责“给定条件、测量电流、返回结果与单位”，不负责决定 Bin、不负责写数据库、不直接操作继电器矩阵。

模块接口通常包含：输入参数（电压、延时、量程）、输出结果（测量值、单位、状态）、资源声明（需要哪些通道与仪器）。资源声明让流程层可以自动做冲突检测与并行调度，这是多工位量产的关键。

# 测试模块接口示例（伪代码）
class LeakageTest(TestModule):
    name = "IDD_LEAKAGE"
    resources = ["PS1", "DMM1", "CH_A"]

    def setup(self, ctx):
        ctx.ps1.set_voltage(3.3)
        ctx.dmm1.set_range("1uA")

    def run(self, ctx) -> TestResult:
        ctx.wait_ms(5)
        i = ctx.dmm1.measure_current()
        return TestResult(value=i, unit="A",
                          limits=(0, 1e-6), bin_on_fail="LEAK_FAIL")

    def teardown(self, ctx):
        ctx.ps1.set_voltage(0)

这种写法让测试项可以被单独仿真、单独回归，也可以在流程层被条件跳过或重测，而不影响其他模块。

三、可扩展性与可维护性原则

可扩展性关注“新增变化时改动面有多小”，可维护性关注“出问题时定位有多快”。两者共同依赖以下原则：

• 面向接口而非实现：流程层只依赖抽象仪器接口，不出现具体型号字符串。
• 配置与代码分离：电压、限值、延时、Bin 映射放入配置文件或数据库，代码只保留逻辑。
• 显式资源管理：谁申请、谁释放，避免继电器状态残留导致串扰。
• 统一日志与追踪 ID：每个测试项输出站点号、时间戳、原始值、判定结果，便于复盘。
• 版本化测试程序：程序、配置、校准数据三者版本绑定，保证可复现。

四、案例与场景：从“单机脚本”到“多工位平台”

某电源管理芯片项目初期只有一台测试机、一个工位，工程师把仪器命令、测试逻辑、判定和报表写在一个脚本中，两周完成导入。半年后产量上升，需要扩展到四工位并行，并新增两家代工厂的不同型号仪器。原脚本中大量硬编码的仪器地址与通道号导致无法复用，重测逻辑与数据记录耦合，任何改动都要全量回归。

重构时按本节分层落地：把仪器命令收敛到抽象层，测试项改为模块并声明资源，流程层用配置描述测试顺序与并行策略，判定与落库独立成服务。结果是：新增工位只改流程配置；更换仪器只新增一个驱动适配器；新增测试项只增加一个模块文件。回归范围从“全量”缩小到“受影响模块”。

五、常见误区与复盘要点

复盘时建议检查三个问题：第一，最近三次变更分别改动了哪些层，是否出现跨层修改；第二，新增一个测试项的平均耗时与回归范围是否在收敛；第三，现场异常能否仅凭日志与追踪 ID 还原到具体模块与资源。若答案不理想，应优先回到分层边界与模块接口上做修正，而不是继续在流程层打补丁。

量产测试架构的最终目标，是让“变化”成为可预期、可隔离、可验证的常规操作。分层提供边界，模块化提供单元，可扩展性与可维护性原则提供长期演进的约束。三者结合，测试程序才能从一次性交付物，变成可持续运营的工程资产。