CN108733877A - 一种ate测试系统元模型的构建方法 - Google Patents

Abstract

本发明涉及一种ATE测试系统元模型的构建方法，属于自动化测试领域，解决了现有技术中不同的视图表格中存在着交叉引用的不一致的问题。所述方法包括以下步骤：获取ATE测试系统中所涉及到的概念以及所述概念的属性，根据概念属性对所述概念进行分类；确定不同类型视图与上述不同类型概念之间的关系，建立ATE测试系统元模型；将上述得到的ATE测试系统元模型与ATE测试系统视图进行绑定；建立上述ATE测试系统元模型对应的一致性检查规则。本发明提供了基于ATE领域的元模型以及一致性检查规则来对ATE各类视图信息进行一致性检查，能够帮助开发者理解领域知识，同时提高开发效率，降低出现不一致错误的概率。

Description

一种ATE测试系统元模型的构建方法

技术领域

本发明涉及自动化测试技术领域，尤其涉及一种ATE测试系统元模型的构建方法。

背景技术

ATE(自动化测试设备)主要用于硬件设备的信号测试(如电压、电流、电阻等)。这些被测设备种类繁多，遵循的标准规范各异。即便是同类设备，也存在不同厂家和不同型号之间的差异。因此，对于这些设备，虽然存在许多相同或相似的测试需求，但各自也有很多不同的特殊要求，致使大多数的ATE都是针对特定领域中某一型号或某几种型号被测设备的专用设备。一种ATE，尽管是相对专用设备，但一般可用于测试多种类型的设备，包括同种类型设备的不同型号、不同厂商的设备(不同标准、制式)等，即一种ATE的开发需求必需满足所有被测设备的测试需求。

目前造成ATE领域开发效率低下的主要原因有：1)采用(无约束的)自然语言描述方式，容易出现专业术语、缩略语等使用上的不一致，甚至矛盾(冲突)等问题；2)由于涉及跨领域和跨专业的不同知识体系，不同人员提供的测试信息所使用的标准、概念、方法、策略、规则可能存在差异，从而导致测试文档中的信息经常产生歧义，进而造成开发效率低下的问题。

在使用了表格化的ATE测试信息描述方法后，ATE开发过程中的一致性、完整性、正确率得到了一定的改善，但在不同的视图表格中仍然存在着交叉引用的不一致现象。例如，在测试流程中，在引脚A1和引脚A3之间添加3V电压，而在测试设备的表格中明确规定引脚A1只允许添加电流信号，类似这种错误屡见不鲜，需要耗费极大的人力物力进行反复审查，否则严重的会有烧毁设备的危险。

发明内容

鉴于上述的分析，本发明旨在提供一种ATE测试系统元模型的构建方法，用以解决表格化的ATE测试信息中不同的视图表格所描述的信息存在的不一致、属性缺失的问题。

本发明的目的主要是通过以下技术方案实现的：

一种ATE测试系统元模型的构建方法，包括以下步骤：

获取ATE测试系统中所涉及到的概念以及所述概念的属性，根据概念属性对所述概念进行分类；

确定不同类型视图与上述不同类型概念之间的关系，建立ATE测试系统元模型；

将上述得到的ATE测试系统元模型与ATE测试系统视图进行绑定；

建立上述ATE测试系统元模型对应的一致性检查规则。

本发明有益效果如下：本发明提供了一种ATE测试系统元模型的构建方法来对ATE各类视图信息进行一致性检查，能够帮助开发者理解领域知识，同时提高开发效率，降低出现不一致错误的概率。

在上述方案的基础上，本发明还做了如下改进：

进一步，所述获取ATE测试系统中所涉及到的概念以及所述概念的属性，包括：

将每个测试流程分解为一步或多步测试步骤；

获取每一测试步骤中所涉及的概念和所涉及概念的属性；

经过去重处理后，得到ATE测试系统中所涉及到所有概念以及概念的属性。

进一步，根据概念属性将所述概念分为测试信号、测试引脚和测试动作三类。

进一步，所述确定不同类型视图与不同类型概念之间的关系，建立ATE测试系统元模型，包括：

获得四类不同类型的视图，所述四类不同类型的视图包括信号视图、被测设备视图、测试设备视图和测试流程视图；

分别建立上述四类视图与测试信号、测试引脚、测试动作的关系，得到四类视图的元模型；

将上述四类视图的元模型进行整合，得到ATE领域的元模型。

采用上述进一步方案的有益效果是：在有了元模型的支持后，模型将根据概念之间关系和约束自动检查出这些错误。

进一步，所述分别建立上述四类视图与测试信号、测试引脚、测试动作的关系，包括：信号视图引用测试信号；被测设备视图、测试设备视图均引用测试引脚和测试信号；测试流程视图引用测试信号、测试引脚、测试动作。

进一步，所述基于上述得到的ATE测试系统元模型设计对应的一致性检查规则，包括：通过在模型元素上附加OCL逻辑表达式来表达指定的一致性检查规则。

采用上述进一步方案的有益效果是：通过制定一致性规则进一步约束并增强计算机的一致性检查能力。

进一步，采用轻量级建模框架进行ATE测试系统元模型与ATE测试系统视图绑定，包括：

建立视图-类-元模型的映射，信号类型视图对应测试信号类，被测设备视图和测试设备视图对应测试引脚类和测试信号类，测试流程视图对应测试信号类、测试引脚类和测试动作类；

将上述视图的表格绑定监听器，当表格内容发生改变时，所述监听器记录下所述发生改变的表格内容，并更新对应模型的内容。

采用上述进一步方案的有益效果是：这样当开发者完成输入后，系统后台将解析输入，将其转化为元模型对应的类的实例化对象，从而存储到系统后台，当输入的对象产生不一致现象后，系统能够自动的检测并进行输出。

进一步，所述采用轻量级建模框架作为基础来进行元模型的构建，包括以下步骤：

将元模型所需的信息通过可视化界面编辑；

通过TypeBuilder和AttributeBuilder读取加载上述编辑得到的模型的类及类所对应的属性；

响应于触发模型转化到代码的操作指令，TypeLoader类扫描上述TypeBuilder和AttributeBuilder中存储的信息，将上述扫描得到的信息通过反射机制构建得到元模型。

进一步，所述在模型元素上附加OCL逻辑表达式包括：利用OCL描述不变量约束。

进一步，所述采用轻量级建模框架包括LMF上下文、类型装载器、类型构建器和属性构建器。

本发明中，上述各技术方案之间还可以相互组合，以实现更多的优选组合方案。本发明的其他特征和优点将在随后的说明书中阐述，并且，部分优点可从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过说明书、权利要求书以及附图中所特别指出的内容中来实现和获得。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本发明实施例中ATE测试系统元模型的构建方法流程图；

图2为本发明实施例中整理ATE概念、属性示意图；

图3为本发明实施例中采用UML表示ATE模型示意图；

图4为本发明实施例中构建的ATE测试系统元模型示意图；

图5为本发明实施例中LMF核心实现类示意图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理，并非用于限定本发明的范围。

使用ATE测试被测设备的基本方式是将其测试端口与被测设备的被测端口进行物理连接，通过指定的引脚向被测设备发送测试信号，同时接收其反馈信号，进而分析、显示和判断被测设备的状态是否符合其规范要求。与传统硬件测试不同的是，ATE测试具有时序性特点，即前序测试步骤的执行结果构成下一步测试的基础。在测试中，完整地记录测试流程对于判断测试结果的正确性和进行必要的调试是至关重要。由此可见，开发ATE的需求中需要包含四类基本信息，即测试信号、测试设备和被测设备的引脚，以及测试流程。

本发明的一个具体实施例，公开了一种ATE测试系统元模型的构建方法，整合ATE多视图概念、属性，并提出ATE领域的元模型及一致性检查规则，如图1所示，具体包括以下步骤：

步骤S1，获取ATE测试系统中所涉及到的概念以及所述概念的属性，根据概念属性对所述概念进行分类；

步骤S2，确定不同类型视图与上述不同类型概念之间的关系，建立ATE测试系统元模型；

步骤S3，将上述得到的ATE测试系统元模型与ATE测试系统视图进行绑定；

步骤S4，建立上述ATE测试系统元模型对应的一致性检查规则。

与现有技术相比，本实施例公开的一种自动化测试设备的测试系统元模型的构建方法，1)提出了ATE测试系统的元模型对ATE测试系统进行抽象概括，帮助开发者理解领域知识；2)利用构建的ATE测试系统元模型和ATE测试系统视图的绑定以及一致性规则来实现跨视图的概念一致性检查，提升了开发效率、提前避免了审查、测试过程中的许多错误。

具体来说，所述步骤S1中获取ATE测试系统中所涉及到的概念以及所述概念的属性，包括：

将每个测试流程分解为一步或多步测试步骤；

获取每一测试步骤中所涉及的概念和所涉及概念的属性；

经过去重处理后，得到ATE测试系统中所涉及到所有概念以及概念的属性。

需要说明的是，所述ATE领域的概念可归类整理为三类，一是测试信号、二是测试引脚、三是测试动作，其中测试信号(如电压、电流、电阻等)和测试引脚针对不同的ATE设备有不同的种类，测试动作通常固定，可分为七类自动动作(由计算机完成)和两类手工动作(由人完成)，自动动作分别为：发送、接收、重置、测量、判定、等待、退出，手工动作为警告和提示。

在ATE测试领域中，每一个测试流程都可以分解为一步或多步测试步骤，其中一步测试步骤如图2所示。需要说明的是，所述步骤分解过程为：将句式分解为测试动作、测试信号和测试引脚的组合。

其中，测试引脚、测试信号(如图2中“电压”)可以看作是ATE的物理(硬件)特性，而测试动作(如图2中“测量”)和整个句子可以看作是ATE的软件(逻辑)特性，进而可以简单的将图2的几个概念分类，采用UML(统一建模语言)将概念抽象成类与属性，如图3所示。

需要说明的是，对于概念属性的定义是用的统一建模语言UML的类图。具体地，类图显示了一组类、接口、协作以及他们之间的关系。可以在类图中对概念的属性进行严格的定义，如数据类型、取值边界等。在上述对概念属性进行定义的基础上，整理出概念的种类：测试信号、测试动作、测试引脚，将这三种模型元素构建出来，作为三个类。

类似的，其他的ATE领域概念也可以根据其具备物理特性或逻辑特性进行分类，再根据其属性和功能进行进一步细化。

在经过步骤S1得到上述这几类概念之后，进而通过步骤S2：确定不同类型视图与不同类型概念之间的关系，建立ATE测试系统元模型，具体包括：

获得四类不同类型的视图，所述四类不同类型的视图包括信号视图、被测设备视图、测试设备视图和测试流程视图；

分别建立上述四类视图与测试信号、测试引脚、测试动作的关系，得到四类视图的元模型；

将上述四类视图的元模型进行整合，得到ATE领域的元模型。

ATE中有四类视图来分别描述不同的ATE测试信息，各类视图由不同的开发方输入，也由不同的开发方关注。每种视图都有各自的元模型对其字段语义进行支持，将各个视图的元模型整合到一起，可以整理出整个ATE测试系统的各类概念以及它们之间的关系，也就是ATE测试系统的元模型。在人为输入测试信息时，经常会出现引用不一致或关联错误等问题，在有了元模型的支持后，模型将根据概念之间关系和约束自动检查出这些错误。

所述整合元模型具体包括：ATE对于开发需求的描述其实是对上述三个类的实例对象进行引用，通常ATE有四类表格视图(信号视图、被测设备视图、测试设备视图、测试流程视图)，整理这四类视图也作为四个类，并建立与上述测试信号、测试引脚、测试动作三个类直接的关系，构建出ATE领域的元模型。

所述测试信号视图包括信号类型、单位、数值类型、测试方式字段。具体地，信号类型指的是该信号所属类型，如电压、频率等；单位指的是该信号的单位，如伏特；数值类型指的是该信号取值的数字类型，如浮点型；测试方式指的是ATE领域中的信号一般有单端测量和双端测量，该表项用于描述此类信息。

所述测试设备视图包括引脚标识、信号类型、功能、数值范围、精度、数量。具体地，引脚标识指的是测试的引脚号，可以英文字母加数组的形式描述，如引脚B2；信号类型指的是该引脚对应的信号类型；功能指的是该组引脚对应的功能；数值范围指的是设备测试能力允许测量的最大范围；精度指的是设备测量的精度；数量指的是该类功能需要使用的引脚数。

所述被测设备视图包括引脚标识、信号方向、备注名称、信号类型、期望值、可接收最大值、可接收最小值。具体地，引脚标识指的是被测设备的引脚号，通常以英文字母加数组的形式，如引脚A12；信号方向指的是添加至该引脚信号的方向，即输入或输出；备注名称指的是使用者自定义的备注信息；信号类型指的是该引脚对应的信号类型；期望值指的是预期信号值；可接受最大值指的是允许的最大信号值；可接受最小值指的是允许的最小信号值。

所述测试流程视图包括基本属性、主测试流。其中，基本属性用于说明测试流程的基本信息，包括：测试用例名、描述项、前置条件、依赖关系；具体地，测试用例名表示该测试需求用例的名称，为必填项；描述项表示该测试需求用例的简要描述，为非必填项；前置条件表示该测试需求用例的前置条件，为必填项；依赖关系表示该测试需求用例的所依赖的其他用例名称，为必填项；主测试流用于描述测试需求用例成功执行情况下的步骤和测试流程的后置条件，为必填项。包括步骤和后置条件两部分；其中，步骤表示主测试流步骤，每个测试步骤按顺序执行，相互不重叠，每个测试步骤包括测试信号视图、测试设备视图、被测设备视图的相关信息，具体内容由测试需求决定，为必填项。后置条件表示主测试流程的后置条件，为必填项。

由于实际测试流程中存在分支、错误等异常现象，所以，测试流程视图还可以包括特定测试分支流和全局测试分支流，用于描述异常发生时的分支情况。

所述特定测试分支流是指从其它流中某个特定步骤产生的分支流；包括触发步骤、步骤和后置条件三部分，根据被测设备测试需求，如果测试流程视图包含特定测试分支流，则这三部分为必填项。其中，触发步骤表示特定测试分支流引用的测试步骤标号；步骤表示特定测试分支流步骤，每个步骤按顺序执行，相互不重叠，每个测试步骤包括测试信号视图、测试设备视图、被测设备视图的相关信息，具体内容由测试需求决定。根据被测设备测试需求，在各个步骤中添加相应的参数化句式。后置条件表示特定测试分支流的后置条件。

所述全局测试分支流是指从主测试流中所有步骤均可产生分支的分支流；包括守护条件、步骤和后置条件三部分，根据被测设备测试需求，如果测试流程视图包含全局测试分支流，则这三部分为必填项。其中，守护条件表示全局分支守护的条件；步骤表示全局测试分支流步骤，每个步骤按顺序执行，相互不重叠，每个测试步骤包括测试信号视图、测试设备视图、被测设备视图的相关信息，具体内容由测试需求决定。根据设备测试需求，在各个步骤中添加相应的参数化句式。后置条件表示全局测试分支流的后置条件。

需要说明的是，所有概念类型(如信号、引脚等)都是Concept类的泛化(扩展)，在Concept类基础上，有三个基本数据类：测试信号(signal)、测试引脚(pinport)、测试动作(action)，四个视图类：测试流程视图(或测试用例，TestCaseTemplate)、信号视图(SignalTypeView)、被测设备视图(IODefinitionView)、测试设备视图(TestCapbilityView)。信号视图引用了测试信号类，被测设备视图和测试设备视图都引用了测试引脚类和测试信号类。测试流程视图引用了测试信号、测试引脚、测试动作类。测试流程视图是由测试流类组成的，其中的每个流又有多个步骤类组成，每个步骤类可以看做是一个ATE语句类(如图2中的句式分解)。

在有了ATE测试系统的元模型后，必须与视图表格建立对应的映射关系，这样，使用者的输入会在后台自动转化成类的对象，从而让计算机自动化的进行一致性检查。

具体地，通过步骤S3实现ATE测试系统视图和元模型的绑定。构建了ATE测试系统的元模型后需要和开发者的输入建立映射关系，这样当开发者完成输入后，系统后台将解析输入，将其转化为元模型对应的类的实例化对象，从而存储到系统后台，当输入的对象产生不一致现象后，系统能够自动的检测并进行输出。所述自动解析具体为：将输入的语句中包含的模型中的类自动构建实例化对象，例如在引脚A1和引脚A2添加2V电压这个输入中，后台将实例化两个引脚对象和一个电压(信号)对象。所述输出具体为：输出错误提示，可以有多种输出形式，如：警告提示框或者生成文档形式存储在磁盘中。

将元模型与测试系统视图进行绑定可以通过多种方式实现，本发明实施例中采用轻量级建模框架(LMF)作为基础来进行元模型的构建与元模型-视图绑定。

所述进行元模型-视图绑定具体包括：

首先，建立视图-类-元模型的映射，元模型是由类和它们之间的关系组成的，因此需要建立视图和类的关系即建立了视图到元模型的映射，在ATE中，信号类型视图对应信号类，被测设备视图和测试设备视图对应引脚类和信号类，测试流程视图对应信号类、引脚类和动作类，实际的视图表格实际上是上述类的实例化对象(即类的属性有了实际取值)。

然后，将视图的表格绑定监听器(监听器是一种现有的开源技术)。引用所述监听器机制的原因是，当使用者动态改变表格内容时，监听器获取到该事件，记录下更新内容，从而对对应模型的内容进行更新，这就实现了表格视图-元模型的绑定。

LMF的核心实现类的结构如图5所示。用于构建元模型的类主要包括LMF上下文(LMFContext)、类型装载器(TypeLoader)、类型构建器(TypeBuilder)、属性构建器(AttributeBuilder)。由于构建类型实例的过程涉及属性的继承、交叉引用、类型检查等问题，过程比较复杂，所以使用了Builder设计模式，将类型的构造过程和它的表示解耦。不必关心类型和属性的实际构建过程，而只需要将元模型所需的信息填入TypeBuilder和AttributeBuilder对象，一起封装在TypeLoader对象内即可。通过LMFContext的静态方法load来加载一个或多个TypeLoader对象，并通过静态方法pack来构造元模型。调用pack方法之后，就可以从LMFContext通过反射机制获取构造出来元类和属性对象了。

所述采用轻量级建模框架(LMF)作为基础来进行元模型的构建具体包括以下步骤：

步骤301，将元模型所需的信息通过可视化界面编辑。

步骤302，框架读取到模型信息，通过TypeBuilder和AttributeBuilder读取加载模型的类以及与其对应的属性；

步骤303，使用者触发模型转化到代码的操作，TypeLoader类将扫描上述TypeBuilder和AttributeBuilder中存储的信息，将上述扫描得到的信息通过Java反射构建出实际的Java类代码，即元模型代码。

为了进一步约束并增强计算机的一致性检查能力，通过步骤S4中一致性检查规则，将上述构建的元模型配合形式化的一致性检查。

元模型有时对于一致性的约束还不够强大，通常需要配合形式化的一致性检查规则来增加约束。所述一致性可以理解为同一数据(如同一类或者同一类的同一实例化对象)在不同的视图表格中是否保持了一致，这在实际开发中非常重要，如果出现不一致经常会造成很严重的后果(如：某引脚只能规定添加电流信号，但在实际的测试流程中向这个引脚添加了功率信号，这就是不一致现象)。

本发明实施例采用OCL(Object Constraint Language)建立上述ATE测试系统元模型对应的一致性检查规则。OCL是针对某一特定模型的约束语言，通过在模型元素上附加OCL逻辑表达式来表达指定的规则，它是一种用于施加在指定的模型元素上约束的语言，同时也是一种查询语言。使用OCL可以用来描述四类约束：(1)不变量，是保证一个属性在生命周期内一直为真的规则；(2)前置条件，是一个断言，是在一个操作被调用必须为真的规则；(3)后置条件，和前置条件相对，是在一个操作调用结束后必须为真的规则；(4)监护条件，是两个状态发生迁移时必须为真的规则。需要强调的是，本发明实施例中仅仅用到了OCL不变量约束。表1列举了一些本发明实施例中所采用的OCL的基本操作。

表1OCL操作举例

对于规则的形式化表达，采用对象约束语言(OCL)来表达。例如对于规则“任意一条路径应该至少包括两个节点”可以用OCL结合流程模型的元模型表达如下：

Context：路径

Inv：路径.allInstances()->forAll(s1|s1.节点集合.size>＝2)

其中路径是流程模型中的路径元素，路径的节点集合属性是一个该路径包含的所有节点的有序集合。

本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种ATE测试系统元模型的构建方法，其特征在于，包括以下步骤：

获取ATE测试系统中所涉及到的概念以及所述概念的属性，根据概念属性对所述概念进行分类；

确定不同类型视图与上述不同类型概念之间的关系，建立ATE测试系统元模型；

将上述得到的ATE测试系统元模型与ATE测试系统视图进行绑定；

建立上述ATE测试系统元模型对应的一致性检查规则。

2.根据权利要求1所述的方法，其特征在于，所述获取ATE测试系统中所涉及到的概念以及所述概念的属性，包括：

将每个测试流程分解为一步或多步测试步骤；

获取上述每一测试步骤中所涉及的概念和所涉及概念的属性；

经过去重处理后，得到ATE测试系统中所涉及到的所有概念以及概念的属性。

3.根据权利要求2所述的方法，其特征在于，根据概念属性将所述概念分为测试信号、测试引脚和测试动作三类。

4.根据权利要求3所述的方法，其特征在于，所述确定不同类型视图与不同类型概念之间的关系，建立ATE测试系统元模型，包括：

获得四类不同类型的视图，所述四类不同类型的视图包括信号视图、被测设备视图、测试设备视图和测试流程视图；

分别建立上述四类视图与测试信号、测试引脚、测试动作的关系，得到四类视图的元模型；

将上述四类视图的元模型进行整合，得到ATE领域的元模型。

5.根据权利要求4所述的方法，其特征在于，所述分别建立上述四类视图与测试信号、测试引脚、测试动作的关系，包括：信号视图引用测试信号；被测设备视图、测试设备视图均引用测试引脚和测试信号；测试流程视图引用测试信号、测试引脚、测试动作。

6.根据权利要求1或5所述的方法，其特征在于，所述建立上述ATE测试系统元模型对应的一致性检查规则，包括：在模型元素上附加OCL逻辑表达式来表达指定的一致性检查规则。

7.根据权利要求6所述的方法，其特征在于，采用轻量级建模框架进行ATE测试系统元模型与ATE测试系统视图绑定，包括：

建立视图-类-元模型的映射，信号类型视图对应测试信号类，被测设备视图和测试设备视图对应测试引脚类和测试信号类，测试流程视图对应测试信号类、测试引脚类和测试动作类；

将上述视图的表格绑定监听器，当表格内容发生改变时，所述监听器记录下所述发生改变的表格内容，并更新对应模型的内容。

8.根据权利要求6所述的方法，其特征在于，采用轻量级建模框架作为基础来进行元模型的构建，包括以下步骤：

将元模型所需的信息通过可视化界面编辑；

通过TypeBuilder和AttributeBuilder读取加载上述编辑得到的模型的类及类所对应的属性；

响应于触发模型转化到代码的操作指令，TypeLoader类扫描上述TypeBuilder和AttributeBuilder中存储的信息，将上述扫描得到的信息通过反射机制构建得到元模型。

9.根据权利要求8所述的方法，其特征在于，所述在模型元素上附加OCL逻辑表达式包括：利用OCL描述不变量约束。

10.根据权利要求9所述的方法，其特征在于，所述轻量级建模框架包括LMF上下文、类型装载器、类型构建器和属性构建器。