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

3. STM32量产测试软件框架设计

当STM32产品进入量产阶段，测试软件不再是“能跑通就行”的验证工具，而是一套需要长期维护、可追溯、可扩展的工程系统。本节围绕上位机测试序列引擎、SCPI仪器控制、测试脚本模块化和日志数据追溯四个核心模块，讨论如何构建一套适用于量产环境的测试软件框架。

一、整体架构与数据流

量产测试软件通常运行在PC上位机上，通过USB、串口、LAN或GPIB与测试仪器和被测板（DUT）通信。框架的核心职责是：按预定顺序执行测试项、控制仪器输出激励并采集响应、判定结果、记录数据并生成可追溯的测试报告。一个典型的分层结构如下：

表现层：操作员界面，显示当前测试项、进度、结果和异常提示。
序列引擎层：解析测试序列，调度测试项执行，管理超时、重试和异常分支。
仪器抽象层：封装SCPI命令，提供统一的电源、万用表、示波器、信号发生器等设备接口。
DUT通信层：通过串口、SWD或CAN与STM32交互，下发测试指令、读取ADC值或寄存器状态。
数据追溯层：记录原始测量值、判定阈值、时间戳、操作员、设备编号和DUT序列号。

下图展示了测试序列从加载到结果落盘的数据流与模块关系：

二、测试序列引擎的设计要点

测试序列引擎是整个框架的调度核心。它读取测试序列文件，按顺序执行每个测试项，并处理超时、重试和条件分支。序列文件建议采用YAML或JSON格式，便于人工编辑和程序解析。一个测试项通常包含以下字段：

- id: "VDD_3V3"
  name: "3.3V电源电压测试"
  instrument: "DMM_1"
  command: "MEAS:VOLT:DC?"
  condition: "VDD_EN=1"
  min: 3.20
  max: 3.40
  unit: "V"
  timeout_ms: 2000
  retry: 2
  on_fail: "continue"

引擎执行时，先检查前置条件（如使能电源），再向仪器发送SCPI查询命令，读取返回值并与min/max比较。若超时或读数超限，按retry次数重试；重试仍失败则根据on_fail决定是继续下一项还是终止整个序列。这种设计使测试流程与测试逻辑分离，修改测试项无需改动引擎代码。

三、SCPI仪器控制与抽象层

SCPI（Standard Commands for Programmable Instruments）是仪器控制的通用命令集。上位机通过VISA、TCP Socket或串口发送ASCII命令，仪器返回测量值或状态。例如，用万用表测量直流电压：

# 设置万用表为直流电压测量
DMM.write("CONF:VOLT:DC")
# 查询读数
value = float(DMM.query("MEAS:VOLT:DC?"))
# 返回示例：3.312

仪器抽象层的作用是屏蔽不同品牌仪器的命令差异。例如，Keysight 34461A和Fluke 8846A的直流电压查询命令可能不同，但抽象层对外暴露统一的measure_dc_voltage()接口。这样测试脚本只依赖抽象接口，更换仪器时只需修改驱动配置，不必重写测试逻辑。

四、测试脚本模块化

量产测试项往往有几十甚至上百个，如果全部写在一个脚本里，维护成本极高。模块化思路是将测试按功能分组：电源测试、时钟测试、GPIO测试、ADC测试、通信接口测试、功耗测试等。每个模块是一个独立的Python类或C#类，实现统一的execute()接口。序列引擎通过反射或注册表加载模块，按序列文件中的module字段调用对应实现。

例如，一个ADC测试模块可以这样组织：

class ADCTest:
    def __init__(self, dut, dmm):
        self.dut = dut
        self.dmm = dmm

    def execute(self, params):
        self.dut.send("ADC_START")
        raw = self.dut.read_adc()
        voltage = raw * params["lsb"]
        return {
            "raw": raw,
            "voltage": voltage,
            "pass": params["min"] <= voltage <= params["max"]
        }

模块化的另一个好处是支持并行测试。对于多工位产线，每个工位可以独立加载相同的测试模块，但使用不同的仪器资源和DUT序列号，互不干扰。

五、日志与数据追溯系统

量产测试的数据追溯是质量体系的基本要求。每一块STM32板卡在测试后，都应能回答：测了什么、用了哪台仪器、原始读数是多少、判定阈值是什么、谁在什么时间操作的、结果如何。日志系统需要记录三个层次的数据：

原始测量数据：仪器返回的原始值、单位、时间戳。
判定上下文：测试项ID、上下限、重试次数、最终判定。
环境信息：DUT序列号、工位号、仪器编号、操作员、软件版本。

数据存储建议采用“本地CSV + 数据库”双写策略：本地CSV用于快速排查和离线分析，数据库（如SQLite或MySQL）用于长期追溯和统计。每条记录应包含唯一测试流水号，便于与MES系统对接。对于FAIL项，还应保存失败时的原始响应和仪器状态，方便复现问题。

实践建议：在框架设计初期就定义好日志字段和数据库表结构，避免后期因追溯需求变更而大规模重构。测试序列文件、脚本模块和日志格式应纳入版本管理，确保不同批次的测试结果可对比。

综上，一套可用的STM32量产测试软件框架，应以序列引擎为调度中心，以仪器抽象层隔离硬件差异，以模块化脚本承载测试逻辑，以日志追溯系统保证数据完整性。四个模块各司其职，才能支撑从工程验证到批量生产的平滑过渡。