多种自动化测试学习Word下载.docx
- 文档编号:21299436
- 上传时间:2023-01-29
- 格式:DOCX
- 页数:27
- 大小:277.77KB
多种自动化测试学习Word下载.docx
《多种自动化测试学习Word下载.docx》由会员分享,可在线阅读,更多相关《多种自动化测试学习Word下载.docx(27页珍藏版)》请在冰豆网上搜索。
也就说是使用RFT对脚本语言形式的API进行测试需要:
(1)创建使用测试对象—API的测试文件
(2)使用RFT编写测试脚本对测试文件进行验证。
这样对一个脚本语言形式的API进行自动化测试需要维护
(1)包含测试对象的测试文件
(2)需要维护RFT测试脚本,一旦被测的API有变动,需要很大的精力进行维护。
按照问题分析一节中图1的分类方法,API可以分为2类,对于第1类API,需要验证图形界面效果的,如果进行自动化测试则需要使用RFT等测试工具对GUI进行验证。
而第2类API,只需要验证返回值,不需要验证界面效果,不必使用RFT等测试工具进行辅助。
因此本文借鉴RFT和Junit进行自动化测试的思想,使用RFT对对第2类不需要验证界面效果的API进行自动测试。
从实现的角度来看测试工程,一般包括:
(1)测试工程的组织结构
对于测试工程的组织,使用RFT对GUI进行自动化测试有成熟的解决方案,工程组织一般采用分层的结构,AppObjects层(驱动应用程序的Objects),Task层(完成常见操作),测试脚本层(测试用例脚本)。
使用Junit等进行自动化测试时,也往往会对测试工程进行设计或分层的结构,不同的层负责完成不同的功能,从而达到易于维护的目的。
(2)测试文件的组织
测试文件,也就是测试脚本,是对测试用例的实现。
为了方便的组织和使用测试脚本,Junit中的每个测试方法都使用test为前缀来命名,RFT中使用testMain作为执行测试脚本的入口。
(3)验证点的比较
自动化测试的一个核心就是对验证点的处理,只有能自动处理验证点,才能进行自动化测试,无论普通的功能测试还是对API进行测试都不例外。
功能测试验证点的处理往往是通过其控件状态,对话框标题等进行验证;
对API进行测试,可以通过其返回值,或者借助其它API返回结果来进行验证。
在JUnit中对验证点使用assertEquals,assertNoNull等方法对验证点进行处理,自动返回测试结果。
(4)测试结果生成
通常根据验证点的结果,生成测试结果。
(5)测试的执行
对测试脚本进行连续自动执行。
因此,对应用程序脚本语言的API进行自动化测试,也可以采用上文介绍的方法进行组织和执行。
下文将一一进行详细阐述。
3测试工程的组织结构
VBA之类的脚本语言不能像Java、C++等高级语言单独存在,它们往往和其应用文件一起存在,如一个Excel文件可能包含VBA代码(ALT+F11可以看到其代码)。
因此对此类脚本语言的API进行测试,首先需要创建相应的应用程序文件来使用这些API,如创建一个Excel文件。
如对VBA中的API:
Worksheets.Count进行测试,需要在test.xls中使用方法Worksheets.Count,因此测试要测试API:
Worksheets.Count就必须创建一个Excel文件。
如图3所示。
图3.VBAAPI存在的Excel文件
虽然脚本语言不能像高级语言那样方便的在一个工程中通过分层等对代码工程进行优化,但我们仍然可以借鉴上文第2节测试工程组织结构提到的RFT组织测试文件的思想,尽可能的对代码复用。
而从功能的视角来看,测试工程或者测试工具一般需要具有以下功能
(1)编写测试脚本,用于实现测试用例
(2)对验证点进行处理的功能,用于实现对验证点的比较,判断验证点Fail或者Pass(3)执行过程中的Log的处理功能,用于对执行过程中结果写文件日志等(4)错误处理功能,用于执行过程中发生的错误进行恢复和处理。
因此对上文中提到每一个功能使用一个模块(Module)来完成。
除了每个测试用例必须要和测试文件一起之外,其它的部分可以和测试用例分离,做成加载宏来供测试用例调用。
4测试脚本
对于每个测试脚本来说,本文结合JUnit和RFT组织测试脚本的方法,
(1)对每个测试方法使用test为前缀名,方便组织和阅读
(2)使用testMain作为执行入口,调用测试方法。
如对方法Worksheets.Count、Worksheet.Name进行测试,我们按下列结构进行组织。
清单1.对方法Worksheets.Count、Worksheet.Name进行测试
SubtestMain()
testWorksheetsCount
testWorksheetName
EndSub
SubtestWorksheetsCount()
….//TestScript.
SubtestWorksheetName()
….//Testscript.
5验证点的比较
不存在VBA语言的类似JUnit的测试API的工具。
根据上文第2节中阐述的思想,可以自己编写相应的验证点比较方法。
只需要函数返回的真实值和期望值进行比较就可以得到验证点的测试结果,即和真实值和期望值相等,这验证点通过,反之则验证点失败。
为了使结果更有可读性,我们可以提供验证点的描述信息。
例如验证方法:
assertEquals,需要传入期望值,真实值,描述信息,同时把比较结果直接写入文本文件。
测试用例脚本中,在验证点处可以调用此方法对验证点进行判断,自动生成测试结果。
脚本如下所示:
清单2.在验证点处可以调用此方法对验证点进行判断,自动生成测试结果
SubassertEquals(realValueAsVariant,expectValueAsVariant,testDescriptionAsString)
DimvpResultAsBoolean
vpResult=TestAreEqual(realValue,expectValue)
DimtestMsgAsString
testMsg="
---------------------VPStart---------------------"
+Chr(13)+Chr(10)
IfvpResult=TrueThen
testMsg=testMsg+"
VP:
Result=Pass"
Else
Result=Fail"
Test_Result=False
EndIf
Desciption="
+testDescription+Chr(13)+Chr(10)
RealValue="
+CStr(realValue)+Chr(13)+Chr(10)
ExpectValue="
+CStr(expectValue)+Chr(13)+Chr(10)
testMsg
=testMsg+"
----------------VPEnd-----------------------"
IfTESTLOG_VERBOSEThen
TestLog_ITEMtestMsg
6Log文件处理的方法
测试的过程中往往会有异常发生或验证点失败,为了测试执行结束后对异常或者测试失败情况进行分析,需要把测试执行过程的信息进行记录,因此需要有Log处理机制。
我们把测试执行中步骤信息,测试说明,测试结果等写入文本文件。
为了有可读性,同时方便分析Log文件生成更易读的报告文件,需要对Log文件的内容和格式进行定义。
生成的Log文件包括以下部分:
(1)开始执行时间
(2)验证点信息,包括验证点描述信息、验证点期望值、真实值、验证点的结果(3)执行结束时间(4)整个测试用例的执行结果。
每个测试用例生成一个Log文件,使用测试文件名来对Log文件来命名。
我们使用以下格式:
--------------------------VPStart--------------------------
Result=PassorFail
Desciption=Theverificationpointdescriptioninformation.
RealValue=Therealvalueoftestobject
ExpectValue=Theexpectvalueoftestobject.
--------------------------VPEnd----------------------------
7错误处理机制
测试执行过程中必然会遇到错误发生,为了使测试能够连续的执行,不会因为一个错误而中断了整个测试的执行过程,同时方便测试执行结束后分析错误原因,需要对运行时的错误进行处理。
从测试的观点来看,测试用例是用来测试被测对象,测试脚本只需要严格按照测试用例中的步骤来编写。
如果对测试脚本加了容错方法,则成为测试“测试脚本”,因此不应在每个测试脚本中加容错处理。
我们只需要在testMain方法中加上容错处理,来捕获运行时的错误,运行时的错误描述信息写入Log文件。
代码片段如下:
清单3.将运行时的错误描述信息写入Log文件
OnErrorGoToErrorProcess
testMothed1()
testMothed2()
....
ExitSub
ErrorProcess:
TestLog_Error(Err.Description)
Resume.Next
endsub
8连续的执行测试
上文中我们提到一个或多个API存在一个测试文件中,也就是一个测试脚本存在于一个测试文件中。
它不像JUnit等所有测试脚本都在一个工程中,而且有TestSuite机制可以方便的连续执行需要的测试脚本。
RFT运行测试脚本时,会自动运行testMain方法,且脚本都在一个Java工程中,可以方便的连续执行所有的测试脚本。
上文中介绍到本文测试脚本的组织结构,每个测试脚本都存在testMain方法中,因此我们只需要运行测试文件,调用testMain方法既可脚本以运行测试脚本。
我们借鉴这种运行测试脚本的机制,只要可以连续处理测试文件,测试脚本就可以被连续的执行。
我们使用VBA语言来操作测试文件,连续执行测试脚本。
也可以使用其它高级语言来操作测试文件,启动测试脚本。
考虑到Symphony项目中对VBA只是部分支持,我们使用Java去操作测试文件,执行测试脚本,SymphonyToolkit中存在相应JavaAPI可以读取和操作测试文件。
图4所示其流程图:
(1)读取测试文件列表
(2)逐个打开测试文件(3)调用测试脚本。
对于其它脚本语言也可以根据此思想通过其它方法进行操作。
如使用RFT打开测试文件,模拟用户去调用测试脚本等。
图4.连续执行测试脚本流程图
9TestSuite的生成
在Symphony项目中我们使用基于Domino和LotusNotes的TestCaseDatabase对测试用例和测试执行进行管理。
测试存在不同的测试阶段如FVT,SVT,即使是一个测试阶段如FVT又可以分为FVTFistPass,RegressionTest等,并且需要在不同的操作系统上进行测试,需要执行不同的测试用例集合。
每个测试用例中包含了所需要的测试文件(Excel文件),测试对象(被测API列表)等。
一个测试用例可以在多个测试Cycle中执行,而每个测试执行文档记录都有一个唯一的URL,因此我们可以根据测试需要,生成由URL,测试文件名组成的TestSuite文件。
从而根据TestSuite来执行需要被执行的测试脚本。
我们使用Java代码去操作TestCaseDatabase生成TestSuite。
其核心代码片段如下:
清单4.使用Java代码去操作TestCaseDatabase生成TestSuite
NotesThread.sinitThread();
//初始化连接NotesDB线程
Sessionsession=NotesFactory.createSession(
(String)null,(String)null,password);
//获取连接NotesDB的Seession
Databasedatabase=session.getDatabase(host,nsf,false);
//获取TestCaseDatabase
DocumentCollectiondc=database.search("
ExecCycleID="
+"
\"
"
+cycle+"
);
//根据Cycle获取测试记录集合
Documentdoc=dc.getFirstDocument();
//把测试集合中的测试记录关键信息写入TestSuite
while(doc!
=null){
suiteFileWriter.write("
-DexecutionURL="
+doc.getURL()+"
"
+tcID+"
\r\n"
doc=dc.getNextDocument();
}
10测试结果写TestCaseDB
为了对测试执行过程进行管理,执行完测试脚本,需要把测试结果写入到TestCaseDB,达到对测试过程的追踪和记。
一次测试过程往往需要对上千个API进测试,也就会有上千个执行记录,如果根据执行结果,手工去标记执行结果的状态会浪费大量时间,而且容易出错。
从上文中可以看出,对每个测试脚本我们都会生成Log文件,Log文件中包含测试脚本的执行结果和TestCaseID,TestSuite中含有可以唯一标识测试记录的URL和TestCaseID,因此可以通过分析Log文件和TestSuite文件,把测试结果批处理写入到TestCaseDb中。
核心代码片段:
清单5.把测试结果批处理写入到TestCaseDb中
Sessions=NotesFactory.createSession((String)null,(String)null,password);
Databasedatabase=s.getDatabase(host,nsf,false);
//获取TestCaseDataBase
Documentdoc=db.getDocumentByUNID(getDocUNID(URL);
//获取测试记录文档
...
doc.replaceItemValue("
ExecCountPassed"
newInteger(doc.getItemValueInteger("
)+1));
//写入测试用例执行结果
ExecDateLast"
newDate().toString());
//写入执行时间
doc.save();
11测试报告的生成
上文中介绍到执行每个测试脚本后都会生成一个Log文件。
对整个测试来说,我们需要有一个概要的测试报告,而不是去查看所有Log结果文件。
我们只需要分析Log文件和TestSuite文件,生成一个可读的测试包括,Symphony项目中我们采用XSL定义生成一个HTML文件。
对于XSL本文中不进行介绍。
12使用RFT自动进行测试
本节将介绍结合RFT对脚步语言进行自动测试在IBMLotusSymphony中的实践。
上文第8节中提到了连续的执行的方法,因此我们只需使用RFT在IBMLotusSymphony中连续打开包含需要测试的脚本API的文件,并点击一个CommandButton,使脚本进行执行,其它的验证点处理等则由脚本语言自己处理。
因此只需要编写一个通用的根据文件名,打开文件,并点击CommandButton的RFT脚本,不需要对每个测试文件编写一个RFT脚本。
处理完所有的测试文件,则生成测试结果,并写入测试用例数据库TCDB。
如图5所示。
图5.RFT自动执行测试流程图
所用的RFT脚本核心代码如下:
清单5.RFT脚本
publicvoidtestMain(Object[]args){
StringfileName="
;
if(args!
=null&
&
args.length!
=1)
return;
else{
fileName=(String)args[0];
try{
//打开测试文件
CommonTask.openFile("
sample/Macro/"
+fileName);
//Sheet1上的StarMacro按钮,根据类型ID进行查找
VclButtonbtn=newVclButton("
.find:
588183260"
//触发调用脚本语言API
btn.click();
//释放资源,关闭这个测试文件
CommonTask.discardAll();
}catch(Throwablet){
//异常处理
//处理VBA脚本生成的Log文本文件,放到Log目录下
FilelogDir=newFile(VBAConstant.OUT_DIR);
if(!
logDir.exists())
logDir.mkdirs();
FilenewLoc=newFile(VBAConstant.OUT_DIR,fileName.substring(0,
fileName.lastIndexOf("
.xls"
))+"
.log"
booleanret=VBAUtil.copyFile(logFile,newLoc);
//根据Log文件,分析脚本API执行结果
booleanresult=false;
StringexcResult=VbaLogProcessor.analyzeLog(logFile);
if(excResult.equals(VbaLogProcessor.TEST_PASS)){
result=true;
}elseif(excResult.equals(VbaLogProcessor.TEST_FAIL)){
result=false;
}else{
Logger.error("
ErrorOccured"
Verify.verifyTrue(tcid+"
result:
result);
根据上文的描述和以上代码,只需要使用RFT根据文件路径和名称在IBMLotusSymphony中打开一个Excel测试文件,并点击Sheet1中的CommandButton:
StartMacro就可以VBA
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 多种 自动化 测试 学习