TestStand 开发系统的验证与确认【7】
概览
产品?测试?一直?以来?都?面临?着?一个?挑战，?即?确保?测试?系统?设计?的?正确?性?且?能够?继续?正常?运行。?开发?测试?系统?时，?工程?师?会?创建?测试?程序?并?设置?测量?限?值，?以便?正确?检测?有?缺陷?的?产品。?确定?测试?方法?后，?必须?先?对?测试?系统?本身?进行?测试，?确认?软件?和?硬件?能够?正确?执行?任务。?执行?验证?与?确认?(V&V)?过程，?可?顺利?确保?测试?系统?得到?正确?开发?并?达成?其?预期?用途。?V&V?主要?影响?受?ISO?或?FDA?规程?约束?的?企业，?例如?制造?药品、?医疗?设备?或?汽车?和?航空?用品?的?企业。?由于?此类?产品?对?健康?和?安全?至?关?重要，?因此?这些?行业?受到?正式?监管，?包括?完成?明确?的?V&V?过程。?一些?公司?出于?降低?成本?或?竞争?目的，?自愿?执行?正规?V&V?过程。?如果?公司?的?竞争?力?取决?于?质量?或?可靠性，?那么?为?正规?V&V?过程?投资?势必?会?带来?回报。
?NI TestStand?软件?通过?提供?具备?明确?定义?的?组?件?的?模?块?化?架构，?满足?测试?系统?的?各种?需求，?从而?帮助?工程?师?开发?有效?的?测试?系统。?TestStand?组?件?的?这种?分离?有助?于?V&V?工作?的?开展，?因为?每?个?组?件?的?需求?可?单独?进行?定义。
?本文?档?讨论?了?适用?于?通过?TestStand?开发?的?测试?系统?的?V&V。?本文?档?涵?盖?以下?主题：
?? 定义?适用?于?TestStand?的?验证、?确认?和?影响?分析?的?概念。
?? 探讨?TestStand?的?组?件?及其?如何?帮助?简化?V&V?工作。
?? 介绍?V&V?的?通用?最佳?实践。
内容
- 确认、?验证?和?影响?分析
- 记录?和?收集?需求
- 利用?TestStand?应对?V&V?挑战
- 确认?测试?系统?更新
确认、?验证?和?影响?分析
在?讨论?验证?与?确认?的?最佳?实践?之前，?请?务必?先?了解?这些?概念?之间?的?区别?以及?它们?如何?应用?于?测试?系统。
确认
在?开发?任何?测试?系统?时，?首先?都?需要?了解?和?记录?测试?需求。?要?定义?这些?需求，?应?从?待?测?设备?(UUT)?的?规范?入手，?并?编制?测试?需求，?确保?检测?出?待?测?设备?中的?所有?缺陷。?在?开发?过程?的?这?一?阶段，?至?关?重要?的是?要?确保?测试?需求?全面?体现出?待?测?设备?的?所有?故障?情况。“确认”是?指?确保?测试?系统?能够?实现?原定?用途?的?过程。
确认是?评估?系统?是否?真正?实现?其?目的?或?用途?的?过程。
整个?测试?开发?过程?都?必须?进行?确认，?但?首先?应当?从?需求?收集?阶段?开始，?因为?在?项目?生命?周期?的?早期，?任何?缺陷?都?更?容易?得到?解决。?确认?可能?包括?正规?的?通过/?失败?测试?程序，?也?可能是?与?客户、?用户?或?患者?一起?进行?的?主观?可用性?研究?形式。?确认?通常?涉及?一些?主观?需求，?例如“拒绝?有?缺陷?的?产品”或“界面?简单?易?用”。?在?可能?的?情况?下，?您?应该?定义?更?详细?的?较?低?级别?需求，?充分?体现?这些?主观?陈述，?从而?确保?所有?参与?方?就?目标?达成?一致。
验证
详细?的?测试?需求?编制?完成后，?测试?开发?人员?就?可以?设计?和?实现?满足?这些?需求?的?测试?系统。?完成后，?工程?师?必须?确保?测试?系统?满足?所有?定义?的?需求。“验证”是?指?确保?测试?系统?正确?满足?特定?需求?的?过程。
验证是?用于?确定?测试?系统?是否?根据?设计、?图纸、?工作?说明?书?或?其他?类似?准则?中?规定?的?规范?而?构?建?的?过程。
验证?测试?应?在?产品?开发?的?几个?重要?阶段?进行。?既?可以?在?整个?系统?上?整体?进行，?也可以?在?测试?系统?的?较?小组?件?上?进行。
为了?说明?验证?与?确认?之间?的?区别，?我们?假设?测试?部门?构?建?了?一个?简单?的?测试?装置，?用于?测量?待?测?设备?(UUT)?的?电流?消耗。?测试?系统?必须?将?待?测?设备?电源?引?脚?的?电流?测量?值?与?要求?待?测?设备?电流?消耗?少?于?500mA?的?测试?限?值?进行?比较。?为了?解决?这个?问题，?测试?开发?人员?定义?了?一个?需求：“待?测?设备?全?功率?运行?时?电流?不得?超过?500 mA”。?然后，?开发?人员?使用?规定?的?硬件，?设计?和?实现?一个?测试?装置?来?进行?这项?测量，?并?创建?一个?测试?用例?来?检查?提供?全?功率?后?待?测?设备?的?电流。
为了?进行?测试?系统?的?验证，?开发?人员?需要?验证?系统?是否?以?可?接受?的?重复?性?正确?进行?了?测量，?且?在?功率?超过?500 mA?时?出现?故障。?如果?测试?系统?的?行为?符合?需求，?则?验证?通过。
但是，?制造?过程?中?存在?一个?故障?模式 — 反向?安装?的?二极管?可能?会?导致?电路?的?某些?部分?无法?激活，?从而?导致?150 mA?的?过?低?电流?消耗。?由于?测试?系统?仅?测试?了?最大限?值，?因此?未?将?这些?问题?报告?为?故障，?而?故障?设备?可能?会?被?正常?交付。?尽管?已?根据?规范?正确?构?建?了?测试?系统，?但?该?系统?未?达到?既定?目的，?因此?无法?通过?确认。?必须?将?规范?和?测试?系统?修改?为?包含?一个?测量?上限?值?和?一个?测量?下限?值，?例如?400-500 mA。
如果?根据?正确?编制?的?规范、?工程?图?或?工作?说明?书?进行?系统?验证，?则?相对?容易?一些，?且?测试?方法?非常?简单，?能够?轻松?发现?缺陷，?但?正如?上述?示例?所?示，?确认?工作?可能?更?具?挑战?性。
影响?分析
测试?系统?完成?确认?与?验证?并?投入?使用?后，?可能?需要?对?系统?进行?更改?或?更新。?这些?更新?可能是?出于?维护、?维修?或者?试图?改善?或?纠正?系统?性能?的?目的，?例如?更换?故障?的?仪器?或者?修改?算法?或?设置。?对?系统?进行?更改?时，?请?务必?了解?测试?系统?的?哪些?部分?必须?经过?重新?确认，?才能?确保?这些?更改?不会?导致?缺陷，?而?这?一?过程?称为“影响?分析”。
影响?分析是?确定?哪些?测试?系统?组?件?受到?一系列?所?做?更改?影响?的?过程。
进行?详细?的?影响?分析?非常?重要，?因为?更改?可能?导致?系统?异常?运行?且?不易?被?发现，?并?可能?导致?产品?召回、?生产?停工?或?对?业务?的?其他?干扰。?更改?还?可能?导致?系统?在?正常?运行?的?情况?下?影响?结果?或?测试?结果，?并?导致?对?受?试?产品?做出?错误?决定。?如果?某些?更改?未?被?注意到?或?确认?存在?错误，?可能?需要?付出?巨大?代价。?在?某些?行业?中，?如果?发?运?有?缺陷?的?产品，?可能?最终?会?导致?产品?召回。?FDA?保留?采取?监管?措施?的?权利。
为了?减轻?更改?对?系统?的?影响，?请?务必?以?模?块?化?方式?设计?测试?系统，?这样，?对?某?个?组?件?的?更改?才不会?影响?其他?组?件。?为此，?必须?确保?每?个?组?件?与?其他?组?件?完全?分离，?并?采用?独立?的?确认?程序。?例如，?可以?引入?硬件?抽象?层?(HAL)。?硬件?抽象?层?提供?了一?组?与?硬件?交互?的?标准?函数。?HAL?定义?的?函数?可以?独立?于?测试?系统?的?其他?部分?进行?确认。?如果?用户?进行?硬件?更改，?影响?将?仅?限于?HAL?层，?因为?用户?可以?在?更改?后?验证?HAL?函数?是否?具有?相同?的?行为。
确认?与?验证?行业?标准
许多?行业?都有?明确?定义?的?V&V?指导?原则，?而且?这些?原则?都是?依照?各类?规范?（例如?《生产?质量?管理?规范》?(GMP)）?或?法规?（例如?ISO-9000、?FDA?的?21 CFR?或?IEEE?标准）?制定?而?成。?每?个?V&V?系统?都很?类似，?只是?使用?略有?不同?的?术语?来?解释?这?两?个?过程?的?通用?需求，?但?通常?不会?定义?具体?的?需求。?本文?档?探讨?了?自动?化?测试?系统?的?V&V?过程。
FDA 21 CFR?中?与?医疗?器械?相关?的?确认?需求?含糊不清，?包括?规定?医疗?器械?必须?经过?确认?符合?用户?需求?和?预期?用途?的?表述?也是?一样，?因此?质量?系统?经理?必须?定义?需求?并?监督?确认?测试。?对于?测试?系统，?定义?确认?测试?的?方法?可以?很简单，?例如，?跟踪?已知?故障?模式?和?提供?优?劣?产品?样本?有助?于?确保?系统?检测?到?已知?缺陷。?另?一种?方法?则?可能是?使用?值得?信赖?的?人工?测试?程序，?也?可能是?纳入?另?一个?自动?化?系统?来?确认?新?测试?系统?的?结果。
某些?确认?实例?必须?格外?周密，?例如?关于?航空、?制药?和?医疗?设备?行业?的?确认，?因为?确认?过程?涉及?安全?性、?质量?或?成本?的?极端?情况。?周密?的?系统?确认?可能?需要?数?周?或?数?月?才能?定义?并?执行。?例如，?如果?测试?系统?使用?16x32?配置?的?开关?矩阵，?则?测试?工程?师?可以?使用?连续?性?测试?系统?来?测试?每?种?可能?的?连接?组合，?并?确保?绝?无?受限?连接。?再?例如，?确认?通信?系统，?此?系统?中?每?个?可能?的?命令?和?命令?序列?都?必须?经过?测试?和?确认。?尽管?这种?确认?过程?看似?极端，?但?我们?必须?确保?系统?在?任何?情况?下?不会?导致?损坏、?伤害?或?错误?结果。
记录?和?收集?需求
V&V?过程?以?明确?定义?的?规范?为?中心。?确认?也?可能?会?遇到?一些?客观?问题，?例如?市场?或?最终?用户?定义?的?宽?泛?需求。?对于?任何?测试?系统，?最?重要?的?第?一步?都是?研究?并?记录?良好?的?工作?规范?和?V&V?需求。?如果?规范?不够?具体、?留有?解释?空间?或?模棱?两?可，?则?很?难?确保?测试?系统?的?完整性。?如果?审核?员?或?观察?员?发现?没有?记录?或?实施?不?正确?的?情况，?可以?停止?测试。?要?轻松?完成?V&V?过程，?必须?认真?执行?经过?精心?编制?的?规范。
验证?过程?需要?一份?或?多?份?设计?文?档?或?图纸?来?控制?系统?必须?达成?的?效果。 文?档?和?图纸?可能?涉及?一个?组?件、?装置?或?整个?系统。?验证?的?规范?和?测试?方法?必须?是?详尽?的?文?档，?其中?应?提供?尽可能?多?的?信息，?以便?能够?创建?正确?的?测试?系统。
确保?记录?规范?的?任何?变更，?无论?这类?变更?是?客户?或?工程?师?提出?的，?还是?在?学习?和?了解?过程?中?发现?的。?采用?工程?变更?通知?单?流程?记录?变更?和?原因，?正式?记录?变更。?只有?在?将?说明、?设置?和?测试?限?值?与?正确?的?文?档?相?匹配?时，?验证?才能?通过。
设计?确认?测试?通常?比较?主观，?它?更像?是?一?门?艺术?而?非?一?门?科学，?尽管?智慧?和?经验?似乎是?确认?设计?的?唯一?工具，?但?请?记住，?收集?需求?也能?揭露?问题?且?非常?有用。?具体?的?方法?包括?审查?其他?测试?装置?或?产品?的?过往?性能、?访问?操作?员?及其?主管，?以及?研究?过去?的?测量?数据。?如果?一家?公司?通常?将?测试?外?包给?测试?系统?集成?商，?则?应?针对?每?个?项目?进行?详细?审查，?找出?能?让?未来?项目?更加?成功?的?方法，?并?将?这些?方法?运用?到?下?一个?项目。
利用?TestStand?应对?V&V?挑战
TestStand?建立?在?模?块?化?的?架构?上，?具备?许多?分离?式?组?件，?包括?TestStand?引擎、?过程?模型、?测试?代码?和?用户?界面。?这种?架构?可以?更?轻松?地?独立?分析?每?个?组?件，?对于?V&V?工作?很有?帮助。?此外，?由于?影响?通常?仅?限于?单?个?组?件，?因此?如果?对?现有?测试?系统?进行?了?更改，?只需?少量?的?重新?确认?工作。
TestStand?的?模?块?化?架构?允许?单独?验证?和?确认?每?个?组?件，?并?减少?更改?对?整个?测试?系统?的?影响。
在?设计?测试?系统?时，?务必?考虑?到?验证?与?确认，?并?思考?如何?构?建?能?简化?相关?工作?的?系统。?以下?几节?提供?了?在?考虑?V&V?的?情况?下?设计?测试?系统?组?件?的?最佳?实践。
设计?序列?文件
在?开发?测试?序列?时，?请?牢记?以下?目标：
- 利用?功能?逻辑?块?的?子?序列?来?实现?功能?的?组?件?化。
- 减少?步骤?之间?的?交互，?从而?减轻?单?个?步骤?更改?对?测试?系统?的?影响。
关注?这些?目标?能?更好?地?跟踪?需求?在?测试?代码?中?是?如何?满足?的，?并?能?减少?单?个?步骤?更改?导致?的?影响。
使用?单独?的?步骤?与?步骤?设置
在?定义?步骤?的?某?项?条件?时，?请?考虑?该?条件?是否?会?应用?于?多个?步骤。?在?TestStand?环境?中?使用“If/?Else”或“Case”步骤?来?实现?逻辑?更?为?直观、?可?扩展?且?可?修改，?从而?运行?不同?的?选项，?并?按照?条件?添加?多个?步骤。?但是，?它们?引入?了?测试?步骤?和?流?控制?之间?的?关系。?对于?始终?会?应用?于?单?个?步骤?的?逻辑，?可?使用?前提?条件，?从而?将?逻辑?和?步骤?添加?到?单?个?组?件?中。
在?测试?代码?中?实施?切换?时，?请?使用?类似?的?方法。?针对?应用?于?单?个?测试?的?路线，?可?使用?步骤?切换?设置，?从而?通过?测试?代码?来?实现?测试?功能?的?组?件?化。?对于?影响?多个?步骤?的?切换，?在?序列?中?使用?切换?步骤?更?为?直观，?还?能?让?该?序列?更?具?可读?性。
使用?子?序列?实现?模?块化
要?将?内?置?步骤?设置?的?组?件?化?优势?与?使用?单独?步骤?的?可?扩展?性?相?结合，?可以?创建?子?序列?来?封?装?相关?的?步骤?集。?通过?在?单独?的?序列?文件?中?包含?此类?序列?的?集合，?可以?有效?地?创建?一个?序列?文件，?该?序列?文件?是?一个?函数?库，?可以?独立?进行?确认?并?在?多个?测试?应用?程序?之间?共享。
此外，?测试?序列?应当?几乎?完全?由“序列?调?用”步骤?组成，?每?个?步骤?都?对?测试?进行?逻辑?分组。?子?序列?的?组织?应?映射?到?测试?规范，?其中?较?高级?别的?需求?（例如“系统?应?测试?设备?的?音?频?功能”）?应?映射?到?测试?中的?序列，?而?较?低?级别?的?支持?需求?（例如“最大?音量?不得?超过?80 dB”）?应?映射?到?序列?中的?步骤。
减少?多个?步骤?之间?的?依赖?关系
当?步骤?需要?使用?上?一步?中?获得?的?数据?时，?也可以?引入?步骤?之间?的?依赖?关系。?避免?使用?PreviousStep?属性?直接?访问?另一?步骤?中的?数据，?而?应?使用?局部?变量?来?存储?第?一步?中的?数据，?然后?在?后?续?步骤?中?使用?该?变量。
还?应?确保?在?执行?测试?之前，?每?个?步骤?都?独立?设置?或?验证?是否?设置?了?所需?条件。?例如，?如果“音?频?音量?测试”步骤?包括?了“低”、“中”和“高”音量?的?音量?测试，?而?随后?的?步骤?会?执行?必须?在“中”音量?下?进行?的?音?频?质量?测试，?那么?在?执行?之前，?应?确保?将?音量?设置?为“中”。?这样?可以?确保?两?个?测试?均?独立?进行：?对?音?频?音量?测试?进行?更改?不会?影响?音?频?质量?测试。
记录?测试?序列
要?充分?满足?规范?中的?所有?需求，?最?重要?的是?清晰?地?记录?序列?文件。?但?应?避免?记录?重复?信息，?例如?限?值?或?测试?参数。
步骤?名称?和?描述?可?用于?记录?步骤?的?用途。?步骤?名称?应?描述?该?步骤?执行?的?操作?以及?执行?该?操作?的?原因，?但?不?应?包含?该?步骤?中?定义?的?参数?值。?例如，?不要?将?步骤?命名?为“等待”(Wait)，?而?应?命名?为“等待?系统?重?启”(Wait for system to boot)。?如果?名称?需要?更多?信息，?请?使用?步骤?的?Description?属性?来?指定?其他?详细?信息。
将?TestStand?与?NI Requirements Gateway?集成?在一起，?也可以?有效?跟踪?实际?测试?代码?中?需?满足?需求?的?情况。?借助?NI Requirements Gateway，?可以?快速?查看?满足?了?哪些?需求，?并?能?导航?至?满足?该?需求?的?步骤，?从而?加快?验证?过程。
NI Requirements Gateway?可在?需求?文?档、?测试?序列?和?测试?报告?之间?创建?关联，?确保?满足?所有?需求
借助?可?用于?步骤、?序列?和?序列?文件?的“Requirements”字?段，?可?提供?所?满足?需求?的?相关?信息。?结合?使用?NI Requirements Gateway?与?这些?字?段，?可在?需求?文?档?和?测试?代码?之间?创建?映射，?从而?快速?了解?满足?需求?的?情况。
“Requirements”字?段?可?用于?将?步骤、?序列?或?序列?文件?映射?到?规范?文?档?中的?具体?需求
有关?将?NI Requirements Gateway?与?TestStand?结合?使用?以?跟踪?需求?的?更多?信息，?请?参见《结合?使用?NI Requirements Gateway?与?NI TestStand》?教程。
开发?独立?的?代码?模块
TestStand?步骤?会?调?用?代码?模?块，?以便?与?仪器?和?自动?化?硬件?进行?通信。?代码?模?块?可以?用?多种?语言?实现，?包括?LabVIEW、?C?+?+或?C#。?由于?TestStand?在?步骤?和?代码?模?块?之间?提供?了?自然?边界，?因此?有利?于?编写?可?独立?于?TestStand?序列?进行?测试?和?确认?的?代码?模?块。
为了?确保?能?在?测试?序列?之外?测试?代码?模?块，?请?避免?使用?SequenceContext?或?其他?TestStand?引用?直接?访问?数据，?而?应当?通过?参数?将?数据?传递?到?代码?模?块?中。?对于?需要?使用?SequenceContext?的?情况?（例如?实现?终止?监视?器），?应?设计?代码?模?块，?使?其?无?需?TestStand?专用?代码?即可?运行。?在?LabVIEW?代码?模?块?中，“非?引用”函数?可?用于?在?使用?SequenceContext?之前?检查?其?是否?有效。
使用?独立?的?可?执行?代码?模?块，?可?设计?能够?循环?代码?模?块?并?传递?所有?输入?参数?置换?的?测试?装置。?然后，?测试?装置?可以?将?结果?与?已知?正确?结果?进行?比较，?从而?确认?代码?模?块?的?行为?是否?符合?预期。
使用?插?件?更改?过程?模型
TestStand?过程?模型?会?处理?并非?特定?于?待?测?单元?的?测试?功能，?包括?待?测?设备?跟踪、?报表?生成、?数据?库?记录，?以及?批量?测试?或?并行?测试。?TestStand?附带?的?过程?模型?很?复杂，?因此?对?这些?模型?进行?更改?需要?大量?的?确认?工作。
过程?模型?使用?插?件?架构，?该?架构?可?实现?默认?的?报表?生成?和?数据?库?记录?功能。?此?架构?可?用于?扩展?现有?过程?模型?的?功能，?而无?需?更改?过程?模型?序列?文件?本身。?为此，?应?创建?一个?自?定义?插?件，?在?单独?的?插?件?序列?文件?中?实现。?此?插?件?的?行为?可?单独?确认。
过程?模型?插?件?是?独立?于?过程?模型?文件?的?组?件，?可以?单独?进行?确认
如果?需要?直接?在?过程?模型?中?更改?功能?（例如?更改?模型?收集?待?测?设备?序列?号?的?方式），?请?考虑?禁用?过程?模型?中?实现?当前?功能?的?步骤，?然后?创建?一个?单独?的?插?件?来?实现?新?功能。?通过?使用?这种?方法，?未来?对?自?定义?行为?所?做的?更改?可以?仅?限于?插?件，?这样?将?更易?于?重新?确认。
如需?了解?更多?关于?如何?自?定义?过程?模型?和?插?件?的?信息，?请?参阅《NI TestStand?过程?模型?开发?和?自?定义?的?最佳?实践》?文?档。
管理?测试?设置?和?配置
在?开发?测试?系统?时，?请?务必?确保?所有?TestStand?设置?在?执行?测试?的?所有?工作站?上?都?相同，?并且?在?未经?相应?更改?确认?的?情况?下?未?做?修改。?但是，?由于?许多?TestStand?组?件?具有?单独?的?设置，?因此?很?难?确保?不存在?任何?更改。?除了?TestStand?设置?外，?还?必须?确保?多个?测试?系统?的?仪器?设置?一致。?仪器?设置?可以?包括?在?NI Measurement & Automation Explorer (MAX)?中?进行?的?NI-?DAQmx?设置，?或?设备?的?GPIB?和?COM?设置。?此类?设置?数?不胜?数，?因此?确认?测试?很?难?设计。
确保?设置?正确?的?方法?之一?是在?测试?序列?中?以?编?程?方式?进行?设置，?然后?查询?每?个?设置?以?确保?仪器?或?程序?接受?该?设置。?如果?无法?查询?设置，?请?找到?设置?的?存储?位置，?然后?从?文本、?INI?或?XML?文件?读?取?设置。?系统?可以?验证?并?记录?TestStand?外部?项目?的?状态，?并?使?其?处于?受?控?状态。
使用?源?代码?控制?工具?管理?文件
管理?设置?的?另?一种?方法?是?严格?控制?包含?设置?的?文件。?存储?所有?TestStand?设置?的?配置?文件?位于
监视、?控制?和?存储?测试?系统?文件?的?行业?公认?方法?是?源?代码?控制?(SCC)?程序，?例如?Subversion、?Perforce?和?Microsoft Visual Source Safe。?许多?此类?程序?的?设计?初衷?都是?为了?符合?Microsoft SCC?界面，?并且?用户?可以?在?TestStand?或?LabVIEW?中?使用?这些?程序。?在?某些?情况?下，?如果?无法?获得?临时?所?有权?并?记录?以?保存?变更，?则?用户?无法?修改?文件。?这些?程序?通常?能?告知?哪些?文件?已?更改，?并?会?分析?旧?文件?和?新?文件?以?突出?显示?更改，?从而?帮助?简化?验证。
文件?校?验?和?也?可?用于?确保?设置?文件?的?已?确认?状态?未?改变。?要?使用?这种?方法，?可以?添加?相应?的?步骤，?将校?验?和?与?为?确认?文件?值?计算?的?校?验?和?进行?比较，?如果?两者?不?匹配?则会?生成?测试?故障。
确认?测试?系统?更新
除了?测试?系统?之外，?请?务必?确保?支持?测试?的?所有?硬件?和?软件?都?处于?已知?且?已?确认?的?状态。?本?节?介绍?了?维护?系统?状态?的?方法，?以及?在?必要?时?应用?更改?的?方法。
管理?硬件?配置
必须?为?系统?以及?每?个?单独?的?测试?正确?选择、?安装、?编?程?和?配置?仪器。?例如，?数字?万?用?表?(DMM)?或?示波器?包含?几?种?用于?进行?正确?通信?和?信号?采集?的?配置?选项，?这些?选项?必须?在?测试?系统?完成?时?进行?验证?和?确认，?并?在?未来?用于?硬件?更改。
创建?硬件?抽象?层?(HAL)?来?管理?硬件?交互，?这?有助?于?减少?对?测试?系统?中的?硬件?进行?更改?时?所需?的?重新?确认?工作。?与?测试?序列?中?采用?设备?特定?的?代码?模?块?不同，?抽象?层?可?将?测量?类型?和?仪器?特定?的?驱动?程序?从?测试?序列?中?分离?出来。?由于?测试?程序?通常?是?根据?仪器?类型?（如?电源、?数字?万?用?表?[DMM]、?模拟?输出?和?继电器）?而不是?具体?的?仪器?进行?定义，?因此?使用?抽象?层?有助?于?开发?更?容易?适应?新?仪器?和?需求?的?测试?序列。?HAL?就绪?后，?用户?可以?确认?新?硬件，?只需?确保?HAL?函数?在?一?组?测试?用例?中?产生?与?之前?硬件?相同?的?输出?即可，?而无?需?全面?测试?整个?测试?系统。?有关?使用?HAL?的?更多?详细?信息，?请?参阅《测试?系统?构?建?基础?知识：?硬件?和?测量?抽象层》。
在?运行?时?确认?硬件?也是?一个?好主意。?通过?在?运行?时?读?取?和?存储?设置?或?其他?因素，?可?确保?所有?必须?与?软件?一起?确认?的?项目?已?按?预期?配置?和?运行。?例如，?TestStand?步骤?可能?会?查询?仪器?的?校准?日期，?确保?校准?是?最新?的，?还?会?验证?连接?到?COM?端?口?的?仪器?型号?和?序列?号，?确保?仪器?未?被?更换。?在?设计?测试?序列?甚至?购买?仪器?时?牢记?这些?考量?因素，?这?有助?于?简化?V&V?过程。
如果?更改?硬件?不可避免，?则?必须?考虑?V&V?过程?中的?更改。?如果?一台?仪器?出现?故障，?然后?插入?另一?台?相同?品牌?和?型号?的?仪器，?请?思考?必须?完成?哪些?工作?才能?确认?这?台?仪器?运行?正常，?并?设计?测试?来?确保?更改?成功。?使用?可?互换?虚拟?仪器?(IVI)?驱动?程序?和?接口?进行?仪器?设置，?有助?于?简化?两?台?同?品牌?或?同?型号?仪器?的?转换，?或?两?台?不同?品牌?或?不同?型号?仪器?之间?的?转换。
管理?软件?配置
维护?测试?系统?时，?需要?考虑?升级?LabVIEW、?TestStand?或?任何?其他?程序，?以便?能够?使用?各种?新?功能。?进行?此类?软件?升级?通常?需要?重新?确认?和?重新?验证。?将?可能?的?升级?视为?投资?回报?(ROI)?的?一种?尝试。?例如，?要?获得?简化?的?开发?界面，?则?应?在?开发?过程?中?而不是?在?系统?部署?后?进行?升级。?但是，?与?最近?的?TestStand?升级?一样，?提高?执行?速度?可以?缩短?测试?时间，?提高?吞吐量?并?带来?更多?收入。?在?这?两?种?情况?下，?重新?确认?的?成本?都是?决定?因素，?但是?这样?的?投资?成本?也可以?带来?可观?的?回报，?因此?投入?资金?和?精力?势在必行。?通常?应?一次?完成?多个?软件?升级，?尽量?减少?软件?的?确认?次数。
要?在?测试?系统?上?维护?一套?一致?的?软件，?请?考虑?从?经过?确认?的?系统?上?创建?一个?基础?镜?像，?并?在?设置?新的?测试?站?时?使用?该?镜?像。?但是，?即使?在?使用?镜?像?时，?也?必须?确保?不?进行?软件?更新。?对于?National Instruments?软件，?请?确保?将?NI?更新?服务?配置?为?从不?自动?安装?更新。?默认?情况?下，?大?多数?计算?机会?自动?执行?Microsoft Updates。?Sun、?Apple?和?Adobe?等?其他?公司?也?使用?基于?Web?的?自动?更新。?在?任何?需要?完成?V&V?过程?的?系统?上，?必须?禁用?任何?自动?更改?和?升级。?自动?更新?进行?的?更改?通常?不可?预测，?并且?可能?会对?操作?和?设置?产生?未知?的?影响。
IT?部门?可能?会?有?控制?公司?内?计算?机?的?常规?策略，?包括?使用?病毒?扫描?软件、?设置?安全?策略?（如?屏幕?保护?程序）?以及?根据?需要?安装?补丁?和?升级。?制造?部门?必须?与?IT?部门?合作?进行?管理，?确保?不对?TestStand?系统?进行?任何?更改。?务必?确定?哪些?更改?项?会?特别?影响?相关?的?计算?机，?但是?您?的?需求?可能?会?与?IT?策略?冲突，?例如?需要?删除?病毒?扫描?程序、?关闭?屏幕?保护?程序?以及?不?执行?全?公司?范围?的?升级?或?修补?安装。
本文转自：https://www.ni.com/content/ni/locales/zh-cn/support/documentation/supplemental/08/verification-and-validation-with-teststand.html