📚 课程目录第3章 Keysight测试软件栈与开发环境

3. Keysight测试软件栈与开发环境

在量产测试平台开发中，Keysight的软件栈并不是单一工具，而是一组围绕“测试程序开发—流程编排—测量执行—数据回传”分工协作的组件集合。理解它们各自的职责边界，比记住安装步骤更重要，因为工程组织方式直接决定了后续测试项复用、并行站点扩展和数据闭环能否顺利落地。

一、软件栈的分层职责

PathWave Test Executive（常简称 Test Executive）是测试程序的“执行与调度中枢”。它负责加载测试计划、管理测试流程、控制仪器会话、处理通过/失败判定，并把每个测试项的结果写入结果记录。它不直接实现具体测量算法，而是调用下层测量代码或 Measurement Manager 提供的测量能力。

Test Flow 是流程编排层。它把测试项按顺序、分支、循环、并行等逻辑组织成可执行的测试流。量产测试中常见的“先校准、再功能测试、最后参数测试”的顺序，以及“某项失败后跳转到重测或标记报废”的分支，都在 Test Flow 中定义。Test Flow 的输出是一份可被 Test Executive 加载的流程描述，而不是可执行代码本身。

Measurement Manager 是测量资源与测量逻辑的管理层。它统一管理仪器连接、测量函数、单位换算、量程设置和结果缓存。开发人员把常用的测量封装成 Measurement 模块，Test Flow 通过名称调用，Test Executive 负责执行。这样做的价值在于：同一测量逻辑可被多个测试项复用，仪器更换时只需修改 Measurement Manager 中的连接配置，而不必改动上层流程。

二、安装配置的关键顺序

安装顺序直接影响组件能否互相识别。推荐顺序是：先装仪器驱动与 VISA 层，再装 Measurement Manager，然后装 Test Flow，最后装 PathWave Test Executive。原因是 Test Executive 在启动时会扫描已注册的 Measurement 和 Flow 组件，如果底层未就绪，扫描结果为空，后续配置会反复报“找不到测量模块”。

安装完成后需要做三项基础配置。第一，在 Measurement Manager 中建立仪器连接表，字段至少包括逻辑名、VISA 地址、驱动类型、超时时间。例如逻辑名 SMU_1 对应 TCPIP0::192.168.1.101::inst0::INSTR，超时设为 5000 ms。第二，在 Test Flow 中注册测试项，每个测试项绑定一个 Measurement 名称和一组参数。第三，在 Test Executive 中配置站点数、结果输出路径和 Pass/Fail 判定规则。

建议把仪器连接表、测试项注册表和流程文件放在同一个工程目录下，用相对路径引用。这样整个工程可以整体拷贝到另一台测试机，只需修改连接表中的 IP 地址即可运行。

三、工程组织方式与目录结构

一个可维护的量产测试工程，通常按“配置—测量—流程—结果”四类内容分目录存放。下面是一个示例结构，实际项目中可根据站点数量和测试项规模调整：

MyTestProject/
├── config/
│   ├── instruments.csv        # 仪器连接表：逻辑名, VISA地址, 驱动, 超时
│   ├── limits.csv             # 测试限值：测试项, 下限, 上限, 单位
│   └── stations.json          # 站点配置：站点数, 并行模式, 结果路径
├── measurements/
│   ├── meas_vcc.py            # 测量模块：电源电流
│   ├── meas_freq.py           # 测量模块：频率
│   └── meas_gain.py           # 测量模块：增益
├── flows/
│   ├── main_flow.xml          # 主流程：校准→功能→参数
│   └── retest_flow.xml        # 重测流程：失败项重测
├── results/
│   └── 2025-06-01_run001.csv  # 结果记录
└── logs/
    └── executive.log          # 执行日志

这种组织方式的核心思想是“配置与代码分离”。仪器地址、限值、站点数都放在 config 目录，换线体或换产品时只改配置，不动测量代码和流程逻辑。Measurement 模块只负责“怎么测”，Test Flow 只负责“按什么顺序测”，Test Executive 只负责“测完怎么判、怎么记”。

四、一个最小可运行示例

假设要测试一个电源模块的 VCC 电流，测试条件为 VCC=3.3 V，限值 10 mA～50 mA。在 Measurement Manager 中定义测量函数 meas_vcc，参数为 voltage=3.3、delay=0.1。在 Test Flow 中建立流程节点：先调用 meas_vcc，再把返回值与 limits.csv 中的上下限比较，最后把结果写入 Result Log。Test Executive 加载该流程后，执行一次，结果记录中会出现类似字段：

test_item, value, unit, lower, upper, status
VCC_current, 32.4, mA, 10, 50, PASS

如果实测值为 62.1 mA，状态为 FAIL，Test Executive 会根据流程定义决定是跳转到重测流程还是直接标记报废。这个判断逻辑写在 Test Flow 中，而不是写在测量代码里，保证了测量模块的复用性。

常见配置错误：Measurement Manager 中的逻辑名与 Test Flow 中引用的名称不一致，导致运行时提示“Measurement not found”。排查时先检查 instruments.csv 和 flows 目录下的名称拼写，再确认 Test Executive 是否已重新扫描组件。

五、组件协作的边界与数据闭环

理解三个组件的边界，可以用一句话概括：Test Flow 决定“测什么、按什么顺序”，Measurement Manager 决定“怎么测、用什么仪器”，Test Executive 决定“测完怎么判、结果放哪里”。三者通过配置文件解耦，任何一个组件更换或升级，只要接口不变，其余部分不需要改动。

数据闭环的起点是 Test Executive 写出的 Result Log。该文件通常包含测试项名称、测量值、单位、上下限、判定状态和时间戳。后续的数据分析系统读取该文件，生成良率趋势、失效分布和测试项相关性分析，再把优化建议反馈到 limits.csv 或 Test Flow 中。这样就形成了“测试执行—结果记录—分析反馈—配置优化”的闭环，而不是一次性跑完就结束的孤立测试。

在实际项目中，建议先用一个最小测试项跑通整条链路，确认仪器连接、测量调用、流程执行和结果写入都正常，再逐步增加测试项和站点。这样能把配置问题、代码问题和流程问题分开定位，避免一次性引入过多变量导致排障困难。