自动化测试实现研究（精选9篇）
自动化测试实现研究 篇1
地添加测试用例, 为测试用例提供公用函数, 执行测试用例, 发送测试结果等功能。
1 自动化测试的重要概念
检查点 (Check Point) :将特定属性的当前数据与期望数据进行比较的地方, 用于判定被测试程序的功能是否正确。
成本收益比:并不是所有的测试都适合自动化测试, 衡量一个用例是否适合自动化测试一个很重要的参考是国际上流行的自动化测试成本收益比, 即是p=k*n/c1+c2。各个参数的意义下:
K=手工执行自动化测试案例所花费的时间成本。
N=自动化测试案例执行的次数
C 1=花费在自动化测试前期的 (时间成本+人力成本+金钱成本)
C 2=花费在自动化测试后期的 (时间成本+人力成本+金钱成本)
二八定律:1897年意大利经济学家帕列托发现的二八定律在软件行业同样适用, 而可以给我们很多启发, 指导我们的软件开发和测试。8 0%的用户经常使用的是20%的软件功能。在软件测试中, 80%的bug是集中在2 0%的软件模块中, 对于自动化测试来说, 找出这20%的测试用例是至关重要的。
2 自动化测试的执行步骤
每次脚本都是从一个统一的文件开始执行的, 就是如上的Start.py。这样做的好处是可以把每个脚本都需要处理的工作放到一个文件中去执行, 例如收集一些配置信息, 读取命令行参数。以这样统一的处理风格为脚本的可读性提供了保证, 也为简化了测试脚本的编写, 不用每次都要处理一些基本的事务。
启动文件Start.py首先会读取命行参数, 如pthon Start.py-s File Menu.suite-t FileNew
通过python的内置函数sys.argv就可以读取命令行参数, 非常方便。读取到命令行参数后, 在Start.py内部可以判断命令行的格式是否符合我们的格式, 如测试人员不小心把-s写成了-z这样就要退出测试执行。
如果输入的格式是正确的, Start.py负责在特定的目录下寻找特定的Suite文件和Testcase。Suite文件和Testcase的格式会在下边的具体实例中作介绍。
找到特定的Testcase后就可以执行测试用例, 根据检查点的通过或失败发送测试报告, 该报告会以网页的形式显示, 方便测试人员和开发人员的查找调试。
3 用python实现GUI测试
图形用户界面 (GUI) 就是使用图象, 输入的文字, 带图标的计算机界面, 取而代之了许多键盘的功能。G U I可以让用户通过图标和鼠标与计算机进行交互, 而不是单调地在命令行中输入文本进行操作。设计良好的图形用户界面可以使用户从命令中解放出来。
G U I测试主要包括两个方面:一是纯GUI测试, 主要关注应用程序上G U I组件是否符合规范或是用户的使用习惯, 二是功能测试, 主要是检验和验证系统是否实现了系统的业务需求, 旨在验证系统的业务实现能力。但事实上两者不是完全独立的, 一方面GUI的测试必定要触发功能, 另一方面, 功能测试也一定要通过GUI将事件传递给后台服务。
3.1 编写测试用例
3.2 测试用例分析
以上是一个完整测试用例, 该测试用例包括:
测试ID 466540, 有了测试ID就可以在测试人员提交bug后, QA或开发人员通过ID找到这个测试用例。还有一个更大的用处就是, 在自动个脚本生成测试报告后, 可以根据测试ID把该测试用例显示在测试报告中, 以供测试人员和开发人员调试。
测试名称, 根据测试名称应该可以很快了解测试用例的内容, 所以好的测试名称也是非常重要的。
测试用例的版本 (Version) 。
测试优先级 (Priority) , 测试优先级也是一个很重要的参数, 因为大型项目都要有很多测试用例要执行。只有明确测试优先级才能确保重要的测试用例得以及时进行, 保证软件质量。
测试用例概述 (summary) , 帮助测试执行人员了解该测试用例的用测的功能。
测试步骤, 描述测试人员或是自动化脚本每一步是怎样操作的, 例如本例告诉测试人员选择菜单F i e, 然后选择菜单项N e w。
预期结果 (Expected Results) , 说明经过以上测试步骤, 期望程序运行出现的结果。
4 结语
本文在明确软件测试理论的基础上, 对自动化测试做了重点阐述, 通过实际项目的自动化测试分析, 有些测试用例特别适合用自动化测试。例如GUI测试中, 用些是要验证界面元素是否显示正常。如果是脚本就可以准确无误地很快验证完毕, 而用人工验证不仅容易出错而且费时间。由于时间和硬件条件有限, 本论文规避了许多问题, 所以仍有许多工作需要完成。例如:做好脚本的复用, 使测试脚本不断积累。及研究怎样在测试工具和自己搭建框架中寻找平衡等。
摘要：自动化测试近年来的技术已经越来越成熟, 在某些方面有着不可替代的作用, 例如在性能测试, 压力测试中, 自动化测试可以模拟成千上万个用户对目标程序进行测试。本文通过对大型实际项目的分析研究, 分析针对某一产品的自动化测试框架。然后讨论怎样用python实现自动化测试。
关键词：测试技术,手工测试,自动化测试,python脚本
参考文献
[1]张克东.《软件工程与软件测试自动化教程》.北京:电子工业出版社, 2002.
[2]朱菊, 王志坚, 杨雪.《基于数据驱动的软件自动化测试框架》[J]计算机技术测试与发展, 2006.
[3]马瑞芳, 王会燃.《计算机软件测试方法的研究》.小型微型计算机系统, 2003.
[4]朱鸿, 金凌紫.《软件质量保障和测试》[M].北京:电子科学出版社, 1997.
自动化测试实现研究 篇2
前言:由于一个客户的项目中需要将WORD文档转换成PDF格式,故写了本篇实站教程
需求分析:客户的项目以B/S结构为主,提供一个WORD文件在后台自动转换成PDF,经过实际测试,如果该篇WORD文档有100多页的话,转换需要20分钟左右的时间(环境:CPU是奔腾M 1.6G,512M内存),整个CPU的占用率近乎95%~100%,此结果告诉客户以后,客户提议:到客户下班后,自动转换PDF,同时如果使用人确认要查看该PDF文档,如果没有转换,提供给客户选择,是现在转换成PDF,还是由服务器在客户下班后,自动转换，
项目功能:按需求分析要写两个功能
第一为:B/S结构后台转换,要提交给客户选择
第二为:Windows服务自动转换WORD文档到PDF
这两个分类:核心的转换程序都是采用线程的方式执行,只不过第一个功能是针对一个WORD文件,第二个功能针对所有未转换的WORD文档.
分析到现在:我们开始实战转换了!
一:必备工具
安装必须的工具MS VS.Net,MS Office2003,Adobe Acrobat 7.0 Professional,postscript.exe,gs811w32.exe
MS VS.Net2003的安装不说明
MS Office2003的安装不说明
Adobe Acrobat 7.0 Professional安装说明
运行setup.exe文件,出现输入序列号,就运行注册机,用鼠标在第一行刷下就可以看见序列号，复制粘贴到Adobe Acrobat 7.0 Professional安装程序对话框，安装到最后出现注册时,点击PHONE...将安装程序中显示的第二行序列号（第一行是刚才注册机生成的序列号）复制粘贴到注册机的第二行，点击右边的按钮，再用鼠标刷第三行授权号就出来了，将其复制粘贴到安装程序的最后一行，完成安装注册！
postscript.exe默认安装就可以了,它是一个PDF转换时所需要的脚本
gs811w32.exe默认安装就可以,它其实是个PDF虚拟打印机的驱动
二:配置虚拟打印机
进入Windows的控制面板,进入打印机,点击“添加打印机”图标.在安装对话框上“按一步”,出现选择打印机时,在制造商一栏中选择“Generic”,在打印机一栏中,选择“MS Publisher Color Printer”,然后一路按下一步,知道安装结束.
三:开始写第一个程序(脚本程序)
为什么要使用脚本程序进行转换呢,其实实际测试过程中,使用PDF Distiller的对象引用到C#后,转换成功,但整个PDF Distiller对象不能释放,第二次再转换时,就发生了错误,故此处使用脚本程序实现转换.这样我们只要在C#的程序中调用脚本程序就可以实现WORD到PDF的转换。
宿主脚本文件名:ConvertDoc2PDF.js
脚本文件内容:
var files = WScript.Arguments;
var fso = new ActiveXObject(“Scripting.FileSystemObject”);
var word = new ActiveXObject(“Word.Application”);
var PDF = new ActiveXObject(“PDFDistiller.PDFDistiller.1”);
word.ActivePrinter = “MS Publisher Color Printer”;
//files(0) 为WORD文档文件名
//files(1) 为,转换后需要保存的路径
//调用fso.GetBaseName(files(0))后,为无路径,无扩展名,的文件名
//files.length为文件参数的个数,使用循环可以支持多个WORD文档的转换
var docfile = files(0);
var psfile = files(1) + fso.GetBaseName(files(0)) + “.ps”;
var pdffile = files(1) + fso.GetBaseName(files(0)) + “.pdf”;
var logfile = files(1) + fso.GetBaseName(files(0)) + “.log”;
try{
var doc = word.Documents.Open(docfile);
//WORD文件转成PS文件;
word.PrintOut(false, false, 0, psfile);
doc.Close(0);
//PS文件转成PDF文件;
PDF.FileToPDF(psfile,pdffile,“”);
fso.GetFile(psfile).Delete;//删除PS脚本文件
fso.GetFile(logfile).Delete();//删除转换的日志文件
word.Quit();
WScript.Echo(“isuclearcase/” target=“_blank” >ccess“);//成功
WScript.Quit(0);
}
catch(x)
{
word.Quit();
WScript.Echo(”isfail“);//失败
WScript.Quit(0);
}
然后测试该脚本程序
启动MS-DOS,输入如下命令:
c:>cscript. //nologo c:ConvertDoc2PDF.js c:test.doc c:
说明:
运行成功后将看到test.pdf文档了
c:test.doc参数对应的是脚本程序中的files(0)
c:参数对应的是脚本程序中的files(1)
你可以安照该脚本改写成,支持多个参数,使用FOR循环,一次转换多个WORD文档,此处没有使用多个文件转换功能,是考虑到,该段脚本放在C#的线程中执行,这样一来也可以转换多个WORD文档.
四:使用C#调用ConvertDoc2PDF.js脚本
新建一个C#的WINDOWS应用程序,添加一个按钮button1
添加一个函数,函数名StartConvertPDF
public void StartConvertPDF()
{
Process proc = new Process();
proc.StartInfo.FileName = ”cmd.exe“;
proc.StartInfo.WorkingDirectory = @”c:“;
proc.StartInfo.CreateNoWindow = true;
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.RedirectStandardInput = true; //输入重定向
proc.Start();
proc.StandardInput.WriteLine(@”cscript. //nologo c:ConvertDoc2PDF.js c:test.doc c:“);
proc.StandardInput.WriteLine(”exit“);
proc.WaitForExit();
}
然后在按钮的CLICK事件中添加调用线程的代码
private void button1_Click(object sender, System.EventArgs e)
{
//定义线程序
Thread thConvert = new Thread(new ThreadStart(StartConvertData));
thConvert.Start();
}
注意:在测试上面的C#程序时,必须添加如下命名空间
using System.Diagnostics;
using System.Threading;
五:健壮的C#调用代码(实际考虑,可放在B/S系统中)
完成第4步的C#测试后,细心的读者,可能看到一点问题,那就是如何得到脚本运行后输出的结果,如何给线程中调用的StartConvertData方法传递参数
1:传递参数,此话说来也可用一篇教程告诉大家线程中方法如何来传递参数,现在就讲一个方案,此种方案很多,我采用一个类,初始化这个类,然后调用该类的方法作为线程执行的方法
2:得到脚本的输出结果,使用Process对象的输出重定向,就是说改变输出方向,使脚本不输出到控制台(MS-DOS窗口),而是重定向输出到C#程序中,并采用线程的异步回调方法,显示脚本运行结果，
添加一个新类,类名为ToPdf
using System;
using System.Diagnostics;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
namespace Doc2Pdf
{
public class ToPdf
{
private string strWord = ”“;//此处的WORD文件不含路径
private string sPath = ”“;
public string sExecResult = ”“;
public bool bSuccess = false;
public ToPdf(string sParamWord,string sParamPath)
{
strWord = sParamWord;
sPath = sParamPath;
}
public void StartConvertPDF()
{
Process proc = new Process();
proc.StartInfo.FileName = ”cmd.exe“;
proc.StartInfo.WorkingDirectory = sPath;
proc.StartInfo.CreateNoWindow = true;
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.RedirectStandardInput = true;//标准输入重定向
proc.StartInfo.RedirectStandardOutput = true;//标准输出重定向
proc.Start();
proc.StandardInput.WriteLine(”cscript. //nologo “+sPath+”ConvertDoc2PDF.js “+sPath+strWord+ ” “+sPath);
proc.StandardInput.WriteLine(”exit“);
sExecResult = proc.StandardOutput.ReadToEnd();//返回脚本执行的结果
proc.WaitForExit();
proc.Close();
}
public void EndConvertPDF(System.IAsyncResult ar)//ar参数必须写,是线程执行完成后的回调函数
{
if(sExecResult.IndexOf(”isuccess“)!=-1)bSuccess=true;
else if(sExecResult.IndexOf(”isfail“)!=-1)bSuccess=false;
//如果放在B/S系统,你可以在此处写数据库,是成功还是失败,并用一个WEBService程序不断检查数据库,此WEBService程序不放在该回调用函数中
//如果放在C/S系统,回调函数可以不放在类中,以便在窗体程序中调用结果
}
}
}
改写原来的button1_Click事件中的代码
private void button1_Click(object sender, System.EventArgs e)
{
ToPdf my2Pdf = new ToPdf(”test.doc“,”c:“);
ThreadStart thStartConvert = new ThreadStart(my2Pdf.StartConvertPDF); //开始异步调用线程
thStartConvert.BeginInvoke(new AsyncCallback(my2Pdf.EndConvertPDF),null);//设置异步线程的回调函数
//如果需要转换多个WORD,你可以用循环
//如果是B/S系统,可以将本段代码放在ASPX中,并结合客户端的无刷新显示数据的技术,不断访问WEBService程序,以确定PDF是否转换成功或失败
}
六:编写更加健壮的C#调用代码(实际考虑,可放在WINDOWS的服务程序中)
实际使用时,由于转化PDF时CPU的占用率很高,考虑只在同一时间转换一篇WORD文档,放弃异步线程的回调函数的使用,考虑一个WINDOWS的服务程序。
写一个函数CheckData2Convert(),不断的检查没有转换的WORD文档,并使用循环调用ToPdf类中执行转换方法StartConvertPDF
//以下给出,泛代码,用户按照自己的需求,填写完整即可
//bool bStart为全局变量,控制循环的进入与退出
//例:18:30开始检查并转换,那么18:30时,bStart=true;并启动转换线程
//6:30停止转换线程,bStart=fasle;
private void CheckData2Convert()
{
//检查指定目录下的没有转换的WORD文档,你同样可以检查数据库中记录的没有转换的WORD文档
string sPath = System.Threading.Thread.GetDomain().BaseDirectory; //当前的路径
while(bStart)
{
int iFileCount = CheckWord(); //CheckWord为一个方法,检查当前没有转换的WORD文档,返回没有转换的文件数,该方法的代码由读者自己编写
for(int i=0;i
{
string sWord = GetWordFileName(i) //GetWordFileName为一个方法,返回一个不带路径的WORD文件名,该方法的代码由读者自己编写
//ToPdf类中的StartConvertPDF()方法使用的是不带路径的WORD文件名
ToPdf my2Pdf = new ToPdf(sWord ,sPath);
my2Pdf.StartConvertPDF();
if(my2Pdf.sExecResult.IndexOf(”isuccess“)!=-1)
{
//成功,写日志,或回写数据库
}
else if(my2Pdf.sExecResult.IndexOf(”isfail")!=-1)
{
//失败,写日志,或回写数据库
}
}
if(!bStart)break;
Thread.Sleep(1000);
}
}
然后在服务的开始事件中,启动线程
protected override void OnStart(string[] args)
{
//可以使用一个开始定时器,检查是否到开始时间,时间一到,就开始执行线程,此处的开始执行线程可以放在开始定时事件中
//可以使用一个结束定时器,检查是否到结束时间,时间一到,就结束线程,结束线程的代码可以放在结束定时事件中
//注意:应该使用组件中的定时器,而不是Windows的FORMS中的定时器
//该定时器的类名为System.Timers.Timer,千万别搞错,不然执行不会正常的
bStart = true;
Thread thConvert = new Thread(new ThreadStart(StartConvertData));
thConvert.Start();
}
然后在服务的结束事件中,设置停止线程的标识bStart= false
protected override void OnStop()
{
bStart = false;
//为何次处不停止线程呢,因为考虑到,现在线程正在转换WORD文档,但没有结束,所以只设置停止标识,转换完成后,线程也执行结束了.
}
结束语:
Adobe Acrobat 7.0 Professional,postscript.exe,gs811w32.exe这三个文件可以在itbaby.jss.cn下载,都包含在同一个RAR的压缩文件中了。
itbaby.jss.cn是动态域名,主机在作者家里,如果网站不能访问,说明电脑没有开,请稍后几天再试。
自动化测试实现研究 篇3
关键词：USB总线；自动测试仪；电缆网；绝缘检查
中图分类号：TP391文献标识码：A文章编号：1009-3044(2007)12-21628-01
Design and Implementation of Automatic Test Instrument for Cable Network Based on USB
YANG Zhao-zhong,LEI Xiao-qing,LEI Jin-hong
(The Army 63981,Hubei 430311,China)
Abstract:In order to have the testing of a bulky cable network,The article introduces the way of the design and implementation,and working process.After cascading，the instrument can test more than four thousands cores of the cable.the content of the testing include the switching and insulation resistance. Now,the instrument be widely worked in all kinds of cable to test.
Key words:USB;Automatic Test Instrument;Cable Network;insulation resistance
1 引言
某裝备的某型号电缆网线路容量较大，接近500余点。为了保证电缆线束的安全可靠使用，必须对线束的导通、阻抗和绝缘性能等进行严格的检测。随装的导通检查采用欧姆表逐点进行；绝缘电阻测试仪有两种，一是500V 手摇式传统兆欧表，另一种是经过对8节2号电池进行DC— DC转换成100V/500V的指针式兆欧表，并与专用电缆测试转接箱构成专用测试仪。测试时，操作手按照被测电缆的接点分配表，逐次接通各孤立点(在插头处连接在一起的若干导线芯或独立的导线芯都称为一个孤立点)，测量并逐项记录被测孤立点的绝缘电阻值。因此， 传统测试方法存在测试时间长、自动化程度低、对操作人员要求高等缺点。所以，研制一种大容量的电缆线束自动测试系统的要求显得尤为迫切。
通用串行总线（简称USB）是为了解决传统总线的不足，而推出的一种新型串行通信标准，该总线接口具有安装方便、高带宽、易扩展等优点，已经成为现代数据采集、控制、传输的发展趋势。
本文将介绍一种基于USB接口的大容量的电缆线束自动测试仪，通过本测试仪，用户可以对大量的电缆线束进行自动测量。可检测到电缆导通和兆欧级的绝缘阻值，检测出其可能存在的配线错误、通断路，绝缘不良等问题。
2 测试仪工作原理
2.1绝缘电阻测试原理
该测试仪绝缘电阻测试原理如图1所示。高压直流电源(500V／100V)由PC机控制经继电器加到被测电缆的导线芯上，该导线芯与其他的导线芯间绝缘介质上的泄露电流，经I／V转换、A／D转换电路， 由单片机测量采样电阻R2上的电压值，按下式计算出绝缘电阻Rx的值：Rx＝R2U/U0-R2-R2-R1。
图1 绝缘电阻测试原理
2.2多芯电缆测试原理
某型号电缆网由若干相互连接在一起的电缆束和若干单根电缆组成，插头座为多个某型号航空插头，最大导线芯为512个。为了传输电源、大电流信号或保证重要信号的可靠性而采用了冗余技术， 即采用多芯或双芯导线传送一个信号或电源。多芯电缆测试的基本思想是：测试前所有的导线芯均不与高压电源相连，测试的第一步是将第一个点通过继电器接通高压电源，其他点接测量端(R1的前端)，测量第一个点与其他点间的绝缘电阻； 然后将第一、二个点通过继电器接通高压电源，其他孤立点接测量端， 测量第一、二个孤立点与其他孤立点间的绝缘电阻，绝缘电阻为零的为导通点，反之为孤立点，测试值为绝缘电阻值；依此类推，测试所有的点。
3 测试仪硬件组成
整个系统分为PC机软件和自动测试仪两个部分。每台电缆自动测试仪有512个测试点的容量，最多可级联8台测试仪以扩大测试容量。为了灵活配置，测试仪采用基于USB总线形式的机箱插板式结构，内部有控制测量电路、电缆测量接口电路、干扰抑制电路等组成。硬件电路原理见图2。
图2 测试硬件原理图
3.1控制测量电路
控制测量电路的核心是阿尔泰的USB2016模板，能够完成测试仪的级联通信、转接测试命令和进行命令的分发、同时控制激励源信号，以及完成电缆通断、绝缘的测量。。测试过程中，4路D/A输出通道提供0~10直流电压，经相关转换电路输出0~500直流电；16路单端模拟量输入通道，测量绝缘电阻电压；16路开关量输出控制接口板完成电缆测试；16路开关量输入监测接口电路状态。电缆测量接口板一共有4块，每板有128个测试接点，通过板上的继电器阵列，将激励信号送到面板的待测电缆接人点，将电压测量信号返回到控制测量电路。
3.2 电缆测量接口电路
接口板主要功能是将激励信号送到面板的待测电缆接人点，将电压测量信号返回到模拟量输入通道。接口电路通过12位开关量输出完成512点的选择，4位开关量输出、16位开关量完成测试仪的级联以及测试接口板状态检测。驱动电路芯片MC1413组成，其输出端能提供50 mA 的负载电流，可以驱动继电器。该电缆芯经继电器闭合触点接100V／500V的高压电源，继电器常开点则接分压电阻测量电路。
3.3 干扰抑制电路
考虑到测量电路的测量结果稳定性，在硬件电路中设计了干扰抑制电路。该测试仪在分压电阻测量端加了射极跟随器，射极跟随器的深度负反馈作用，使之具有工作稳定、频响宽、输入电阻大和输出电阻小等突出优点，解决了输入信号测量的干扰问题。为了滤除电路的杂波干扰信号，在分压电阻的测量端加了低通滤波电容，滤除杂波干扰。
4 应用软件设计
应用软件采用VC++6.0开发，采用自顶向下的模块化设计方案，其组成框图如图3所示。主程序位于应用软件的最上层，主要功能是进行系统初始化设置、测试条件选择、人机交互等，并通过调用各功能程序模块完成测试指令生成与调用、测试逻辑控制、A／D转换控制、测试结果通讯、分析、显示与打印等测试过程控制。功能程序模块是由6个独立的基本子程序组成，用于完成测试过程某一阶段的任务：系统维护程序主要用于录入与维护导弹电缆网或其他已知电缆网的型号、接点分配表等电缆网信息，并生成符合测试逻辑的控制指令；测试控制程序由测试选择子模块和测试指令调用子模块组成，用于选择被测电缆的型号，并调用相应的测试控制指令，该程序模块也可以按固定的测试逻辑生成未知电缆的测试指令，顺序寻找出孤立点，并完成绝缘电阻测试，对未知电缆进行测试。信号采集与控制程序主要用于对测试指令进行地址译码，将其锁存到端口扩展锁存器中，控制接通相应的电缆芯，并测量该孤立点与其他孤立点间的绝缘电阻，将测试结果存放在数据库中，供分析、显示与打印用。测试记录管理程序主要由结果判读子模块、结果显示与打印模块组成，主要用于将测试结果与预先存储的标准结果相比较， 自动判别测试结果，并进行结果显示与打印。系统监控程序，对测试过程中出现的异常能够适时监控和处理，保护测试系统和被测单板不受伤害。
图3
软件框图
5 结束语
该测试仪总体设计USB总线模式，既体现了仪器的便携性， 又考虑到维护、测试操作的方便和直观；在测试方式上考虑了绝缘电阻测试，同时兼顾导通测试，既能测试已知电缆，又能测试未知电缆，简化了硬件电路设计，缩短了测试时间，具有很强的通用性和可扩展性；在测试控制上采用了端口扩展、输出驱动、信号采集、继电器矩阵等设计思路，实现了多路信号的输出控制， 完成了绝缘电阻的测量；在使用管理上采用了菜单、控件、文本框等友好界面和开放式维护管理措施，使测试原理、测试过程和测试结果形象直观，便于测试接点分配表的添加、修改和删除等维护。
因此，该测试仪能够完成自动测量、自动判别测试结果、显示并打印绝缘电阻测量值、生成与维护被测电缆网数据库等任务，具有测试操作简单、测试时间短、人-机界面友好等特点， 已应用于某型导弹电缆网和通用多芯电缆的自动测试。
参考文献：
[1]张弘.USB接口设计[M].西安电子科技大学出版社,2002．
[2]黄艳华.一种大容量电缆自动测试仪的设计和实现[J].微计算机信息,2005-2.
[3]汪庆宝.通用串行总线用于测试和测量仪器[M].国外电子测量技术,2000年第3期.
通信软件的自动化测试及实现研究 篇4
1 通信软件自动化测试主要特性分析
如果针对通信软件自动化测试而言, 想要大幅提高测试效率, 就应当熟知软件自动化测试的一些主要特性。
1.1 主要优势分析
回归测试更为全面彻底。软件测试中回归测试实际上是一种重复性测试行为系数非常高的用例程序测试。自动化测试过程实际上将回归测试应用了“执行回归”模式进行测试, 即测试程序预先写好以后进行高效测试, 测试效果较为显著。
对于测试用例数量较多的测试工作而言, 自动化测试能够大幅提高时效性, 可以处在最短的时间周期内提高测试成果, 进而能够达到有效控制测试成本的目的。
对于一些传统手工难以模拟, 或者根本人工测试操作不可能完成的复杂测试而言, 许多软件程序测试根本不可能配备大量的测试人力资源与测试设备等。因此, 对于测试难度系数大、资源耗费量大、高速率类型测试等都可以通过自动化测试工作来完成。
自动化测试的核心工作流程是脚本编写, 通过脚本编写行为来达到自动化测试目的。因此, 它只需要不同版本的软件进行上下小幅度的程序脚本改动就能完成多数用例测试, 避免了一些测试工作流程的繁冗与重复。
1.2 主要弊端分析
1、并非所有软件测试都如想象中那样适用于自动化测试, 仍然还会有些必要的测试程序步骤需要利用手工方式来完成;同时, 有些测试程序手工完成会更加简单, 也能省去必要的成本与人力资源。
2、自动化测试实际上较为适用于重复性次数较多, 测试步骤较为繁冗的测试工作。因此, 这种特性也直接决定了自动化测试后的软件故障率很低。但是用来研究新的测试项目往往需要一定时效性。
3、自动化测试需要对测试版本测试效果更为精准, 它要比传统手工测试带来的影响更大。有些软件由于版本的变化甚至会带来测试脚本的异常崩溃。因此, 对于软件开发测试前期与后期而言, 维护工作需要做足, 会增加必要的测试成本, 有一定局限性。
综上所述, 通信软件通过自动化测试来完成传统手工形式上的测试工作有着它的必要优势, 但也同样存在一定局限性明显的弊端问题。基于此, 不能直接武断的否定自动化测试, 更不能对其全招“肯定”, 应需要理性认知自动化测试工作, 合理利用传统手工与融入自动化测试, 使两者效率化差异互补, 提高测试工作效率。
2 通信软件自动化系统功能模块的主要构成
一般对于整个测试框架结构而言, 在框架底层我们需要自定义API, 用以对上层框架提供一种必要的过渡性操作;同样, 上层结构也是测试用例中较为重要的主体内容, 包含应用脚本、公共包封装等。
2.1 设备连接模块
结合参数设置要求对测试对象选用必要的服务器配套类型链接, 如Telnet、CLI等。这是由于当链接建立完成之后, 可以取得设备的必要信息及某些文件的必要环境变量, 指导我们完成科学化配置设计。
2.2 公共包封装模块
当对某些程序展开功能性拓展时, 一般会通过拓展包完成该项任务。于此, 脚板编写也正是辅助于拓展包功能拓展所用, 即脚本属于一种开源社区, 功能丰富, 可解决诸多功能拓展问题。
2.3 收发包模块
测试职工一般会协议状态的验证用以检测协议状态机转化的一致性。完成协议状态机转换需要通过信息资源来完成驱动过程。所以信息资源消息的内容及其报文类型非常关键。也就是说, 协议状态机切换需要凭借报文类型的编写来提高测试质量与速度等。
2.4 日志信息处理模块
在测试工作执行开来, 测试程序与测试场景比较繁复多变, 要解决的复杂问题情况较多。因此, 为了解决这些复杂状况, 就必须必要设置一些状态检测次数。该模块的日志信息设置, 正是通过详细的信息记录、反馈、处理等来完成状态检测响应, 以便测试职工准确定位故障部位。
2.5 测试脚本
脚本测试是通信软件测试流程中的重点核心模块。一般研发测试人员都非常关注于脚本功能实现是否与设计相互配套。在对测试脚板执行自动化操作测试时, 测试人员通常在这工作环节略显被动。一方面一旦出现问题却又不能及时终止, 则可能影响到整个测试环境;另一方面, 碍于问题出现, 增加测试工作量也会耽误整个测试进度。因此, 脚本测试时, 应预先关注测试环境是否有利;同时, 也要自身检查脚本的缺陷、异常错误等, 合理预先制定基本处理机制等。
3 通信软件自动化测试系统的测试设计与实现研究
3.1 测试设计功能实现
软件自动化测试工作应能使系统设计目标具备普遍应用性、易拓展性、便于操作等主要功能。
3.1.1 普遍应用性
本文主要最为常用的Tcl类数据库展开分析, 因此系统设计采用该数据库对脚本展开测试工作比较适用。由于Tcl属于常用数据库类, 所以在测试运行工作执行时应能配备好基础操作环境。另外, 由于该测试程序能够脱离系统进行独立工作。此时, 如果系统中又陆续出现其他的待测试任务对象, 测试操作人员完全可以通过接入新的测试借口展开自动化的针对性测试。当然, 如果测试时遇到不同的差异化系统, 数据化并不能展开特定程序识别, 测试系统也应重新予以设计再展开必要对象测试。
3.1.2 可扩展性
基于Tcl类数据库在拓展性能上比较突出, 所以在设计测试系统时应建议多设置一些必要的接口, 但应能保证这些接口与测试程序无关, 仅针对于测试系统而言。这样一来, 接口设计可以针对不同程序选用不同的脚本予以完善, 用以完成自动化脚本测试。
3.1.3 易操作性
为了测试系统便于操作, 技术开发有关设计人员应能设置一套易操作管理的模板与必要的管理系统。如此一来, 在系统后期应用过程中, 许多测试人员能够针对该模板与Tcl类数据库来完成进一步的脚本测试。同时, 设计人员也可结合自身权限登录管理系统客户端展开特定测试工作。
3.2 测试系统的实现
该测试系统的实现主要由测试脚本、系统类库、系统控制模块、Agent端、测试资源等部分组成, 如图1所示。
3.2.1 系统控制模块
该模块主要应用的是关键词结合数据驱动方式来完成必要的自动化测试工作处理。它采用的是Tcl类数据库创建出一定数量的线程组, 以通过测试脚本对其展开有关执行控制。同时, 线程组也会Agent端通过映射性链接完成通信;此时测试人员进行测试, 在Tcl执行指令的操作下, Agent端就能接受有关指令, 使最终的测试解释结果通过服务器端口存储到库中。
3.2.2 系统类库
系统类库属于一种具备深度拓展性的组件库, 在软件测试设计及功能实现方面应能善于应用其各种设计测试接口, 包括功能函数等, 用以满足测试需求需要。在设计过程中, 为显著提升类库的复用性与易拓展性, 笔者建议测试测试系统设计在应用Tcl中的一些对象新开发功能, 使其和类库功能完成对接。同时, 服务端与Agent端为了能够均实现共享, 可以将类库文件安置在NFS中。
3.2.3 Agent端
Agent端主要是客户端节点, 用于将Tcl中某些必要的解释程序安置在其中。这样一来, 当服务端口如果有需求命令时发送至Tcl时, Agent端就能及时的针对执行命令展开解析及结果输出等。
3.2.4 测试脚本管理
测试效率的高低, 编写脚本的管理十分关键。在脚本编写阶段时, 测试系统需要针对某些特定脚本功能展开设定;同时, 需要在该基础上针对一些测试需求不断完善脚本功能的拓展。同样, 当我们测试流程结束以后, 我们也应要再次考虑测试需求, 优化脚本版本, 即将其部署在相应的目录之中, 一方面便于对该版本展开必要回归测试;另一方面通过CVS或SVN来对其进行管理时也十分方便。
3.2.5 日志报表
通常情况下, 日志报表的功能实现与设计目的在于对测试结果反馈情况展开分析, 从而才能使得测试人员进行依据性较高的判断, 以该测试反馈结果作为依据, 完成不同需求测试工作。通常, 日志文件都采用XML或是HTML格式表现, 也便于存入数据库中。
4 结语
通信软件自动化测试有着易操作、拓展性强等优势存在, 在诸如应用Tcl脚本语言进行测试优化时, 一方面应能加强必要开发设计方法的研究, 另一方面应能便于指令管理, 从而才能便于解决测试中脚本语言在二层API的功能实现问题。同时, 测试人员也应当在实践测试工作中不仅要看重功能特性测试, 也需要保持功能特性测试的稳定性, 以此才能结合不同需求在脚本编写中加入不同测试内容, 不断完善通信软件测试功能实现问题。
摘要：社会随着时代发展要求不断进步, 信息化技术呈现出了跨越式的发展姿态, 通信软件技术测试领域也越发受到各个行业所关注, 这不仅是因为软件测试利于保障软件寿命周期, 促进计算机硬件设备系统等维持稳定运行周期, 更是软件开发设计工作的重要基础工作。本文结合通信软件本身特点展开分析, 提出了通信软件自动化系统主要模块构成部分, 并以此提出了自动化测试与实现的一些研究成果, 以供交流。
关键词：通信软件,自动化,系统,模块,测试
参考文献
[1]冯伟, 李波, 何倩.软件测试自动化应用分析[J].制造业
[4]黄茂生.软件自动化测试工具的评估与选择[J].电子测试, 2010 (12) .
[5]刘腾.软件测试技术与自动化测试框架模型的研究与应用[J].电脑知识与技术, 2011 (26) .
[6]陈琪.自动化测试平台的设计与实现[D].西安:西安电子科技大学, 2014.
[7]陈杰.自动化测试平台的设计与实现[D].成都:电子科技大学, 2013.
自动化测试实现研究 篇5
1 自动化测试概念
1.1 定义
自动化测试是测试过程中仅需由测试者开发测试运行脚本,不需用户参与过程即可自动执行测试程序。所开发代码可以用于单元测试、功能测试,以及集成测试,从而完成整个系统的测试工作。总之,自动化测试的过程就是用代码测试源程序,指导测试过程,代替人工测试。
1.2 自动化测试发展阶段
1.2.1 简单录制回放阶段
利用工具录制对所需测试操作,执行脚本,实现自动化回放。
1.2.2 数据驱动阶段
使用实例作测试数据,采用专用格式存储和读取,在测试过程中调用不同测试数据及相关变量。
1.2.3 关键字驱动阶段
以数据驱动为基础,在测试工具提取出改进的测试用例:将数据与脚本分离,把内部元素和外部对象分离,从而也把测试描述与具体实现方式区分。
1.2.4 模型驱动阶段
通过不同测试场景设置相应条件,每一个模型对应一个测试场景。
1.3 自动化测试框架
它就是由多个自动化测试基本模块、管理模块及统计模块等所组成的工具集合。测试框架分为二类:Selenium等提供最基础的自动化功能测试模块,通过模拟鼠标键盘,点击或操作该页面中的测试元素,验证该元素属性是否正确,判定程序正确性;Robot等可提供自动化测试执行和管理模块,不提供基础支撑,仅用于组织管理和执行那些已有的测试用例。
2 自动化测试工具Selenium简介
2.1 Selenium组成
Selenium由ThoughtWorks推出的开源测试工具,针对功能测试或验收测试中JUnit无法解决的测试问题,用户与Web系统交互时所需的回归测试、集成测试或冒烟测试。此工具支持多种浏览器,也支持各类编程语言。
它集成了WebDriver,提供支持在复杂页面中重新加载以及动态网页等不能处理的情况。最新的Selenium2.9.1由以下内容组成:IDE、Core、Remote Control以及Grid四大模块。
2.2 Selenium工作原理
Selenium具体的架构如下:
前端:Firfox、IE、Chrome平台运行的Web App;
中间层:WebDriver;
后端:Java、Ruby、C#等客户端。
2.3 Selenium工作环境
开发环境:IDE使用Eclipse、Note Pad等,开发语言可使用Java、C#;
运行环境:Selenium四大核心、Firefox等浏览器;
其它工具:部署:Ant;集成:Junit4、Test NG。
3 具体测试过程
3.1 分析系统测试需求
以邮箱——用户登录为例,需求如下:
(1)系统帐号、登录密码正确与否;
(2)系统登录后是否有跳转页面;
(3)Session过时后有否提示重新登录;
(4)登录用户相关信息的验证。
3.2 测试用例
设计测试用例:
需求描述:登录账户、密码是否正确;前置条件:处于登录界面
基本操作1.输入账号密码;2.点击登录按钮;
用例01,Test001/123456登录并跳转匹配用例
用例02,Test001/654321提示密码错断言失败
3.3 录制测试过程
主要步骤:
(1)在Firefox添加Selenium IDE插件;
(2)Selenium IDE的Base URL输入访问地址并点击录制;
(3)登录页面输入账号、密码,点击登录按钮,进入主面;
(4)Selenium会自动记录并通过以下参数定位网页元素并而完成脚本录制:
3.4 生成测试脚本
在Selenium IDE中,通过菜单“Export TestCase As…”,选择“Java/JUni t 4/Web Driver”,将IDE与Selenium2.9相结合,完成IDE向Webdriver的Java脚本转化,可以生成Junit4框架文件。
3.5 执行并分析测试结果
编辑测试脚本后,在Eclipse运行,Web Driver会自动启动Firefox,在页面账号和密码处分别自动输入用例Test001数据项,并自动点击“登录”按钮,跳转至主页面。测试结果是“登录并跳转成功”,符合预期,测试通过。修改测试用例脚本,修改密码,再次运行时测试不通过。
4 总结
本文定义了自动化测试,回顾了发展历程,简棕了Selenium构成、工作原理及环境,结合实例列出过程。尽管自动化测试针对重复性测试工作,但是测试人员主要工作都用在编写、调试以及维护测试代码,以至偏离原有目标,故实践中,应正确认识自动化测试优缺点,将手工与自动有机结合达到最佳效益。
摘要：本文对自动化测试概念发展演变过程进行了简要概述,结合业界流行工具Selenium以实例进行描述,以期达到理论结合实际效果,同时也便于读者理解和应用。
关键词：Selenium,WEB测试,自动化测试
参考文献
[1]Glenford J.Myers,Tom Badgett,Corey Sandler.软件测试的艺术(原书第3版)[M].北京:机械工业出版社,2013.
[2]陆璐,王柏勇.软件自动化测试技术[M].北京:清华大学出版社,2006.
自动化测试实现研究 篇6
关键词：驱动,自动化测试,软件测试,回归测试
地震处理、解释软件系统是我国拥有独立自主产权的一套用于石油勘探开发的软件系统, 目前发行的版本已经达到第三代, 其底层软件平台开发、性能以及功能都在不断的开发和完善之中。产品的测试人员在测试更新产品时需要进行回归测试、新功能测试等工作, 工作较为繁琐并且有一定的重复之处。为了有效的节约成本, 提高测试人员的工作效率让工作人员将更多的工作时间和工作精力放在新产品用例上, 因此本此的研究具有重要的实际意义。
1 软件自动化测试分析
随着科学技术的快速发展, 软件自动化测试技术也在不断的更新, 目前软件自动化测试技术已经可以与传统的手工测试同时工作, 二者在测试方面取长补短、不可分割。软件自动化测试主要利用长时间的稳定测试、回归测试以及多用户开发测试, 将系统测试的工作人员从复杂的工作中摆脱出来, 将更多的精力用于其他的测试工作, 从而极大的提高软件测试的工作效率。另外, 人工测试系统时由于人为因素可能出现测试错误或者测试遗漏等现象, 软件自动化测试正好可以解决这一问题, 并且可以自动显示测试结果方面工作人员对数据进行分析。自动化测试经历了三个阶段, 目前迎来了新一代关键字驱动自动化测试。新一代代的关键字自动化测试可以将被测软件逻辑从测试的脚本中分离开, 使待测软件的数据可以将逻辑数据分开, 从而得到测试数据、测试逻辑以及测试脚本三者分开的技术, 这样可以更好的适应业务变化的需求。关键字驱动和过去的数字驱动不同之处是, 测试的文件数据需要有关键字以及具有描述性质的字段。
2 关键字驱动的自动化测试分析
测试文件主要包括对测试配置文件以及具有层次化的数据文件。自动化测试系统的驱动模块是通过对配置文件进行加载, 调整相应的测试数据、关键字的脚本从实现系统的自动化测试。系统测试日志和模块可以将本次测试的结果精细化输出, 并且标记测试用例。经过一系列的操作流程后测试工作人员可以根据测试的报告分析出本次测试结果。
2.1 层次关键字测试
层次关键字分离测试可以将关键字按照一、二、三级进行设计, 对其功能进行划分, 可以分为测试用例、测试用例业务逻辑以及测试步骤。自动化测试系统正是由于可以对用例进行逐层的调用, 从而使系统的用例得到细化。一级关键字的测试表是一种概要设计, 将各个功能点进行有机罗列, 从而使系统的测试功能更加全面, 涉及面更广, 对测试用例文件更加方面快捷。另外, 高级关键词对可以通过索引搜索二级关键字驱动。二级关键字驱动测试是对系统的详细测试, 可以将系统的每个用例进行逻辑测试, 二级关键字可以搜索三级关键字的信息搜索表。三级关键词测试的是详细步骤, 其测试的是最小单位, 二级关键字驱动测试与三级关键字驱动测试是组合测试套件。
在一级测试表中, Test01对应的是User Login;Test02对应的是Strategy Confi guration;Test03对应的是Log Module;Test04对应的是Command Line Interface。
二级用例表是对一级关键字进行细化的过程。其中User Login对应的是Verify Admin Logoin Verify Invalid User Ve r i f y N e w U s e r C r e a t e R e a l D B;S t r a t e g y Confi guration对应的是Create Virtual DB Create App Server Create App;Log Module对应的是Export Confi guration File Import Confi guration File;Command Line Interface对应的是Test All Command。
三级关键字驱动是对每个测试用例细化的过程。
Verify Admin Logoin对应的是Login Create;Verify Invalid User对应的是Login Loninexit;Verify New User对应的是Login Exit;Create Real DB对应的是Open Real DB Add Real DB Test Real DB;Test All Command对应的是testcommand。
2.2 关键字支持脚本
系统测试的具体步骤制成关键字支持脚本, 其包括测试的业务信息, 可以实现测试脚本与测试数据以及逻辑三者相互分离。在测试脚本数据时再重新调用, 可以调用关键字支持脚本, 模拟整个测试流程。
2.3 关键字结构设计
在本系统中关键控制着测试的整个流程, 每个关键字有对应的脚本, 每个步骤代表测试流程, 系统可以对关键字对测试流程进行搜索, 来获取每个字段的具体值。关键字的结构设计可以根据三级关键字测试表将其中的Test Step一一进行设计, 并对测试框架中的信息进行读取, 将相应的脚本数据传输到具体的代码中。
3 结论
综上所述, 地震处理、解释软件系统对软件的稳定性、正确性有较高的要求, 利用人工的方法很难有效实现系统软件的回归测试, 软件自动化测试的引入一定程度的解决了大型石油软件系统开发过程中的测试难题, 具有现实意义。本文首先对软件自动化测试分析进而论述关键字驱动的自动化测试分析, 在分析层次关键字测试、关键字支持脚本以及关键字结构设计后, 对基于关键字驱动自动化测试更加了解。
参考文献
[1]陈丽丽, 林莉, 傅晓娟.基于关键字驱动的自动化测试框架研究[J].长春理工大学学报, 2012, 07 (25) :238-239.
[2]王军, 孟凡鹏.基于关键字驱动的自动化测试研究与实现[J].计算机工程与设计, 2012, 09 (21) :3652-3656.
自动化测试实现研究 篇7
软件测试[1]是软件系统工程中的一个很重要的组成部分, 是软件开发的重要环节和保证软件质量的关键步骤, 其目的是是以最少的时间和人力来找出软件中存在的错误和缺陷, 软件自动化测试是当前软件行业的研究热点之一, 目前各大IT和互联网公司十分重视测试技术的研究。如BAT和IBM, 网易等公司, 都有专门的测试团队, 尤其以IBM等代表的外企十分重视测试技术。IBM中国开发中心自1999 年成立以来, 某部门一道测试的流程 (测试出错率高, 而且操作繁杂) , 十几年一直没有实现自动化, 后来咨询了美国I BM也没有实现过。作者基于SWTBot技术进行了探索性的研究开发, 实现了xpage自动化导入导出问题, 将一道测试流程进行了自动化, 测试正确率为100%, 效率提高了20 多倍, 节省了人力资源成本, 产生了一定的经济效益。SWTBot是一个开源的基于Java的U I/功能测试工具。测试SWT和基于Eclipse的应用程序。它就像一种点击机器人。SWTBot提供简单的读取和写入应用程序的编程接口。API隐藏了SWT和E clipse的复杂性, 这使得它适合于UI /功能测试, 而不只是开发者。SWTBot很好的集成Eclipse, 并支持Ant任务。SWTBot可以运行在SWT运行的任何平台, 也包括Eclipse RCP应用程序。很少有测试工具提供了这样一个支持的平台。SWTBot还提供了自己的一套断言。安装SWTBot到Eclipse中使用SWTBot up date site, 一个新的“Run as...”选项才会出现 (SWTB ot Test) 。SWTBot的测试case类SWTBot Test Case (为独立的SWT应用程序测试) , 和SWTBot Eclipse Test Case (适用于Eclipse的SWT插件测试) 子类JUnit的Test Case类, 所以所有的JUnit的设施齐备, 再加上一些额外的方法来访问SWT部件.从2.1.0 版本开始, SWTBot还提供了一个Test Recorder and Gener ator, 您可以使用简单的通过记录用户界面操作生成测试用例, 这能帮助减少测试成本。
1 安装和SWTBot的配置
1.1 Eclipse集成开发环境
安装SWTBot测试需要的Eclipse IDE
1.2 安装SWTBot插件
安装SWTBot插件最简单的是使用更新网址:
两者都必须安装, 然后Eclipse应该重新启动。创建插件项目并添加以下所需的插件依赖关系:
1.3 创建一个简单的测试
下面是使用Swtbot启动Eclipse的一个例子:
测试代码使用案例
1.4 运行测试
对于测试类Example Test.java运行SWTBot test
·即使第一次的运行是错误的-它将会导致默认的运行配置
·运行Run As/Run Configurations
·打开Main标签
·定义Run a product作为pegasus.branding.Pe gasus RCP
·运行测试
打开试运行后一个JUnit视图。如果测试执行显示绿色, 那么一切都OK。
2 Eclipse RCP
RCP提供了一个通用的Eclipse工作台, 开发人员能够扩展从而构建自己的应用程序。其中的RCP应用程序有许多优点, 最重要的是:易于扩展插件架构, 响应性, 本地外观的用户界面, 易于编写的帮助系统。每一个Eclipse RCP的应用程序包括至少一个自定义插件, 并使用相同的UI元素作为Eclipse 3.5 的IDE。熟悉基本的Eclipse用户界面的元素是很重要的, 以区分SWTBot测试。由于笔者研究的是swtbot在Do mino Designer上的应用。下面主要阐述了swtbot应用于Eclipse RCP应用 (包括IBM Domino Designer) 的运行流程。图1 所示是IBM Domino Designer的界面。
这是一个用Eclipse启动Eclipse RCP应用的流程:
1.使用Eclipse IDE去在一个平台上运行测试:
2.Eclipse IDE安装SWTBot, 然后进入SWTBot的配置选项
3.创建一个由应用程序和SWTBot运行时间构成的目标平台
4.输入您工作区中的项目的测试包
5.然后使用“SWTBot测试”向导来配置执行:考虑包括目标平台+SWTBot+你的测试包;参考您的应用程序来配置产品。
你也可以使用调试功能。
3 研究内容
3.1 启动Eclipse RCP应用的运行流程
启动Eclipse RCP应用的运行流程是进行自动化测试的第一步。测试驱动开发[2]是研究的重点。SWT Bot技术可以直接对Eclipse平台的控件进行自动化测试, 但是并不具备对其他Eclipse RCP应用程序进行测试的能力;而SWTbot技术本身无法对其他非ecli pse平台进行直接的自动化测试。在Eclipse的worksp ace空间里面指定要启动的平台, 然后通过启动Eclip se平台编写SWTBot代码来启动另外的一个平台, 针对Domino Designer平台, 指定workspace之后, 我们就可以对这个非Eclipse平台进行自动化测试了。第一步:将自己的ID好改为server.id;可以参考这个路径"C:Program FilesIBMDominodataserver.id") ;由于swtbot不能自动化测试登陆 (用户名, 密码) 的界面, 所以我们最好避开这一关) 。第二步:设置目标平台和JRES:
在Eclipse平台上点击:Window >Plugin Develo pment >Target Platform进行设置。如图2。
然后在Windows>Java>Install JRES选中本地安装的JRES. (C:/Program Files (x86) /Java/Java60) 。第三步:点击Run>Run Configuration >Eclipse Applicat ion >创建一个名为designer的应用程序。并分别进行M ain, Arguments, plug-ins参数的配置。
VM argument的内容可以用两种方式来获取:第一种使用VM argument产生器。当Notes程序运行时:Start->All Programs->Lotus Applications->Get Not es VMArgs.
第二种可以使用进程管理器Process Explorer来获取。启动Notes, 启动进程管理器,
复制命令行属性文件到剪切板, 然后粘贴到文本编辑器, 复制第一个–vmargs后 (除空格) 的第一个字符到最后的所有字符到VM argument。
然后是配置plug-ins参数, 选择all workspace an d enabled target plug-ins即可。
第四步:关闭正在运行的Notes and Designer, 然后点击Run->Run Configurations, 检查下刚才的配置, 然后点击Run按钮, 一个基本的配置流程就完成了, 下图展示的是启动Designer界面的情景。
3.2 实现Xpage自动化导入导出的详细设计
上一小节已经详细的描述了启动Eclipse RCP应用的运行流程。项目需求需要连续打开100 个DB, 取出里面的xpage中的某些properties属性的文件 (参考图1) 。设计方案的第一步就是如何打开IBM DB。但面临一个困难就是SWTbot技术本身无法打开本地对话框, 需要通过对打开本地对话框的功能进行优化 (清单3 Domino Designer打开一个DB的示例) , 实现了可以自动导入本地对话框的项目文件。然后就可以借助对控件进行自动化测试的功能来编写代码实现导入导出某些属性文件。SWTBot提供的API可以帮助读者进行测试用例的编写, 流程化的测试用例, 可以参考:清单2.手写代码来替换录制代码案例。设计方案的第二步是导入导出propersities属性文件。每一个导入导出流程需要几十个步骤, 为了方便代码复用, 需要设计测试框架[3]。我设计了Abstract Navigator Ope rations类。Abstract Test Operation类。Import_propersit ies类和export_propersities类。Abstract Navigator Oper ations类是Abstract Test Operation类的父类;其中Abs tract Navigator Operations规定了Import_propersities和export_propersities类需要使用的方法, 是后两者的父类。在Import_propersities方法中, 我们定义set Up () 方法实现测试驱动, Open Application Dlg () 方法实现打开DB, open App Props Editor () 和select XPages Tab () 方法用来选中Xpage, 使用add Multiple Language F or Localization方法来选中本地语言, open Import View () 和set Input Directory (Import Path) 用来找到导入的路径和需要被导入的文件路径。verify Filter Type Selec t () 方法用来找到需要被过滤的属性文件。clean Desi gner Project () 方法用来进行项目清理。上述详细设计主要描述了一个导入属性文件的基本流程。其中, l og Message ("") 方法用来对测试流程中的方法进行注释, 可以显示在控制台中, 方便进行代码调试。Sleep (short Wait Time) ;方法用来针对每一个测试流程进行适当延时以保证测试顺利进行。
另外我在设计方法的第一步中加入了For循环, 用于连续打开100 个DB, 如图6 所示。
图7展示的是成功导入Properties.
3.3 Capture/Playback和Recorder
许多GUI测试工具供应商把大部分的注意力放在所谓的Capture/Playback。测试执行工具需要一个测试脚本。
3.3.1 Capture/Playback
为什么Capture/Playback不划算?捕获的测试是一个线性的脚本, 它不是一些很好解决方案的原因包括:测试脚本只存储已记录的输入, 不是测试用例。所以它不知道什么是预期的结果, 直到你编程实现它。.AUT中小的变化可以破坏你的大部分脚本。.捕获的脚本只能应付恰恰相同的条件。任何突发事件 (例如:由于文件已存在的对话窗口显示) 将被解释为一个错误。除对AUT进行操作, 该工具用户不停中断插入验证点, 测试数据和其他检查点, 这是劳动密集和乏味的任务。有些时候, 记录测试输入在短期情况是有用的。捕获的测试可以接受为一些测试, 当软件的变化不是巨大的。但他们绝对不会扩展到成百上千的测试。
3.3.2 Recorder
记录功能可以生成大量的代码, 但这些代码通常需要有人重新编程。只有当它不增加维护成本时, 减少测试的创建时间才是一个好主意。计划, 优化测试的创建实际上是在增加了生命周期成本。图8 展示的是Eclipse安装Recorder效果图。笔者曾使用Swtbot Recorder功能去自动化测试IBM Domino Designer时候, 发现这个录制的效果并不能满足要求, 有些控件没有识别, 比如图1 中的xpage等;并且有些常规的控件竟然也没有录制上去 (见图9) 还需要自己添加断言等其他语句, 但有个好处就是用来学习代码书写时使用。由于我们需要在Designer平台上从DB里面导出一些文件, 比如.property文件, 所以我们想考虑用Recorder来实现这个功能, 可是我们发现了一些问题, 就是:Recorder既不能打开本地对话框 (这个问题可参考清单3.Domino Designer打开一个DB的示例) , 也不能识别.property文件, 下面就是这个问题的描述和解决方案。下面是Recorder录制代码案例: (这段代码是为了在DB中导出一个.property文件, 可以参见图9)
清单1.Recorder录制代码案例
观察以上录制代码, 发现当选择.property文件的时候, 无法录制。还有一个就是本地对话框也无法导出到某个文件夹.这是由于其不支持本地对话框.
下面这个手写的方法, 用于识别*.propersities控件
清单2.手写代码来替换录制代码案例
3.4 SWTBot测试的局限性
在写swtbot测试的时候, 往往浪费时间在一些不能实现的东西, 笔者列举以下不能够进行自动化的主要例子, 方便规避。
不支持本地对话框 (打开/保存文件对话框等等) 。这是一个Bug.虽然不支持本地对话框, 但是有技术方案可以避开这个问题, 这个问题可在Eclipse论坛中找到国外的一些论述, 如参考文献[4]。针对IBM Domi no Designer而言, 当需要使用导入功能的时候, 可以使用如下方法去写入地址, 从而打开本地的资源文件。
清单3.Domino Designer打开一个DB的示例
当试图测试AUT的Restart - 它也重新启动所有的测试并进入无休止的循环
无法访问状态栏文字
只是部分支持关闭按钮 (在窗口的顶部右上方) 。人们可以使用close方法, 但如果有一个确认对话框 (这是一个标准的Eclipse行为对于主窗口) 就会失败。
不能测试登陆对话框, 一个很好的办法可以通过设置用户名和密码的系统属性绕过它。像这样的登录对话框是一个不错的选择:
清单4.登陆对话框:
然后你就可以开始SWTBot测试用下面的JVM参数。你可以在目标平台 (首选) 或启动配置为SWT Bot测试设置这些JVM args。-Dcom.yourapp.usernam e=joe -Dcom.yourapp.password=secret.对于Domino Designer而言, 需要配置一下rcp.security.properties文件到指定的位置, 并且把ID改为server.id, 这样的话就可以绕过登陆操作, 直接打开Designer.
4 研究结果
研究结果对比:测试分为两组, 一组是手工测试, 每次工作流程需要100 个DB的Xpage导入导出。另外一组是自动化测试;测试结果如表1:
5 总结
GUI的自动化测试一直是费力且困难的工作。但是如果实现了自动化测试, 对于人力成本和时间的节省也是巨大的。SWTBot是功能强大的GUI自动化测试工具。本文作者基于SWTBot技术对Eclipse RC P应用进行自动化测试, 具有普遍的研究意义和创新性。
摘要：本文主要研究基于SWTBot技术的软件自动化测试技术, 实现了一种自动化测试Eclipse RCP应用的功能, 而非仅针对Eclipse GUI测试。作者开发了一个自动化测试工具, 将Xpage导入导出流程进行了自动化。文章主要包括:swtbot应用于Eclipse RCP应用 (包括Domino Designer) 的运行流程和详细设计, swtbot的写法, Recorder的使用经验及问题解决办法, swtbot的不足之处及规避方法等研究内容以及研究结果。结果表明, 该技术正确率为100%, 效率提高了约30倍, 节省了人力资源成本, 具有普遍研究意义。
自动化测试实现研究 篇8
随着软件开发技术的日益成熟,软件开发项目的日益庞大,自动化测试技术的重要性日益突出[1]。在web产品的开发过程中,由于高频率地发布不同版本,也为了确保软件产品的健壮性,使得测试工作人员必须得不断的一遍又一遍的做回归测试。在一些非常专业化并要求是非严格的企业里,对于产品质量更是控制的十分严厉。于是自动回归测试迫在眉睫。本文主要研究如何在Selenium基础上搭建测试框架,并实现了对zosmf产品的自动化测试。
研究人员指出,确保web应用程序不单能在当前版本的浏览器上正常工作,并能很好的在该浏览器的后续升级版本中运行正常,是web应用程序开发生命周期的一个重要组成部分。传统上,web开发人员使用广泛的回归测试, 以确保跨浏览器兼容性,但是这种方法是建立在昂贵的时间和资源上的。另一种方法则是创建多个适合完全自动化的测试,可以在各种浏览器上运行。[2]
下面对z/OS Management Facility进行简明介绍,进一步再阐述基于Selenium封装出适用于z/OSMF自动化测试的框架Java类包,最后实现以其中一个模块的自动化测试工作。
二、IBM z/OS Management Facility
IBM z/OS Management Facility[4]提供了一个现代的、基于浏览器的控制台,可以帮助我们更容易地进行主机z/OS系统的日 常运营和 管理 。 IBM z/OS Management Facilit (z/OSMF)还提供了一 个模块化 的框架 ,可以使用 它们来集中那些基于网络的常用的资源,它提供了一种更流畅的用户体验,帮助更有效地执行z/OS管理任务。其管理界面如下:
三、基于Selenium封装Java包
1、zosmf.fvt.component
Web产品测试的对象,归根到底是一些web元素[5]的操作。例如点击button,选择checkbox,从文本框输入内容等等。本文在测试过程中要用到的对web元素进行的操作封装到了zosmf.fvt.component包中 , 有如下类 :Button.java, Check Box Label.java, Commaon Text Unit.java, Floating Message. java, Grid Cell Item.java, Message.java, Option.java, ZOSMFDropdown Listy Type.java. 其中ZOSMFDropdown Listy Type.java是对z OSMF产品中的一个特殊且高频出现的“Action”按钮 (下拉菜单)的封装。
2、zosmf.fvt.base
Zosmf.fvt.base包将更高一层的逻辑动作封装到了各个类中 。 它包括了Constants.java,Log Recorder.java,PropertyManager.java,Performer.java,Util.java. 下面将进 一步介绍Property Manager和Performer.java类。
(1)Property Manager.java
管理属性(如url,用户名,密码,输入信息,或者是页面中某个元素的显示文字需要改动等),使之从txt文本读入, 由于有些地方内容需相同,为了提高修改效率并减少改变带来的风险,降低软件维护的成本,将这些属性统一写入Test With Selenium.pro的txt文件中。
(2)Peformer.java
实现一系列人工测试时需要完成的动作,将基本动作封装成此类中各个方法。
3、zosmf.fvt.asserter
现建立了一个Base Asserter.java类,各个不同模块的测试可在此基础上进一部细化。完成检查页面元素成功显现的动作,相当于人工测试时确定元素存在,并在找不到元素时在程序运行控制台输出提示未找到该元素的信息。
4、zosmf.fvt.action
zosmf.fvt.action包进一步封装模拟更高逻辑动作。包括Base Helper.java,Core Helper.java,ISPFHelper.java,PDWHelper. java,RMFHelper.java,SMHelper.java,WLMhelper.java,Workflow Helper.java. 其中Base Helper.java是公共可用的部分,其它为各个模块不同的测试动作封装。
四、各个模块测试的自动化
从zosmf.fvt.acion中我们不难发现,z/OSMF一共有七个模块需要进行自动化测试,下面以core部分为例子,简要阐明如何实现自动化测试。
1、zosmf.fvt.action中完成CoreHelper的编写
Corehelper继承Base Helper,这样可以直接使用甚至重写Basehelper里的某些方法,在Corehelper类中把core模块的测试动作封装到里面,使得测试脚本写起来更加贴近我们的实际手工测试动作的描述,大大提高脚本的可读性和健壮性。
2、建立测试案例
使用对应 的部分的Helper, 如core对应的是CoreHelper,写测试脚本,封装于Seleniumtest.testcase.Core包中。 不同的功能模块用一个java类来表示,以core部分为例, 包括Application.java,Links.java,Notification.java. 以便于分 开测试。为了统一测试,则再建立all Core.java,调用前面三个类,囊括所有部分以及零零散散的测试内容,使测试整体化。
五、测试结果
对于同一个版本的web内容在同一个浏览器上进行测试,分别对连续测试1,2,3,4,5次进行计时,并对五个升级版本 (包括自身bug修复后发布的版本和dojo升级后做出适应调节的版本)进行了同一测试。测试结果如下:
1、测试时间
由此实验统计数据我们可以得到具有代表性的数据, 一个平均测试时间数据:
得到图标数据统计如下:
从图中我们 更能直观 的发现 ,自动化测 试随着连 续测试的 次数增多 其增加的 时间呈线 性上升 ,也就是说 , 每一次测 试所花费 的时间是 一般多即 测试速率 是稳定的 ; 而对于手 动测试而 言 , 次数多了 它的斜率 越来越大 ,也就是说 测试速率 越来越慢 ,这是无可 避免的 ,因为人工 测试连续 进行会使 得人产生 疲倦厌烦 情绪 ,而自动化 测试则恰 恰可以避 免连续测 试所产生 的情感上 的影响。
2、发现的bug数量
第一次测试手动发现bug数比自动化发现得少两个; 第二次测试bug数量的增加是在升级的浏览器进行一次测试,之前的bug并未修复,人工测试在基于前一次自动化测试的bug结果上多发现一个bug,而自动化测试却发现了包括人工测试发现的问题在内的两个bug;第三次测试是修复了两个bug后,人工测试除了原有的剩余4个bug,并未发现新的bug,而自动化测试又发现了修复带来的两个新的bug。第四次修复了两个bug后,人工测试未发现新bug, 而自动化测试发 现一个新的bug, 验证发现 此问题并 非bug。第五次是升级dojo后的测试结果。显然,自动化测试比人工测试更能高效工作,提高测试质量。
六、总结
实验表明,由于频繁的回归测试以及有限的时间,使得测试人员从情感上干到疲倦,很难做到非常专业不遗漏等。本文实现了自动化测试在Firefox上稳定进行,自动生成测试结果,不单能节约时间更,并且能发现人工测试过程中因疲倦而难免忽视掉的问题。然而,还是存在很多值得改进的地方,比如,会发现一些并非bug的问题,仍需人工进一步验证;在IE上还未能稳定测试,等等;这些都是是需要改进的;再者就是z/OSMF本身的一些源码设计很可能会有所改动,故需自动化测试的设计也会要跟着有所改动,权衡改动代码的代价和仍旧采用人工测试的代价成为一个需要人们思考的问题。如果源码的改动不是非常频繁,采用自动化测试是值得继续的,这不但能将测试人员从繁琐的回归测试中释放出来,更能为软件项目节省人力,减少软件成本。
摘要：本文研究并采用Selenium+Apache Ant+TestNG,编写出符合实际项目的自动化测试的类框架,并实现自动化测试,通过实验数据证明,自动化后可以使得测试结果更为稳定、可靠。
测试用例自动生成方法研究与实现 篇9
软件测试数据生成在软件系统开发费用中占很大比重。如果该过程能自动实现,则会极大地减少软件开发的周期和费用。这里介绍一种链方法,它利用数据的相关性分析来指导测试数据的生成,因而能更有效地生成测试数据。
1生成测试数据的方法
在初始化测试数据之后,程序员面临的问题是找到额外的测试数据测定没有被覆盖的程序元素,如何找到合适的数据测试那些语句(还称为节点)需要程序员有丰富的编程经验,往往需要花费很多时间,从而增加了软件开发的整体开销。这是因为在软件维护中,程序员并不总是处理自己编写的代码,经常需要修改其他人的程序,往往只能理解一部分,这给维护工作带来一定的困难。而利用测试数据生成器能帮助程序员生成输入数据来测定语句。它主要采用2种方法,即面向路径和面向目标。
1.1 面向路径
面向路径指的是选择程序路径,然后生成该路径的输入数据。要测试的路径可以自动生成,也可以由用户提供。现有的面向路径的测试数据生成器有一些不足之处,这些不足之处与选择路径的过程有关。不知道选定路径是否可行,使得面向路径的方法在使用上受到限制,也就是说常会选定一些不可执行的路径,对这些路径的分析计算成果往往都被浪费掉了。
1.2 面向目标
面向目标是指评定目标语句(或节点)的过程与所选取的路径无关。它的一般方法是只考虑“必要”的分支(它影响目标节点的执行),忽略“不必要”的分支(它对目标节点的执行毫无影响)。该方法克服了面向路径方法的局限性,完全基于程序的控制流图。经实验证明,该方法与以往的方法相比,能更有效地生成测试数据。
2目标搜索的实现
本系统的研制就是基于程序的控制流图,采用面向目标的方法,并利用动态调试工具,从而有效地生成测试数据。它的基本思想是在目标节点执行之前先执行一系列“必要”的节点。如果目标节点没有执行,可以根据逆向推理进一步查找原因。这里定义一种探测器结构,以记录程序的执行路线。此外,还定义了一种链式存储结构——双向邻接表,它将传统的邻接表和逆邻接表结合起来,在表结点和头结点中分别加上指向前一条弧的指针,以及指向第一条指向该顶点的弧的指针,以便于逆向推理的实现。
2.1 探测器技术
探测器结构如下所示:
为记录程序的执行路线,只要跟踪跳转语句的执行情况即可,因此,在每一个跳转语句之后插入一个探测器,就可以很好地记录程序的语句覆盖情况。首先,建立一个记录文件,初始文件中各位数据均为0,其中,相邻的两位分别代表跳转语句的左右2个分支。执行插入探测器的程序之后,会将记录文件中相应位上的0改写为1。通过判断文件中1的位置来确定对应的行号,并在源文件中相应的行上作出标记。在记录文件中可出现4种组合情况:00,01,10,1l。在源程序中对应的行上分别标记为:none,left,right及double,分别表示没有执行跳转语句、执行了左分支、右分支以及双向分支。
2.2 插装技术
分支插装技术记录的是“遍历”程序分支的情况。在8086/8088中的转移指令分为条件转移指令和非条件转移指令(这里只考虑条件转移指令)。以下面的源程序段中的jz labl指令为例说明分支覆盖测试的实现。
如果在jz labl与add bx,ax之间插入探测器,在labl标号与add dx,ax之间插入另一个探测器,并不能准确记录jz lab1这条转移指令产生的2条分支的执行情况。本系统采用将条件转移指令略加变换的方法来完成。变换的方法是生成2个临时标号,如11与12,将jz labl转化为如图1所示的形式。
从功能上讲,它与原来的程序是等价的。转化后的程序中要想记录jz labl产生分支的执行情况就很容易了。可在11与jmpl2之间插入一个探测器,在11与jmp labl之间放入另一个探测器,这样就能正确记录程序分支的执行情况。其中▭代表探测器。
2.3 双向邻接表
表结点和头结点结构如下所示:
程序流图的双向邻接表存储结构说明如下:
以下面程序段为例进行说明。该程序段的流程图如图2所示。其双向邻接表如图3所示。
3目标搜索
输入目标节点之后,即可根据记录文件中的信息进行目标搜索,其过程如下:
(1) 建立双向邻接表(节点的adjvex域为行号);
(2) 输入目标节点序号;
(3) 查找目标节点。程序执行之后,在记录文件中将会记录其执行路线。若从该文件中找到目标节点的记录,说明该节点已被执行过,查找成功;若没有找到,则沿其后向指针找到其父亲节点,再查找父亲节点的执行情况。若没有执行过,则继续查找,否则,说明目标节点的执行与此节点有关,可进一步判断出该语句是一个跳转语句。若改变该节点的执行条件,则一定会改变分支走向。
因此,通过更换一组测试用例的方法可以改变该点的执行流。如果无法找到合适的测试用例,可利用动态调试工具(TuboDebug)中的数据修改功能修改寄存器中的值,从而改变该点的执行流。改变后的程序执行后,在记录文件中会生成新的执行记录。根据新的记录文件再次进行统计,并建立新的文件标记。重复上述操作,直到找到目标节点或其后向节点为空为止。若其后向节点为空,则说明此目标节点是不可达的。
4结语
基于程序的控制流图,通过双向邻接表链式存储结构的定义及实现,插装技术的应用,以及目标跟踪方法的采用,能有效地生成测试数据,从而进一步推进了软件测试技术的自动实现。
摘要：测试用例的生成工作是指选定被测任务、分析输入数据、确定其取值、并分析对应的输出数据。软件测试数据生成在软件系统开发费用中占很大比重,如果该过程能自动实现,则会极大地减少软件开发的周期和费用。介绍一种测试用例自动生成的链方法,这种测试技术,结合插装技术及目标跟踪方法,能有效生成测试用例,从而提高了测试效率。
关键词：测试用例,链,目标搜索,测试数据
参考文献
[1]郑人杰.软件测试技术[M].北京:清华大学出版社,1992.
[2][美]莫斯里.软件测试自动化[M].邓波,黄丽娟,曹青春,等译.北京:机械工业出版社,2003.
[3]Doong R K,Frankl P G.The ASTOOT Approach to TestingObject-oriented Programs[J].ACM Transactionson Soft-ware Engineering and Methodology,1994,13(2):101-130.
[4]夏辉,宋昕,王理.基于Z路径覆盖的测试用例自动生成技术研究[J].现代电子技术,2006,29(6):92-94.