3、自动化测试基础：自动化测试原理、测试脚本语言选择（Python/LabVIEW）、测试序列与测试流程设计
射频自动化测试台的核心价值在于将重复性高、复杂度高、人工易错的射频测量任务转化为可重复、可追溯、高效率的自动化执行过程。本章作为从“手动测试”迈向“自动测试”的桥梁，将深入剖析自动化测试的底层原理，对比主流脚本语言（Python与LabVIEW）的适用场景，并重点讲解测试序列与测试流程的设计方法论。理解本章内容，是后续搭建具体射频测试系统、编写高效测试代码的基石。
3.1 自动化测试核心原理与抽象模型
自动化测试的本质，是将工程师手动操作仪器、读取数据、判断结果的“经验行为”转化为由计算机程序驱动的“确定性指令序列”。在射频领域，这一转化过程必须遵循严格的物理层与协议层规范。其核心原理可以概括为“三个替代”：用程序替代手动按键、用标准命令替代人工读数、用算法判定替代目视观察。
从系统架构看，任何自动化测试台都包含三个抽象层次：控制层（测试脚本与序列）、仪器层（信号生成与测量）、被测对象层（DUT及其外围电路）。控制层通过标准总线（如GPIB、LAN、USB、PXI）向仪器发送SCPI（可编程仪器标准命令）指令，仪器执行测量后返回数据，控制层解析数据并做出判定。这一闭环模型是理解所有自动化测试系统的基础。
射频测试的自动化还面临独特的挑战：信号路径的校准与补偿。由于线缆、转接头、开关矩阵的插入损耗随频率变化，自动化系统必须内置校准数据表（如开路/短路/负载校准后的误差系数），在测试执行时实时补偿。这意味着自动化测试框架不仅要控制仪器，还要管理“校准数据库”和“路径损耗表”。
3.2 测试脚本语言选择：Python vs LabVIEW
选择脚本语言是搭建自动化测试台的第一步，也是最容易引发争论的决策。Python与LabVIEW代表了两种截然不同的设计哲学：Python是“文本代码 + 丰富生态”的通用语言，LabVIEW是“图形化数据流 + 硬件集成”的专业工具。下表从射频测试的典型需求维度进行对比：
| 对比维度 | Python (配合PyVISA/pyvisa-py) | LabVIEW (配合VISA/SCPI) |
|---|---|---|
| 学习曲线 | 需要掌握语法、面向对象、异常处理；但网上资源极多 | 图形化编程直观，但调试复杂逻辑时可视化连线易混乱 |
| 仪器驱动生态 | 通过PyVISA统一接口，几乎所有支持SCPI的仪器均可控制 | NI官方提供大量仪器驱动，但第三方仪器需额外安装 |
| 数据处理能力 | NumPy/SciPy/Pandas 提供强大的数组运算与数据分析能力 | 内置数学节点，但复杂算法实现效率低于Python |
| 界面与报告 | 需借助PyQt/Tkinter或Web框架；报告可用ReportLab | 原生前面板设计便捷，适合快速搭建操作界面 |
| 实时性与并行 | 多线程受GIL限制，但射频测试通常非硬实时，影响不大 | 原生支持多线程与FPGA集成，适合高速数据采集 |
| 版本管理与复用 | Git + pip 管理依赖，代码复用性强 | VI文件为二进制格式，版本对比与合并困难 |
选择建议：如果团队已有深厚的LabVIEW积累，且测试台需要与NI硬件（如PXI模块）深度耦合，LabVIEW是合理选择。但对于新项目，尤其是需要大量数据分析、与MES（制造执行系统）对接、或需要算法迭代的场景，Python通常更具长期优势。一个折中方案是：用LabVIEW做底层仪器驱动与高速采集，用Python做上层测试逻辑与数据处理，两者通过TCP/IP或文件接口通信。
无论选择哪种语言，都必须遵循“仪器控制层与业务逻辑层分离”的原则。建议将SCPI指令封装为独立的函数库（如 signal_gen_set_freq(freq)），上层测试用例只调用这些函数，不直接接触原始指令。这样即使更换仪器型号，只需修改底层驱动函数，测试用例无需变动。
3.3 测试序列与测试流程设计
测试序列是自动化测试的“剧本”，它定义了测试步骤的执行顺序、依赖关系、循环与跳转逻辑。一个典型的射频测试序列包含以下阶段：准备阶段（上电、仪器预热、DUT初始化）、配置阶段（设置频率、功率、带宽等参数）、测量阶段（执行扫描、采集数据）、判定阶段（与限值比较）、清理阶段（断电、复位、数据归档）。
设计测试流程时，必须考虑“异常路径”的处理。例如，当DUT输出功率异常偏高时，应立即中断测试并触发保护机制，而不是继续执行后续步骤。这要求在序列引擎中实现“条件分支”和“超时控制”。以下是一个简化的测试序列伪代码示例：
# 射频收发信机发射功率测试序列（Python伪代码）
def test_tx_power():
# 准备阶段
dut.power_on()
sa.preset() # 频谱仪复位
sa.set_center_freq(2.4e9)
sa.set_span(100e6)
# 配置阶段
dut.set_tx_freq(2.4e9)
dut.set_tx_power(20) # dBm
# 测量阶段
sa.sweep_once()
measured_power = sa.get_marker_y()
# 判定阶段
if measured_power > 23 or measured_power < 17:
log_result("FAIL", f"Power={measured_power:.2f}dBm")
dut.power_off()
return False
else:
log_result("PASS", f"Power={measured_power:.2f}dBm")
dut.power_off()
return True在实际工程中，测试序列设计需要遵循“高内聚、低耦合”原则。每个测试项（如增益、噪声系数、EVM）应独立成函数，测试序列引擎负责调度这些函数。同时，必须引入“参数化”机制——将测试频率、限值、仪器地址等外部化到配置文件（如YAML或Excel），避免硬编码。
3.4 案例拆解：多频段Wi-Fi模块自动化测试流程优化
背景与约束：某通信模组厂需要测试一款双频Wi-Fi模块（2.4GHz/5GHz），共12个射频指标（发射功率、EVM、频谱模板、接收灵敏度等）。原手动测试需8分钟/台，且漏测率约2%。产线要求节拍≤3分钟/台，并实现100%数据可追溯。
初始现象与目标：手动测试时，工程师需反复切换频谱仪和信号源设置，且记录数据易出错。目标是将测试时间压缩至2.5分钟以内，并建立完整的数据库记录。
关键输入数据：测试频点共6个（2.4G: 2412/2437/2462MHz；5G: 5180/5220/5785MHz），每个频点需测试发射功率和EVM。接收灵敏度测试需在3个频点、2种速率下进行。
分析判断过程：通过时间分析发现，手动测试中约40%时间浪费在仪器设置切换上，30%时间在记录数据，20%在判断结果。自动化改造的核心是“并行化”和“批量处理”。
实际操作步骤：
- 硬件改造：增加射频开关矩阵，将DUT的TX/RX端口与频谱仪、信号源、功率计固定连接，避免手动插拔。
- 脚本开发：使用Python编写测试序列，将12个指标拆分为3个测试组（发射组、接收组、频谱组），每组内使用循环遍历频点。
- 优化策略：利用频谱仪的“列表扫描”模式，一次扫描同时测量多个频点的功率，将6个频点的发射功率测试时间从60秒缩短至15秒。
- 数据管理：测试结果实时写入SQLite数据库，并生成JSON格式报告上传至MES系统。
结果对比：改造后单台测试时间降至2分10秒，漏测率降至0.1%以下。更重要的是，由于消除了人为读数误差，测试一致性显著提升。
风险与代价：初期开发耗时约2周，且射频开关矩阵的插入损耗需额外校准。但通过引入自动校准程序，每4小时自动执行一次全路径校准，消除了该风险。
3.5 常见误区与总结复盘
在自动化测试台开发中，以下误区最为常见：
- 误区一：忽视仪器状态管理。未在测试前执行仪器预设，导致测试结果受上次设置影响。解决方法是建立“测试初始化”标准模板。
- 误区二：硬编码测试参数。将频率、限值直接写在代码中，一旦产品改版，需修改代码并重新测试。应使用配置文件或数据库管理参数。
- 误区三：缺乏超时与重试机制。当仪器通信异常时，脚本可能无限期等待。必须为所有SCPI操作设置超时（如5秒），并定义重试次数。
- 误区四：忽略数据精度与格式。频谱仪返回的数据可能是科学计数法字符串，直接比较会出错。应使用
float()转换并设置合适的有效位数。 - 误区五：测试序列过于线性。没有考虑“测试项B依赖测试项A的测量结果”的情况。应使用“动态跳转”或“条件执行”机制。