QTP自动化测试流程规范试用.doc

QTPQTP 自动化测试流程规范自动化测试流程规范 创建者创建者确认确认批准批准 姓名姓名朱启祥朱启祥 日期日期2010 12 22 修订历史记录修订历史记录 版号改号日期修订者修订要点 V1 0A2010 12 22朱启祥创建该规范文档结构及主要内容 V1 1M2010 12 27朱启祥增加第 4 5 7 章 第 6 章增加 6 1 2 6 1 3 6 1 4 6 1 5 小节 完善了 6 1 9 小节 V1 2M2010 12 29朱启祥修改第 6 2 小节 A 添加 M 修改 D 删除 目录目录 1概述概述 4 2自动化测试流程自动化测试流程 4 3对象库管理规范对象库管理规范 5 4使用策略使用策略 5 4 1脚本复用 5 4 2ACTION划分粒度 6 5脚本录制规范脚本录制规范 6 5 1识别属性调整 6 5 2脚本录制 8 6测试脚本规范测试脚本规范 9 6 1自动化脚本编写的规范 9 6 1 1 基本信息 9 6 1 2 ACTION设计 10 6 1 3 ACTION命名规范 10 6 1 4 数据表命名规范 10 6 1 5 常量命名规范 11 6 1 6 变量命名规范 11 6 1 7 参数命名规范 11 6 1 8 函数命名规范 12 6 1 9 代码注释规范 12 6 1 10 空行 14 6 1 11 缩进 14 6 1 12 续行 14 6 2信息文档化 14 6 3操作和业务分离 15 6 4数据和脚本分离 16 6 5总结 16 7脚本管理规范脚本管理规范 16 8需求变更需求变更 17 9其他其他 17 1概述概述 本文档主要对自动化测试过程的资源管理维护和需求变更规范说明 测试 过程的资源有 测试脚本 测试操作 库函数 场景恢复 测试数据 对象库 等 2自动化测试流程自动化测试流程 自动化测试流程主要是用来指导自动化测试过程的 在整个过程中 做自 动化测试框架已经包括了对自动化的要求 也包括了自动化框架代码 根据外 包项目情况可选择适合的自动化测试框架或编写自动化测试框架 如果使用 QTP 作为自动化测试工具 则可以选择先录制脚本 再修改脚本 的方式 但是这样的脚本往往比较冗长 且对于系统中的一些页面或窗口控件 支持上有问题 所以可以采用直接在 QTP 中编辑脚本的方法 自动化测试流程如图 2 1 所示 业业务务分分析析师师项项目目经经理理测测试试工工程程师师测测试试开开发发工工程程师师文文档档 选选择择自自动动化化测测 试试框框架架 选选择择业业务务 设设 计计测测试试场场景景 测测试试数数据据准准备备 检检查查入入口口条条件件 编编辑辑测测试试脚脚本本 参参数数化化 执执行行脚脚本本 分分析析测测试试结结果果 缺缺陷陷分分析析 是是否否达达到到自自动动 化化覆覆盖盖率率要要求求 结结束束 业业务务分分析析指指 导导与与咨咨询询 用用例例评评审审 是是 否否 测测试试设设计计测测试试执执行行 是是 否否 开开发发测测试试工工具具 维维护护测测试试工工具具 测测试试用用例例 测测试试记记录录 缺缺陷陷报报告告 自自动动化化测测试试流流程程 图 2 1 3对象库管理规范对象库管理规范 对象仓库的管理要满足以下几个原则 1 每个 Browser 下的 Page 或 Windows 不要太多 即使系统都在同一个 IE 窗口下 没有弹出新 IE 也可以分几个 Browser 管理 把业务上关 联较强的几个 Page 或 Windows 放在一个 Browser 下 2 制定统一的对像命名规范 对象按照所代表的业务属性命名 最好用 中文 不要出现一些晦涩难懂的字符 比如 abc 要生成一份命名规范对照表 原始对象名 使用对象名 3 避免在一个 tsr 文件中堆放过多的对象 根据业务流程把对象分为几个 tsr 文件保存 这里没有统一标准 以每个 tsr 文件结构清晰为宜 4 避免每个测试脚本单独对应一个对象库 要求所有的脚本对应一个或 几个对象库 并且对象库之间的对象唯一区分 4使用策略使用策略 4 1 脚本复用脚本复用 由于我们测试团队是分组合作的模式 每个组分别管各自的模块 组间的 合作比较密切 我们开发测试脚本时 一定要考虑到我们自己设计的脚本不光 只有我们自己使用 别的组或者测试人员都可以使用 尽量避免业务流程重复 录制工作 达到脚本最大程度上的复用 如图 4 1 是脚本组织示意图 图 4 1 下面提供一个公用模块的 Excel 列表 其中有各个模块被抽象出来的 Action 名以及明细内容 Action Param 4 2 Action 划分粒度划分粒度 在考虑的 action 划分时 要考虑到脚本的复用性 同时也要考虑到其实现 业务功能的明晰性 以下是我认为要注意的几个原则 其一 实现功能单一与其他模块耦合度比较低 其二 输入及输出数据不要太复杂 其三 实现的步骤最好不要超过 100 行脚本代码 其四 对于比较长的 action 尽量将其划分为多个子 action 其五 尽量按照与菜单一一对应的方式来实现 Action 5脚本录制规范脚本录制规范 5 1 识别属性调整识别属性调整 有如下原则遵循 其一 要考虑到语言的无关性 如下两点要注意 Winbutton 语言无关性调整 调整前如图 5 1 图 5 1 调整后如图 5 2 图 5 2 Web page 如图 5 3 图 5 3 可以通过 Generate Script 按钮生成相关 Object Indentification 的配置文件 vbs 统一存放在 TD 上 大家只需要直接运行该 vbs 文件就能对本地 QTP 的 Object Indentification 做统一的配置管理 其二 配置特殊的事件方法 web event OnMouseOver 事件配置如图 5 4 图 5 4 Webcheck 特殊事件配置如图 5 5 图 5 5 5 2 脚本录制脚本录制 我们在开发自动化测试脚本时 最简单有效的方式是录制待测业务流程 然 后对脚本进行修改 再进行回放 然而在实际工作中 往往会出现对同一操作 多次录制的情况 这种情况很可能会导致对象库对象冗余甚至凌乱不堪 这给 后期的维护带来很大的不便 因此推荐大家从 Active Screen 中来产生步骤 特 别是在环境不稳定的情况下 同一页面的很多操作都可以通过录制一步操作而 记录出 Active Screen 其它的步骤再通过 Active Screen 产生出来 如下原则请 注意 第一 录制前对所录制流程应该非常熟悉 建议最少要手工做三次以上 第二 录制操作尽量做到规范到位 不要有很大的随意性 比如在录制菜 单操作时 如果没有将 web event 配置好 onMouseOver 事件是没有的 这时到下一级菜单前就点击当前菜单项 当在页面输入数据时 控件之 间焦点切换我们经常使用 tab 键 在录制时我们尽量使用鼠标点击来使 控件获得焦点 第三 对于要重新录制的操作能从现有 Active Screen 中产生的要尽量从 Active Screen 中产生 参见如下操作如图 5 6 图 5 6 6测试脚本规范测试脚本规范 为了使所有的测试工程师在进行自动化设计和测试时能够使编写的脚本风格 一致 步骤一致 能够把大家的设计和代码组装在一起 因此有必要对自动化 测试脚本编写进行统一的规范化 下面就先来介绍我们的项目组整理编写的自 动化脚本编写的规范 6 1 自动化脚本编写的规范自动化脚本编写的规范 6 1 1 基本信息基本信息 在每个脚本模块的最上面 必须写上脚本运行的软件和硬件环境 如 IE 版 本 QTP 版本 数据库版本等 外包项目名称 脚本编写人 使用英文名或 中文拼音缩写 脚本创建时间 脚本修改时间 修改说明 输入参数 输出参 数 脚本描述等 6 1 2 参数传递参数传递 有如下基本使用原则 其一 对于 Action 内部的参数传递尽量使用局部变量 其二 对于必须使用 DataTable 传参的尽量使用 local table DataTable para name dtLocalSheet 其三 对于 Action 之间传递参数尽量使用 Action 本身的参数 其次选 用 Global table Action 参数传输 RunAction NB Initial Reg OneIteration in param out param In param 传入到 NB Initial Reg 的参数 即下图 prd flag 的值 Out param 传出的参数值 即下图的 policy code 输出值 Action 定义如图 6 1 Action 参数使用 Parameter prd flag 2 6 1 3 Action 设计设计 Action 设计请注意如下事项 其一 命名要有一定的业务含义并且遵从 4 2 的命名规范 其二 Code 的编写遵从一定的编程规范 I 脚本开头遵从模版文件的约束 II 代码格式应该比较整齐 可采用 Tab 进行缩进对齐 III 遇到多层循环要详细注明其意义 IV 代码注释尽量详尽 其三 尽量将复用比较多的业务流程设计成公用的 Action 比如登录系 统等 其四 Action 调用最好不用超过两层 其五 对于 public 公共模块的 Action 最好封装起来不使用额外的 xls 表 格 传入或者传出的参数请尽量使用 Action 参数传递 6 1 4 Action 命名规范命名规范 Action 命名要有一定的业务意义 往往与业务逻辑的划分 遵从如下民 命原则 Action name 前缀 实现功能简称 如下的例子做参考 NB Login 新契约登录 NB Initial Reg 新契约基本信息录入 NB Detail Reg 新契约详细信息录入 6 1 5 数据表命名规范数据表命名规范 每个脚本用一个数据表 命名为 脚本名 Param 数据表基本分为三个 sheet 分别为 In Param 即 input parameters 输入参数表 存放脚本运行前所依赖的输入 参数 比如 环境 URL 登录系统的用户名 密码 运行次数 保单号等 RT Param Run time parameters 运行时参数表 运行脚本的时候所依赖的输 入参数 比如 新契约险种信息 保全客户资料信息等 如果运行时脚本之间有多个 Action 导致运行时参数会有很多 可以再对参数 表进行细分 比如 RT Action1 Param RT Action2 Param Out Param Output parameters 输出参数表 存放脚本执行完成后输出信息 比如 新契约产生的 保单数据 理赔产生的案件号等 具体示例参加如下 xls 文件 NB Param xls 6 1 6 常量命名规范常量命名规范 常量的命名应该全部用大写 使用 作为单词间的分隔符 单词尽量使用 全名称 如 Public Const MSG EMPTY ROW As String 有空行存在 使用 Public 而不是早期版本的 global 来声明变量 另外 对常量的声明必须带上类型 如前面的 As String 6 1 7 变量命名规范变量命名规范 变量命名应该简单 应尽量使用缩写 如果是一般的值类型 如 integer string 则直接使用变量用途命名 尽量使用全名 例如 Dim name 如果是 一般的临时性变量定义 应该尽可能地简单 例如 Dim i 如果名称由多个单 词组成 则取每个单词的首字母 如 EntityManager 缩写为 em ProcedureManager 缩写为 pm 如果名称由一个单词组成 则对单词进行分 段取首字母 如 Entity 缩写为 et 缩写应该控制在 3 个字母以内 且尽量清晰 例 6 1 8 参数命名规范参数命名规范 参数命名的原则是全部用小写 如果参数包括两个或两个以上的单词时 首 单词字母小写 其他单词首字母大写 如 stepName stepDescription 6 1 9 函数命名规范函数命名规范 此处函数包括 sub 和 function 函数表示的是一个动作 所以它的结构应该 是动词 名词 动词必须小写 后面的名称首字母大写 如 getMaterialCode 函 数命名尽量不要使用缩写 而且它的名称应该使人一目了然 能够从名称就知 道这个函数的功能 不要使用无意义的函数名称 当函数名称不足以表达其功 能时 应使用在函数头部加上让调用者足够明白的注释 6 1 10 代码注释规范代码注释规范 注释务必做到准确简洁 能够充分表达代码实现的功能 脚本在录制和设计过程中一定要做好比较详尽的注释 保证第一次使用的人 能够看懂使用 有如下几方面需要注意 其一 脚本注释尽可能注明其实现的功能及其局限性 必要时附上 readme 文件 如下是新契约脚本注释示例 Environment supported sg test env sg sit env sg uat env Implemented function Products supported 0170 0158 158C 0170 T81 Workflow InitialReg Detail Reg Verification UW collection Policy generated all policy inforced are recoreded in out param sheet 其二 Action 内部业务逻辑步骤需要注释 如 login system Add proposal information Complete proposal information in detail 其三 特定变量 参数的含义需要注释 如 global var declaration Dim cust name customer name Dim cust id customer centi code Dim cust bir customer birthday Dim pro prefix proposal number first part Dim pro sec proposal number second part Dim pro number proposal number Dim ct pr proposar centicode Dim ct la life Assured centicode 其四 Action 实现的功能及其输入输出参数需要注释 如图 6 1 图 6 1 其五 添加 ActionTemplate mst 模板文件到安装目录的 dat 文件夹下面 如 Option explicit OBJECTIVE TC NAME COUNTRY CALLED SCRIPT NAME CALLING SCRIPT NAME INPUT PARAMETER OUTPUT PARAMETER DESIGNER TEAM Description 6 1 11 空行空行 空行是区分代码块与块的间隔 在函数之间必须加上空行 而在函数内部 变量声明块和实现块 实现块指除变量声明外的其他代码 要使用空行来间隔 实现块的内部 通过空行来标识一个功能段 6 1 12 缩进缩进 必须严格执行缩进 变量声明块不缩进 实现块必须保证全部缩进 不可能 有实现块是行首对齐的 对于基本的控制结构来说 必须要有缩进 如 IF DO WITH FOR WHILE 块 6 1 13 续行续行 对于过长的语句来说 必须使用续行 续行位置要有明显意义 例如 sql SELECT code name FROM Person WHERE code LIKE 001 另外 还要通过管理对象库来提高代码的可读性 通过修改命名来达到更加 易读的效果 对于使用比较频繁的代码块来说 最好将其写成函数 并尽量将 功能复杂的大函数拆分成小函数 注意 在任何地方 不要写 ElseIf 语句 最好转换成 If Else Endif 结构 6 2 信息文档化信息文档化 为了使测试脚本更容易维护 必须文档化所有测试脚本相关执行信息 这 些信息在头文件中体现 头文件包含 1 脚本支持的业务范围 函数的功能 2 脚本中的变量 参数数量 数据的格式 例如日期格式 3 脚本的作者 创建和修改日期 4 所有依赖的测试脚本 脚本头文件格式 标题 描述 注意事项 功能说明 通过 Flight Date 查询机票信息 参数说明 脚本说明 QTP 飞机订票系统 作者说明 朱启祥 版本说明 V0 1 创建日期 2010 12 28 修改日期 备注 调用订票中的名为 login 的 Action 库函数头文件格式 功能说明 提交 Bug 到 QC 参数说明 status Bug 状态 summary 摘要 desc 描述 severity Bug 严重等级 deteDate 检测日期 project 所属项目 priority Bug 优先级 assignTo Bug 分配给 detectedBy 检测者 作者 朱启祥 版本说明 V0 1 创建日期 2010 12 29 修改日期 描述 备注 6 3 操作和业务分离操作和业务分离 QTP 在组织测试逻辑时 提供了 Testcase 和 Action 两种结构 这两种结构 是包含和被包含的关系 一个 Testcase 可以包括多个 Action 将可复用的业务 实现分割为独立的 Action 每个 Action 都有自己对应的 object repository Acti on 可以设置为 reused 进行复用 每个 Action 都有自己 DataSheet 测试用例 的相互调用 也是通过 Action 来进行 而 Testcase 按照实际逻辑对众多 Action 进行组织 同时提供公共设置的管理 如设置使用到的函数库 错误现场恢复 测试使用的相关参数设置 对于什么时间点进行 Action 的拆分又是一个关键问题 如果把一个业务从 头到尾录制完毕后再拆分 存在对象库重复的现象 即每个 Action 的对象库都 包含整个业务脚本的对象 因此 建议在设计自动化测试用例之前 明确哪些 操作步骤可复用 接着 录制时在拆分的地方暂停 拆分 action 后在新建的 Ac tion 继续录制 6 4 数据和脚本分离数据和脚本分离 测试数据是测试中非常重要的资源 测试脚本可能要移植到不同的测试机 或测试环境中执行 也可能 AUT 被测试的系统 版本需要升级 更重要的是 我们需要模拟实际用户用不同的数据类型测试相同的业务 因此需要