NI自动化测试技术展望2:系统软件栈

软件是自动化测试系统的重要组成部分，软件第一次被用于控制独立的仪器到现在已有40多年。从那时起，软件在自动化测试中的作用日益凸显。事实上，当前大多数测试系统中，软件开发费用通常是硬件成本费用的2到10倍以上。从许多测试工程企业的工程人员的组成比例即可看出这种情况，即雇佣的软件工程师比硬件工程师多。为了应对软件开发成本的上升及产品开发周期的缩短，当前业界领先的公司都在强调设计一个强大的系统软件栈，以确保他们在软件方面的投入能 够被延续下去，提高软件资源的重用率。事实上，2010年NI进行的测试经理人调查报告显示，测试经理们对系统软件方面投入更多的关注，其重要性在2011年提高测试开发效率的策略中排名第二。

从系统软件的角度来看，大多数公司正在远离一体式的软件栈，这种栈通常包含固定不变的代码和直接调用仪器驱动函数。相反，他们正在探索一种模块化的软件栈，这种栈的成员既独立又紧密关联，包括测试管理软件、应用软件及驱动软件等。这种类型的系统软件栈可帮助工程师针对每个领域的应用选择最佳的工具，而且可在标准化的商用现成工具(Commercial Off The Shelf -COTS)和非现成的工具之间作出选择。可以看到一个重要的趋势，就是将模块化的理念应用到软件栈的每一层之中，这包括越来越来多地使用过程模型 (Process Model)、代码模块库以及硬件抽象层等。

测试管理软件用于定义测试系统关键的自动控制策略及序列流程。其中过程模型是测试管理软件层中的关键技术，因为过程模型能够将非测试任务与测试任务分离，从而让工程师们能够轻松地在不同测试序列之间以及测试站之间对非测试任务进行标准化管理。非测试任务包括与企业的连接任务中的绝大部分，用于数据输入、质量数据库的数据记录、与车间沟通以及生成可编辑的测试报告。有了这个模块化框架，企业可以拥有几个过程模型，这些过程模型能够应用在许多不同产品线及所部署的成百上千的测试设备上。过程模型还可以在不影响测试任务的情况下简化对测试站的非测试功能修改，从而减少了对已部署的测试站进行更新所需的时间。例如，工程师们根据市场需求可以在顺序执行、批处理和并行执行等测试过程模型中进行切换，从而快速改变测试站的执行流程。

模块化的软件架构可以增加灵活性，并缩短测试系统开发时间

应用软件层同样重要，因为它直接影响了测试系统中测试相关的任务。很多企业已经开始开发模块化的测试代码，也就是所谓的代码模块。这些模块由测试管理软件进行调用，进行实际的测量和分析，来确定特定测试步骤的通过/失败状态。许多代码模块对不同类型的待测设备(Devices Under Test- DUT)执行类似的I/O功能，因此在这方面，实现资源的重用以及使用基于团队的开发方法分配开发任务非常重要。近来，业界已经有越来越多的企业采用重用测试代码库和更多的源代码控制（Source Code Control-SCC）工具。现在，许多应用软件供应商在软件中集成SCC工具和一些高级功能（如三方对比与合并，three-way diff/merging），以适应这种测试软件开发趋势。一些企业甚至设立专门的监督机制以确保一定程度的资源重用和团队开发，以防止重复开发和过分依赖单一开发者完成所有的代码开发。

此外，企业在应用软件层中对需求管理软件工具的集成日益增多。这有助于确保根据设计需求进行一对一的测试项目覆盖，这对有严格质量标准的行业来说至关重要。新的需求管理软件在应用软件与需求管理环境（例如Telelogic DOORS）之间提供了一个连接，这极大地减少了在测试系统开发中跟踪需求覆盖所花的时间。

系统软件栈的最后一个部分是硬件抽象层（Hardware Abstraction Layer -HAL），它的需求和使用越来越多。HAL位于系统软件栈的驱动软件层，它将应用软件从仪器硬件中分离，最大限度减小移植和升级测试系统花费的时间和成本。一般有两种HAL设计方法：以仪器为中心或以特定应用为中心。对于以仪器为中心的API，定义了一个内部通用的以仪器为中心的API“标准”，可用于多种类型的待测设备。

可互换虚拟仪器（Interchangeab