TestStand类型管理最佳实践

TestStand使用不同类别的类型来存储信息并定义步骤行为。 数据类型用于在测试系统开发和执行期间存储信息，步骤类型用于定义步骤的行为以及相应步骤在执行过程中收集的结果。 数据类型和步骤类型既可以是TestStand随附的内置组件，也可以是用户开发的自定义类型。

TestStand类型分为步骤类型、自定义数据类型和标准数据类型

数据类型

在许多情况下，需要定义复杂的数据结构才能管理测试数据。 数据类型可用于中心节点管理相关数据结构。 数据类型定义了TestStand属性或变量的结构，例如序列文件全局变量、序列局部变量和步骤属性。 所有数据类型都具有以下组成部分：

• 类型名称：用于类型的唯一标识。 TestStand无法在内存中加载多个名称相同的类型。
• 版本：用于管理类型的修订情况并解决类型冲突。
• 数据：在类型中定义的属性结构
• 默认值：在类型窗格中定义的属性值，充当相应类型实例的默认值。

通常，数据类型可用于定义一组相关的复杂数据，这些数据可能包含多个不同的属性和容器。 例如，错误数据类型可能包含三个属性：类型中的布尔属性可以指定是否发生错误，字符串值属性包含错误消息，而整数属性可以定义错误代码。

在管理复杂数据时，应始终使用数据类型，因为在修改数据类型结构时，数据类型的所有实例都会更新，以反映新的数据类型结构。 这可以实现在中心节点管理数据结构。 

标准数据类型

标准数据类型是TestStand附带的一组特定数据类型，定义了用于存储错误、路径或波形等常见数据类型的标准格式。 大多数标准数据类型都无法修改。尽管某些标准数据类型可以修改，但由于这些类型广泛用于其他TestStand组件，因此仅应在必要时进行修改。 

步骤类型

正如可以根据自定义数据类型创建变量或属性，也可以根据步骤类型创建步骤。 每个步骤类型均包含唯一名称、内置和自定义步骤类型属性，以及属性和步骤类型操作的默认值。 所有步骤类型共享一组通用属性，这些属性定义了所有步骤的基本操作和数据。 “步骤类型属性”对话框可用于编辑这些通用属性。

本文档重点介绍适用于所有类型的概念，包括步骤和数据类型。 关于步骤类型最佳实践的具体信息，请参阅《自定义步骤类型开发的最佳实践》一文。

创建新类型时，需要考虑存储类型的磁盘位置。TestStand可以将类型存储在序列文件或类型选板文件中。 在大多数情况下，创建的所有类型都应存储在类型选板文件中。使用类型选板具有以下优势：

• 类型选板文件提供了一个中心节点，以便将类型存储在多个序列文件中。
• 经过配置后，类型选板文件可以在启动TestStand时加载到内存中，确保类型可用于新的序列文件。
• 如果多个开发者对存储在多个位置的类型进行更改，可能会发生冲突，因此为类型提供单一中心节点有助于避免类型冲突。
• 默认状态下，TestStand不会自动更新类型选板中的任何类型，这种保护能力可以防止不必要的类型传递。

如果序列文件中所用的类型来自类型选板文件，则类型副本将存储在相应文件中，即使不提供类型选板文件，也依然有效。但是，只能使用类型选板中的版本对类型进行更改。 部署测试序列时，无需在部署中添加类型选板文件。 不过，添加类型选板文件将使测试系统的增量更新变得更轻松。 如果特定类型需要更新，则可以创建和部署类型选板文件的新版本，而无需对序列文件进行更改。

在多个开发者之间共享类型时，需要确保每个开发者都使用相同的、最新版本的类型定义。此外，由于合并更改难度较大，因而必须确保开发者不会对同一类型进行单独更改。 以下技术可用于有效管理共享类型：

• 定义类型选板文件的所有者
• 对类型选板进行源代码控制

定义选板文件的所有权

为了控制类型更改，需要为每种类型确定明确的所有者，负责实施或批准类型更改。 在大型组织中，通常会将类型所有权分配给组中的不同个人。 为了简化这一方法，可创建单独的类型选板文件，将类型划分为逻辑组，例如，可将特定于项目的类型存储在包含项目名称的类型选板中，并将用于多个项目的常规类型保存在共享类型选板文件中。 然后，可确定每个类型选板文件的所有者。

将类型选板文件划分为逻辑组后，便可以更轻松地为每个类型选板文件分配类型所有者

源代码控制可用于限制类型选板文件更改

要进一步控制对类型版本的更改，可借助源代码控制解决方案来确保只有在检出文件后才能编辑文件。 源代码控制权限可用于确保只有特定类型选板文件的所有者才可以签入更改。 至少，类型选板所有者应启用文件通知，以便了解与相应文件有关的活动。

尽管用户仍然可以在本地计算机上修改类型，但是使用源代码控制可以防止TestStand将这些更改保存到磁盘或共享文件中。 

预防不相关类型之间的冲突

如果多个不相关的类型在无意中具有相同的名称，那么就可能出现类型冲突。由于类型名称是系统中的唯一标识符，因此在开发新类型时，应提前为类型名称确定唯一的组织ID。 例如，TestStand随附的所有步骤类型名称均以前缀“NI”开头。 这样可以确保在各组之间共享代码时，您的类型不会与在组织外部创建的类型冲突。

TestStand每次只加载一个具有特定名称的类型版本，从而确保测试站上加载的所有文件均使用相同的类型信息。 如果尝试打开的序列文件或尝试加载的类型选板所包含的类型名称与已加载的文件或选板相同，则会发生类型冲突，TestStand必须确定是继续加载当前类型还是将其替换为新类型。 

如果尝试加载的文件所包含的类型定义与当前TestStand中加载的类型定义不同，则会发生类型冲突。 此时必须先解决冲突，然后才能加载新文件

如果开发者做到了谨慎维护唯一的类型名称，并在单个受控类型选板文件中维护类型，那么TestStand就能够正确处理类型冲突。 但是，由于自动类型冲突解决规则或开发者的错误决定，类型冲突可能导致文件更改错误，进而可能导致不必要的类型版本传递。 

不必要的类型版本传递

不必要的类型传递是指解决类型冲突时对包含不同类型版本的文件进行了不必要的更改。共享文件的类型错误时，其他开发者可能会在不知情的情况下加载错误版本的类型。 随着文件在更多开发者之间共享，新类型将会传递到许多文件，要想找到类型不正确的全部文件，更是困难重重。
解决在以下情况下发生的冲突时，可能会出现上述情况：

• 在TestStand早期版本中加载类型，类型与版本不兼容
• 创建多个具有相同名称的不相关类型
• 多个开发者同时对类型进行更改

本部分中的技巧可用于尽量减少错误处理类型冲突的情况，并预防不必要的类型版本传递。

维护类型版本字段

TestStand类型借助版本字段来确定类型的最新版本。 如果内存中加载了类型的最新版本，而您加载了使用旧版本的序列文件，则TestStand可以根据测试站设置自动更新相应文件，使用类型的新版本。 默认状态下，TestStand会自动解决所有不更新类型选板文件中的类型的冲突。

为了帮助确保类型版本已更新，TestStand会使用“已修改”类型标签跟踪经过编辑的类型。 在保存已启用该标签的类型时，TestStand会显示警告，表示类型已更改。 

对类型进行修改时，TestStand会在保存类型之前发出警告，确保更改的合理性。

在这种情况下，应选择增加类型版本，确保所做的更改可以传递到其他文件，而这些文件在TestStand中加载时会引用该类型。 但是，不应在保存设置时选择不提示的选项，因为该警告是防止不必要的类型更改的有用工具。 如果对更改不确定，那么可以取消对话框，这将取消保存操作，此时可以检查类型并确保更改有效。

配置自动类型冲突解决功能

在某些情况下，如果出现类型冲突，TestStand可以自动确定应加载的类型。 只有在满足以下条件时，才能自动解决类型冲突：

• 两种类型的类型版本不同
• 两种类型均未设置“已修改”标签。

TestStand提供了“启用自动类型冲突解决功能”(Allow Automatic Type Conflict Resolution)设置，您可以自行确定何时TestStand将自动解决这些冲突。 以下是访问该设置的方式：

1. 在序列编辑器中，选择“配置”(Configure) »“工作站选项”(Station Options)
2. 选择“文件”(File)选项卡

TestStand可用于配置何时自动处理类型冲突，以及何时提示开发者选择要保留在内存中的类型版本。

在大多数情况下，应使用该设置的默认值，即只提示类型选板是否需要修改。 基于这种设置，只要较低版本的类型未存储在类型选板文件中，TestStand将自动选择较高版本的类型。 该设置有助于确保仅在可能出现不必要的类型传递时提示类型冲突。 它还可以确保自动解决无害冲突，例如，在新版本TestStand中加载具有较旧NI类型的旧序列文件，而无需用户做出决定。

举例来说，开发者A更新了步骤类型“RunCalibration”，这是一个存储在公司类型选板文件Company_types.ini中的类型。 与类型选板文件所有者讨论之后，开发者A将该更改保存到了类型，然后选择将类型版本增加为1.0.1.0。 然后，开发者A将更新后的类型选板保存在源代码控制存储库中。 另一个开发者B随后同步到了该存储库，获取了类型更新后的Company_types.ini版本。 然后，开发者B打开TestStand，并加载了引用该类型的序列文件。 由于序列文件仍引用以前的类型版本，因此序列文件中的引用会自动更新，这是符合计划的。

但是，第三个开发者C也拥有使用“RunCalibration”步骤的序列文件，他们无意中对“RunCalibration”步骤类型进行了单独更改，而未联系类型所有者，并将其本地实例更新为版本1.1.0.0。 如果开发者C同步公司类型选板文件，然后将其序列文件加载到TestStand中，则TestStand将提示他们解决类型冲突，因为如果使用较新版本，类型将被修改。 开发者C将得知类型选板文件在之前便已更新，于是将联系类型选板所有者，或还原对类型所做的本地更改。

如果TestStand无法自动解决类型冲突，系统将提示您决定如何解决冲突：

“文件中的类型冲突”(Type Conflict In File)对话框可用于解决无法自动解决的类型冲突

要解决类型冲突，可以选择加载两种类型中的一种、重命名其中一种类型，或取消打开文件。 选择要使用的版本时，TestStand会转换内存中的所有实例，以便匹配所选类型。如果重命名其中一种类型，则TestStand会修改内存中的实例以引用已加载的类型，并修改新文件中的实例以引用文件中的类型。

调整特定于类型的冲突解决设置

在严格受控的环境中，您可能会倾向于选择始终提示用户解决冲突选项，在任何情况下都禁用自动类型冲突解决功能。在所有检测到类型冲突的情况下，系统都将提示用户解决冲突，从而有助于完全控制要加载的类型。 但是，这会增加开发过程中的决策，可能导致开发者做出错误决策并快速关闭可能遇到的诸多对话框。 

接下来介绍一种更好的方法，那就是对需要严格控制的类型使用特定于类型的设置。 在“类型”(Type)设置的“版本”(Version)选项卡中，可以指定是否自动解决类型冲突。 该设置可用于防止低风险类型冲突带来不必要的用户交互，例如在新版本TestStand中加载具有较旧NI类型的旧序列文件，同时仍然能够全面掌控需要严格控制的自定义类型。

为需要更严格控制的特定类型禁用自动类型冲突解决功能

避免不必要的类型版本传递到TestStand的早期版本

虽然可将序列文件保存到TestStand的早期版本，但是某些类型可能无法在TestStand的早期版本上正确运行，这种情况下可以指定可运行某种类型的TestStand最早版本。在“类型属性”(Type Properties)对话框的“版本”(Version)选项卡上启用“设置可以使用该类型的TestStand最早版本”(Set Earliest TestStand Version that can Use this Type)选项，并将最早版本设置为TestStand的当前版本。这将防止类型的当前版本用于或意外传递到TestStand的早期版本。

如果需要在TestStand的早期版本中使用某种类型，则应创建该类型的不同版本，以便于在TestStand的不同版本中运行。保存TestStand早期版本的序列时，TestStand会搜索一系列兼容性目录，查找与为其保存序列文件的早期版本兼容的类型版本。TestStand会将来自类型选板文件的类型与序列文件保存在<TestStand Public>\Components\Compatibility\<version number>和<TestStand Public>\Components\Compatibility\<version number>目录中。可将来自TestStand早期版本的类型选板文件放置在<TestStand Public>\Components\Compatibility\<version number>目录中，从而确保TestStand将正确的类型版本与序列文件保存在一起。

自定义内置数据类型（包括标准数据类型和过程模型数据类型）时，开发者应保持谨慎。 许多内置类型（例如CommonResults）广泛应用于其他TestStand步骤类型或数据类型，从而增加了不必要类型传递的可能性。

自定义标准数据类型的注意事项

如果要创建作为第三方产品分发或者在多个组织中使用的序列文件或类型选板文件，则不得自定义内置类型。已修改内置类型的文件只能用于了解类型更改的单个组织内部。 在分发您的序列文件或类型选板后，如果这些类型的其他组织版本加载到了您的文件中，那么这些组织将继续使用您的类型自定义项，否则便会遇到冲突。 

由于对内置类型的更改会对相关测试站产生重大影响，因此需要指派了解组织测试架构的核心开发人员或架构师批准更改，以便减少类型管理问题。

自定义过程模型数据类型的注意事项

TestStand过程模型和插入序列使用多种数据类型来定义过程模型数据结构。 例如，待测设备数据类型包含序列号、产品编号和测试插槽索引等数据。 尽管可以对这些类型进行自定义，但仅应在必要时进行这种操作。 过程模型类型仅在序列文件中定义，不包含中央类型选板。 基于默认的自动冲突解决设置，TestStand可以自动更新这些类型，因此对于这些类型来说，不必要的类型传递更容易发生。
如需向待测设备或NI_StationInfo数据类型添加附加数据，AdditionalData属性（该类型中定义的非结构化容器）可用于在运行时向该类型的实例添加附加数据。 关于这一方法的详细信息，请参阅《在过程模型中存储待测设备和测试站的附加信息》帮助主题。

单击查看TestStand高级架构系列中的其他文档，其中涵盖NI TestStand高级开发人员感兴趣的主题。