QTP框架及编码标准.docx
《QTP框架及编码标准.docx》由会员分享，可在线阅读，更多相关《QTP框架及编码标准.docx（16页珍藏版）》请在冰豆网上搜索。
QTP框架及编码标准
目录
1概要1
1.1目的1
1.2参考文档1
2项目自动化测试用例设计构架1
2.1测试脚本与测试数据相分离1
2.2测试脚本的组织1
2.2.1脚本文件分类1
2.2.2脚本模块化规则2
2.3测试数据的组织3
2.3.1测试数据的分类3
2.3.2测试数据组织方法4
2.3.3测试数据与相关模块在管理工具及本地的目录组织方法4
2.3.4测试脚本中数据库操作4
2.4非测试脚本文件的组织5
3脚本设计规则5
3.1脚本文件命名规范5
3.2书写格式5
3.3变量，常量命名规范6
3.4Checkpoint基本规则8
3.5Action脚本设计规则8
3.5.1Action命名规范8
3.5.2Action划分粒度9
3.6注释9
3.7参数传递10
4脚本制作过程12
5.1基于QTP的流程规范,如图所示：
12
5.2脚本录制及对象库的维护13
5.3设置对象识别属性14
功能自动化测试脚本设计规范
1概要
1.1目的
提高自动化测试效率，提高代码复用程度，减少重复劳动，增强代码的易读性，易维护性，通用性等。
提高测试质量，降低脚本维护成本；最终达到减低项目成本，提高项目质量的目的。
1.2参考文档
QTPTutorial
QuickTestAutomationReference
QuickTestProfessionalCodeSamplesPlus
QuickTestProfessionalHelp
2项目自动化测试用例设计构架
架构包括输入数据，操作过程和输出数据以及相关标准。
为对项目自动化测试用例进行有效管理，定义如下设计规则。
2.1测试脚本与测试数据相分离
测试脚本记录了业务实现的操作过程，一个测试脚本可对应多组数据，每组数据与测试脚本构成一个测试用例。
当数据与脚本分离后，数据的组织更具多样性，提高测试覆盖率。
测试脚本通过对输入与输出数据进行参数化来达到脚本与测试数据分离的目的。
2.2测试脚本的组织
2.2.1脚本文件分类
按照QTP脚本组织形式，自动测试脚本文件分为如下类型：
1.Action脚本
记录人机交互操作过程和checkpoint功能；
2.公用脚本
典型算法函数或操作脚本等，供Action脚本或其它脚本函数调用；
3.测试恢复脚本
自动测试异常恢复运行脚本，也包括当出现异常时初始化被测试系统的initialization脚本；
4.场景组织脚本
通过call不同的Reusableaction脚本，形成特定场景，也可通过条件语句控制ReusableAction的执行，也可包括checkpoint功能。
脚本文件分类关系如下图所示：
2.2.2脚本模块化规则
1.借鉴编程思路，抽象出公用算法作为单独函数保存在一个文件中，被其它脚本统一调用；
2.一般每个最小功能点（如addnewrecord）作为一个Action处理，功能复杂时分拆为多个Action，建议每个Action作为一个测试模块文件，以提高维护性；
3.每个测试场景通过建立自己的main脚本call不同ReusableAction模块文件形成场景过程；
4.测试数据以Xls文件进行组织管理，在一个基本UseCaseModel内的测试场景对应一个xls文件，这个xls文件保存测试场景对应的所有测试数据，包括多个UseCaseModel的大型复杂场景，可按照实际需要组织多个xls文件。
5.测试脚本对应一个场景组织脚本，一个场景根据测试目的、粒度不同，可由一个Action脚本构成（此时，Action即为测试脚本），也可由多个Action脚本组成。
2.3测试数据的组织
2.3.1测试数据的分类
根据测试用例的定义，测试数据包括：
输入数据和期望值。
为控制和了解测试用例的运行状态，以及配置测试环境，测试数据还包括用例状态标识数据和运行环境数据4种类型，定义如下：
1.运行环境数据
包括:
用于确定测试对象应用系统运行环境数据、包括数据源、数据库访问帐号等。
如：
URL,登录系统的用户名，密码，操作权限等；在测试用例运行前后数据值保持不变；
2.用例状态标识数据
用于标识和记录测试用例运行过程状态。
这些数据在用例运行前作为输入数据，在运行结束后作为输出数据，数据值在用例运行前后会发生改变；
3.输入数据（在XLS文件中用蓝色表示）
指测试对象应用系统按照测试场景运行时，从人机界面输入的数据，输入期望值等；在测试用例运行前后数据值保持不变,包括；
人机界面输入数据
运行期望结果
用例标识及循环控制变量等
4.输出数据（在XLS文件中用绿色，其中是否通过的标志位当值为PASS时为绿色，FAIL时使用红色，当非必填字段时背景应设置为灰色）
指测试用例按照测试场景和输入数据运行完成后，按照测试对象应用系统用户需求或设计规则，必需产生或输出的结果。
包括：
运算后输出值
测试用例的运行结果
用例是否通过的标志字段（用红色表示）
2.3.2测试数据组织方法
根据Excel文件数据管理方式：
一个Excel文件相当于一个数据库，Excel中的Sheet表的第一行定义Field的名字。
一个sheet对应一个Action所需要的输入/输出数据。
即对应一个界面的输入/输出数据。
基于Excel文件数据管理特点和测试用例总体规范，测试数据组织规则如下：
1.按照测试需求覆盖性要求，一个UseCaseModel对应一个Excel文件。
Excel文件命名与被测模块同名；
2.一个测试用例的运行环境数据用一个或多个sheet表管理。
3.Sheet表可按照业务对象进行组织，也可按照业务状态进行组织，业务对象数据包括属性值、状态值等。
Sheet表命名与对应的Action名一致;
4.数据组织模板如下：
2.3.3测试数据与相关模块在管理工具及本地的目录组织方法
为了提高代码及数据的共享程序，整合测试管理与测试执行，提高测试的自动化程序。
在如TD和QC等工具上相关的目录结构如下：
Automation
|Commonfunctionlibrary（存放整个项目的公有函数）
||
||-----------Actionnamefunctionlib（存放相应的Action的公有函数）
|Commonscript<-存放整个项目的公用Action
||
||-----------Actionnamecommonscript（相应Action的公有函数）
|Resume<-（存放测试些模块所需要的脚本文件）
||---------Addresume<-（测试此模块中相应子模块的脚本）
|Data（测试所需要的数据文件）
|Recourse<--（测试所需要的其它资源文件，即本节2.4里提到的文件）
测试脚本与测试数据的交互
2.3.4测试脚本中数据库操作
由于测试脚本为模拟用户操作过程，容易出现运行异常中断，因此，在测试中数据库操作规定如下，以提高测试脚本质量。
1.脚本尽量使用相对路径连接数据库；
2.在数据库打开与关闭语句间，尽量不要插入操作记录语句，以防止脚本运行异常后数据库死锁和状态记录标记不一致；
3.从数据库读入数据时，通过测试脚本中定义的变量赋值后保存，以供脚本使用；
4.向数据库更新数据后，必需尽早Close数据库的连接。
5.所有打开的数据库连接，在程序中一定要关闭。
2.4非测试脚本文件的组织
项目测试中，还包括项目需求、变更需求、设计说明等文档。
在目前测试用例的构架中，只作为引用附件处理，作为测试需求与测试变更的依据。
存放于每个项目的resource目录下。
3脚本设计规则
3.1脚本文件命名规范
脚本命名应尽可能表达包含的业务意义，一般包括项目名称和模块名称，必要时可以加入其它信息简称，如下是一些例子：
db_connect:
连接数据库
db_disconnect:
关闭数据库连接;
db_execute_query:
执行查询
db_get_field_value_SQL:
获取字段值
．．．．．．
3.2书写格式
1.代码格式应该比较整齐，可采用空格进行缩进对齐，相关业务代码进行换行；
2.遇到多层循环要详细注明其意义；
3.代码注释应尽量详尽；
4.IF/EndIF语句要分嵌入层次进行缩进对齐。
5．考虑到项目具体情况的不同，每个项目应有符合项目需要的头文件。
6．添加ActionTemplate.mst模板文件到安装目录的dat文件夹下面，如：
Optionexplicit
'------------------------------------------------------------------
'scriptname
'Desc:
'Inputs:
'Outputs:
'Author:
'Date:
'ModifyHistory（包括更改日期，更改人，更改原因等）:
'relatedfunctions:
'------------------------------------------------------
具体例子如下：
Optionexplicit
'------------------------------------------------------
'scriptnamePMS_Modify_Resume_Record
'Desc:
ThisActionfileisforeditingtheresumerecord.
'Inputs:
resume_test_case.xlssheetname:
modify_resume_record
'Outputs:
resume_test_case.xlssheetname:
modify_resume_record
'Author:
Claude
'Date:
11/07/2006
'ModifyHistory:
11/07/2006modifiedbyClaude
'relatedfunctions:
OpenExcel（），ReadExcel（）,SaveToExcel（）
'------------------------------------------------------
3.3变量，常量命名规范
1.变量名称借用Camel法则，每个单词的首字母大写，且变量名称尽量能表达业务内容，如：
PolicyCode、CaseNo等；
2.为提高脚本可读性，变量名可增加适当的前缀，表示为【前缀】【_】【变量名】的形式。
引入如下前缀：
●Glb_:
全局变量；
●Re_:
脚本从人机界面取值的变量；
●Ex_:
在checkpoint中，使用的期望值；
●DB_:
变量值需要输入/输出数据文件的变量，常用的前缀见下表：
●Out_：
函数或Action用到的返回值
●In_：
函数或Action的输入参数。
●Arr_:
数组数据。
Subtype
Prefix
Example
Boolean
Bln_
Bln_Found
Byte
Byt_
Byt_RasterData
Date（Time）
Dtm_
Dtm_Start
Double
Dbl_
Dbl_Tolerance
Error
Err_
Err_OrderNum
Integer
Int_
Int_Quantity
Long
Lng_
Lng_Distance
Object
Obj_
Obj_Current
Single
Sng_
Sng_Average
String
Str_
Str_FirstName
当使用描述性语言引用对象时，应该使用如下表所示的前缀：
Objecttype
Prefix
Example
3DPanel
Pnl_
Pnl_Group
Animatedbutton
Ani_
Ani_MailBox
Checkbox
Chk_
Chk_ReadOnly
Combobox,drop-downlistbox
Cbo_
Cbo_English
Commandbutton
Cmd_
Cmd_Exit
Commondialog
Dlg_
Dlg_FileOpen
Frame
Fra_
Fra_Language
Horizontalscrollbar
Hsb_
Hsb_Volume
Image
Img_
Img_Icon
Label
Lbl_
Lbl_HelpMessage
Line
Lin_
Lin_Vertical
ListBox
Lst_
Lst_PolicyCodes
Spin
Spn_
Spn_Pages
Textbox
Txt_
Txt_LastName
Verticalscrollbar
Vsb_
Vsb_Rate
Slider
Sld_
Sld_Scale
3.不同脚本或action中的同一业务变量用相同变量名称表示；
4.在函数内部局部简单变量中，如循环控制变量，记数器等，可采用简单表示，但需要增加适量说明。
5.常量命名约定：
使用大写的格式，并以“CON”作为常数名的前缀。
例如：
CON_ARRAY_LENGTH
3.4Checkpoint基本规则
1.对于输入数据的预期结果，需通过Checkpoint或手写的类似于checkpoint功能的函数进行验证；
2.与业务状态、业务算法有关的所有运行结果一般都需有Checkpoint或手写的类似于checkpoint功能的函数进行验证；
3.Checkpoint必须有验证通过与不通过两种处理：
验证通过后，输出预期值到Excel文件中，作为期望值保存；如果验证不通过,应在Checkpoint的False结果中输出实际值，便于更详细的提交BUG。
如：
IfsomestatementThen
reporter.ReportEventmicPass,,"checksuccessfully!
"
else
reporter.ReportEventmicFail,,someinformation
EndIf
3.5Action脚本设计规则
3.5.1Action命名规范
Action命名按照业务逻辑遵从如下命名原则：
Actionname=前缀+实现功能简称，如下的例子做参考：
PMS_Modif_Resume:
修改简历记录。
PMS_Add_New_Resume:
添加新的简历记录。
PMS_login_Resume:
登录脚本
PMS_Search_Resume:
简历记录的查询
．．．．．．
3.5.2Action划分粒度
在考虑的action划分时，要考虑到脚本的复用性，同时也要考虑到其实现业务功能的明晰性。
1.每个最小功能点（如addnewrecord）能尽量以一个Action来对应；
2.通常一个Action应该与一个用户界面相对应，尽量只从一个sheet中提取数据。
3.6注释
脚本在录制和设计过程中一定要做好比较详尽的注释，保证第一次使用的人能够看懂使用，有如下几方面需要注意：
其一，脚本注释尽可能注明其实现的功能及其局限性，必要时附上readme文件．
如下是新契约脚本注释示例：
Environmentsupported:
sgtestenv,sgsitenv,sguatenv
Implementedfunction:
Productssupported:
0170,0158,158C,0170+T81
Workflow:
InitialReg-->DetailReg-->Verification-->UW-->collection
......
Policygenerated:
allpolicyinforcedarerecorededinout-paramsheet.
......
其二，Action内部业务逻辑步骤需要注释，如：
‘loginsystem
…
‘Addproposalinformation
…
‘Completeproposalinformationindetail
…
其三，特定变量，参数的含义需要注释,如：
‘globalvardeclaration
DimGlb_cust_name'customername.
DimGlb_cust_id'customercenticode
DimGlb_cust_bir'customerbirthday
DimGlb_pro_prefix'proposalnumberfirstpart
其四，Action实现的功能及其输入输出参数需要注释，如：
3.7参数传递
有如下基本使用原则：
1）对于Action内部的参数传递尽量使用局部变量。
2）对于Action之间传递参数尽量使用Action本身的参数，其次选用公共变量，Globaldatatable等.
Action参数传输：
RunAction“NB_Initial_Reg”,OneIteration,in_param,out_param
In_param:
传入到NB_Initial_Reg的参数
Out_param:
传出的参数值
Action定义：
Action参数使用：
Parameter（"In_prd_flag"）=2
4脚本制作过程
5.1基于QTP的流程规范;
5.2脚本录制及对象库的维护
5.2.1脚本录制的相关说明
在开发自动化测试脚本最简单有效的方式是录制待测业务流程，然后对脚本进行修改，再进行回放。
为避免同一操作多次录制导致对象库对象冗余甚至凌乱不堪，推荐用关键字驱动方法产生脚本，可从ActiveScreen中来产生步骤来实现。
特别是在环境不稳定的情况下，同一页面的不同操作都可以通过录制一次操作而记录出ActiveScreen，其它操作再通过ActiveScreen产生出来。
脚本录制建议如下：
1）录制前对所录制流程应该非常熟悉，建议最少要手工做一次以上．
2）录制操作尽量做到规范到位，不要有很大的随意性．比如在录制菜单操作时，如果没有将webevent配置好，onMouseOver事件是没有的，这时到下一级菜单前就点击当前菜单项；当在页面输入数据时，控件之间焦点切换尽量使用鼠标点击来使控件获得焦点，避免经常使用tab键。
3）对于要重新录制的操作能从现有ActiveScreen中产生的要尽量从ActiveScreen中产生。
5.2.2对象库的相关维护说明
1）对象的命名需按变量命名规定中相关说明对相应的对象进行命名
2）尽量采用descriptiveprogramming，避免对象库过于庞大。
如图所示：
5.3设置对象识别属性
有如下原则遵循：
其一，要考虑到语言的无关性．如下两点要注意：
Winbutton:
语言无关性调整：
调整前：
调整后：
Webpage:
其二，配置特殊的事件方法（webevent）
注：
这里的特殊事件是指QTP在默认情况下不记录的事件，如：
mouserover,webcheck等。
如果程序中需要记录则需要一定设置，才可进行相关操作。
OnMouseOver事件配置：
Webcheck特殊事件配置：
升级会员 