CN109254905A - 基于工作流的分布式并行自动化测试系统 - Google Patents

Abstract

本发明公开了一种基于工作流的通用化、分布式、并行化的自动化测试系统，由测试流程子系统和测试服务子系统组成。测试流程子系统实现的功能有测试流程的开发与管理、测试的执行控制与调度、历史数据管理、用户管理与权限分配、接收测试指令、执行测试指令以及返回测试结果；测试服务子系统实现的功能主要为测试服务注册、测试服务管理、测试服务的调用、资源管理与驱动、仿真模型驱动以及测试服务执行。本发明是基于IEEE1226标准设计，提供开发接口，便于二次开发与扩展；分布式架构具备测试资源灵活配置的能力；工作流和关键字概念的引入简化了测试用例的编写过程，可实现面向广泛测试对象的各级测试、并行测试以及测试平台复用。

Description

基于工作流的分布式并行自动化测试系统

技术领域

本发明涉及一种基于工作流的分布式并行自动化测试系统，属于自动化测试领域，尤其涉及基于各类总线/非总线测试资源的通用测试领域。

背景技术

自动测试系统(Automatic Test System，ATS)是指在人极少参与或不参与的情况下，利用计算机控制，自动完成信号激励、测量、数据处理、故障诊断等任务的测试系统，通常在标准的仪器总线基础上组建而成。工程上，自动测试系统往往针对特定的领域和被测对象展开，与人工测试相比，自动测试系统省时省力、能显著提高生产效率和产品质量。

自动测试系统的发展自20世纪50年代起，大体可以分为三个发展阶段：(1)第一代自动测试系统——专用型测试系统；(2)第二代自动测试系统——台式积木型；(3)第三代自动测试系统——模块化化仪器集成性。自动测试系统的发展经历了三代，逐步克服测试对象专一、缺乏硬件接口标准、软件规范缺失等不足，近十几年来，通用自动测试系统的开发已成为主流。通用自动测试系统更注重于采用公共的测试资源去适应不同的测试需要，朝着建立统一的测试系统体系结构、实现测试程序的可移植和互操作、与人工智能技术结合提高测试诊断的效率和有效性以及实现分布式集成诊断测试等方向发展。

在自动化测试领域，传统通用测试平台具有规模大、复杂度高、配置能力差、资源使用率较低等缺点，而测试平台软件与测试资源的耦合程度，也严重影响着测试平台的扩展性、移植性与可重配置性。

发明内容

本发明的目的是解决传统自动化通用测试平台的配置灵活性差、设计重用度低和资源使用率较低的技术问题，提出一种基于工作流的通用化、分布式、并行化的自动化测试系统，集成了测试流程的开发与管理、测试执行、任务调度、历史数据管理、用户管理、资源管理与驱动、仿真模型驱动等功能。

自动化测试系统采用分布式架构，包含一个测试流程控制端、多个测试执行端、一个测试服务注册端和多个测试服务节点，每个测试服务节点可以采用相同或不同的软件应用程序配以相同或不同的测试资源(总线资源/非总线资源/仿真资源)。测试流程控制端实现的功能有测试流程的开发与管理、测试的执行控制与调度、历史数据管理以及用户管理与权限分配；测试执行端实现的功能主要为接收测试指令、执行测试指令以及返回测试结果；测试服务注册端实现的功能主要为测试服务注册、测试服务管理以及测试服务的调用；测试服务节点实现的功能主要为资源管理与驱动、仿真模型驱动以及测试服务执行。

所述的分布式架构可以分为测试流程和测试服务两个相对独立的子系统，同时整个系统遵循IEEE1226标准所描述的分层逻辑结构。测试流程子系统是以测试流程控制端为中心的星型拓扑结构，测试需求与测试策略层、测试过程层的实现都位于测试流程子系统。测试服务子系统是以测试服务注册端为中心的星型拓扑结构，资源管理与仪器控制层的实现都位于测试服务子系统。用户在测试流程子系统根据测试需求与测试策略开发测试用例，生成测试任务，经过统一调度后通过通信网络向测试服务子系统发送命令，在测试服务子系统调用相关测试资源执行测试服务。自动化测试系统分布式、层次化的结构设计降低了测试系统与测试资源的耦合度，提高了测试系统的扩展性与可重配置性。测试执行端和测试服务节点的数目、测试服务节点所配置的具体资源，都由用户根据需求与测试策略灵活配置。

测试服务子系统包含一个测试服务注册端和多个测试服务节点。测试服务节点包含资源代理模块，资源代理对二次封装的仪器驱动进行解析和控制，隔离了不同测试资源厂家与类型的差别，将每一个测试资源作为一个通用的对象，工作人员通过配置文件管理可用的测试资源。软件中利用Python语言的动态性实现测试资源驱动的动态加载与控制，实现了逻辑仪器到真实仪器/虚拟仪器的一一映射。测试服务注册端是外界调用测试服务的唯一通道，测试服务节点在提供服务前必须主动将自身信息发送到测试服务注册端，由测试服务注册端保持通信连接。测试服务注册端提供多种编程语言的API，使得符合平台规范的由不同语言开发的服务节点均可以被测试服务注册端管理，提高测试服务的通用性。

测试流程子系统包含一个测试流程控制端和测试执行端，测试流程是整个子系统的核心。正如人们使用编程函数进行程序开发一样，用户利用测试关键字(也可以叫做关键字)完成测试任务的开发。关键字包含一段可以执行并返回标准结果的代码，一般可以由脚本语言书写，不需要编译就可以直接运行，是整个测试流程中的原子操作。另外，关键字也包含键值对形式的配置信息，配置信息的参数化使关键字具有良好的可复用性。

测试流程的开发既可以在测试流程控制端的界面上进行可视化设计，又可以导入符合测试流程子系统所约束的规范的测试流程JSON文件。JSON文件中所描述内容可以看作一幅有向无环图，图中节点表示待执行的测试关键字，有向图中的边表示各测试关键字的依赖关系以及测试数据的传递方向。JSON文件所描述的内容只包含关键字依赖关系、关键字的标识ID和测试相关参数，关键字的具体代码只保存在关键字库中，在运行时由平台统一调用。在测试流程子系统的界面中中进行流程开发，实质上是生成测试流程的实例对象，并对其属性值进行编辑。用户通过对测试关键字的调用与配置，完成测试流程编辑，进而完成测试流程执行过程。

本发明的优点在于：

(1)所述的自动化测试系统采用分布式架构实现了IEEE1226标准所描述的测试泛环境，标准的使用提高了测试平台的通用性和重用性，分布式架构实现是测试平台具有更强的配置能力并提高资源使用率，给用户以更大的测试配置自由度与灵活度。

(2)本发明在资源管理层引入资源代理，将每一个用户配置的测试资源模块作为一个通用逻辑对象，使软件平台适配各厂家各类测试资源，对测试服务节点测试资源进行修改时只需修改相应驱动，无需修改软件代码，极大程度上实现测试软件与测试资源的解耦。

(3)本发明使用参数化的有向无环图描述测试流程，并支持数据根据有向图方向进行传递，因此整个测试描述具有良好的通用性和可读性，并易于复用和修改，极大地提高了测试流程的开发效率。

(4)本发明中关键字概念的引入简化了测试流程的编写过程，使测试人员无需编程就可以根据关键字结合测试逻辑编写测试任务与执行控制，其中关键字库的实现为面向广泛测试对象的各级测试与测试平台复用提供了基础。

附图说明

图1为本发明提供的自动化测试系统结构图；

图2为本发明的测试流程子系统分层结构；

图3为本发明的测试服务节子系统分层结构；

图4为本发明的测试流程描述图；

具体实施方式

下面将结合附图对本发明提供的自动化测试系统及其实现方法进行详细说明。

本发明提供一种基于工作流的通用化、分布式的并行自动化测试系统，所述测试系统结构如图1所示。所述的自动化测试系统采用分布式架构，包含一个测试流程控制端、多个测试执行端、一个测试服务注册端和多个测试服务节点，每个测试服务节点可以采用相同或不同的软件应用程序配以相同或不同的测试资源(总线资源/非总线资源/仿真资源)、测试流程控制端实现的功能有测试流程的开发与管理、测试的执行控制、测试任务调度、历史数据管理以及用户管理与权限分配；测试执行端实现的功能主要为接收测试指令、执行测试指令以及返回测试结果；测试服务注册端实现的功能主要为测试服务注册、测试服务管理以及测试服务的调用；测试服务节点实现的功能主要为资源管理与驱动、仿真模型驱动以及测试服务执行。参照IEEE1226标准设计软件分层逻辑结构。测试流程子系统是以测试流程控制端为中心的星型拓扑结构，测试需求与测试策略层、测试过程层的实现都位于测试流程子系统。测试服务子系统是以测试服务注册端为中心的星型拓扑结构，资源管理与仪器控制层的实现都位于测试服务子系统。分布式与层次化结构的结合，从测试逻辑与测试仪器等不同维度对整个测试系统进行解耦，便于配置扩展与二次开发。

测试流程子系统和测试服务子系统都采用分布式和模块化设计，如图2和图3所示。同时，测试流程子系统和测试服务子系统没有直接的依赖关系，两者通过测试用例联系在一起，如果测试程序中不涉及调用测试服务子系统的代码语句，则两个子系统完全独立。由于测试引擎采用分布式架构，自动化测试系统内置通信服务。用户在测试流程子系统根据测试需求与测试策略开发测试用例，生成测试任务，经过统一调度后通过通信网络向测试服务子系统发送命令，在测试服务子系统调用相关测试资源执行测试服务。

测试服务节点的资源代理功能模块会为每一个测试资源建立一个虚拟设备资源到实际资源的映射关系，即用虚拟设备资源实例化对象装载一个实际资源驱动的实例化对象。测试服务注册端包含测试服务节点信息管理表，而每一个测试服务节点元素内，又包含一个测试资源管理表，其中又包含若干测试资源元素。结合面向对象的程序设计思想，利用节点与资源的层级关系和集合与元素的关系来建立测试服务节点与资源的信息系统，管理测试服务节点资源信息。软件利用Python语言的动态特性实现测试资源驱动的动态加载与控制，实现了逻辑仪器到真实仪器/虚拟仪器的一一映射。这种动态加载机制实现了资源管理层与仪器控制层的解耦，使自动化测试系统具备良好的通用性、可扩展性与可重配置性。

完整的测试流程由测试关键字和任务模式组成。测试关键字是测试流程执行动作的最小单元，每个测试关键字具有下列属性：唯一的名称、期望的输入值(输入参数)、期望的输出值(输出参数)、动作代码(Python代码)以及自身运行所需要的参数列表。每一个测试关键字都可以独立运行，即可以将测试关键字看作一个黑盒子，只要给予相应的输入参数，就能得到相应的输出。任务模式描述了若干个测试关键字间的依赖关系，如图4所示，具有下列三种类型：线性模式、集合模式和有向图模式。线性模式也可以称为顺序模式，即所有的测试关键字必须按照指定的顺序执行，前面的操作没有执行完毕，后面的操作也不能执行；集合模式也可以成为并行模式，即所有的测试关键字没有指定的执行顺序和依赖关系，可以同时执行；有向图模式使用有向无环图描述测试关键字间的关系，测试关键字的执行顺序依赖于图的结构，是一种比较灵活的模式；测试关键字以及其对应的任务模式，构成了整个测试流程。三种类型的任务模式可以相互嵌套，形成更加复杂的测试流程，在提高了测试灵活性的同时保持了测试流程的可读性。

关键字库的实现主要依托于关键字库类与数据库中关键字管理表，关键字管理表中存储开发人员录入的测试关键字，关键字库类提供关键字管理表的操作接口，主要为对关键字库中关键字的一些操作，包括获取关键字各种属性、添加或修改关键字库中元素等。测试关键字的开发是开发人员的工作，测试执行人员不需要关注测试关键字的具体实现，只需要了解其功能即可。

测试流程的开发既可以在测试流程控制端的界面上进行可视化设计，又可以导入符合测试流程子系统所约束的规范的测试流程JSON文件。JSON文件中所描述内容可以看作一幅有向无环图，图中节点表示待执行的测试关键字，有向图中的边表示各测试关键字的依赖关系以及测试数据的传递方向。JSON文件所描述的内容只包含关键字依赖关系、关键字的标识ID和测试相关参数，测试关键字的具体代码只保存在测试流程子系统中。在测试流程子系统的界面中中进行流程开发，实质上是生成测试流程的实例对象，并对其属性值进行编辑。

测试数据记录模块将测试任务执行记录以字符串的形式存储，为后期进行测试的分析提供有效的支持。测试记录在数据库中的存储形式为数据表表格，每一次测试的结果作为表格中的一行，主要包含执行记录、测试结果与辅助信息。其中，测试记录表存储测试流程每一个测试关键字的结构，以及关键字相应的执行结果，如通过和未通过。测试结果包含本次测试流程需要记录的数据，以键值对的形式存储，如“电压峰值：5.12V”。辅助信息包括测试开始时间、运行时间、测试人员信息等额外记录。每一行测试记录的字段，都是符合平台约定标准的JSON字符串，随后用户可以根据需求，基于JSON数据生成不同样式的测试报表。

用户管理模块对自动化测试引擎的用户权限进行管理,用于保证对本系统的合法和安全的使用。用户管理模块保证系统安全性的具体功能表现在：支持用户管理模块和数据库的关联，保障用户在登陆系统时将用户信息录入数据库的操作记录模块；支持对操作人员的权限划分，不同的权限的用户所能行使的操作命令不同；支持用户的注册和删除功能，注册后会将用户名、用户密码、用户级别存储进数据库，方便以后登录时的便捷性。用户管理模块根据用户角色或权限的不同，为用户配置不同的功能模块组合，提供所需功能模块，并屏蔽用户使用过程完全不需要或无权限使用的模块，为每个用户提供既满足需求又无赘余的自动化测试系统，保证自动化测试系统对不同用户的适用性。

Claims (7)

1.基于工作流的分布式并行自动化测试系统，其特征在于：所述的自动化测试系统采用分布式架构，包含一个测试流程控制端、多个测试执行端、一个测试服务注册端和多个测试服务节点，每个测试服务节点可以采用相同或不同的软件应用程序配以相同或不同的测试资源(总线资源/非总线资源/仿真资源)、测试流程控制端实现的功能有测试流程的开发与管理、测试的执行控制、测试任务调度、历史数据管理、用户管理与权限分配以及人机交互界面；测试执行端实现的功能主要为接收测试指令、执行测试指令以及返回测试结果；测试服务注册端实现的功能主要为测试服务注册、测试服务管理以及测试服务的调用；测试服务节点实现的功能主要为资源管理与驱动、仿真模型驱动以及测试服务执行。

2.根据权利要求1所述的自动化测试系统，其特征在于：所述的自动化测试系统采用分布式架构，形成测试流程和测试服务两个相对独立的子系统，同时整个系统遵循IEEE1226标准所描述的分层逻辑结构。测试流程子系统是以测试流程控制端为中心的星型拓扑结构，测试需求与测试策略层、测试过程层的实现都位于测试流程子系统。测试服务子系统是以测试服务注册端为中心的星型拓扑结构，资源管理与仪器控制层的实现都位于测试服务子系统。用户在测试流程子系统根据测试需求与测试策略开发测试用例，生成测试任务，经过统一调度后通过通信网络向测试服务子系统发送命令，在测试服务子系统调用相关测试资源执行测试服务。

3.根据权利要求1所述的自动化测试系统，其特征在于：测试流程子系统和测试服务子系统都采用分布式和模块化设计。同时，测试流程子系统和测试服务子系统没有直接的依赖关系，两者通过测试用例联系在一起，如果测试程序中不涉及调用测试服务子系统的代码语句，则两个子系统完全独立。由于测试引擎采用分布式架构，自动化测试系统内置通信服务。用户在测试流程子系统根据测试需求与测试策略开发测试用例，生成测试任务，经过统一调度后通过通信网络向测试服务子系统发送命令，在测试服务子系统调用相关测试资源执行测试服务。

4.根据权利要求1所述的自动化测试系统，其特征在于：测试服务子系统包含一个测试服务注册端和多个测试服务节点。测试服务节点包含资源代理模块，资源代理对二次封装的仪器驱动进行解析和控制，隔离了不同测试资源厂家与类型的差别，将每一个测试资源作为一个通用的对象，工作人员通过配置文件管理可用的测试资源。软件中利用Python语言的动态性实现测试资源驱动的动态加载与控制，实现了逻辑仪器到真实仪器/虚拟仪器的一一映射。测试服务注册端是外界调用测试服务的唯一通道，测试服务节点在提供服务前必须主动将自身信息发送到测试服务注册端，由测试服务注册端保持通信连接。测试服务注册端提供多种编程语言的API，使得符合平台规范的由不同语言开发的服务节点均可以被测试服务注册端管理，提高测试服务的通用性。

5.根据权利要求1所述的自动化测试系统，其特征在于：测试流程子系统包含一个测试流程控制端和测试执行端，测试流程是整个子系统的核心。正如人们使用编程函数进行程序开发一样，用户利用测试子程序(也可以叫做测试关键字)完成测试任务的开发。测试关键字包含一段可以执行并返回标准结果的代码，一般可以由脚本语言书写，不需要编译就可以直接运行，是整个测试流程中的原子操作。同时，关键字也包含键值对形式的配置信息，参数化使得测试关键字具有良好的可复用性。另外，由于基于有向无环图可以清晰地体现出各关键字的依赖关系，因此平台可以基于依赖关系实现关键字的并行化执行。

6.根据权利要求1所述的自动化测试系统，其特征在于：测试流程的开发既可以在测试流程控制端的界面上进行可视化设计，又可以导入符合测试流程子系统所约束的规范的测试流程JSON文件。JSON文件中所描述内容可以看作一幅有向无环图，图中节点表示待执行的测试关键字，有向图中的边表示各关键字的依赖关系以及测试数据的传递方向。JSON文件所描述的内容只包含测试流程、测试关键字的标识ID和测试相关参数，测试关键字的具体代码只保存在测试流程子系统中。在测试流程子系统的界面中中进行流程开发，实质上是生成测试流程的实例对象，并对其属性值进行编辑。

7.根据权利要求3所描述的自动化测试系统，其特征在于：测试流程子系统与测试服务子系统均采用B/S(浏览器/服务器)架构，使用HTML网页完成人机交互。HTML页面均采用统一的基础布局样式，测试流程子系统包含登录相关页面、通信服务页面、功能页面和后台管理界面。其中，功能页面包含测试流程的开发与管理、测试流程的执行控制、测试任务调度、历史数据管理以及用户管理与权限分配等按钮，每一个按钮点击后都出发各功能模块子页面。