概览
创建可部署的解决方案后，您可以使用多个选项将该解决方案部署到一个或多个测试站。本文档讨论了使用NI程序包、安装程序技术或共享网络驱动器的部署策略。
内容
- 识别部署所需的组件
- 选择部署机制
识别部署所需的组件
测试系统通常很复杂，包含许多组件和文件，必须正确部署所有组件和文件，从而确保在生产系统中的测试顺利运行。在本文档中，我们仅考虑测试产品时使用的软件组件。
TestStand测试系统的主要组件包括测试代码、测试框架文件以及驱动程序和Runtime引擎。
测试代码
测试代码包括为了执行实际测试而创建的序列文件和代码模块。部署测试代码时，必须确保代码模块的所有必需依赖项均包含在内，并且文件已部署在磁盘上的正确位置，以便调用者可以找到它们。测试代码通常包括一个或多个序列文件以及这些文件引用的文件。
序列文件
序列文件取决于它们调用的代码模块、序列文件依赖项以及补充文件（例如属性加载器文件）。您可以使用TestStand部署工具来分析序列文件并枚举这些依赖项。TestStand部署工具无法识别动态引用的依赖项（例如TestStand表达式指定的属性文件）或隐式引用的文件（例如测试文档）。
应尽可能将特定序列文件的所有依赖文件存储在序列文件路径下的子目录中。此结构具有以下优点：
- 可以使用相对于当前序列文件的路径来引用文件，从而确保在将序列文件和依赖项复制到另一个位置时，这些路径仍然有效。
- 跟踪动态调用的隐式依赖项要容易得多，因为可以整体部署依赖项目录。
您还必须考虑代码模块本身的依赖项。部署此类依赖项的过程因模块类型而异。
LabVIEW代码模块
LabVIEW代码模块包括VI、LabVIEW类成员调用、Express VI调用和属性节点调用。为了在未安装LabVIEW开发系统的系统中执行LabVIEW代码模块，必须确保VI代码模块的所有依赖项均保存在相同版本的LabVIEW中。您还需要考虑LabVIEW开发系统附带的所有依赖VI，例如LabVIEW安装中的vi.lib或instr.lib目录中出现的VI均包含在部署中。您可以使用以下方法来确保两个条件均得到满足：
- 为所有代码模块VI创建LabVIEW源代码发布，并确保未选择不包含vi.lib、instr.lib和user.lib的选项。为了防止源VI与源代码发布中的VI出现交叉链接，请确保将文件添加到新项目库中。
- 为源文件创建一个或多个打包项目库(PPL)。PPL是包含所有VI及其依赖项的单个编译文件。借助这种方法，可以将已部署的PPL替换为更新的版本，从而更新现有部署。
*PPL不包括DLL或已编译为PPL的VI的依赖项
要自动处理此过程的大部分内容，您可以使用TestStand部署工具部署调用LabVIEW代码模块的序列文件。TestStand部署工具将所有VI保存在单个LabVIEW版本中，并包含LabVIEW ADE中的所有必需的依赖项。还可以选择使用这一部署工具生成打包项目库(PPL)。有关更多信息，请查看《在LabVIEW打包项目库中部署VI》。
C/C++ DLL依赖项
在通常情况下，任何依赖DLL都将被复制到生成目录中，或成为包含在所需Runtime引擎中的系统DLL。您应尽量不直接将DLL或其他二进制文件部署到Windows系统目录，而应先确定安装这些依赖项的软件，然后再将其包含在部署中。有关部署其他软件的更多信息，请查看下面的《驱动程序和Runtime》章节。
.NET依赖项
与非托管C/C++ DLL一样，托管.NET DLL是可以在不使用ADE的情况下执行的编译代码。与C/C++ DLL不同，.NET程序集可以引用全局程序集缓存(GAC)中的依赖程序集，其中包括已安装驱动程序或Runtime软件的程序集，但也可以包含您自己的代码。
生成.NET程序集时，可以对引用的程序集使用“复制本地”属性，从而在您的程序集旁边加上这些程序集的副本。这样一来，您可以确保通过部署包含程序集和依赖项的文件夹来部署.NET依赖项。
测试框架文件
除了测试代码外，还必须部署TestStand框架文件。如果在部署中包含TestStand Runtime，系统中将安装这些文件的默认版本。但是，如果您已自定义这些组件的版本，则需要在测试系统部署中将其包含在内。
TestStand配置文件
TestStand配置文件存储TestStand的本地安装设置。 这些文件描述并驱动测试系统的行为。TestStand配置文件位于<TestStand应用程序数据>Cfg目录中。
有关TestStand包含的配置文件以及每个文件中所存储信息的详细信息，请查看《配置文件》帮助主题。
TestStand组件
TestStand组件用于实现测试系统的高层执行，与测试序列分离，从而增强TestStand架构的模块化。TestStand组件实现了登录和注销、报告、数据库记录和序列号输入等功能。这些文件位于<TestStand>Components目录中。
有关TestStand组件目录中各项的详细信息，请查看《组件目录》帮助主题
TestStand用户界面
为了在已部署的计算机上运行序列，您需要部署至少一个用户界面，因为序列编辑器仅在开发计算机上可用。用户界面可以很简单，也可以高度自定义，具体取决于您的需求。TestStand包括可以在<TestStand Public>/UserInterfaces中部署的用户界面应用程序。
有关创建在已部署的计算机上使用的TestStand用户界面的特定信息，请查看《NI TestStand用户界面开发的最佳实践》文档。
驱动程序和Runtime引擎
要在生产系统中执行序列和测试代码，必须确保安装了所有必需的Runtime引擎(Runtime)和硬件驱动程序。Runtime引擎是执行软件组件（例如DLL、VI和序列文件）所必需的。驱动程序是测试系统使用的硬件组件所必需的。您将始终需要部署TestStand Runtime，其中包含TestStand引擎和支持文件。
如果使用TestStand部署工具进行部署，可以选择检测并包含代码模块引用的所需版本的驱动程序和Runtime。如果不包括Runtime，TestStand部署工具会提供一条信息记录消息，指示应在部署中包含哪些版本。
软件许可证
您必须确保已部署的计算机有适当的软件许可证。每台已部署的计算机至少需要基本部署许可证，该许可证允许序列执行，但不允许开发。LabVIEW和LabWindows/CVI Runtime等许多Runtime引擎没有任何许可要求。您应该查阅文档来了解所部署的所有其他组件，从而确保获得所有必要的部署许可证。有关已部署应用程序需要获得许可证的所有NI产品的列表，请查看《NI软件的部署和调试许可证》的《部署许可证》章节帮助主题。
如果要部署到大量生产计算机上，NI将提供批量许可，您可以通过中央许可服务器管理许可证。有关批量许可选项的更多信息，请查看《软件的批量许可计划》页面。
选择部署机制
对需要包含在测试系统部署中的文件集进行定义之后，需要选择将文件分发到生产计算机的机制。以下章节介绍了下列部署机制：
基于NI程序包的部署
NI程序包提供了将部署中的所有文件整合为一个文件的机制，您可以使用NI Package Manager将其部署并提取到生产计算机上的正确位置。可以使用TestStand部署工具来构建一个包含部署中所有文件的程序包。对于基于程序包的部署，部署所需的驱动程序和组件作为程序包的依赖项，但不包含在程序包中。
在生产计算机上安装程序包时，NI Package Manager将检测这些依赖项，并允许您下载并安装这些程序包。您还可以使用SystemLink软件在组织内提供NI程序包的存储库，包括您创建的NI程序包。有关使用SystemLink管理基于程序包的部署的更多信息，请查看《如何使用SystemLink配置系统和部署软件？》
由于每个NI程序包均为单个组件，因此可以使用更新的版本号创建程序包的新版本，来更新基于程序包的部署。新版本经过测试和验证之后，您可以通过传统的文件传输或SystemLink将其分发到生产计算机上。
基于安装程序的部署
部署文件的另一种方法是创建一个包含部署所需的所有组件的安装程序，该安装程序可以复制并安装在测试站计算机上。与程序包不同，安装程序可以将所需的驱动程序和组件均包含在内。将这些组件包含在内会大大增加安装程序在磁盘上的容量，但可确保驱动程序和Runtime引擎始终包含在内且可用。借助TestStand部署工具，您无需直接了解Microsoft安装程序技术即可为TestStand系统创建安装程序，并提供以下功能：
- 将文件分发到目标计算机上的特定目录，例如<TestStand>目录或<Desktop>目录。
- 导入您在Measurement and Automation Explorer(MAX)中生成的硬件配置。
- 可以包含其他组件，包括驱动程序和Runtime。
- 能够创建补丁安装程序以将更新应用于现有部署。
有关TestStand部署工具可用功能的更多详细信息，请查看TestStand帮助中的《使用TestStand部署工具构建安装程序》主题。在大多数情况下，TestStand部署工具提供了构建自定义部署安装程序所需的功能。如果需要进一步控制部署安装程序的行为，可以使用第三方工具创建安装程序。请查看《使用第三方工具构建安装程序》，详细了解有关有必要进行此操作的情况。
要将更新应用于现有安装程序，可以使用TestStand部署工具创建仅包含已更新组件的补丁安装程序。有关创建补丁安装程序的更多信息，请查看《补丁部署》帮助主题。此外，还可以考虑创建多个安装程序来实现部署的模块化，例如，为测试代码、TestStand组件、驱动程序和Runtime引擎创建单独的安装程序。借助这种方法，您可以仅更新和分发有更改的安装程序。
由于安装程序会自动将文件放置在正确的位置，并且可以包含所需的驱动程序和Runtime引擎，因此创建了有效的安装程序后，即可轻松部署系统。但是，由于必须将基于安装程序的部署移动并安装到每台测试计算机上，因此它们通常最适合在少量测试计算机上使用的部署。
网络驱动器部署
借助网络驱动器部署架构，可以直接使用网络驱动器与测试站计算机共享文件，而无需整合到安装程序中。对网络驱动器上文件的访问可以通过源代码控制解决方案进行管理。借助这种方法，测试开发人员可以在共享存储库中创建和更新文件。完成测试后，这些文件会被复制到生产计算机上，或直接从网络位置即可使用。
您可以采用网络驱动器部署策略，使用共享存储库在开发、暂存和生产计算机之间共享文件
开发新的测试代码时，请务必确保开发使用的代码在经过测试和验证之前，从未在已部署的系统中使用。通常情况下，可以访问测试硬件的生产计算机被指定为暂存测试器，并用于验证和测试预发布测试系统。在暂存测试器上验证了测试系统后，即可将其部署到生产计算机上。
确保已部署的代码得到验证的最佳方法因需要将更新应用于测试站的频率而异。
对于需要频繁更新的情况，持续集成和交付(CI/CD)方法可以帮助确保最新的代码在测试计算机上可用，同时仍可确保代码已经过正确的测试和验证。借助CI/CD方法，您可以将构建、测试和部署测试代码更新的大部分过程自动化，从而尽可能减少开销。您可以使用第三方工具（例如Jenkins）来实现这种类型的自动化。
对于更严格控制的环境，验证要求通常非常严格，因此不可频繁进行测试系统更新。对于这些测试系统，可以定义一个单独的存储库或主干，让开发人员在其中进行更改并为测试添加新功能。测试系统的最新版本完成并经过验证后，开发人员会创建主干的版本分支，并在生产计算机上使用。该分支应锁定在源代码控制中，用于防止对已验证的代码进行任何更改。新分支完成并经过验证后，可以创建一个包含代码的新版本分支。
为了部署测试代码，生产计算机会获取版本化代码的副本，该副本应保持只读状态以确保其不被更改。为了进一步确保不对已验证的文件进行任何更改，可以将代码添加到测试序列中来验证所有文件的校验和。有关此方法的更多信息，请查看《TestStand系统检验和验证的最佳实践》文档。
借助网络驱动器部署来部署驱动程序和Runtime引擎
当使用基于网络驱动器的方法时，您需要使用单独的机制在测试计算机上安装必要的驱动程序和Runtime。可以通过以下机制来部署Runtime引擎和驱动程序：
- 构建包含所需软件的安装程序。TestStand部署工具可以生成一个包含Runtime引擎和驱动程序的安装程序。
- 基于已安装所有必需的驱动程序和Runtime的系统创建系统镜像。
最佳方法主要取决于系统更新的频率。在许多情况下，可以结合使用多种方法。以下常见场景对选择驱动程序和Runtime部署策略进行了说明：
- 对于更新频率不高的系统，创建镜像通常会实现正投资回报率。仍然可以对测试系统进行小更新，而无需更新镜像。
- 对于更新频率更高的系统，应使用所需的驱动程序和Runtime为测试系统创建安装程序。
访问测试系统文件的策略
对于网络驱动器部署，您可以使用以下其中一种常规方法来管理文件存储：
- 直接从网络驱动器访问文件。
- 使用第三方工具将文件从网络驱动器复制到本地，从而确保本地文件与驱动器同步。
直接从网络驱动器访问文件
直接从网络驱动器访问文件具有一定的优势，在网络驱动器上更新文件时，可以确保将更新应用于所有测试计算机。但是，直接从网络驱动器访问文件意味着测试站的操作将取决于共享驱动器和网络连接的可用性。如果其中一个不可用，生产操作人员将无法从测试站运行测试文件，这可能导致生产线停工。因此，应与IT部门合作以确保满足共享驱动器和网络的正常运行时间要求，这一点至关重要。例如，使用服务器冗余来满足共享驱动器的正常运行时间要求。
要使用共享驱动器存储TestStand配置文件和组件，必须使用TestStand环境功能，帮助您指定TestStand目录的位置。为此，您可以创建一个包含这些目录的网络驱动器位置的环境文件(tsenv)。有关如何创建和使用此文件的详细信息，请查看《TestStand环境》帮助主题。
将文件复制到本地各测试站
您还可以选择创建所有部署文件的本地副本，此方法具有以下优点：
- 测试站可以在没有永久网络连接的情况下执行测试。
- 可以减少测试系统文件的加载时间。
但这种方法增加了额外的工作量，需要将文件复制到所有测试站。在运行任何测试之前，还必须确保所有测试系统都有最新文件。
您可以构建其他工具，从而在每次启动测试站时自动比较测试站上与共享驱动器匹配的文件版本，并下载所有非最新文件。