4. 脚本结构设计原则

射频测试自动化脚本与普通软件自动化有一个本质区别：它必须同时面对硬件状态的不确定性（仪器连接中断、信号漂移、校准失效）、测试序列的强顺序性（先上电、再配置、后采集），以及多型号仪器之间的指令差异。如果脚本结构设计不合理，往往会出现“换一台仪器就要改全部代码”“增加一个测试项就要复制粘贴一大段”“某个用例失败后整个测试序列崩溃”等灾难性后果。本章围绕模块化与分层架构展开，重点解决三个问题：如何划分职责边界、如何组织代码层级、如何让脚本在长期迭代中保持稳定与弹性。

4.1 模块化设计：从“大而全”到“小而专”

核心原理

模块化设计的本质是单一职责原则在射频测试脚本中的落地。一个模块只负责一类变化：仪器驱动模块只处理SCPI指令的封装与解析；业务模块只描述“测什么、怎么测”的测试逻辑；用例模块只描述“针对哪个被测件、在什么条件下、执行哪些业务步骤”。模块化的好处在于：当仪器型号升级时，只替换仪器层对应驱动；当测试规范变更时，只修改业务层参数；当新增测试场景时，只新增用例文件。

判断方法

判断脚本是否模块化，可以从三个维度审视：依赖方向（高层是否依赖低层抽象而非具体实现）、替换成本（更换一台同类型仪器是否需要改动业务代码）、复用率（同一段代码是否被多个用例重复调用）。如果一段代码超过50行且被复制粘贴超过两次，就应该考虑提取为独立模块。

案例拆解

某通信模块产线需要测试Wi-Fi 6E的发射功率、EVM和频谱模板。初期脚本将所有代码写在一个文件里，信号源、频谱仪、DUT控制逻辑全部混在一起。当产线将频谱仪从Keysight N9020B更换为R&S FSW时，工程师不得不逐行查找所有与频谱仪相关的SCPI指令并替换，耗时两天且引入了三处回归缺陷。重构后，仪器层提供统一的SpectrumAnalyzer基类，N9020B和FSW各自实现该基类；业务层只调用set_span()、set_rbw()、get_marker_frequency()等抽象方法。更换仪器时，只需在配置文件中修改仪器型号，代码零改动。

常见误区

• 过度抽象：为每个仪器方法都创建接口，导致类层次过深，调用链冗长，反而降低可读性。
• 模块粒度太粗：一个“仪器控制”模块包含信号源、频谱仪、功率计的所有功能，仍然无法独立替换。
• 忽略配置模块：将仪器地址、测试频率、限值等硬编码在用例中，导致换环境就要改代码。

4.2 分层架构：仪器层、业务层、用例层的职责边界

核心原理

分层架构的核心思想是单向依赖：用例层依赖业务层，业务层依赖仪器层，仪器层不依赖任何上层模块。每一层只解决一个层面的问题。仪器层解决“如何与硬件对话”，业务层解决“如何完成一项测量任务”，用例层解决“如何组织一个完整测试场景”。这种架构让测试脚本从“面向仪器的编程”转变为“面向业务的编程”。

操作流程

1. 定义仪器层接口：列出所有需要用到的仪器功能（如设置频率、读取功率、触发测量），为每类仪器定义抽象基类或协议类。
2. 实现具体驱动：针对不同品牌型号的仪器，实现基类中的方法。每个驱动内部处理SCPI语法差异、超时控制、错误恢复。
3. 构建业务层：将测试规范中的测量步骤转化为可复用的业务方法。例如“测量信道功率”业务方法内部调用仪器层的扫频、标记、功率统计等操作。
4. 编写用例层：用例只描述“前置条件、执行步骤、预期结果、判定准则”，不直接出现任何SCPI指令或仪器API调用。

案例拆解

以5G NR基站发射机测试为例，一个典型的“发射功率与EVM”用例在分层架构下的执行路径如下：

# 用例层 test_nr_tx_power_evm.py
def test_nr_tx_power_evm():
    # 前置条件
    dut = DUTController("192.168.1.100")
    sa = SpectrumAnalyzerFactory.create("sa_config.yaml")
    sg = SignalGeneratorFactory.create("sg_config.yaml")
    
    # 业务层调用
    tx_power = nr_tx_measurements.measure_channel_power(sa, freq=3.5e9, bandwidth=100e6)
    evm = nr_tx_measurements.measure_evm(sa, sg, freq=3.5e9, mode="NR-TM1")
    
    # 断言
    assert tx_power > 43.0, f"TX power too low: {tx_power} dBm"
    assert evm < 3.5, f"EVM too high: {evm}%"

业务层nr_tx_measurements.py内部实现测量流程，仪器层sa_driver.py负责将业务参数转换为具体SCPI指令。当测试从3.5GHz频段切换到2.6GHz时，只需修改用例中的频率参数；当频谱仪更换为另一品牌时，只需修改工厂配置。

常见误区

• 跨层调用：用例层直接调用仪器层方法，绕过业务层，导致业务逻辑散落在用例中。
• 层间耦合：业务层方法返回仪器特有的数据类型（如SCPI查询的原始字符串），而不是统一的Python对象。
• 缺少工厂模式：在用例中直接实例化具体仪器驱动，导致更换仪器时需要修改所有用例。

4.3 可维护性设计：让脚本“活”过产品生命周期

核心原理

射频测试脚本的生命周期往往比预期长得多——一个产品可能持续生产5年以上，期间会经历硬件改版、仪器升级、测试规范修订。可维护性设计的目标是让脚本在这些变化中保持稳定。关键手段包括：配置与代码分离、日志与报告标准化、命名与注释规范、版本控制策略。

操作流程

1. 建立配置体系：将仪器地址、测试频率、限值、路径等参数放入YAML或INI配置文件，代码中不出现任何魔法数字。
2. 统一日志格式：每个关键步骤输出结构化日志（时间戳、级别、模块名、消息），便于自动化解析和问题定位。
3. 制定命名规范：仪器层类名以仪器类型结尾（如SpectrumAnalyzer_FSW），业务层方法名以动词开头（如measure_channel_power），用例文件名以test_开头。
4. 实施代码评审：每次修改必须经过评审，重点检查是否破坏了分层边界、是否引入了重复代码、是否更新了配置模板。

案例拆解

某射频模组测试系统在运行一年后，测试规范要求增加“带外杂散”测试项。由于原始脚本采用了分层架构，工程师只需在业务层新增一个measure_spurious_emission()方法，在用例层新增一个测试文件，配置文件中添加杂散测试的频段和限值。整个开发耗时半天，且未影响已有用例。而同期另一个未分层设计的项目，为了增加该测试项，需要修改6个文件，涉及仪器控制、数据处理、报告生成等多个模块，测试两天且引入了两个回归缺陷。

常见误区

• 配置过度复杂：配置文件层级过深、参数命名晦涩，导致维护人员需要查阅大量文档才能修改一个参数。
• 日志信息不足：只在出错时打印堆栈，没有记录仪器状态、测量值、配置参数等关键上下文。
• 忽略代码风格：不同工程师使用不同命名风格和缩进，导致代码阅读困难，增加维护成本。

4.4 可扩展性设计：面向未来的测试需求

核心原理

可扩展性意味着脚本能够以最小的改动适应新的测试需求。这要求设计时预留扩展点：新仪器型号的接入、新测试项目的增加、新频段/新制式的支持。实现可扩展性的关键技术包括：工厂模式（根据配置创建不同仪器实例）、插件架构（业务模块可动态加载）、数据驱动（测试参数与测试逻辑分离）。

判断方法

评估脚本可扩展性时，可以问自己三个问题：如果新增一台从未用过的频谱仪，需要修改哪些文件？如果新增一个测试项目，需要复制多少代码？如果测试频段从sub-6GHz扩展到毫米波，现有架构能否支持？如果答案是需要修改多个层级的代码，说明扩展性不足。

案例拆解

某企业测试系统最初只支持Wi-Fi 5（802.11ac），后来需要扩展支持Wi-Fi 6E（802.11ax）。在可扩展性良好的架构下，工程师在仪器层新增了Wifi6ESignalGenerator驱动，在业务层新增了measure_wifi6e_evm()方法，在配置文件中添加了Wi-Fi 6E的频段和带宽参数。由于用例层通过配置文件读取测试参数，现有Wi-Fi 5用例无需修改即可继续运行。整个扩展工作耗时两天，且没有影响已有测试的稳定性。

常见误区

• 过度设计：为永远不会发生的扩展场景设计复杂的抽象机制，导致代码难以理解。
• 忽略向后兼容：新增功能时修改了已有接口，导致旧用例无法运行。
• 缺乏版本管理：没有对配置文件和驱动代码进行版本控制，导致不同产线使用不同版本，难以统一维护。

4.5 综合实战：从零构建一个分层射频测试脚本

场景描述

某物联网模组产线需要测试NB-IoT终端的发射功率、频率误差和EVM。测试系统包含一台信号源（用于模拟基站）、一台频谱仪（用于测量终端发射信号）、一个可编程电源（用于控制终端供电电压）。要求脚本支持两种信号源型号（Keysight E4438C和R&S SMW200A）和两种频谱仪型号（Keysight N9020B和R&S FSW26）。

架构设计

project/
├── config/
│   ├── test_config.yaml          # 测试参数配置
│   ├── instrument_config.yaml    # 仪器地址与型号
│   └── limit_config.yaml         # 测试限值
├── instrument/
│   ├── base/
│   │   ├── signal_generator.py   # 信号源抽象基类
│   │   └── spectrum_analyzer.py  # 频谱仪抽象基类
│   ├── keysight/
│   │   ├── e4438c.py
│   │   └── n9020b.py
│   └── rohde_schwarz/
│       ├── smw200a.py
│       └── fsw26.py
├── business/
│   ├── nb_iot_tx_test.py         # NB-IoT发射测试业务
│   └── power_control.py          # 电源控制业务
├── testcase/
│   ├── test_nb_iot_tx_power.py
│   ├── test_nb_iot_freq_error.py
│   └── test_nb_iot_evm.py
├── utils/
│   ├── config_loader.py
│   ├── logger.py
│   └── report.py
└── main.py                       # 测试入口

关键实现

仪器层基类定义统一接口，具体驱动实现SCPI指令差异。业务层通过工厂方法获取仪器实例，不关心具体型号。用例层只描述测试步骤和判定标准。

# instrument/base/spectrum_analyzer.py
class SpectrumAnalyzer:
    def __init__(self, address):
        self.address = address
        self.connected = False
    
    def connect(self): raise NotImplementedError
    def set_frequency(self, freq_hz): raise NotImplementedError
    def set_span(self, span_hz): raise NotImplementedError
    def set_rbw(self, rbw_hz): raise NotImplementedError
    def get_marker_power(self): raise NotImplementedError
    def get_marker_frequency(self): raise NotImplementedError
    def disconnect(self): raise NotImplementedError

结果与复盘

该架构上线后，产线在三个月内完成了两次仪器切换（信号源从E4438C更换为SMW200A，频谱仪从N9020B更换为FSW26），每次切换仅需修改配置文件中的仪器型号和地址，代码零改动。测试脚本的维护成本从每月约8人天降低到每月约2人天。复盘经验表明，前期在架构设计上投入的3天时间，在后续半年内节省了超过30人天的维护工作量。