1. 部署工程总览

在NI TestStand的工程实践中，开发环境里跑通一个测试序列只是起点。真正决定项目能否在产线上稳定运行、能否被产线操作员正确使用、能否在换型或升级时快速切换的，是部署打包与产线发布这一环节。本节从整体视角梳理部署工程的核心目标、需要交付的物、典型产线场景以及必须提前识别的工程约束，为后续各章节的具体操作建立统一的概念框架。

一、部署工程要解决的核心问题

TestStand本身是一个测试执行管理框架，它并不直接包含被测对象的测试逻辑，而是通过调用LabVIEW、C/C++ DLL、.NET程序集、Python脚本等代码模块，配合序列文件（.seq）来组织测试流程。这种“框架+模块+序列”的结构带来了灵活性，也带来了部署的复杂性：开发机上能运行的序列，到了产线工控机上可能因为路径、依赖、权限、硬件资源、许可证等原因无法启动。

部署工程的核心目标可以归纳为三条：

• 可运行：目标机器上TestStand引擎、运行时许可证、代码模块依赖、硬件驱动全部就位，序列能正常加载并执行。
• 可复现：同一份部署包在相同配置的产线机上安装后，行为一致，不依赖开发机的临时文件或手工配置。
• 可维护：产线需要换型、升级、回滚时，能够通过替换部署包或切换配置快速完成，而不需要重新在产线机上调试。

这三条目标决定了部署包不能只是“把开发目录拷过去”，而需要经过依赖分析、路径重定向、许可证确认、安装脚本封装等处理。

二、交付物清单

一个完整的TestStand产线部署交付物通常包含以下内容，具体项目可根据产线规模裁剪：

交付物	典型内容	作用
TestStand部署包	由TestStand Deployment Utility生成的Installer或Image	安装引擎、序列文件、代码模块、驱动依赖
序列文件集	主序列、子序列、StationGlobal、类型定义	定义测试流程与数据传递
代码模块	LabVIEW VI、DLL、.NET程序集、Python脚本	执行具体测量与判断
配置文件	硬件通道映射、限值文件、产品型号配置	适配不同产品与工位
运行时许可证	TestStand Runtime、LabVIEW Runtime等	保证目标机合法运行
安装与发布说明	安装步骤、依赖顺序、回滚方法	指导产线维护人员操作
验证记录	部署后自检结果、冒烟测试记录	确认部署成功

其中，TestStand Deployment Utility生成的部署包是核心交付物。它能够扫描序列文件引用的代码模块、驱动、配置文件，并把这些依赖收集到一个安装程序中。但工具不会自动解决所有问题，例如动态加载的模块、运行时才确定的路径、需要手工注册的COM组件，仍需要工程师在部署前识别并补充。

三、典型产线场景

不同产线对部署的要求差异很大，常见场景包括：

• 单工位手动测试：一台工控机、一个操作员、一个产品型号。部署重点是安装简单、启动快捷，通常使用TestStand Deployment Utility生成单个Installer即可。
• 多工位并行测试：多台工控机共享同一套序列和代码模块，但各自连接不同硬件。部署时需要统一序列版本，同时通过StationGlobal或配置文件区分工位参数。
• 多产品换型：同一工位需要测试多种产品，通过产品型号选择不同的序列入口和限值文件。部署包需要包含全部型号配置，并保证切换时不残留上一型号的状态。
• 产线升级与回滚：产线不能长时间停机，升级需要快速完成，且一旦失败能回滚到上一版本。这要求部署包版本化，并保留上一版本的安装包和配置备份。

这些场景的共同点是：部署不是一次性动作，而是贯穿产线生命周期的持续活动。因此，部署工程需要把“安装”和“配置”分离，把“序列”和“数据”分离，才能在不同场景下灵活组合。

四、工程约束

在制定部署方案前，必须识别以下约束，否则容易在产线现场才发现问题：

• 操作系统与位数：TestStand 2019及以后版本通常要求Windows 10/11 64位，代码模块的位数必须与TestStand引擎一致。32位DLL无法被64位TestStand直接调用。
• 运行时许可证：产线机通常只需要TestStand Runtime，但Runtime的授权方式与开发环境不同，需要确认许可证已正确激活，否则序列无法执行。
• 硬件驱动版本：DAQmx、VISA、仪器驱动等必须与代码模块兼容。驱动版本不一致可能导致初始化失败或测量偏差。
• 路径与权限：产线机可能限制用户权限，部署包安装路径、临时文件目录、日志目录都需要提前确认可写。
• 网络与隔离：部分产线机不联网，部署包必须包含所有依赖，不能依赖在线下载。
• 版本一致性：TestStand引擎版本、代码模块编译版本、序列文件保存版本三者需要匹配，否则可能出现加载失败或行为异常。

五、部署工程的整体关系

下图从“开发侧输入”到“产线侧输出”梳理了部署工程的主要对象、处理环节和约束条件，帮助建立整体视图。图中左侧是开发环境中的源对象，中间是部署打包过程，右侧是产线目标环境，下方是贯穿全程的约束与验证。

从图中可以看出，部署工程不是简单的“打包—安装”两步，而是开发侧对象经过依赖扫描、路径重定向、安装包生成后，在产线侧完成运行时安装、配置确认和冒烟测试的完整链路。底部的工程约束贯穿全程，任何一项未满足都可能导致部署失败。右侧产线环境的验证结果需要反馈到打包环节，用于修正部署包，形成闭环。

六、部署前的检查要点

在正式生成部署包之前，建议按以下顺序完成检查，避免返工：

1. 确认目标产线机的操作系统版本、位数、已安装的TestStand Runtime版本。
2. 在开发环境中使用TestStand Deployment Utility扫描序列文件，查看依赖列表中是否有“未找到”或“路径异常”的条目。
3. 检查所有代码模块的位数与TestStand引擎一致，检查驱动版本是否满足代码模块的最低要求。
4. 确认序列文件中使用的路径变量（如<TestStand>、<StationGlobal>、自定义路径）在目标机上能够正确解析。
5. 确认产线机用户对安装目录、日志目录、临时目录有写权限。
6. 准备一份冒烟测试序列，覆盖硬件初始化、一次完整测量、结果判断和报告生成，用于部署后快速验证。