4. 部署依赖分析
在把 TestStand 测试系统从开发机搬到产线之前，最容易被低估的工作不是打包本身，而是依赖关系的梳理。很多“在我电脑上跑得好好的”问题，本质上是部署包漏掉了某个 DLL、某个驱动版本不匹配，或者配置文件路径在目标机上根本不存在。部署依赖分析的目标，就是把一个测试站真正运行所需的全部对象识别出来，并明确它们之间的依赖方向、版本约束和加载顺序。
TestStand 的部署对象可以归纳为五类：序列文件（Sequence File）、代码模块（Code Module）、仪器驱动（Instrument Driver）、运行时引擎（Runtime Engine）和配置文件（Configuration File）。它们不是并列关系，而是层层依赖：序列文件调用代码模块，代码模块调用驱动，驱动依赖运行时引擎提供的执行环境，而配置文件决定这些对象在目标机上如何被找到和初始化。
一、序列文件：依赖的起点
序列文件是依赖分析的入口。一个 .seq 文件里通常包含多个序列、步骤和变量，每个步骤都可能引用外部代码模块。梳理时首先要区分两类引用：相对路径引用和绝对路径引用。相对路径以序列文件所在目录为基准，部署时只要保持目录结构一致就能找到；绝对路径则写死了开发机上的盘符或目录，例如 C:\Projects\TestLib\measure.dll，到了产线机几乎必然失效。
实际操作中，可以在 TestStand 的 Sequence Editor 中打开序列文件，使用 Tools > Update Sequence File Paths 或查看步骤的 Module 属性，逐条确认路径类型。对于必须使用绝对路径的场景，应通过 StationGlobals 或配置文件中的变量来间接指定，而不是硬编码。此外，序列文件还可能引用序列文件模板、类型定义文件（.ini 中的 Type Palette）和回调序列，这些同样需要纳入依赖清单。
二、代码模块：最易遗漏的 DLL 依赖
代码模块是序列文件真正执行动作的地方，常见形式包括 C/C++ 编译的 DLL、LabVIEW VI、.NET 程序集和 CVI 可执行模块。这里最容易出问题的是传递依赖：你的 measure.dll 可能还依赖 mathlib.dll、log4cxx.dll 等第三方库，这些库不会自动出现在 TestStand 的部署列表中。
梳理方法是使用依赖查看工具（如 Dependency Walker 或 Visual Studio 的 dumpbin /dependents）对每个 DLL 做一次静态扫描，把直接依赖和间接依赖都列出来。同时要确认位数：32 位 DLL 只能被 32 位 RTE 加载，64 位同理。对于 LabVIEW VI，需要确认其调用的子 VI 是否都在同一项目或已打包进 .llb，以及是否依赖特定版本的 LabVIEW Run-Time Engine。
三、仪器驱动：版本与逻辑名双重约束
仪器驱动层通常包括 VISA、IVI 以及厂商专用驱动（如 NI-DMM、Keysight 驱动）。这一层的依赖有两个维度：版本兼容性和逻辑名映射。版本方面，不同仪器驱动对 VISA 版本有最低要求，例如某型号 PXI 模块驱动要求 VISA 18.0 以上；如果目标机装的是 VISA 15.0，初始化就会失败。逻辑名方面，IVI 驱动通过逻辑名（如 DMM1）在 IviConfigStore 中查找实际资源地址，部署时必须把逻辑名配置一并迁移，否则代码里写的是 DMM1，目标机上却找不到对应映射。
建议在依赖清单中为每个驱动记录：驱动名称、版本号、依赖的 VISA/IVI 版本、逻辑名列表、对应仪器型号。这样在目标机部署时可以直接对照安装，而不是靠记忆。
四、运行时引擎：部署的底座
TestStand Runtime Engine（RTE）是执行序列文件的底座，它包含序列引擎、适配器（LabVIEW、C/C++、.NET 等）和必要的服务。需要特别注意的是：开发版 TestStand 和部署版 RTE 不能混用。开发机上安装的是完整开发环境，目标机上应安装对应版本的 RTE，并且适配器要按实际使用的代码模块类型勾选安装。如果序列文件里用了 LabVIEW 适配器，但 RTE 安装时没有勾选 LabVIEW 支持，运行时就会报“适配器未找到”。
此外，RTE 的版本必须与序列文件保存时的版本兼容。高版本 TestStand 保存的序列文件通常无法在低版本 RTE 上打开，因此部署前要确认目标机 RTE 版本不低于开发版本。
五、配置文件：让依赖“找得到”
配置文件决定了上述对象在目标机上如何被定位和初始化，主要包括 StationGlobals.ini、TestStand.ini、搜索路径配置以及各驱动的配置文件。其中最关键的是搜索路径（Search Paths）：TestStand 在加载代码模块时，会按照搜索路径列表依次查找。如果目标机的搜索路径没有包含你的 DLL 所在目录，即使文件已经拷贝过去，仍然会报“找不到模块”。
部署时建议把自定义代码模块统一放在一个固定目录（如 D:\TestStand\Modules），并在目标机的 TestStand 配置中把该目录加入搜索路径。对于 StationGlobals，要确认其中的文件路径变量、仪器逻辑名变量与目标机实际环境一致。一个实用的做法是：在开发机上导出 StationGlobals 为 .ini 文件，部署时导入并逐项核对，而不是手工重建。
六、依赖关系的验证方法
梳理完成后，不能只靠“看起来没问题”就发布。建议在目标机或干净的测试机上做一次冷启动验证：不安装开发环境，只按部署清单安装 RTE、驱动和配置文件，然后加载序列文件并执行一个最小测试序列。观察点包括：序列文件能否正常打开、代码模块能否加载、仪器能否初始化、StationGlobals 中的变量能否正确解析。任何一步报错，都对应依赖清单中的某一类遗漏，回到清单补充即可。
依赖分析不是一次性工作，而是随着测试项目迭代持续维护的过程。把依赖关系梳理清楚，部署打包才有可靠的输入，产线发布也才能从“碰运气”变成“可复现”。