测试驱动

测试驱动（精选九篇）

测试驱动 篇1

并联机床不同于传统机床的结构,它基于Stewart平台原理,实质是一种多环多自由度的并联空间连杆机构。6根驱动杆两端通过球铰或虎克铰分别与装有主轴头的动平台及上方的定平台相连,改变6根驱动杆的杆长,机床的主轴可以实现六自由度的空间运动。并联机床虽然优点很多,但没有被普及的原因还是精度问题,主要有安装驱动杆口的精度和驱动杆本身的精度,但最主要的还是驱动杆本身的精度,因此解决驱动杆的精度问题是解决整个并联机床精度问题的关键。驱动杆在机床中工作时,其精度问题包括:定位精度、刚度、反向间隙等。为了校核精度,必须要有一台专用的测试平台,实际测量驱动杆在空载和加载时工作状态,通过数据分析,找出问题所在。

1 驱动杆测试原理及测试台构成

1.1 驱动杆测试原理

驱动杆在实际工作时将受到轴向的拉伸和压缩力,为了能模拟实际工作状态,设计测试台时驱动杆由V形块支撑和固定,实际测量时,首先能模拟加载驱动杆在实际工作中可能遇到的各种载荷情况,将驱动驱动杆到达任何工作的位置,并能动态和静态的测试驱动杆的输入值和输出值。

1.2 驱动杆测试台的构成

a) 机械部分的设计:驱动杆测试台机械部分的作用主要是改变驱动杆输出的受力大小和方向,用以模拟驱动杆真实工作时的载荷,由于驱动杆是个二力杆,因此加载部分只需要在驱动杆的输出上加上一个轴向的力,这里用一段导轨槽和槽中的一个滑块来保证负载力始终在轴向上,驱动杆的输出固定到滑块上。如图1所示。

1) 导轨架用于支撑导轨及滑块。

2) V型块支撑架用于支撑驱动杆,确定了驱动杆的轴线与导轨方向一致。

3) 加载架用于支撑加载块的上下运动,通过架上的滑轮的带动,改变驱动杆加载时正向和反向的力的大小。

4) 滑块在控制部分的作用下,通过空载和负载带动驱动杆来回移动,进而协助测量驱动杆的输出位置。

b) 运动及控制的设计:运动及控制部分完成由计算到驱动杆输入端的所有工作,即接受计算机发出的运动命令,并完成相应命令驱动驱动杆做相应工作。其总体结构框图如图2所示。

c) 测试软件的设计:测试软件是在PC机上运行的主要程序,其任务是按照测量任务要求给出运动控制器的运动命令,并采集光栅尺和编码器的值,实时的处理这些值,并能在最后能按要求保存这些测量值。测试软件同运动控制通讯用的串行口,不需要单独编写驱动程序,VB 6.0提供了相应的控件,即MScommon。将MScommon加入主程序,并在代码中设置好串口通讯的各个参数。

2 实验驱动杆的测试

驱动杆性能主要围绕工作状况下杆的长度精度。驱动杆工作中伸或缩变化长度,受力状况为拉与压不断变化,因此,除了杆的长度精度外,驱动杆的性能主要体现在如下几个方面:杆的长度变化误差、杆受力方向变化导致的回差(空回误差)、杆的综合刚度。

综合几方面的测量与测试台的情况,以测量行程400mm为例,测量过程简要设计如下:

2.1 空载测试

1) 杆长标定后的“0”点为参考,消除伸长间隙后,保持码盘读数为“0”,伸长400mm,保存光栅与码盘数据在文件中;

2) 缩短杆长400mm,保存光栅与码盘数据在文件中。

2.2 加载拉力测试

1) 加拉伸载荷,记录光栅数据变动值,消除杆伸长间隙,同时调整码盘数值为“0”, 伸长400mm,保存光栅与码盘数据在文件中;

2) 缩短杆长400mm,保存光栅与码盘数据在文件中。

2.3 加载压力测试

1) 加压缩载荷,记录光栅数据变动值,消除杆伸长间隙,同时调整码盘数值为“0”, 伸长400mm,保存光栅与码盘数据在文件中;

2) 缩短杆长400mm,保存光栅与码盘数据在文件中。

2.4 刚度测试

在指定位置通过加载,监测驱动杆长度变化。

测试后,对数据进行了分析,根据数据测试了曲线图,找出了影响精度的原因,得出了建设性的结论。为理论研究得到了认证,同时对提高驱动杆的性能及并联机床的精度提供了参考价值。

3 结论

如何测试软硬盘驱动器参数 篇2

一、如何测试驱动器类型

随着PC硬件的高速发展,各种应用软件对外设的要求亦不断提高,这使得有些软件的设计者在开发软件时需要对主机的配套设备进行检查,以便能更好地利用这些设备。如对处理器CPU及协处理器的检测、对驱动器的检测等等。对于上述的测试,除CPU及协处理器的测试方法已有不少文章论述过外,还很少有对驱动器测试的论述。本文将详细介绍如何测试驱动器,并给出相应的子程序源码,读者可根据需要将其变成一独立程序,也可将其加入到自己的应用程序中去。

在提供的测试驱动器子程序中,使用了DOS INT 21h 的`设备管理功能调用 44XXh(IOCTL)的两个子功能:AX=4409h 和AX=440Dh。通过对What-Drv子程序的调用,可得到指定驱动器的类型。该测试子程序的调用方式为:

输入:AL=驱动器标号(A,B,C,...)

程序:CALL What-Drv

输出:CF= 0 成功

AL= 驱动器类型(提供之源码中有各种类型说明)

DS:DX= Device-Params读取参数缓冲区,共有32Bytes长度

CF= 1失败

AX=错误代码

1.测试指定驱动器状态

本子功能是测试所指定驱动器是否为单机或网络之共享状态输入:AX= 4409h

BL= 0,1,2,...(0=defult,1=A,2=B,3=C,...)

中断:INT 21h

输出:CF= 0成功

DX=返回状态(这里仅讨论DX寄存器的Bit12,在返回的参数中,DX还有其它许多状态值,本节将不在此讨论)

若Bit12=0,则为单机状态

Bit12=1,则为服务器共享状态

CF= 1失败

AX=错误代码

2.读取指定驱动器参数

本子功能将读出指定驱动器的各种参数,包括驱动器类型、文件分配表FAT大小,根目录ROOT大小,及其它BPB各种磁盘参数。本子程序仅读取驱动器类型参数。

输入:AX= 440Dh,

BL= 0,1,2,...(0=defult,1=A,2=B,3=C,...)

CX= 0860h 这里 CH=08h表示磁盘驱动器

CL=60h表示读取驱动器参数

DS∶DX=Device-Params指向读取参数缓冲区,共有32 Bytes长度

中断:INT 21h

输出:CF= 0成功

DS∶DX=缓冲区包含读出驱动器参数

CF= 1失败

AX=错误代码

3.磁盘参数区

表1为一130mm 1.2MB的软盘驱动器参数信息(共32字节长度)。

@@08a08600.GIF;表1@@

4.测试驱动器源码(程序1)

程序1:

;------------

; Check Drive Type

;Input: AL=Can be any drive letter(A,B,C..)

;Output: CF=0 Successfully

; AL=drive type will be returned as an

; ERRORLEVEL.

; DS∶DX=Pointer to parameter block

; CF=1 Failed

; all registers restored.

;-----------------

; ERRORLEVEL Result

; --------------

; -1Drive isn′t local

; 0320K/360K 130mm.drive

; 11.2M 130mm.drive

; 2720K 90mm.drive

; 3Single-density 203mm.drive

; 4Double-density 203mm.drive

; 5Hard disk

; 6Type drive

; 71.44M drive

; 8Something else

;------------;

What-drv proc near

push cx ;save registers

push bx

mov bl,al

and bl,lfh ;bl=0,1,2..

mov ax,4409h

;Check workstation /server

push bx

int 21h

pop bx

jb What-error ;Error to exit

test dh,10h ;test server?

jz What-continue

mov al,-1

jmp short What-Exit

What-continue:

mov ax,440dh

mov cx,0860h

;Get device paramters

push cs

pop ds

mov dx,offset Device-params

int 21h

jb What-error ;Error to exit

mov al,[Device-Params+1]

;Get device type

What-Exit:

clc ;Successfully flag

What-error:

pop bx ;recover registers

pop cx

retn

What-drv endp

Device-Params db 32 dup(0)

二、读取硬盘参数

硬盘是主机重要的存储设备,不同厂家,不同大小的硬盘参数均不相同。这里所说的硬盘参数是:磁头数、簇面数和扇区数。本节将给出一个读取硬盘参数的子程序(不含逻辑,即将一个大硬盘分成两个以上分区。当然读者也可修改本程序,以便能识别两个以上分区的硬盘)。在下面的程序中,将首先读取硬盘的主引导区 Master boot record,因为所有的硬盘参数都存放在里面。程序流程如下:

(1) 将指定的物理硬盘主引导区读入缓冲区

(2) 在引导区偏移地址1BEh处获取相应的硬盘参数

(3) 通过计算求得该硬盘的磁头数、簇面数和扇区数

(4) 由得到的硬盘参数求得其容量大小

Get-FdiskParam 子程序调用方式为:

输入:AL=硬盘物理ID号(80h 或 81h)

程序:CALL Get-FdiskParam

输出:CF=0成功

AX= 硬盘容量大小(Hex)

CX= 簇面数

DL=扇区数

DH=磁头数

CF=1 失败

1.硬盘分区表参数

在硬盘主引导区的1BEh位置即为硬盘分区表参数区,一个硬盘最多只能分成四个逻辑分区,每个分区参数表占10 h Bytes长度。本节为方便起见,仅设定硬盘为一个分区的情况,至于多分区情况,请

读者通过修改本程序亦可获得。这里以162MB硬盘主引导区中的分区表参数为例。

@@08A08601.GIF;表2 硬盘分区表参数@@

由参数表可查出:磁头数=15,簇面数=1010,扇区数=22

2.硬盘容量计算

通过分区表的参数,还可求得硬盘的容量大小。在提供的程序中对硬盘容量的计算均按16进制方式:

硬盘容量(MB)=磁头数×簇面数×扇区数×512/1024为精简程序,笔者在计算时舍掉了许多余数(舍掉较多,仅保留整数),故此计算得来的容量与实际容量有些差异,请读者引用时注意。

3.读硬盘参数源码(程序2)

程序2:

;----------------

;Get Hard Cyls,Sector,Head,Size

;Input:AL= Fdisk ID(80h,81h)

;Output: CF= 0 successfully

;AX= Fdisk size(Hex)

;CX= Number of Cylinders

:DL= Number of Sectors

;DH= Number of Heads

;CF= 1 failed

;-------------

Get-Fdiskparamproc near

cmp al,80h ;test Fdisk ID

jb Get-FdiskExit

mov cx,cs

mov ds,cx

mov es,cx ;set DS,ES segment

mov dl,al ;Fdisk ID

mov bx,offset Partition-area

mov cx,1

mov dh,0

mov ax,201h ;read partition sector

int 13h

jb Get-FdiskExit ;failed to exit.

mov bx,offset Partiton-area+1beh

mov al,[bx+8] ;Sector counter

mov ah,[bx+5] ;Head counter

mov dl,[bx+7] ;cylinder lower

mov dh,[bx+6] ;cylinder high

mov cx,6

shr dh,cl

inc dx ;get cylinder

push dx ;save cylinder

push ax ;save head & sector

mul ah ;compute Fdisk size

mul dx

mov cx,11

Loop-shift:

shr dx,1

rcr ax,1

loop Loop-shift ;Get Fdisk size

pop dx ;sectors & heads

pop cx ;cylinder counter

clc ;clear CF flag

Get-FdiskExit:

retn

Get-FdiskParamendp

测试驱动 篇3

【关键词】软件测试课程；任务驱动教学；应用策略；提升实效

软件测试作为一项新兴科技，本身具有一定的繁琐性、枯燥性，给学生学习带来了诸多困扰。随着社会科技的发展，软件测试课程教学项目不断丰富，增加了学生的学习困难。如何降低软件测试课程教学难度，提高其教学实效，一直是教育界研究的热点。任务驱动教学的提出和开展，在某种程度上缓解了这一问题，突出了学生的教育主体地位，强调了教师主导功能的发挥，使得软件测试课程得到了分解，有助于学生的自主学习。

1 任务驱动教学的相关概述

任务驱动教学以建构主义理论为指导基础，主张教师将教学内容隐含在若干具有代表性的任务中，是一种以完成任务为中心的教学活动。在此过程中，学生受完成任务动机的驱动，通过任务分析，确定其中蕴藏的科学知识，并探寻问题和解决问题，从而在教师的帮助及指导下，自主获取、加工与应用学习资源。任务驱动教学打破了传统教学中强调循序渐进学习的常规，凸显了现代教育以学生为主体的特征，改变了以教定学被动局面，有利于学生的全面发展。完善的任务驱动教学体系应该确定任务核心，解决怎样驱动的关键问题，重视以人为本理念的渗透。而教师作为教学的主导，需要完成向学生传递知识权威角色向学生学习辅导者、合作者的轉变，在合理设计任务、布置场景的基础上，对学生的活动表现作出综合、客观评价，进而有针对性地进行引导教育，养成学生良好的自主学习习惯。

2 软件测试课程教学中开展任务驱动教学的策略

作者结合上文对任务驱动教学的分析，提出了以下几种软件测试课程教学中开展任务驱动教学的策略，以供参考和借鉴。

2.1 创设情景

一堂精彩的课程需要良好的情景触发，引人入胜的开课能够使学生快速融入到课堂中，这也是任务驱动教学的基础。为了最大限度地激发学生的求知欲，教师在软件测试课程教学的开端应该创设任务情景。具体而言，教师可以问题引发思考，开课之初先提出疑问，让学生带着这些疑问踏上探索学习之路，使之有目的地进行学习，引导其自主探究答案。如此既增加了软件测试理论概念教学的趣味性，还加深了学生对知识的理解和印象。值得注意的是，设计问题应尽可能贴近生活，找寻学生感兴趣的话题如“熊猫烧香”等，将学生的思绪集中起来，使其快速地找出答案，让他们感受成功喜悦的同时培养学生的思维能力、探究能力。伟大的科学家爱因斯坦曾经说过：“兴趣是最好的老师。”软件测试课程教学教师应该时刻注意调节气氛，养成学生良好的学习兴趣，鼓励他们创造思维的发展，从而增强学生自主探究学习的动力。

2.2 布置任务

软件测试是一门实操性很强的课程，注重学生的实践训练。因此，教师要保证每一项布置任务的可操作性。一般情况下，教师都会对相关知识进行深入解说和演练之后，就会组织学生实践操作。通过上机操作，学生基本会对所学知识有更深的理解和掌握，也是其项目经验积累的有效途径。所以，软件测试课程教学教师布置任务时，应注意预留出实践操作的时间，提升学生的综合素养。素质教育背景下，新课程改革强调了学生自主学习。任务驱动教学重在体现学生的主体地位，加之教师适时适当的指导，充分发挥学生的主观能动性，从而养成学生自主学习的意识和习惯，有利于促进学生的全面发展。为此，教师把以生为本理念渗透到教学任务当中，认真分析学生之间的个性差异，保证任务的科学性、可行性。教师可以引导学生根据自身的实际情况，设计自己的测试流程、工具、用例等，由其自主完成软件测试。

2.3 评价引导

评价是为了帮助学生更好地认清自身素质和能力，从而有针对性地制定学习计划。良好的评价结果还是教师优化课程教学的重要依据，是任务驱动教学不可或缺的一部分。教师需要在学生完成软件测试教学任务之后，尤其展示自己获得的成果，并组织学生进行自评和互评，肯定其有效行为的同时探究更加完善的解决方案。在此过程中，教师可以将学生群体划分为若干合作小组，在合理分派组内任务的基础上，以小组单位完成教学任务，必要时教师给予适当地指导。此后，让各小组展示自己的成果，并在全班范围内进行讨论，集思广益，共同探究各解决方案的利弊，从而有针对性地进行改进。如此，不仅可以降低学生的学习难度，还可以培养学生的思维能力、合作能力和反思能力等。任务评价要注意保证全面性、公正性以及客观性，并采取有效的激励措施，给予表现优异的学生适度奖励，鼓励学生进行自主探究式学习，以增强学生的参与兴趣和积极性。

3 结语

总而言之，软件测试课程教学中开展任务驱动教学十分重要和必要。由于个人能力有限，本文作出的相关研究可能存在不足之处。因此，作者希望各院校进一步改进和优化软件测试课程任务驱动教学，建立更加完善的教学体系，并结合本文论点在不断的实践探索中，制定更多有效的任务驱动教学策略，以提升教学实效，实现学生的全面发展，使之成为社会经济发展需求的合格人才。

参考文献

[1]黄翘，何银川.任务驱动教学法在高职《软件测试》课程中的运用[J].现代计算机（专业版），2015，06：43-46.

作者简介

姚永明，现为南京邮电大学通达学院助教。

于明潇，男，现为南京邮电大学通达学院2013级通信工程专业130012班学生。

张余，现为南京邮电大学通达学院2012级计算机科学与技术（信息安全）专业120011班学生。

谢超，现为南京邮电大学通达学院2012级广播电视工程专业120040班学生。

作者单位

QTP数据驱动测试方法探讨 篇4

自动化测试是使用软件来控制测试执行过程, 需要在适当的时间使已形式化的手工测试过程自动化, 最好的自动化测试工具是能够将工具与测试需求达成一致, 并且提供高度可自定义的工作流程和跟踪报告能力[1]。

Mercury Quick Test Professional (简称QTP) 是企业级自动化测试工具, 已被惠普公司收购, QTP主要适用于功能和回归测试的自动化, 采用关键字驱动的理论来简化对测试用例的创建和维护, 用户可以直接录制屏幕上的操作流程, 自动生成功能测试或回归测试脚本。当脚本录制完成, 并不能完全立即使用, 主要原因是录制的脚本只能覆盖一条测试用例, 并且对数据的依赖性很强, 更换数据后就会出错, 这种线性的自动化测试方式缺点很明显, 需要对脚本进行优化和增强。

适当调整和增强测试脚本, 提高脚本的灵活性, 数据驱动方式的测试脚本是解决这类问题的重要方式。数据驱动的测试方法要解决的核心问题是把数据从测试脚本中分离出来, 从而实现测试脚本的参数化[2]。

1 数据驱动测试的步骤

数据驱动测试一般按以下步骤进行[3]:

1) 参数化测试数据, 绑定到数据表格中的各个字段;

2) 在表格中编辑多行的测试数据, 取决于测试用例及测试覆盖率的需要;

3) 设置迭代次数, 每次迭代选择一行数据。

2 参数化方法

2.1 Data Table实现参数化

本测试是测试飞行程序的登录用户名和密码, 将多组测试数据放在Data Table的Global或当前Action表中。Data Table是一种最容易实现参数化的方式。

2.2 环境变量实现参数化

参数化在“Value Configuration Option”对话框中设置“Name”和“Value”框中进行设置, 环境变量实现参数化当在同一个Test中多个Action调用同一个参数时, 使用环境变量作为参数是一种很好的方式, 但每个参数值都要指定, 如果测试多组数据工作量就大了。

2.3 使用文本文件实现参数化

先在脚本根目录中创建txt文件, 将内容输入文件中, 输入格式如图4。

QTP脚本代码如下:

do-loop结构是为了使多组数据循环执行下去, 直到文件结尾, ifelse-endif结构是判断对话框“Flight Reservations”的存在与否来推断用户和密码是否输入错误的情况处理, 让循环能继续下一组数据的验证。

2.4 使用excel表实现参数化

先在脚本根目录中创建xls文件, 将内容输入文件中, 输入格式如图5。

QTP脚本代码如下:

datatable.Import Sheet语句是导入Excel外部文件到Data Table的Action1中, do-loop结构依然是为了使多组数据循环执行下去。

3.5 使用XML文件实现参数化

先在脚本根目录中创建XML文件, 将内容输入文件中, 输入格式如图6。

QTP脚本代码如下:

QTP脚本中用到了双层for语句, 外层for语句用于多组数据的循环, 内层for用于同组数据多个字段间的循环。

4 结论

通过参数化方式, 从外部数据源或数据产生器读取测试数据, 从而扩大测试的覆盖面, 提高了测试的灵活性。除了以上方式实现参数化, 还可以使用数据库表作为数据源。在实际的测试工作中, 我们可以根据需要灵活组合方式来进行使用。

摘要：在使用QTP进行自动化测试时, 数据驱动起着举足轻重的作用, 进行数据驱动关键是实现脚本的参数化。笔者结合实例总结和归纳了多种进行数据驱动参数化的方式。

关键词：QTP,自动化测试,参数化

参考文献

[1]王磊.关键字驱动的自动化测试框架设计与实现[J].电子测试, 2010, 41 (8) :91-97.

[2]王蕾.基于数据驱动的软件自动化测试框架系统的研究与实现EJ1[J].软件导刊, 2009, 38 (6) :33-34.

液晶屏显示驱动芯片测试技术研究 篇5

目前, 虽然以京东方、华虹NEC为代表的多家企业投入大量资金研发LCD Driver芯片, 但国内LCD Driver芯片市场仍被外国企业垄断。消费电子产品价格敏感性特别明显, 如何减低成本成为厂商占领、扩大市场份额的一个决定性因素。目前测试成本已占芯片总成本的30%以上, 所以设计一套高效的芯片测试方法可以大幅降低芯片成本, 以适应激烈的市场竞争显得尤为重要。由于通用测试手段无法直接用于LCD Driver芯片的测试, 因此在LCD Driver芯片设计与制造的产业链中, 测试已成为制约发展的一个瓶颈。

由于LCD Driver芯片测试技术含量高、技术进步快, 目前, LCD Driver测试技术完全掌握在日本、美国等企业手中, 我国至今还没有成熟的技术可应用于量产测试, 目前国内有学者进行了相关的研究, 其中有部分研究只是针对某些单项进行研究[1,2,3], 测试技术还停留在实验室。而还有些研究者只是针对某些特定信号的驱动芯片进行了测试[4,5,6]。另一些学者就针对驱动芯片里的某些功能和芯片展开了研究[7,8,9]。

本文提出一套高效、实用测试方法, 采用多通道与高压模拟通道同步测试技术、色阶测试技术、特殊封装适应性技术和ATE等技术, 并结合LCD Driver芯片的特点开展深入研究。通过这些方法可以实现减少测试费用、提高驱动芯片测试吞吐量的同时也能保证客户对芯片质量的严格要求。

1 关键技术介绍

LCD Driver芯片有以下几个特点:频率高、差分低摆幅、精度要求高、模拟测试通道数量众多且需要并测。本文针对这些特点开展共性与关键测试技术研究, 从而提高ATE系统测试效率、优化测试结果。LCD驱动芯片内部包括了多路电压、电流源, 通过改变电压输出值使得液晶屏面板产生不同的输出色彩, 因而它的性能直接决定LCD的显示效果。针对驱动芯片主要进行如下几个关键技术的研究, 下面依次进行介绍。

1.1 开展多通道与高压模拟通道同步测试技术研究

LCD驱动控制芯片是典型的数-模混合SOC芯片, 对于该类型芯片, 通常器件的输入、输出和各类IO PIN数量较多, 其中模拟PIN又占有绝大比例。如何对该类芯片众多的输入、输出PIN进行并行同步测量是该项测试技术的难点之一, 且模拟管脚测试时容易受到众多因素的影响、比较常见的因素有系统纹波工频干扰、复杂接地网络互联和其他测试中通常可忽略的管脚寄生电容的影响等, 这些因素都使得测试精度变差。而数字管脚中, 数据速率多在200MHz以上, EMC问题也同样不可忽视。

针对多管脚高速器件, 测试中如何实现多信号同步是另一项技术难点, 本文针对该技术难点采用了数字接口硬件, 利用数据寄存器和锁存器的硬件实现方法来进行多信号同步, 其硬件实现框架如图1所示。

1.2 开展色阶测试技术研究

LCD Driver器件的一个核心测试项目就是色阶测试, 这部分测试解决直接反映了IC的产品质量。基于白盒测试原理, ATE或者外部激励施加不同的、特定的RGB信号编码序列, LCD驱动芯片应该输出在指标范围内的电压信号。这些电压信号是否符合指标要求也就同时决定了该器件在正常使用阶段能否驱动液晶屏显示正确的色彩。每个驱动IC电压输出对应8比特编码, 8位二进制输入可产生2的8次方共64个编码序列, 根据需求不同, 有两种方法对LCD驱动器件的模拟输出进行测试。一种是快速低精度的电压比较方法;一种是相对慢速高精度的电压均值采样测试方法, 电压测量精度取决于采样ADC位宽和部件整体噪声水平。表1列出了编码序列对应的模拟电压值, 如表1所示。

对于大屏幕的显示器件来说, Driver IC的输出PIN数量巨大。一般的数字采样测量单元测试部件的测试时间为几到几十个微秒, 本次测试的样品共645个待测管脚, 每管脚包含128个电压值, 每次测试包含82560项测试结果, 由此可知测试时间将会比较长。通过实践中大量实验与技术验证, 采用了两个技术方法来优化总体测试时间。首先, 在测试系统总成本允许的情况下, 测试设备提供更多可同步并行工作的采样测量单元, 在单位时间内同时对多个LCD驱动器件的输出进行采样。其次根据被测器件特点, 选用采样频率更快的测量单元进行连续采样、并优化后台数据传输与采用分布式数据处理方式, 也可进一步提升测试效率, 提高测试吞吐量。

研究中开发了专门的测试软件作为测试工具来完成色阶测试, 解决测试过程中耗时长的问题。利用本文搭建的测试系统, 在645管脚中随机抽取一个管脚的测试数据与参考数据进行比较, 分别记录误差百分比。根据测试结果可以看出, 原测试数据在±0.4%范围内波动, 波动比较大, 通过本系统进行优化和改进后, 测试数据在±0.25%范围内波动, 波动范围变小, 满足测试要求。在645个管脚中随机抽取一组管脚的某一个电压值进行数据分布分析, 以此评估测试系统的测试稳定性。原测试结果在8.07~8.14范围内波动, 波动范围约为0.86%。通过本文的优化方法以后, 从图2中可以看出, 分布数据在8.09~8.12范围内波动, 波动范围约为0.37%, 较之前的测试结果有明显改进。如图2所示。

从以上的对比结果来看, 经过本文的优化和改进后, 测试精度和测试稳定性都有很大的提高的改善。

1.3 特殊封装的适应性技术

考虑到缩小LCD模块尺寸、提高集成度的具体需求, 厂商多采用COG (chip on glass) 封装方式来封装驱动芯片。但从测试角度来讲, 这种封装形式却极大增加了测试的难度与成本。集成电路全周期生产工艺中通常包含有两个测试环节, 中测 (CP) 与成测 (FT) , 分别在wafer阶段和封装完成后阶段对器件功能特性和直流参数等指标进行完整验证。

在wafer测试阶段, ATE测试机台采用线缆或者直接硬连接方式与探针卡相连, 探针卡最终再通过探针与wafer上的IC pad相连接。对于LCD驱动IC高密度和高频的测试需求来讲, 如何保证探针卡信号完整性和通用适配性也是整个测试过程需要重点解决的问题之一。由于测试通道信号频率较高 (100MHz以上) , 探卡与测试设备采用直接硬连接的方式, 尽量减小系统本身和外部电磁环境的影响。

本项目将对特殊封装的适应性方案进行研究, 提出了一种能够适用于多种封装并能够根据不同封装形式快速转换的技术方案。方案使用PCB设计形式, 所有信号输出至探卡, 通过探针与被测管芯连接。探针卡如图3所示。

探卡制作过程中有如下技术关键点。

(1) 信号阻抗与skew偏斜控制。通过仿真计算, 设定高速差分线宽6mil, 间距8mil, 阻抗控制为100欧姆。并严格按照提供完整信号回流参考平面的要求, 为高速通道信号提供完整电源或者地参考平面。对数据组信号约束等长要求在50mil范围内, 严格控制信号间的skew偏差。

(2) 地信号连接。首先保证模拟电路和数字电路的地线不能直接连接, 系统设计上采用了远端汇流排共地连接的方式。PCB上根据信号类型划分不同的模拟信号区域和数字信号区域, 并参考相应的地平面, 且两个地平面不能重叠。当地平面信号构成完整环路系统时, 可以大大增加系统噪声容忍度。

(3) EMC设计, 选择合理的导线宽度, 应尽量减小印制导线的电感量;采用正确的布线策略采用平等走线可以减少导线电感, 如果布局允许, 最好采用井字形网状布线结构;在电路设计中, 通常采用源端匹配和终端匹配两种电阻匹配方式来减小信号的反射。LVCMOS电平常用设计为源端串接30欧姆左右电阻吸收反射回来的能量, 终端匹配通常对电源和地信号各接100欧姆左右的电阻。具体设计需求不同, 匹配电阻阻值的选择还同时需根据具体IC数据手册中的输出电流及输入电流来决定。

探卡制作完成后, 对探卡分别进行信号传输测试、探针间阻抗随频率变化的测试。通过ATE测试设备对探卡施加信号, 在探针端对信号进行测量。数据信号输出形态良好, 没有明显变形, 输出信号相比输入信号延时约0.5n S, 对芯片测试无影响。另采用阻抗分析仪对探卡的阻抗特性进行了分析测试, 测试频率范围在5 MH z到40MHz, 数据显示探卡印制线电容在测试范围内最大值为0.32p F, 最小值为0.18p F, 与测试频率呈现负相关, 即在高频下电容较小, 因此对高频信号没有明显影响。基于以上判断, 探卡可以满足高频测试的要求。

4 结语

液晶屏显示驱动芯片测试技术是整个驱动芯片设计制造过程中的关键技术, 是保证芯片品质的重要手段。本文提出了一个实用的测试方案, 同常规采用的方法相比, 在减少测试时间、提高ATE测试效率上具有一定优势。方案中设计制作的自适应探卡, 可以匹配不同型号的驱动芯片。通过这些方法可以实现减少测试费用、提高驱动芯片测试吞吐量, 实现对LCD驱动芯片的高效、高质量测试, 对液晶驱动芯片测试技术的发展起到了一定的推动作用。

摘要：液晶屏显示驱动芯片广泛应用于数码产品领域, 近年来与之配套的驱动芯片的需求量也大幅度增加。驱动芯片测试贯穿在芯片的设计、制造与应用的全过程中, 是保证芯片品质的重要手段。由于驱动芯片不同于一般的通用芯片, 通用测试手段无法用于该类芯片的测试, 目前该技术主要掌握在国外企业手中, 因此在驱动芯片设计与制造的产业链中, 测试技术已成为制约发展的一个瓶颈。针对此背景, 本文提出一套高效、实用测试方法, 采用多通道与高压模拟通道同步测试技术、色阶测试技术、特殊封装的适应性技术和ATE等技术, 可以实现减少测试费用、提高驱动芯片测试吞吐量的同时也能保证客户对芯片质量的严格要求。

关键词：液晶显示驱动芯片,芯片测试,多通道同步测试,色阶测试

参考文献

[1]杨卫丽, 赵野, 黑勇.用于LED驱动芯片的高低边电流检测电路[J].微电子学与计算机, 2013, 30 (01) :94-96+99.

[2]韩新峰.LED驱动类IC的多SITE高效测试[J].电子与封装, 2015 (9) :17-20.

[3]王征宇, 章少云.基于数字测试系统的LCD控制驱动电路测试方法[J].电子与封装, 2013 (2) :11-13.

[4]李博, 魏廷存, 樊晓桠.手机用TFT-LCD驱动控制芯片的测试电路结构设[J].微电子学与计算机, 2006, 23 (12) :125-128.

[5]李妥, 李奇奋, 李福乐, 陈志良.大电容负载LCD驱动芯片的测试及性能改进[J].液晶与显示, 2011 (05) :620-625.

[6]梁茂, 魏廷存, 魏晓敏, 李博.单片集成TFT—LCD驱动芯片内置SRAM验证技术研究[J].液晶与显示, 2008, 23 (1) :91-95.

[7]向荣, 陈祖希, 霍伟伟.基于NiosⅡ的LCD驱动IP核的设计[J].计算机工程, 2008 (5) :246-247.

[8]章少云, 王征宇.点阵式LCD控制驱动电路的测试方法[J].电子与封装, 2008 (12) :24-26.

基于数据驱动的自动化测试平台设计 篇6

2007年10月17日收到数据驱动自动化测试是一种数据被包含在输入测试数据文件中,并且以数据来控制自动化测试脚本执行的流程和动作的测试。输入测试数据记录是从外部文件中读入的,并且是独立于测试脚本程序开发的。数据驱动自动化测试使用存档的测试数据来驱动自动化测试过程,这些数据通常以简单的文本文件或Excel文件(电子表格)形式存在。

1 系统总体框架

图1所示为本自动化集成测试平台的系统架构图,最上一层为测试任务和测试的驱动控制,二者通过配置模块解析关键数据后相互联系。数据驱动主要作用在测试套件级别上,由测试套件读取测试数据,传递给测试用例进行具体地操作测试。日志记录主要是记录底层平台与测试用例的相关信息,而测试报告则是在测试套件级别上产生。该自动化测试平台的搭建思路就是编写基于原子接口操作的测试代码,通过JUnit/TestNG测试框架进行相应组合、设置相互间的依赖关系,由数据进行驱动。这样只需根据测试用例来组装成测试套件,即可按照测试用例所描述的功能来进行自动化测试。

2 数据驱动测试框架的设计

本文所设计的框架中,测试的输入数据是从数据文件中读取,并通过手工生成的测试代码或脚本被载入到变量中。变量用来存放输入值, 存放输出的验证值。在测试程序中,测试代码/脚本来读取数据文件,记载测试的状态和信息。由图2可见,测试的执行先从启动测试脚本开始。脚本向驱动控制提供驱动控制数据文件来激发核心数据驱动引擎;测试的驱动控制处理数据文件,将相关信息传递给测试套件的驱动控制,从而激发测试套件。测试套件的驱动控制处理接收到的相关信息,需要调用测试用例的驱动控制。而测试用例的驱动控制会激发测试脚本,试图保持应用程序与测试同步。当测试脚本遇到一个指定组件的低级命令时,它会判断包含的组件的类型并激发相关的Test Case来处理任务。数据驱动引擎由如下三个部分组成:

测试用例的驱动控制:即测试用例的执行。测试用例的驱动控制对应的是数据定义层,它所完成的工作是预先定义好的。此级别可以生成日志记录,供详细分析使用。具体实施方案分以下三步:设计测试用例、手工运行测试、自动化测试用例执行。

测试套件的驱动控制:即测试套件的执行。测试套件的驱动控制对应的是数据操作层,关心自动化测试如何去做,并将相关参数传递给测试用例。测试报告是在Test Suite级别上生成的。对于测试用例的执行顺序控制,应创建自定义的Test Suite来指定,同时测试报告也是在Test Suite的级别上生成的。对于Test Suite,其构造方法如下:创建Test Suite,导入要测试的接口对应的测试用例类;实例化测试用例类,传入相应的参数。

测试的驱动控制:即测试行为的控制。主要的任务分为如下两点:测试数据的选择;测试套件的控制。测试的驱动控制采用Java与XML实现,其主要目的是对测试套件的驱动控制和测试用例的驱动控制进行包装,与自动化部署相集成,使其更易于使用。

3 配置模块的设计

由图1可知,配置模块是数据驱动引擎与自动化测试间沟通的桥梁。为了最大限度地实现重用及可扩展性, 配置模块采用三层脚本结构,分为重用脚本、测试脚本和映射脚本三层,三层脚本分别实现不同的角色和功能,其组织结构如图3所示。

重用脚本:重用脚本集中处理有关解析XML、文件I/O等相关请求的公共类,为错误的回溯功能和配置文件的管理做出铺垫;根据本系统的不同版本、不同的前台,应用自动调用相关的构造模块。实现公共模块的脚本大多可以在不同的测试过程中实现重用。实现一次编写,多处共享,降低测试脚本的维护工作量。

测试脚本:测试脚本集中处理各个接口调用,解决相应的传入参数、返回值和模块之间的依赖关系,记录断言失败/错误信息,提供相关回溯功能测试脚本实施对特定功能和业务功能的测试,是一种针对特定的、被测试功能的脚本。

映射脚本:映射脚本实现对象逻辑名与本系统真实对象之间的映射关联。采用三层脚本组织结构其优点是:

(1)测试自动化设计与测试用例设计;

(2)测试自动化与测试设计分开;

(3)实现数据驱动,降低测试脚本的数量,从而降低它的维护工作量。

(4)基本脚本重用,确保自动化测试的投入回报不断提升。

配置模块采用三层脚本结构,目的是将脚本与数据分离,更好地实现数据驱动,减小维护脚本的开销。其组织结构图如图4所示。每层脚本功能如下:

(1)重用脚本集中处理有关解析XML、文件I/O等相关请求的公共类,为错误的回溯功能和配置文件的管理做出铺垫;集中处理解析、构造URL相关请求,并根据本系统的不同版本、不同的前台应用自动调用相关的构造模块;

(2)测试脚本集中处理各个接口调用,解决相应的传入参数、返回值和模块之间的依赖关系,记录断言失败/错误信息,提供相关回溯功能测试脚本实施对特定功能和业务功能的测试,是一种针对特定的、被测试功能的脚本;

(3)映射脚本实现对象逻辑名与本系统真实对象之间的映射关联。映射脚本是自动化测试的关键,它可以使测试工程师和自动化测试脚本开发工程师进行工分工,实现测试开发与软件开发的同步。

由于配置模块中每层脚本所实现的功能比较杂,所以使用配置模块间的协作图来表示其关系,如图4所示,具体流程解释如下:

(1)由核心数据驱动引擎启动整个测试;

(2)映射脚本接到指令,调用重用脚本对外部数据文件进行解析;

(3)重用脚本解析完毕后,将其结果返回给映射脚本;

(4)映射脚本通过对重用脚本返回的结果与事先定义好的映射表进行比照,将其结果转化为核心数据驱动引擎所能识别的编码形式,并传递;

(5)核心数据驱动引擎收到映射脚本返回的结果后,组装测试套件及指定测试顺序,调用测试脚本进行测试并传递相关参数;

(6)测试脚本解析核心数据驱动引擎传递的参数,调用重用脚本;

(7)重用脚本对被测应用发出网络请求;

(8)被测应用返回相关信息,由重用脚本进行接收;

(9)重用脚本对接收到的信息进行解析处理,返回给测试脚本;

(10)测试脚本对接收到的返回信息进行断言判断,即判断测试是否成功,并在控制台输出相应的测试信息,同时将断言判断结果和详细信息传递给核心数据驱动引擎;

(11)最后核心数据驱动引擎根据接收到的测试结果信息生成测试报告并输出。

4 自动化部署

本设计采用Ant (Another Neat Tool,译为另一个整洁的工具)来完成自动化部署。自动化部署途径如图5所示。部署可以分为本地自动化部署和远程自动化部署两部分。之所以分成本地部署和远程部署两部分,原因如下:(1)本线上服务器均托管至数据中心,一般情况下为远程连接进行相关操作,远程部署在这种情况下应用频繁;(2)对于某些特殊情况,需要进行实时停机处理,本地部署是为这种情况而准备的。

5 总结

目前自动化测试平台的研究正不断的发展,本文根据自动化测试平台的架构,分别介绍了数据驱动引擎的实现、配置模块的实现、自动化部署的设计。设计一个良好的自动化测试平台还涉及很多的内容,需要在以后的工作中进一步学习和完善。

摘要：以目前流行的自动化测试框架为基础,以数据驱动测试框架为核心,采用数据驱动脚本技术,在设计自动化测试平台的过程中实现了测试数据与测试脚本的分离。同时借鉴了测试脚本模块化的思想,将测试脚本进行分层次、嵌套管理,完成了基于数据驱动的自动化集成测试平台的设计。

关键词：测试平台,自动化测试,数据驱动

参考文献

[1]Conallen J.Web application architectures with UML.Modeling ACM,1999;42(10):63—70

[2]Wu Ye,Offutt J.Modeling and testing Web-based applications.GMUISE Technical,2002;11:21—32

[3]宋艳芳,等.自动化软件测试.应用科技.2001;28(4):117

[4]张向芳,李华,姜英伟.软件测试自动化的实施方案.山西科技,2006;4:40—42

[5]Bertolino A,Mirandola R,Peciola E.Acase study in Branch testing automation.Systems Software,1997;38:47—59

数据驱动的自动化测试方法研究 篇7

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。 通常, 在设计了测试用例并通过评审之后, 由测试人员根据测试用例中描述的规程一步步执行测试, 得到实际结果与期望结果的比较。 在此过程中, 为了节省人力、 时间或硬件资源, 提高测试效率, 便引入了自动化测试的概念。

常见的自动化测试包括UI自动化和接口自动化。 UI自动化指的是通过模拟用户在软件界面的操作而进行的自动化测试, 典型的代表工具有QTP, Winrunner, Selenium, Webdriv er等。 UI自动化工具通常具有录制回放功能。 接口自动化通常是深入软件内部接口的一种自动化测试方法, 又有2 种比较典型的自动化测试方法: 数据驱动和关键字驱动。 我们这里重点介绍数据驱动测试。

数据驱动测试最典型的特点是测试数据和测试行为进行了完全的分离。 从系统的功能来说, 功能一旦实现, 那么就是一个黑盒, 只要提供数据即可进行测试, 这个数据包括两部分: 输入和预期的输出。

数据驱动测试按以下步骤进行:

(1) 编写测试步骤的数据, 并写到数据表格中的某个字段, 例如把数据放到Excel或xml中。

(2) 编写解析脚本和执行逻辑, 对上面的用例进行执行并输出测试报告。

2 XLSX概述

XLSX是Windows下面的Excel文件格式, 通常用它来维护和管理数据, 在Python中最常用的库是Xlrd。

安装: pip install xlrd

读取例子:

执行结果:

3 自动化方案设计

假设要实现一个计算器的自动化测试框架, 被测系统是一个计算器, 测试接口是计算器的4 个基本接口: 加、 减、乘、 除。 设计测试方案如下:

测试数据采用XLSX维护, 有4 个sheet: add/sub/mul/div分别对应4 个测试接口, 每个测试sheet里面的表格数据定义如下:

一个数据样例如图1 所示。

完整的程序如下:

被测程序calc:

数据驱动测试程序

4 结语

测试驱动 篇8

计算机硬件成本不 断下降,而软件应 用领域越 来越广,软件所要解决问题的复杂程度也越来越高。软件功能和质量不能满足实际需求,究其原因主要有:1软件开发过程中,计算机系统观和软件工程观没有得到落实,尤其是没有采用标准工程化的思想指导软件开发,软件需求随意变更,导致软件开发成本和进度难以控制和预测[1];2软件开发过程中虽然借鉴了工程领域某些原则,但大多将软件测试这一质量保证措施放在软件开发工作全部完成后进行。软件属于特殊的智力密集型产品,很难有统一的测试方法和标准保证和控制软件质量[2]。将软件测试方法和质量保证策略贯穿到软件项目生命周期各阶段,加强软件测试对提高软件质量和开发效率尤为必要。

1软件测试现状

从我国软件行业发展历程来看,大多企业往往注重软件设计和开发,而忽视软件测试和质量保障。大多测试工作由编写该模块代码的开发工程师来完成。软件测试和质量保证部门建制 缺失,普遍认为 软件测试 部门可有 可无,而开发人员又不愿意转为专职软件测试人员,从而导致专业技术精湛的软件测试人才缺失。

在高校教学中,往往忽视软件测试的重要性。大多学校没有专门开设软件测试与质量保证的课程,只是将其作为软件工程课程中的一个章节,仅分配4课时,且教学内容偏重于理论。教学中没有向学生灌输在软件生命周期各阶段都要对软件进行测试保障质量的思想;更谈不上在实际项目训练中运用软件测试与质量保证的原理和方法解决实际问题[3]。各高校加强教学改革,培养出具有实际经验的应用型软件测试人才尤为必要[4]。

2软件工程化生命周期与软件测试相互结合

软件工程方法使软件开发过程具有工程化特质。它将软件生命周期分为如下几个阶段:1软件定义阶段,包括软件计划、需求分析;2开发阶段,包括软件概要设计、 详细设计、编码实现、测试;3软件运行维护,包括软件运行、维护和升级。将软件工程每个阶段与软件测试和质量保证有机结合起来,形成一条主线,使软件测试和质量保证贯穿于软件生命周期中,保证软件质量[5]。软件开发生命周期各阶段对应的测试内容如表1所示。

软件工程各生命周期中完成的软件文档是检验软件质量的主要对象。程序中出现的错误,并不一定都是编码引起的,很可能产生于软件设计及需求分析阶段。解决、 纠正错误需追溯到前期工作。正因如此,软件测试和质量保证工作应着眼于整个软件开发生命周期,从软件开发项目生命周期第一个阶段开始,并贯穿于整个软件开发生命周期。

3基于项目驱动的课程改革

根据软件测试工程师应用型人才培养总体目标,基于软件工程项目实践驱动的课程安排可在同一学期开设《软件工程》、《软件测试与质量保证》两门课程。以实际软件项目为驱动,使学生深入理解软件工程、软件测试与质量保证的理论体系,并在项目实践中全面理解软件项目开发生命周期各阶段的任务以及测试方法。在整个项目实践过程中,提高软件需求分析能力、软件设计能力、编程能力、软件测试和质量保证能力,达到强化技能的目的。课程课时安排可课堂理论教学课时和专业实践课时各占一半。

在理论课堂教学中,根据不同阶段,选取具有代表性的案例,理论联系实际,使学生系统掌握软件测试和质量保证的基础理论知识。重点讲解功能测试有关内容:黑盒测试用例设计;逻辑测试即白盒测试用例的设计;白盒与黑盒混合型的灰盒测试用例设计。针对黑盒测试方法,详细讲解等价类划分法、边界值分析法、因果图法及功能图法原理和用例设计方法。可列举经典案例,如三角形等价类划分判定测试;数组边界值划分判定测试;自动售货机测试用例判定等。详细对比常用黑盒测试方法的优缺点和适用场景。针对白盒测试方法,重点讲解语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、路径覆盖方法的原理和用例设计,并列举程序设计流程图,逐一讲解方法应用, 对比常用白盒测试方法的优劣和适用场景。

在实践教学中,重点讲解逻辑测试和功能测试软件工具使用。对各测试软件进行详细介绍,将理论课中已讲解的测试用例进行逐一测试。以软件工程项目小组设计的软件实践项目为驱动,做好项目测试需求,设计完整的测试用例,并逐一进行测试,以便判定实践项目软件是否满足相应的逻辑和功能要求。根据项目小组所选定的开发语言和平台,选用不同的测试软件。其中,针对功能测试重点练习HP的loadrunner性能测试工具、QTP自动回归测试工具、winrunner功能测试工具等的使用;针对逻辑测试和项目选取不同的开发语言,重点运用C++ Test, JUnit,PHPUnit等工具完成软件项目单元逻辑测试。使用TestDirector对系统中所有测试用例数据、测试缺陷及bug进行定位、管理和跟踪。

项目小组形成完整的测试报告,提出具有可操作性的软件质量改善建议。在完善、改进测试方案的基础上,对软件项目进行迭代式再测试,使项目生命周期阶段推进和软件质量保证过程交汇推进,然后在软件项目实施的过程中完成安装、验收和运维测试,最终使软件达到软件需求规格说明书中所规定的软件功能、性能和质量标准。以软件项目为驱动的测试和质量保证各阶段工作内容如表2所示。

4结语

《软件测试》是计算机及软件工程专业的一门核心课程,是应用型软件测试人才所必须掌握的技能。本文提出以软件实践项目为驱动,在软件开发生命周期各阶段贯穿软件测试和质量保证的思维和方法。通过软件开发过程和测试过程交叉融合,使学生将计算机系统观和软件工程观运用到开发软件中,保障软件开发质量。学生往往更乐于接受实践教学,在真实环境中开发软件,并对其进行测试,可以通过加强实践教学环节,以适应行业对测试人才能力和素质的要求。

摘要：当前,软件测试人才培养模式不能完全满足行业实际需求。提出一种以软件工程实践项目为驱动的软件测试人才培养方案,将软件测试方法和质量保证策略贯穿到软件项目生命周期各阶段,达到培养软件测试应用型人才,提高其综合素质的目标。

关键词：软件测试,质量保证,生命周期,应用型人才

参考文献

[1]秦航,杨强.软件质量保证与测试[M].北京:清华大学出版社,2012.

[2]程茂,温静,吴玉洁.软件测试的教学研究[J].河北师范大学学报,2010(12):117-120.

[3]朱志慧.基于项目驱动的软件测试课程改革探索[J].电脑知识与技术,2014,10(33):7960-7961.

[4]董瑞志.面向软件测试工程师培养的《软件测试与质量保证》实验教学改革[J].教育教学论坛,2014(51):94-95.

测试驱动 篇9

在煤炭行业中, 煤炭品质 (简称煤质) 是影响企业效益的关键因素之一, 煤质管理贯穿于煤炭的生产、运输、销售等各个环节。目前, 煤质管理系统的建设取得了很大进展, 但仍存在一些不足:① 煤质管理系统在规模和复杂度上不断增加, 不能很好地与业务关联;② 煤质模型中潜藏的业务逻辑错误不能及早被煤质领域专家发现;③ 不断变化的业务逻辑导致了系统低层次的重复编码;④ 错误的业务逻辑决策下进行煤质软件项目, 成本过高难于修复。

针对上述问题, 本文提出基于模型驱动架构 (Model Driven Architecture, MDA) [1]的模型测试方法, 为煤质管理系统的开发和测试提供了一个新方向。在MDA中, 模型是所构建系统在功能、行为和结构的形式化表示[2]。基于MDA的模型测试在产生任何代码之前, 对需求规约进行充分的演练, 即在开发早期用UML (Unified Model Language, 统一建模语言) 图结合业务逻辑的形式建立测试模型、执行测试用例并且反馈测试结果[3]。将煤质管理系统开发过程中基于模型的测试集成到总体的测试进程中, 提供跨越整个开发生命周期的动态测试, 在测试的保护下, 不断重构模型, 以消除重复设计, 优化设计结构, 提高模型的重用性, 更好地指明设计模型上的缺陷以及需求实施失误, 从而提高煤质管理系统质量。

1 大型煤炭企业煤质管理系统建模

无论煤质管理系统是采用Web Service, EJB或其他构件技术和平台, 基于MDA的软件开发首先要建立平台无关模型 (Platform IndependentModel, PIM) 用于描述软件系统的业务功能和逻辑, 并用UML等建模语言来表示PIM。建立PIM的目的是为了理解问题域, 详述能够满足一组需求的系统行为。它获取和表达了正在建立的所有煤质管理系统的业务需求, 并且包含了对系统的所有规约, 但中立于任何实现 (平台) 。作为测试对象, 煤质管理系统PIM主要包含域模型图、用例图、顺序图、类图、协作图、状态图等, 建立步骤如下:

(1) 域模型图的建立。在域模型图中, 将系统按主题划分为不同的域, 每一个域表示系统中一个独立的主题事务。煤质管理系统层次架构如图1所示, 在服务层将煤质管理系统划分为煤质数据管理、煤质计划下达、煤层信息展示、煤质系统后台管理等域。以上域属于业务逻辑部分的内容, 无需依赖具体的平台或者实现。对域的划分将测试控制到具体的模型空间, 增加了业务之间的内聚性。域之间存在依赖关系, 对域间的交互分析可以借助UML顺序图来完成。

(2) 类图及协作图的建立。类图组成了域的静态视图, 是用来显示煤质管理系统中的类、接口及它们之间的静态结构和关系的一种静态模型。协作图描述了特定行为的参与对象的静态结构, 以及参与对象之间的动态交互。以煤质预测功能为例, 煤质预测基础数据包括:① 采制样员对工作面煤质煤样进行采取、制备, 通过化验分析生成的煤样检测基础数据;② 煤质科根据生产计划制定年度、月度以及月度分解的计划数据;③ 运销中心根据各质检站对商品煤销售数据进行统计, 形成各月商品煤煤质数据等。

(3) 状态图的建立。状态图是描述一个实体基于事件反应的动态行为, 显示了该实体如何根据当前所处状态对不同的时间做出反应。状态图由状态组成, 各状态由转移链接在一起。状态是对象执行某项活动或等待某个事件时的条件, 转移是2个状态之间的关系, 它由某个事件触发, 然后执行特定的操作或评估并导致特定的结束状态。工作面 (回采工作面和掘进工作面) 绘制状态图如图2所示。首先根据工作面要素, 按画图比例来绘制工作面示意图。根据毛煤月度分解计划数据和工作面要素, 计算出每月的开采位置, 并按颜色来区分已采和未采部分。当用户点击某个采样点位置时, 以资料卡的形式弹出该采样点的煤质柱状和相关信息。然后根据煤层煤样采样点信息, 计算出每个采样点在该工作面上的对应位置, 绘制出采样点。根据煤层采样点的煤质数据绘制出沿通风巷和运输巷煤质折线趋势图。最后根据煤质预测的开采计划和煤层采样点的各分层数据, 绘制出工作面, 若数据获取错误则绘制失败。

2 模型测试基本框架

尽管UML规范在MDA过程中是必要的, 但却没有包含可执行语义, 不足以进行可执行建模, 因此需要扩展更多的机制来支持精确建模和分析模型。动作规约语言 (Action Specification Language, ASL) 的出现弥补了这一缺陷, 它是一种符合UML动作语义标准的语言, 提供了操纵模型元素的能力, 为部分UML模型增加了可执行行为的定义, 并且又不偏向于任何实现技术。ASL语句在MDA过程中总是与常规UML模型元素关联, 例如与类的方法或状态图中信号发送关联。各抽象层之间的行为是相互映射的, 每一句PIM中的ASL语句都可以在平台相关模型 (Platform Specific Model, PSM) 和代码层中找到相应的实现[4]。

基于MDA的模型测试框架通过对测试过程的抽象化, 分离测试模型和测试执行, 模型测试流程如图3所示。测试设计人员侧重于对被测试系统需求和业务层面的理解, 从而通过正向或逆向手段建立针对某方面特征的测试模型, 并重用有针对性的测试执行手段。测试模型是基于MDA的模型测试的核心概念, 它在测试的不同阶段表现为不同视图。

(1) 需求模型:需求的形式化就是对需求的表述从自然语言转换成为UML的形式。在进行功能测试时, 输入需求, 对需求进行约束和形式化, 以便将需求模型转换为测试模型, 主要采用UML的用例图和活动图来表述。

(2) 测试模型:被测系统需求模型中加入ASL, 完成对模型中动态属性 (包括动作以及方法的行为) 的描述。描述后的模型具有了可执行语义, 形成测试模型。

(3) 测试用例集:ASL提供了操纵模型的能力, 可以根据业务逻辑和功能点建立测试用例集。

(4) 测试场景:在测试执行之前, 通过相应ASL语句描述测试的执行环境以及执行流程, 将测试用例按次序组合成互为因果的测试流程。在测试场景中更多的是体现需求对流程的描述, 对需求中各个业务流程、业务功能的测试[5]。通过该方法, 能够覆盖到应用系统的各个流程和不同的测试数据分支。

3 建模过程中的测试

加入ASL, 煤质模型具有可执行能力。完成对测试环境和测试用例构建, MDA开发过程利用模型的可执行能力来测试煤质管理系统的业务需求是否准确, 模型中是否存在潜在问题。在煤质业务逻辑中, 根据煤质基础信息以及采样员提供的煤层中煤、矸主要元素的位置、高度数值, 绘制工作面煤质信息图件, 其中绘制工作面展开图包括3 部分:① 沿通风巷和运输巷煤质变化折线趋势图, 主要反映灰分、硫分、发热量等煤质指标的变化情况。② 通风巷和运输巷煤层展开图, 主要反映煤层夹矸的分布情况。③ 开采进度示意图和煤层煤质柱状图。工作面展开图绘制所涉及的类图如图4所示。

3.1 测试初始化环境的构建

MDA不涉及具体技术, 也不依赖于特定平台信息, 因此不能将数据库引入作为测试一部分, 转而由测试初始化块负责对各类测试数据和对象赋值。测试初始化环境控制着测试初始状态以及所有测试预期, 它是否模拟了真实环境将决定测试结果的真实性和正确性。完整的工作面展开图包含以下几种类型的对象:掘进工作面要素、回采工作面要素、毛煤月度分解计划、煤层煤样、回采煤样以及煤质预测。其中2种要素是必须的, 而煤质预测数据由系统自动生成。上述对象生成顺序没有严格要求, 对象生成后可自动绘制工作面展开图。

对象和数据的创建方式有2种:① 在类的静态方法中初始化, 将对象的初始化放入方法体内进行, 数据初值以方法参数的方式传入。② 直接给对象属性赋值, 过程更加直观, 但是缺少初始化过程细粒度的控制。

毛煤数据、毛煤月度分解计划、煤层煤样数据采用第1种方式初始化。

[newRowCoal, errorMessage ]=RCD5:addNewRowCoal[313456, 15.7, 9.3, 0.52, …]

[newCoalMonthPlan, errorMessage ] =CMP2:addNewCoalMonthPlan['CM1010', '201209', 3705, …]

[newCoalSeamSample, errorMessage ] = CSS3:addNewCoalSeamSample['201', '5219', '1.25', 15.7, …]

回采工作面要素和掘进工作面要素采用第2种方式初始化。

stopeWB=create Stope_WB_Elem with face_number='5219'&length=1833&singleProd=180&…

driveWB=create Drive_WB_Elem with face_number='5219'&length=1833&singleProd=180&…

3.2 工作面绘制测试用例

工作面绘制过程中, 模型只是最初对业务逻辑上的描述, 并不会呈现出最终的系统效果, 基于ASL的模型测试, 是将业务逻辑的流程和场景描绘出来, 组合不同的测试用例来模拟功能实现, 以验证功能是否满足需求规格说明。

#测试用例1:查询预测对象, 并向工作面绘制对象发送状态跳转信号

#测试用例2:执行绘制方法, 验证采样点计算的正确性

上述测试用例中涉及到的公式为

公式1:煤层净煤量=分煤层厚度×单循环进尺×工作面倾斜长度×比重;

公式2:分煤层矸量= (各架对应分煤层厚度总和×分煤层长度) ×单循环进尺比重。

在测试用例中, 通过find-only操作, 确保模型中只提供了唯一的有效句柄, 判断actual不为UNDEFINED则向类对应状态图发送信号PT1:Request_Data () , 激发状态跳转并执行入口动作。入口动作中通过关联漫游导航对象关系, 验证对象属性值并进行业务的处理。若测试用例执行过程中报错或者被测系统的行为与模型期望不一致, 针对错误类型修改模型或者调整测试用例, 直到模型反映出系统的预期行为。

4 结语

模型作为MDA软件开发过程中的核心部分, 包含了所有系统需求规约, 对模型的测试研究, 可以从早期针对业务需求进行验证, 避免将重大缺陷遗留在系统中, 对后期的系统造成重大隐患。ASL语言对模型动作语义部分进行了完善的补充, 它操纵模型元素的能力, 可以有助于完成对基于模型测试中初始化环境的创建, 并且调用各个模型元素, 组织测试用例, 模拟出真实场景来精确地完成对模型的测试。

参考文献

[1]RAISTRICK C, FRANCIS P, WRIGHT J, et al.MDA与可执行UML[M].赵建华, 张天, 译.北京:机械工业出版社, 2006.

[2]刘静, 何积丰, 缪淮扣.模型驱动架构中模型构造与集成策略[J].软件学报, 2006, 17 (6) :1411-1422.

[3]刘扬, 李亚芬, 王普.模型驱动的测试用例自动生成框架[J].计算机工程, 2011, 37 (1) :39-40.

[4]张浩华, 赵海, 赵明.大型水电仿真系统的模型驱动架构设计[J].计算机工程与应用, 2009, 45 (4) :72-75.