TestStand开发系统的验证与确认

在讨论验证与确认的最佳实践之前，请务必先了解这些概念之间的区别以及它们如何应用于测试系统。

确认

在开发任何测试系统时，首先都需要了解和记录测试需求。要定义这些需求，应从待测设备(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建立在模块化的架构上，具备许多分离式组件，包括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设置的配置文件位于<TestStand Application Data>\Cfg目录中。对于其他设置，请参阅产品特定的说明信息，以获取有关设置文件位置的信息
监视、控制和存储测试系统文件的行业公认方法是源代码控制(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升级一样，提高执行速度可以缩短测试时间，提高吞吐量并带来更多收入。在这两种情况下，重新确认的成本都是决定因素，但是这样的投资成本也可以带来可观的回报，因此投入资金和精力势在必行。通常应一次完成多个软件升级，尽量减少软件的确认次数。

要在测试系统上维护一套一致的软件，请考虑从经过确认的系统上创建一个基础镜像，并在设置新的测试站时使用该镜像。但是，即使在使用镜像时，也必须确保不进行软件更新。对于NI软件，请确保将NI更新服务配置为从不自动安装更新。默认情况下，大多数计算机会自动执行Microsoft Updates。Sun、Apple和Adobe等其他公司也使用基于Web的自动更新。在任何需要完成V&V过程的系统上，必须禁用任何自动更改和升级。自动更新进行的更改通常不可预测，并且可能会对操作和设置产生未知的影响。 

IT部门可能会有控制公司内计算机的常规策略，包括使用病毒扫描软件、设置安全策略（如屏幕保护程序）以及根据需要安装补丁和升级。制造部门必须与IT部门合作进行管理，确保不对TestStand系统进行任何更改。务必确定哪些更改项会特别影响相关的计算机，但是您的需求可能会与IT策略冲突，例如需要删除病毒扫描程序、关闭屏幕保护程序以及不执行全公司范围的升级或修补安装。

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