测试管理软件开发指南

概览

目录

1. 处理模式理论
2. 软件部署
3. 并行测试
4. 利用NI TestStand实现高效的测试软件开发
5. NI相关产品和白皮书

测试一个被测单元（UUT）不仅仅是执行一组测试。通常来说，测试系统必须在执行完成测试顺序的前后进行一系列的操作。常见的操作包括识别UUT、通知操作人员状态（通过/失败）、记录结果、以及生成测试报告。这些操作定义了测试过程，而这组操作以及相应的执行过程则被称为一个处理模式。处理模式可以直接在您的执行引擎中实现或者成为您所进行测试的一部分。先前的结构限制了系统集成新功能的能力并且减少了稳定性。为了保持系统的模块性，这个处理模式应当与测试代码以及执行引擎分开执行。

处理模式类型
最为广泛使用的三种处理模式是顺序模式（Sequential Model）、批处理模式（Batch Model）、以及并行处理模式（Parallel model）。您可以使用顺序模式于某段时间内在一个UUT上运行测试序列。这种处理模式在测试系统仅有一套测试装置时最为有效，也就是说某段时间内只能够测试一个单元。批处理模式是为含有一套测试装置但有多个测试单元需进行测试的测试系统而设计的。例如，如果一个单元需要在一个温度箱内进行测试，那么这个测试装置将会包含多个需要同时开始和终止所有测试的单元。第三种处理模式与顺序模式类似，但更适合用于包含了多个独立测试装置的系统。这种模式将会使得每个测试装置尽可能多地测试单元，而无需考虑同一个系统内其它测试装置的测试速率。

回调
回调是指通常在处理模式之内执行的测试序列，但允许客户序列重写默认的操作方式从而增强您的系统模块性。当一个回调被重写覆盖后，并不是在调用处理模式序列之内调用代码，而是在客户序列中执行代码。这就允许为某个特定的测试序列实现一个独特的操作方式，而无需影响处理模式的其它部分。例如，对于某个特殊类型的UUT，您可能希望使用条码扫描器而不是手工序列号输入。模式回调的另一个例子是建立处理过程（Process Setup）和清空处理过程（Process Cleanup）序列。当测试一大批UUT时，它可能需要在某个时间初始化和清空一组仪器，而不是在每个UUT之前及之后进行初始化和清空操作。

执行入口点
处理模式中的执行入口点实现了可导致不同测试过程的各种执行模式。NI TestStand中默认的处理模式拥有两个入口点－测试UUT（Test UUTs）和单通道（Single Pass）。测试UUT这种执行入口点将会在一个不断识别并测试UUT的循环中执行，而单通道这种执行入口点则无需识别UUT即可测试某个单一的UUT。执行入口点可以配置成只允许特定的用户进行使用。例如，操作人员只允许运行测试UUT这个测试入口点，但技术人员则允许运行测试UUT和单通道这两种执行入口点。NI TestStand允许用户自定义处理模式从而创建他们自己的入口点来满足诸如调试之类的其它目的。由于在改变处理模式时能够减少重写的代码量，这种模块化的结构实现了难以置信的灵活性及稳定性。

配置入口点
配置入口点使得操作人员能够为处理模式设定不同的配置选择，例如配置报告选项（Configure Report Options）和配置数据库选项（Configure Database Options）。与处理模式的其它部分相同，配置入口点也是完全可自定义的。现有的入口点可以进行自定义以满足其它的选项，而且新配置的入口点则可以进行添加以实现不同的选项。配置入口点使得无需改变代码即可以多种不同的方式来配置测试平台。例如，某个测试平台可能用于诊断问题而可能不需要使用数据库记录。通过使用配置入口点，无需记录处理模式或使操作界面即可将这个测试平台配置成禁止使用数据库记录。

了解更多信息，请查看处理模式理论白皮书

测试系统开发人员在创建一个模块化测试系统时需要完成的众多任务之一就是将这个测试软件配置到生产平台。无论您是选择创建一个安装程序、还是使用网络服务器来分布您的测试软件、或者利用源代码控制包，您都希望能确保测试平台的完整性，同时希望能迅速运行以尽可能地实现无缝的升级过程，因而这就需要正确的软件部署策略。软件部署是在整个企业级网络或生产平台内管理和自动化软件包、测试、发布及安装软件文件和应用程序至测试系统的过程。

在您考虑将使用哪种方式来部署您的测试系统之前，您必须收集所有需要的文件并创建一个可配置的镜像来复制系统。一旦确定了构成您测试系统的文件之后，您就可以使用三种不同的方式来配置您的系统。通过使用文件复制方式，您可以手工复制文件至每个测试台。利用源代码控制系统，你可以决定将哪个版本的文件配置到系统。最后，您也可以创建一个易于使用的安装程序且只包含了您需要安装的任何驱动程序，而没有包含所有必需的文件。

系统复制
一个测试系统需要依赖于各种不同的文件和组件。当开始配置您的测试软件之时，所有这些组件必须能够识别和集中从而将开发系统复制到目标计算机中，而且需要创建一个配置镜像，这个镜像包含了将安装到目标计算机中的文件目录。创建这个配置映像的方式有两种，手动或使用工具自动收集您开发系统中的所有文件。

手动收集分布所需的全部文件是项冗长乏味的工作，但是却使得开发人员能够完全控制哪些文件需要配置到目标计算机中。开发人员在配置测试软件中所遇到的最常见问题是丢失或使用了错误的文件相关性。文件相关性是一个文件进行编译、载入、或正确运行所需的二级文件。通常来说相关性以DLL、,NET汇编程序或子VI的形式存在。极为重要的是，您需要准确地确定您的测试软件所需的相关性以及它们的版本。

复制您系统的另一种方式是使用工具来追踪应用程序中所有的文件并创建一个可部署的镜像。为了追踪您的测试系统文件，您需要使用工作区（workspace）或工程（project）文件在您的测试系统中定义文件。在理想情况下，开发环境既具有某些工作区的功能也拥有某种工具来创建一个可配置的映像。NI TestStand包含了一个称为NI TestStand Deployment Utility的工具，它通过使用NI TestStand Workspace能够自动生成测试系统的可配置的镜像。由于NI TestStand与LabVIEW的紧密集成性，它也可以确定VI间的任何相关性并且把它们包含入镜像中。

部署方式
既然已经创建好配置映像，那么下一步就是使用三种可能的方式将这个映像真正配置到您的测试机器中。您可以使用文件复制方式（File Copy Method）来配置您的测试系统，这种方式就是将所有文件直接从一台计算机复制到另一台。源代码控制方式（Source Code Control Method，即SCC）使用SCC软件来将不同版本的软件部署到生产机器中。最后，使用安装程序方式（Installer Method），即生成一个易于使用的且包含所有必需文件和驱动的安装程序，然后在生产平台上安装系统。

文件复制（File Copy）方式可以把部署映像直接复制和粘贴到测试平台的本地驱动器上，或者网络驱动器上。将配置映像复制到本地驱动器上使得测试平台具有“自主性（self-sufficient）”从而仅依赖于它本身。但是，使用这种方式的缺点在于把更新分布到所有独立的测试平台相当的浪费时间。把部署镜像复制到网络驱动器减少了分布时间并极大地利于更新测试软件。既然这种方式仅基于网络的，那么诸如网络状态（上行、下行）、访问网络组件的速度、以及访问正在使用的文件之类常见的网络问题就必须加以考虑。在部署到网络驱动器时所遇到的另一个问题是确定测试系统的终止是由于新的网络更新还是源于真正的测试失败。当测试软件开发人员向网络发送更新时，通常并不会发送通知，这样很难减少测试失败的出现。

使用源代码控制（SCC）系统来帮助您分布配置映像是十分有益的。在这种情况下，源代码控制服务器将维护一个配置映像的集中式主拷贝并使得客户端（测试平台）能够同步并使用该测试软件。即使在这种情况下SCC软件是基于网络的，配置映像的本地拷贝也会下载至每个客户端机器，从而解决了可能由于网络故障而导致的事件。为了使用SCC软件，您的确需要具备一些SCC的基本知识和经验。与复制和粘贴方式类似，这种方式也需要软件/硬件驱动的安装工作单独完成。

之前所述的配置方式是以一种更偏向于用户控制的配置方式为核心，开发人员完成了其中的大部分工作。但是，随着软件应用程序的复杂度不断增长，一种更为自动化的配置方式也许是更为可行的选择。安装程序允许您可以将安装程序集成至配置映像从而创建一个易于使用的且可使用任何简便的方式进行分布的安装程序包。安装程序所提供的其它好处是可将诸如硬件驱动、文档、许可证、以及配置文件之类的支持性软件与您的软件应用程序绑定至一个单一的软件包。除了包括支持性软件之外，安装程序也可以直接与Windows操作系统协作注册用户所创建的文件，并且可以使用Windows安装程序的更改/修复/卸载等特性。

安装程序确实带来了多种好处，但也带来了一些挑战，例如发布较小的更新以及可用性。将一些较小的更改配置到目标系统是十分困难的，因为这需要重新创建整个新安装程序包。您也必须考虑使用通用安装程序包所带来的可用性问题。大部分安装程序并不是用户友好的。

NI TestStand Deployment Utility减少了普通安装程序的常见问题。用于创建安装程序的易用图形化用户界面便于使用,且提供了灵活的可自定义工作环境来包含各种组件。您无需事先了解安装程序知识即可创建一个NI TestStand安装程序。利用这个配置工具您可以十分轻松地包含NI驱动程序和第三方驱动程序。

了解更多信息，请查看软件配置白皮书。

并行测试可同时测试多个产品或子组件。一个并行测试平台通常在多个测试座（test socket）中共享一套测试设备，但是在某些情况下它可能需要为每个被测单元（UUT）提供一套单独的硬件。大部分非并行测试系统只能在某个时间测试一个产品或子组件，从而使得昂贵的测试硬件在大部分测试时间内闲置。因此，利用并行测试，您无需花费大量的资金来复制并分散安装额外的测试系统就可以提高制造测试系统的吞吐量。并行测试可依据您所处的应用场合的需求采取不同的方式。另一方面，无论您选择何种方式，为了您的系统能够充分利用并行测试所带来的好处，寻找一种简单但功能强大的方式来共享仪器以及同步不同线程间执行是极为重要的。下面的部分将讨论您可在并行测试系统中所采用的不同方式以及如何实现仪器共享和线程同步。

常见的并行处理模式
当测试一个UUT的某个装配组件或功能时将会有很多任务需要在测试系统中完成。这些任务包括模式组合或特定系列的测试以及许多与测试UUT实际上毫无关系的过程。处理模式将系统级任务与特定UUT的测试分离开来，极大地减少开发投入并提高代码的重用性。处理模式所处理的一些任务包括追踪UUT识别号、初始化仪器、启动测试执行程序、收集测试结果、创建测试报告、以及记录测试结果至数据库。两种最为常见的处理模式是并行处理模式和批处理模式。

您可以使用并行处理模式来测试多个独立测试座。利用这种模式，您可以在任何时间开始和终止任何一个UUT上的测试。例如，您可能有五个测试座来完成无线电板卡测试。使用并行处理模式您可以在其它测试座测试其它板卡时将新的板卡放入一个未用的测试座。每个测试座一旦完成之前的单元测试序列后就可以测试新的UUT，从而减少了设备和仪器的空闲时间。

另外，您可以使用批处理模式来控制一套测试座来测试多个UUT。例如，您可能有一套隶属于同一个载体的电路板。批处理模式确保您可同时开始和完成所有板卡测试。批处理模式也提供了批处理的同步特性。例如，如果某个特定的步骤应用到整个批中，那么您可以将这个步骤定义为在每个批次中只运行一次。利用批处理模式，您也可以指定某些步骤或者一组步骤在某个时间内不能运行在多个UUT上或者某些步骤必须同时运行在所有UUT上。

NI TestStand提供了完整实现的并行处理模式和批处理模式。NI TestStand处理模式并不仅仅可以执行您系统中常见的执行流程。它们也包含了数据库记录和报告特性。处理模式的数据库记录特性使得您可以自动地将您的测试结果记录至多种不同的数据库，如Oracle、Microsoft SQL Server和MySQL。报告可生成XML、HTML、ASCII文本、以及ATML格式的测试序列报告。此外，这两种处理模式都是开放且可完全自定义。

仪器共享和同步
为了增强您测试系统的性能同时减少您的成本，为每个测试座提供一套专用仪器并不可行。而实现一个并行的测试系统通常并不需要任何额外的硬件投资。利用并行测试，您可以在多个测试座中共享测试系统中现有的仪器设备。减少一个UUT测试周期中的空闲时间即可显著提升性能，且无需额外的硬件成本。在许多情况下，您可以添加其它成本低廉的仪器以进一步优化系统的总体性能，同时在测试座间共享更为昂贵的硬件。

为不同的测试座间共享仪器的关键是开关。开关允许您路由信号，从而帮助您在不同时间将多个测量源连接至单个仪器输入。您的系统可能含有诸如控制被测试设备（device under test，即DUT）供电的通用继电器之类的简单装置，也可能含有用于连接数以千计测试点至数十个仪器的复杂矩阵开关配置。由于控制所有这些信号路由的复杂性，因此就需要一个功能强大的软件来控制您的开关平台。NI Switch Executive是一款智能的开关管理和路由应用程序。利用Switch Executive，您可以通过交互式配置和命名开关模块、外部连接器和信号路由获得更高的开发效率。在Switch Executive中开发的开关配置可以利用测试步骤的开关属性来应用NI TestStand。通过将开关代码从您的测试代码中分离开来，您可以增强可维护性并能重用开关配置。

在没有现成的测试管理软件之前，通过编程运行并行测试系统的多个测试座间分配，共享仪器需要加入大量的底层同步代码到测试程序中。临界区（Critical section）和互斥（mutexe）常常会与真正的代码混淆，从而使得在将来的测试系统中难以进行编程或重用代码。

通过实现使用了NI TestStand的众多内置特性的并行测试系统，您可以毫不费力地控制仪器共享并同步多个被测设备。您可以在单个测试层中使用同步步骤类型（synchronization step types）和可配置的测试属性（configurable test properties）来管理序列测试间的资源共享。测试序列中所使用的同步步骤类型通常包括锁、会合、队列、通知器、等待、和批同步步骤类型。

了解更多信息，请查看并行测试白皮书。

企业级系统连接
除了这些标准的测试执行功能之外，您也希望您的测试软件框架能包括企业级系统连接功能。企业级系统和解决方案的特性、功能和优点能保持您的测试系统集成至一个更大的，在整个业务中所用的工具和应用程序的网络中。无论您集成的是源代码控制工具还是数据管理系统，在集成多个软件解决方案时都会存在挑战。在您的框架中所包含的连接应当是基于工业级标准的工具和协议并且能够简化企业级系统集成。通常集成至一个测试软件框架的企业级系统包括应用于配置管理、需求管理、数据管理、以及沟通结果等方面的工具。

管理配置
对于软件来说，实现管理配置包括将您的测试软件连接至源代码控制（SCC）工具、管理软件配置和升级过程。软件配置管理与源代码控制或版本控制是相同的。因此，管理您的软件配置的一个重要方面就是控制哪种软件版本安装在测试平台上。目前有许多源代码、或版本控制软件的提供商。微软已经为源代码控制定义了一个标准的应用程序接口（API）。

作为管理您的软件配置的一部分，您可以规划您的软件配置策略。无论您是选择创建一个安装程序还是使用网络服务器或手工复制文件来分布测试软件，您都希望确保测试平台的完整性，而且与此同时能够迅速运行以尽可能地实现无缝的升级过程。

作为管理软件配置的一部分，您可以规划软件配置策略。无论您是选择创建安装程序还是使用网络服务器或手工复制文件来发布您的测试软件，您都希望确保测试平台的稳定性，而且与此同时能够迅速运行以尽可能地实现无缝部署。

对于在已配置的测试平台上升级软件也是需要考虑的问题。无论您是升级已开发的软件还是升级现有的商业（commercial off-the-shelf，即COTS）工具，您所选择的升级方式都可能需要基于新特性的使用或者漏洞的修复。在这两种情况下，您都可以规划和准备这些升级过程以减少升级过程中的停工时间。使用模块化组件可以减少升级所带来的影响，而且保证了升级后的后向兼容性。在购买COTS工具时需要使用软件维护措施。

需求管理
一个项目中所定义的规范或要求包含技术和程序上的需求，都贯穿于项目开发的每个阶段。项目中的参与者和流程都遵循需求，它们可能用于计划和购买决策、向客户报告开发进度、指导软件开发、或者确保最终产品的完成或项目成功。需求管理以追踪不同详细程度的需求间关系以及实施和测试需求间的关系为核心。追踪从需求到测试测量、和控制软件间的关系对于验证实施、分析需求改变时的影响、以及了解测试失败原因是十分关键的。为了达到这种追踪效果，您需要将您的测试软件框架连接至用于撰写或管理您需求的工具。NI Requirements Gateway是一个将您的开发和验证文档与文档和数据库中存储的正式需求相连接的需求追踪解决方案。一旦连接建立，您就可以快速地响应您的需求或代码改变。

数据管理
测试系统中的数据管理不仅仅包括记录测试结果。尽管结果收集是其中的一个基本组成部分，但参数的访问和数据分析功能也是需要考虑的重要特性。如果数据库用于存储测试相关的信息，那么连接到数据库的技术应该明智地选取。用于您测试框架的数据库连接将给您提供动态读写数据至数据库的方式。另一方面，数据的管理并不需要和数据库系统的管理同步。结果可以记录入数据库，但您可能更希望将结果记录入文件。使用数据库还是使用文件各有优缺点。使用数据库中的数据需要具备SQL或DBMS经验。然而，利用数据库记录和读取速度您可以获得接近于实时的报告和警告。文件I/O也有其自身的一些挑战，例如性能、格式、和安全性。记录至文件的一大优势就是记录文件自身所固有的按时间顺序排列特性及持久性。

良好的数据库集成当然会包含数据记录，但是它也提供将测试参数（如边界）从所选数据中载入的功能。利用动态载入参数的功能，如果仅仅是参数值不同，则您的测试序列可以轻松地为多个产品模型所重用。根据您的需求和实施情况，您可能选择将参数保存在文件中而不是数据库中，此时您只需要处理文件I/O，而无需使用您的数据库集成。

沟通结果
虽然数据管理涵盖了测试结果的获取和存储，但是仍然需要考虑如何将这个信息通知测试系统的用户。可以使用不同的方式来实现通信。测试系统可以直接在测试时直接与用户沟通。测试执行程序的用户界面是与测试人员沟通的首要渠道。这是一种十分有效的沟通方式，因为它负责运行测试而且在测试结果生成时能够访问测试结果。

我们可能也希望在测试序列执行之后通过提交测试报告来反映测试结果。测试报告可以使用诸如ASCII文本、HTML和XML等格式生成。报告格式的选取取决于报告的特性及它的目标受众。ASCII报告在众多平台上都兼容，但并不能提供更多的格式，另一方面，XML格式可以包含非常灵活的格式功能但可能需要一个XSL兼容的网络浏览器来查看报告。

了解更多信息，请查看企业级系统连接白皮书

NI TestStand实现了一个模块化的测试系统架构。NI TestStand是一个可直接与几乎任何应用程序开发环境（ADE）所撰写的代码模块相交互的管理工具。NI TestStand与ADE之间的关系表明了模块化测试系统是如何实现的。

最初，NI TestStand只是扮演了测试自动化控制器的角色。所有的测试系统操作都是由各个步骤组成的自动化测试序列。这些步骤执行了序列化的操作或者调用代码模块。每个代码模块完成了由测量采集或非测试相关I/O所构成的任务。非测试相关I/O包含了并不直接与特定UUT完整性相关联的任务，例如读取条形码扫描器以获得UUT条形码。NI TestStand能够调用在多种ADE中所开发的代码模块。每个步骤直接通过NI TestStand的模块适配器来调用代码模块。这些适配器处理与特定模块类型间的通信，如LabVIEW VI、C/C++ DLL、ActiveX自动化服务器以及.NET汇编程序。

此外，NI TestStand通过区分UUT测试序列和处理模式序列将UUT的特定测试操作从系统级操作中分离出来。处理模式序列完成所有的非UUT特定的操作，包括结果追踪、报告生成、数据库记录、以及并行执行。一个处理模式也控制着UUT特定测试操作的执行，从而实现了循环的UUT测试和并发的UUT测试执行。

应用程序开发环境主要用于开发在NI TestStand中执行的代码模块。代码模块执行的任务包括测量I/O、高级数据处理、以及测试特定的对话（test specific dialogs）。模块化测试系统的最终目标就是尽可能少的开发和维护代码。为此，尤为注重开发高度模块化和可重用的代码模块。本文列举的指导准则为实现一个模块化测试系统提供了一些说明。

ADE的另一个任务是为配置的NI TestStand系统开发瘦客户（thin client）操作界面。操作界面提供了一个可在测试平台上执行的可配置的测试应用程序。这个应用程序充当为任何测试人员执行测试的接口。操作界面由开放的NI TestStand API和用户界面组件来创建，每个都通过一套ActiveX自动化服务器来显现。NI TestStand操作界面可以在任何兼容ActiveX功能的ADE中进行开发。

了解更多信息，请查看利用NI TestStand实现高效的测试软件开发指南白皮书