TestStand 类型管理最佳实践【10】
概览
TestStand?数据?类型?和?步骤?类型?（统称?为“TestStand?类型”）?让?您?可以?定义?可?复?用?的?数据?结构?和?步骤。?这些?类型?可?用于?维护?整个?测试?系统?多个?位置?所用?组?件?组成?的?中心?节点。?尽管?TestStand?类型?有助?于?测试?系统?的?开发，?但?由于?其?具有?共享?性?和?模?块?化?特性，?因此?需要?遵循?类型?管理?实践，?从而?避免?计划?外?的?类型?版本?传递。?本文?档?介绍?了?类型?的?原理，?并?提出?了?类型?管理?的?最佳?实践。
内容
- TestStand?类型?的?类别
- 在?类型?选?板?文件?或?序列?文件?中?存储?类型
- 管理?共享?类型?的?更改
- 类型?冲突
- 管理?类型?冲突?解决?功能
- 自?定义?内?置?数据?类型
- 查阅?TestStand?高级?架构?系列?的?其他?章节
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?将?自动?解决?这些?冲突。 以下?是?访问?该?设置?的?方式：
- 在?序列?编辑?器?中，?选择“配置”(Configure) ?“工作站?选项”(Station Options)
- 选择“文件”(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?会?将?来自?类型?选?板?文件?的?类型?与?序列?文件?保存在
自?定义?内?置?数据?类型
自?定义?内?置?数据?类型?（包括?标准?数据?类型?和?过程?模型?数据?类型）?时，?开发?者?应?保持?谨慎。 许多?内?置?类型?（例如?CommonResults）?广泛?应用?于?其他?TestStand?步骤?类型?或?数据?类型，?从而?增加?了?不必要?类型?传递?的?可能性。
自?定义?标准?数据?类型?的?注意?事项
如果?要?创建?作为?第三?方?产品?分发?或者?在?多个?组织?中?使用?的?序列?文件?或?类型?选?板?文件，?则?不得?自?定义?内?置?类型。?已?修改?内?置?类型?的?文件?只能?用于?了解?类型?更改?的?单?个?组织?内部。 在?分发?您?的?序列?文件?或?类型?选?板?后，?如果?这些?类型?的?其他?组织?版本?加?载?到了?您?的?文件?中，?那么?这些?组织?将?继续?使用?您?的?类型?自?定义?项，?否则?便?会?遇到?冲突。
由于?对?内?置?类型?的?更改?会对?相关?测试?站?产生?重大?影响，?因此?需要?指派?了解?组织?测试?架构?的?核心?开发?人员?或?架构?师?批准?更改，?以便?减少?类型?管理?问题。
自?定义?过程?模型?数据?类型?的?注意?事项
TestStand?过程?模型?和?插入?序列?使用?多种?数据?类型?来?定义?过程?模型?数据?结构。 例如，?待?测?设备?数据?类型?包含?序列?号、?产品?编号?和?测试?插?槽?索引?等?数据。 尽管?可以?对?这些?类型?进行?自?定义，?但?仅?应?在?必要?时?进行?这种?操作。 过程?模型?类型?仅?在?序列?文件?中?定义，?不?包含?中央?类型?选?板。 基于?默认?的?自动?冲突?解决?设置，?TestStand?可以?自动?更新?这些?类型，?因此?对于?这些?类型?来说，?不必要?的?类型?传递?更?容易?发生。
如需?向?待?测?设备?或?NI_StationInfo?数据?类型?添加?附加?数据，?AdditionalData?属性?（该?类型?中?定义?的?非?结构?化?容器）?可?用于?在?运行?时?向?该?类型?的?实例?添加?附加?数据。 关于?这?一?方法?的?详细?信息，?请?参阅《在?过程?模型?中?存储?待?测?设备?和?测试?站?的?附加?信息》?帮助?主题。