会用LabVIEW，却没有听说TestStand，好像有点说不过去吧！（上）--粉丝服务平台-粉丝头条-fensifuwu.com

会用LabVIEW，却没有听说TestStand，好像有点说不过去吧！（上）

科技 06-27 来源：知乎李时珍

“ 有小伙伴在后台让大叔推荐一下TestStand的学习资源，其实我接触TestStand也很晚，在这里只是分享一下我所掌握的一下资讯内容，内容有点长，分为上下两篇，大家可以共同提高！”

我接触和使用LabVIEW比较早，2001年从LabVIEW 6i 版本开始上手摸着石头过河式开发，断断续续，分分合合与LabVIEW的开发缘分倒也一致都在！

在2017年左右，正好有个客户项目需要使用TestStand来完成，这再正式开始接触和使用TestSand，关于TestStand的分享将分为两篇文章进行，本篇是上篇，主要是宏观角度讲解一下我对TestStand的认知，也是我知乎的《LabVIEW面向对象编程_初窥门径》系列编程文章的第6篇内容。关于其它的系列文章可以到我的知乎专栏上去查看。

特别警示：文章非常的冗长和啰嗦，如果只对TestStand感兴趣可只看第3部分内容。

—

关于框架的你要先了解的一些事

“编程工作从大体上来分，你不是在开发自己的框架中，就是在别人的框架下进行着开发。”

在测量测控以及计量检测长期开发过程中，随着开发被测类型种类的增多，开发范围的扩展，你就会发现：除了使用到的LabVIEW编程语言提供的编程结构，字符串，界面提示框等基础库函数外,在不同的业务类型的测试测控中都会有重复的代码段，并且重复的主要表现形式有两种，一种是低层的明显可以识别出的显式共用基础功能代码段，另外一种是隐式且较为抽象的高层算法策略。

为了消除重复冗余，显式低层的共用基础功能代码段可以封装为功能函数子Vi，并且进一步按较大的功能模块分组形成打包库（lvlib）结构或者是基础功能类，也即基础性框架（Framework），而隐式高层算法策略要着眼于“关注点分离”的概念，按照分层、分块的思想切分成不同逻辑单元，应用不同的面向过程和面向对象编程范型形成可以复用的高层逻辑框架，不管是高层模块还是底层支持代码都提供了的贯穿于多种相似的应用程序的能力，即表现出一致性，这都是框架代码的体现形式。

这一篇文章主要是讲述Framework框架的概念、层次划分、测量测控主流软件框架应用、调用框架的展示，以及如何开发自己的类库和我们自己以往的相关开发经验，由于内容较多故分解成为上下两个部分。

首先，让我们先从框架（Framework）的基本概念、三层分类以及设计三特性开始学习，“Framework”在英文字典中的意思是骨架、框架，而在软件工程领域中，“Framework指的是一组同时具备一致性、可重用性、可扩展性三准则的类库。

框架（Framework）提供了一种构建软件系统所必需的复用基本架构及功能，协助软件开发者快速开发应用程序，并且能够显著降低出错率，明显提升开发效率，能够提供显著的规模经济效益，自从有了框架，开发人员就无须从头开始编写应用程序。

框架 (Framework)会提供大部分部件，这些部件经过开发人员的定制和拼装，快速实现设计；但是，框架（特别是领域专属框架）也相应的用规定套路固限住了开发人员的思维，强制大家遵循规定的规范来开发应用程序。

一般按照从下到上的层次理论来划分框架（Framework），最下层为基石层是基础框架（Base Framework ）,中间层是程序框架（Application Framework）,高层是领域框架（Domain Framework）。

基础框架（Base Framework ）是为了提供撰写程序软件所需要的基本功能，例如Win32 API 、.NET Framework的基础编程语言库（BCL）、或者LabVIEW中的基础函数库（目录、文件操作、字符串、基本函数等等），基础框架的最为显著的特点是简单性及全面性，简单是指结构简单，可能就只是一组功能函数或者是一些稍加包装的类，并且程序员要用这些基础功能模块组合成程序时相当的耗时费力；全面性是指功能覆盖的层面是相当的广泛的，从基础的文本处理到网络传输等等，程序员可以使用基础框架编写不同领域的应用程序，因此具备高度的灵活性和弹性，缺点是不够便捷及有效率，基础框架通常扮演者一个应用程序的基础角色。

程序框架（Application Framework）基础框架（BF）提供了撰写应用程序的所需要的基础功能函数，但是效率不高，便捷性较差，而程序框架（AF）是构架在基础框架之上（BF），提供快速开发所需要的半成品功能，从而方便程序员提升开发效率，典型的程序框架（AF）就是顶顶有名的MFC框架，许多人都知道MFC框架将200多行的Windows桌面程序魔法般的缩减至只需20行，而.NET Framework Window Forms框架又将它进一步改良成只需要动动鼠标就可以完成的魔法。当然高效率带来的约束就是要按照程序框架（AF）的规范套路来编写程序，另外领域也就受到相应的限制，并且不能完全自由的组合基础框架（BF）完成横跨多领域的应用软件，在LabVIEW的编程语境中，比较典型的程序框架（AF）就是适用于多线程开发测控程序开发的操作者框架（Actor Framework）,并且该框架应用了诸多LVOOP的编程技术。

领域框架（Domain Framework）是为行业领域特殊定制的专属框架，限制条件更多，提供的功能模块相比与应用框架（AF）更加的具体实用，使得程序员开发软件速度无与伦比，另外不但速度提升了，需要开发代码也大幅减少，代码质量和稳定性也相应的有了一定的保证，在计量测试行业最典型的领域框架莫过于Fluke公司的Met/Cal软件平台了，在国外的校准软件市场上等同于事实上的工业标准，除了Fluke公司本身开发Met/Cal测试型号序列程序外，还有大量的第三方校准公司为其提供定制化的测试序列程序。当然，高效率的提升是牺牲软件的广泛性，提供特殊专属功能所带来的。并且开发一款一致性、可重用性和便于扩展的领域框架是一项耗时费力的编码工程，并且还要不断的重构提炼，设计抽象才能越来越精确，这往往是中小型项目难以维系开发出领域框架的重要原因。

在了解了框架的三个层次分类后，让我们再进一步学习一下框架设计的三个设计准则：一致性、可重用性、可扩展性；一致性是指框架代码在被应用时不受外界协作通信代码的影响而始终如一的提供设计之初的功能，一致性体现在接口服务的一致性，用户界面的一致性，代码使用场景的一致性等等具体方面上；而可重用性则是程序代码从重复的片段到逐渐封装成功能函数，进而根据职责内聚封装为模组（类库）的程序进化的最大内驱力。

从另外一个角度考虑也是代码经济学的最重要的体现，可重用性可以体现为代码重用，也可以提供为概念重用，在面向对象编程范型中，更加强调的是概念重用，是面向对象设计原则中依赖反转的核心思想；框架可扩展性是提供灵活、适用的代码结构所必需具备的能力，也是可重用性的重要技术保障手段，常常通过插件结构提供扩展能力。

—

自己的“玩具”框架

上面主要是概念性的框架分类介绍，下面结合我们自己的编程经历，讲讲对框架（Framework）开发认知过程：记得我们刚刚开始接触LabVIEW编程时，那时候的版本还是6i，毫无软件工程和程序框架（Program Framework）的任何的概念，只是心急火燎的想把手头的重复体力工作通过编程映射、转换为可以自动测试的应用程序，最开始从LabVIEW系统自带的硬件设备驱动和编程范例样程直接改造，以适应我们的测试具体要求.

因为是自产自销的开发模式，所以那时候根本就不明白啥叫用户界面，如何发布应用程序，就在开发编辑环境下边修改边直接运行，所有的数据采集完成后就通过一个第三方基于（ActiveX）的Excel工具函数包写入到定制好的Excel被测设备标准模板当中去，Excel电子表格文件即是我们的运行时界面，即呈现数据采集过程，又是最终测试完成后数据保存的文档载体，程序主框图代码虽然也是按照被测项目的项目封装要求具体分解成独立子VI调用函数，但是调用过程却是直接写死在顺序帧结构节点中，有时候测试项目需要定制，就通过与项目一一对应布尔判断来选择，各个子程序Vi中到处都是Crtl+C/V的重复代码片段，杂乱无序的高底层逻辑代码混叠交织在一起，维护和修改代码痛苦不堪，虽然程序代码逻辑现在回想起来，简直是惨不忍睹，不堪入目，就更不要提什么封装性、复用性、一致性、可扩展性等等这些阳春白雪的软件工程名词了，但是由于是自己开发自己改，所以的的确确是能用，就像一辆二十年的老旧拖拉机也比人跑的快，因此也就实打实的提高了我们的工作效率。

后来，我们使用LabVIEW 8.2版本提供的项目管理的能力结合自己慢慢认知到的初级的软件工程概念，使用NI公司提供的报告生成器（RGT）及数据库连接工具包（DCT）软件后，开始着手花费很大的精力、资源对原先的代码进行了全面的重构梳理，封装共用函数到功能模组中形成可重用的工具驱动包，按照关注点分离、功能分组的逻辑结构将共用的功能提取出来分层处理，引入人机操作使用界面和测试过程与证书报告分离的流程切分，特别是使用动态调用功能完成对测试项目的灵活调用,详细的框架情况请参考我知乎的介绍文章。

随着分解功能的越清晰，代码的复用性也就越来越来强，在不断的迭代开发过程中，编程人员的能力也就越来越高，组织结构也演变成核心与基础库代码编程人员和应用参数领域编程人员两组开发者团队共同协作，使用服务接口共同开发编程，从而上层调用逻辑层次代码逐渐演变成为具备我们自己行业（电学、无线电参数）领域特点的专属领域框架(Application Framework)。

该框架(Application Framework)将诸如操作用户界面、被测件配置、标准设备配置、测试项目选择及项目动态调用、报告生成等共用逻辑功能提升到高层操作框架中以便达到复用，具体的被测项目待调用VI则可以动态进行扩展，初步形成了框架设计的基本准则：一致性、可重用性、可扩展性。

首先一致性体现在所有的参数被测设备程序都使用相同的人机操作界面，完成配置、测试、报告生成的统一测控流程，错误处理及提示也都统一一致，降低了使用者测学习认知时间，提高了开发者的开发效率，只需要开发自己的底层调用测试序列就可与上层框架无缝整合成可实用的程序。由于开发过程是演化而成的，测试上层框架保持了最适应的可重用性，并通过动态调用的函数功能模板保证其可扩展性，具体的被测项目测试子VI只要符合公共函数接口模板即可完成可插拔式的插件结构（Plug-in）扩展。

当然，使用框架开发效率的提升也必然带了相应的约束性，如必须遵循一套相对固定的开发、发布的流程，并且只能完成单一被测的测试，不能同时提供多台套的并行测试任务服务，框架没有提供的多文档格式的支持功能就无法输出文本格式到特定的文档载体。当然很多情况是由于开发框架的人员认知、需求范围、开发能力、时间精力等诸多条件受限制，导致的框架提供哪些功能，不提供哪些服务。

在其后来在工作和学习过程中，接触到了测控行业的成熟商业级别的框架TestStand，对比分析了一下，发现我们不知不觉中使用LabVIEW实现了一个符合我们对自动校准测试程序认知的、最小化TestStand的功能子集，又重复地生产了一个“破车轮子”，但是由于我们的存量代码较多且工程师们已熟练掌握了现有的代码开发模式路程，因此目前并没有大规模的移植到TestSand平台上开发。下一步准备部分试验开发应用TestStand框架平台软件的开发我们的计量校准软件。当然研究成熟的商用调用框架非常有助于我们开发自己调用框架，或者完全放弃自己重复制造破车轮代码，直接基于成熟的商用调用框架进行开发。

要想理解成熟的商用调用框架，我们首先先将视野从计量检定校准的自动化测试向上扩展至通用自动化测试系统的大概念上来讨论，这样才能更好的理解框架在其中起到的关键作用。因为从大的范畴上来讲，计量检定校准的自动化测试是属于自动测试的一种特殊类别而已，其特殊点就是其它自动化测试系统中标准的测量设备成为了计量检定/校准中的被测件（Device Under Test），并由此带来的测试指标性能要求更高和需要最高性能的计量标准设备支持。

一般来说，自动化测试任务是由“自动化测试系统”来实施，自动化测试系统通过减少人工干预，显著提升了测试速度，并且测试结果的一致性得到良好的保障，伴随着现代工业的迅猛发展。工业制造业的产线和计量服务单位的自动化程度越来越高，工业机器臂更为广泛的替代人工操作，机器视觉和运动流程控制广泛的应用于各类类型测试当中去。

一个完整的自动化测试系统由测试站、仪器设备、测控软件这三个部分总成。

而往往测试软件是自动化测试系统中最灵活、最为核心的部分，在着手搭建自动化测试系统的过程中，需要确定测试站的详细配置、仪器设备的选型，UUT的测试规格书和需求文档则基本上定义了对仪器设备的性能要求，重点要考虑的问题就是软件的设计，而从设计功能上考虑，测控软件最少需要包含以下四个功能模组。

用户界面（User Interface）：一般来说测试应用程序需要给操作人员一个可视化的用户界面，它的作用是提示测试软件的操作人员通过鼠标点击或者键盘输入完成启动测试、完成必要的测试配置、查询测试进度、异常情况处理提示、测试完成后显示结果等测试任务。通常情况下测试软件的界面设计相比于专门的组态类型的数据采集类的界面更加通用和普通一些，从而可以增加测试软件的适用性。

测试序列程序（Sequence Sub Program）：针对某种特定类型被测件（DUT）的测试序列，测试序列中一般包含一系列的测试步骤，不同型号的测试序列(DUT)的测试序列的组成是不相同的，现在主流的测试管理调用框架平台都支持不同的语言编写的测试序列，即编程环境是异构组成的。一般测试序列程序的开发往往针对的是某个单独的被测件的功能或者是性能的开发，通常是一个独立的测试功能单元，从概念上讲，序列程序类似于编程环境开发的子程序（或者是LabVIEW的子Vi），例如前面的系列文章我们提到开发的直流电源为待测件的“输出电压负载效应”校准/检定项目，就是一个单独的测试序列，在测试中需要选取直流电压表、与之相匹配的直流负载，并且按照一定的设定策略（检定规程或者校准规范所要求的）进行被测件的性能测试。这些将会调动仪器驱动程序，测试结果判断，如果需要还有自研开发的封装函数，当然采用面向对象技术的开发范型会给我们带来更易于扩展与维护的解决方案，提供更好的模块化和组织化。

自动化测试调用程序（Test Exec Program）：测试管理调用程序目标是在自动化测试系统开发过程中提供一个通用性的行业平台化软件，所以必须适应和满足异常庞大而多样化的测试类型和用户需求，与待调用的测试序列程序的千人千面相反，自动化测试调用程序中则包含共用的逻辑实现代码，实现通用的功能，并且往往需要有足够广泛的适应性，来满足于不同类型的被测件DUT的测试需求，这也就要求综合管理测试软件的各个主要组成模块单元必须是灵活可配置，并且尽可能多的是可扩展的插件模式，使得用户交互界面、测试过程函数调用、并发执行、文件格式、结果的存储与呈现以及核心的测试配置等诸多方面达到灵活、扩展和定制的应用目标。高层模块测试调动程序实现的是底层测试序列步骤功能的通用功能要求。进一步具体而言：自动化测试调用程序主要完成以下功能要求：负责测试程序子序列的加载、测试过程数据在用户界面的更新、设定测试相关的配置、并发执行、生成测试结果报表以及存储数据到数据库系统，而上述的测试序列程序则形成具体的测试步骤，组合排列起来形成特定顺序完成一一被调用，并且在管理测试步骤时要求步骤顺序的调整简便快捷。在自动化测试调用程序提供的统一接口或者是代码适配器（Code Adapter）下，开发人员将核心资源（精力、时间）投入到差异的测试序列子程序开发当中去，针对特定的产品被测件，通过编写相应的测试序列完成所需要的功能、性能、指标测试，从而达到上层的自动化测试调用程序可以最大化达到复用效果，缩短整体开发系统的时间，更为快速便捷、有效的输出大批量可被调用的插件序列程序，形成规模效益。

数据管理系统（Data Storage）：数据管理系统用于实现数据的管理，其核心是存储数据的容器存储库，该存储库提供对外的接口完成数据的添加、删除、查询、更新和读取，随着越来越多的自动测试应用程序对数据的重视，数据管理系统单元变得越发的重要。

实际上，仔细观察自动化测试调用程序(Test Exec Program)的功能：如完成调用底层测试序列程序，完成公共功能如界面显示、数据管理与保存等功能，其实，就是我们前面提到过的极其典型的测量测控的领域专业框架。因此，更加细致地学习与比较测量领域的框架软件先进理念和模式，特别是在成熟的商业平台调用程序软件上开发计量校准软件的典型应用也有助于提高自己的开发框架的能力。

—

真正的主角TestStand

有了清晰的整体测试系统软件概念后，特别是了解了调用管理程序（Test Exec Framework）就是框架（Framework）在测量测控领域的典型体现后，让我们看看成熟的商用测试系统软件是如何将这些概念更为具体的落地的，目前应用较为广泛的自动测试系统平台软件除了我们前面提到过的NI公司的TestStand外，还有就是Keysight公司TestExec SL（非常有意思的是TestStand平台本身的运行时执行文件的名称是TestExec.exe ，恰恰是Keysight公司的调用平台的名称），测试管理软件目前基本是这两家独大、赢者通吃的局面。应用行业涵盖了电子、汽车、医疗、半导体、通信、航空、工业机械、能源等，开发的应用模块和各种相关工具包有移动通信、音视频测试、机器视觉、开关管理、半导体测试、需求管理、分布式数据管理、用户界面开发、配置管理等等。

该类软件才是行业中真正的巨无霸，也是借助平台软件系统发力引流促进自己硬件产品销售的大杀器，有了竞争就不免有排名，那么谁是行业的第一名呢？！由于尚未找到市场份额方面的具体数字，所以让我们先对比看看TestStand和TestExec SL的功能列表。

从性能特点与功能对比表上来看，两者经过十几年的不断更新，都能够满足自动化产线所需要综合测试平台的测试序列管理通用要求，所以从功能列表中很难得出谁是王中王的地位，并且最为有意思的一点是：也都能通过微软公司的通用对象组件技术（COM/ActiveX）提供对竞争对象的主流图形化软件编程环境开发的测试序列支持，其中NI的TestStand支持竞争对手Keysight公司的类似的图形化编程软件VEE，同样的TestExec SL也支持了NI公司的当家花旦LabVIEW，两家公司很好的诠释了什么是竞合关系。

虽然TestStand和TestExec SL不好直接对比得出谁强谁弱的结论，但是图形化编程环境VEE和LabVIEW还是是很容易对比得出结论的，从国内发表的论文、出版的图书和论坛讨论帖子的数量均是LabVIEW占有绝对的优势地位，在测控行业中国外也有类似的调查图表显示LabVIEW（47%）相比VEE（8%）遥遥领先。

LabVIEW广泛的测控工程师使用基础，使得不管是从个人能力提升开始使用TestStand的技能发展的角度来看，还大量是编写底层测控子序列Vi的就业适应性的角度来看，TestStand毫无疑问的是更好的选择。当然，企业开发考虑角度与个人技能与就业角度不尽相同，更多是是考虑到从事行业领域特色的本身、遗留代码库的情况、两家公司的技术背景特色等等，就我所有限接触的行业来看，电子通信等行业TestStand独占鳌头，TestExec SL在汽车电子（ECU）行业积累深厚。

另外有趣的是，两家公司分别应用自己的调用平台开发了支持本公司硬件产品的专用计量校准测试软件，即NI公司的Calibration Executive系统软件和KeySight公司的N7800软件（具体的对比可以参看以前博客相关文章），完美的诠释了各自调用框架系统的的强项和能力，也是我们编写自己的上层共用参数调用框架时，可以模范与学习的范例。

还有个题外话可以八卦一下，在NI公司出品的测量测控等领域软件使用者当中，有着一条秘密的鄙视链条，使用不同产品的人处在该链条的不同的位置，毫无疑问给不会开发程序的工程师们使用的花里胡哨的LabVIEW是最被鄙视的，处在鄙视链的最底层，更高一层的是使用.NET Framework Measurement Studio平台开发的工程师，最高等级的就是会使用LabWindows/CVI天龙人工程师们拥有最高的荣誉度。当然以上鄙视链条还有个特殊附件规则，一旦掌握了附加技能序列调用管理软件TestStand，就可以在鄙视链自动向上递进一级。

由于自己对LabVIEW较为熟稔，理所当然的也是归属到不会编程的测控工程师群内，因此也就爱屋及乌的重点关注过母公司NI出品的TestStand，TestStand 1.0是美国NI公司于1998年发布的测控序列调用执行器，并逐渐成长为大型综合测试管理软件。其目标是“为自动化测试系统软件的开发者们提供一个高质量的开放式扩展架构和高性能组件的模块化体系”，目前最新版本的TestStand是2021 SP1版本。