轻量级自动化测试框架 UFT 初学者 学习编写

自动化测试框架UFT BASED



自动化测试,一个现在被炒的火热的词;各大公司都在嚷嚷着要上自动化测试的项目,都在招聘各种自动化测试人员。。。

本材料对于编程基础较低初学者,在编写和学习过程中可以接触到很多旁枝侧节的知识,这些都是做好自动化所有需要的知识;对于有一定技术储备。

本框架不能帮你成为高大上的编程大牛,或者自动化测试的行家。但是,它可以引领你迈入自动化测试的领域。

师傅领进门,修行靠个人;一切的一切都还是要靠你自己去多多实践,不是有一句名言么?实践是检验真理的唯一标准!


一、自动化测试基础

手工测试VS自动化测试

手工测试:

手工测试就是由人去一个一个的去执行测试用例,通过键盘鼠标等输入一些参数,查看返回结果是否符合预期结果。

自动化测试:

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

自动化测试又可分为:功能自动化测试与性能自动化测试,在本文中我们着重探讨功能自动化测试。


什么样的项目适合自动化测试

1、任务测试明确,不会频繁变动

2、比较频繁的回归测试

3、软件系统界面稳定,变动少

4、需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务

5、软件维护周期长

6、被测软件系统开发比较规范,能够保证系统的可测试性

7、具备大量的自动化测试平台

8、测试人员具备较强的编程能力

UFT简介

UFTUnified Functional Testing的简称,是一种自动测试工具。

VBS为内嵌语言。

UFT自动化测试的基本功能包括:

创建测试

检验数据

增强测试

运行测试脚本

分析测试结果

维护测试

UFT工具特点

特点:易于上手,开发简单,功能强大

注:主流配置都能带起了(选择UFT11.5和UFT12.0)

二、自动化测试模型介绍


一个自动化测试框架就是一个集成体系,在这一体系中包含测试功能的函数库、测试数据源、测试对象识别标准,以及种可重用的模块。自动化测试框架在发展的过程中经历了几个阶段,模块驱动测试、数据驱动测试、对象驱动测试

线性测试


通过录制或编写脚本,一个脚本完成一个场景(一组完整功能操作),通过对脚本的回放来进行自动化测试。这是早期进行自动化测试的一种形式。

参见下图test1test2实例:


通过上例,我们可以看出:

每一个脚本都是独立的,任何一个脚本文件拿出来就能单独运行;当然,缺点也很明显,用例的开发与维护成本很高。

一个用例对应一个脚本,假如登陆发生变化,用户名的属性发生改变,不得不需要对每一个脚本进行修改,测试用例形成一种规模,我们可能将大量的工作用于脚本的维护,从而失去自动化的意义。

这种模式下数据和脚本是混在一起的,如果数据发生变也需要对脚本进行修改。这种模式下脚本的没有可重复使用的概念。

模块化与类库


我们会清晰的发现在上面的脚本中,其实有不少内容是重复的;于是我们就考虑能不能把重复的部分写成一个公共的模块,需要的时候进行调用,这样就大大提高了我们编写脚本的效率。

参见下图:

通过阅读上面的代码发现,我们可以把脚本中相同的部分代码(登录)独立出来,形成模块或库。

这样做有两方面的优点:

一方面提高了开发效率,不用重复的编写相同的脚本;假如,我已经写好一个登录模块,我后续需要做的就是在需要的地方调用,不同重复造轮子。

另一方面方便了代码的维护,假如登录模块发生了变化,我只用修改文件中登录模块的代码即可,那么所有调用登录模块的脚本不用做任何修改。

数据驱动

数据驱动应该是自动化的一个进步;从它的本意来讲,数据的改变(更新)驱动自动化的执行,从而引起测试结果的改变。这显然是一个非常高级的概念和想法。其实,我们可直白的理解成参数化,输入数据的不同从而引起输出结果的变化。

参见下面例:



不管我们读取的是数组,还是字典、函数,又或者是csvtxt文件。我们实现了数据与脚本的分离,换句话说,我们实现了参数化。我们传一千条数据,通过脚本的执行,可以返回一千条结果出来。

同样的脚本执行不同的数据从而得到了不同的结果,是不是增强的脚本的复用性呢!


关键字驱动

理解了数据驱动,无非是把“数据”换成“关键字”,通过关键字的改变引起测试结果的改变。

关键字驱动用编程方式就不太容易表现了。UFTrobotframework等都是以关键字驱动为主的自动化工具,因为这类工具主打的易用性,“填表格”式的关键字驱动帮我们封装了很多底层的东西,我们只要考虑三个问题就可以了:我要做什么? 对谁做?怎么做?。


三、自动化框架设计

环境要求

1.UFT 11.5 以上
2.Office Excel 已安装

体系结构与驱动逻辑




文件组织结构


文件组织结构说明

1. Autotest文件夹,整个工程的最高一级目录,名称可以修改。

2. driver文件夹,这个是整个框架的入口,内有Driver.vbs驱动程序、wyz.vbs辅助程序和UFT测试项目文件夹

3. testpro文件夹,用于记录有哪些项目,是否执行

4. testdata文件夹,用于设计测试用例,给testscript提供数据、期望值等信息

5. testscript文件夹,存放测试脚本,全部存储为vbs文件。类名对应项目名,对应文件名,一个函数对应一个用例(需和testdata中信息对应),也可添加其他公共函数

6. library文件夹,按项目名称分文件夹放置的对象库文件

注:testdatatestscript目录下的内容,是真正需要开发的。

数据组织结构说明




数据组织总结

1、基于把测试设计和脚本开发分开的思路,设计了testprotestdata Excel表格。测试设计时,主要是设计testdata中的测试用例数据表格;

2、开发testscript中的测试用例脚本;

因此,希望尽可能把这些Excel表格做得更易用。所谓的框架,就是把这几个Excel 表格串起来的东西。

driver 脚本驱动逻辑

1.测试结果打印初始化;
2.测试资源初始化,读取 PRO.xls 中信息获得需要执行到测试项目名称及次数;
3.for 遍历每个项目,如需执行,导入该项目testdata 测试用例数据信息和对象库,进入下一步;
4.根据 testdata 中的信息,再次使用 for 遍历执行 testscript 中的对应函数,并保存结果至 result 文件夹中;
5.释放资源。

该自动化测试框架的优点缺点

优势:

脚本文件少,并且占用的空间也少了;

可以使用版本控制工具对单个的数据文件或者vbs 文件进行版本控制;

测试设计和脚本开发解耦;

测试用例和数据的展现更加人性化。

缺点:

异常的捕获考虑得很少;

日志只是打印到output或输出到文件,不利于查看。如果把日志输出到数据库,就可以生成相应的测试执行报告;

测试用例的管理太过于简陋。

注:该框架编写和学习对于想要学习自动化框架编写的同学,可以起到一个入门,可以帮助同学理清楚自动化框架设计的思路


以上内容皆为wyz私有版权,转载请注明出处,如果有同学或者同事进行共同深入的研究,需要相关自动化材料和自动化框架的代码,请加QQ:2604947115,我们共同进行探讨。

















本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。

springmvc SSM后台框架源码 - 2016-07-25 17:07:55

获取【下载地址】    QQ: 313596790   【免费支持更新】 三大数据库 mysql  oracle  sqlsever    更专业、更强悍、适合不同用户群体 【 新录针对本系统的视频教程,手把手教开发一个模块,快速掌握本系统 】 A 集成代码生成器 [ 正反双向 (单表、主表、明细表、树形表, 开发利器 ) +快速构建表单 ; QQ:313596790 freemaker模版技术 ,0个代码不用写,生成完整的一个模块,带页面、建表sql脚本,处理类,service等完整模块 B 集成阿里巴

ip报头分片 - 2016-07-25 17:07:06

分片介绍:          IP分片是网络上传输IP报文的一种技术手段。IP协议在传输数据包时,将数据报文分为若干分片进行传输,并在目标系统中进行重组         在IP协议中的分片算法主要解决不同物理网络最大传输单元(MTU) 的不同造成的传输问题。分组在传输过程中不断地分片和重组会带来很大的工作量还会增加一些不安全的因素。 为什么需要分片:          每一种物理网络都会规定链路层数据帧的最大长度,称为链路层MTU(Maximum Transmission Unit).IP协议在传输数据包
写在前面的 策略模式 概念 具体实例 比较和理解 总结 写在前面的 上一篇文章我们说到,如果我们需要在原本已经整理好的代码中添加新的内容(包括算法或者功能性模块),我们可以应用简单工厂来实现,比如添加算法(活学活用嘛)、在已有的功能模块中再添加新的功能等。但是,我们在上一篇文章中提到过 开放-封闭原则 ,试想一下,如果我们写出来的代码在应用过程中一直需要不断的调整和增加新的功能,那么每次维护都要打开这个工厂,添加相应的功能或算法之后再重新部署,这样无意间会增加我们的工作量,所以简单工厂在某种意义上就不适用
课程概要:          讲解 Struts2 中数据封装的三种方式以及具体实现原理   一、 Struts2 数据封装机制之属性驱动   我们先来看一下传统的 servlet 是如何处理从页面传递过来的数据的。 首先我们在表单发送了对应的数据到 servlet 中去 form action="%=path%/loginservlet"method="post" 账号:inputtype="text"name="username"/br 密码:inputtype="password"name="pas
Spring MVC框架是有一个MVC框架,通过实现Model-View-Controller模式来很好地将数据、业务与展现进行分离。从这样一个角度来说,Spring MVC和Struts、Struts2非常类似。Spring MVC的设计是围绕DispatcherServlet展开的,DispatcherServlet负责将请求派发到特定的handler。通过可配置的handler mappings、view resolution、locale以及theme resolution来处理请求并且转到对应的

通过WSDL生成客户端代码 - 2016-07-25 14:07:03

目录 1.WSDL2Java:Building stubs,skeletons,and data types from WSDL . 1 1.1示例 ... 1 1.2测试 ... 4 1.2.1异常:没有定义com.pan.model.User的序列化的实现 ... 5 1.3WSDL与生成的客户端代码结构分析 ... 5 1.3.1Types . 6 1.3.2Holders . 12 1.3.3PortTypes . 13 1.3.4Bindings . 13 1.3.5 Services . 14
                                               Ofbiz:数据库移植mysql并创建自己的mysql            Ofbiz原生数据库是derby,而作为开发使用,其就不能满足我们需求,ofbiz支持多种数据库,我们就可以将数据移植到mysql.            第一步:找到framework\entity\config\entityengine.xml这个文件,找到之后进行下面相关操作.          1、添加或者修改datasourc

linux的一些简单命令 - 2016-07-25 14:07:59

这里只是列出实际中使用频率较高的,可以通过 man 命令或者 命令 –help 来查看更为详细的内容 文件有关的 1:【ls命令】 ls [option] …[file]… -a all 列出所有的文件 包括隐藏文件 [eg ls -a /home] -l 列出详细的文件信息 可以简写为ll filename [eg: ls -l /home or ll /home ] -h –human-readable 将文件的大小通过字节的方式列出来 -R 递归显示出该目录所有的文件 -d 只显示本文件下面 可以通

Nginx下的rewrite规则 - 2016-07-25 14:07:08

正则表达式匹配,其中: * ~ 为区分大小写匹配 * ~* 为不区分大小写匹配 * !~和!~* 分别为区分大小写不匹配及不区分大小写不匹配 文件及目录匹配,其中: * -f 和! -f 用来判断是否存在文件* -d 和! -d 用来判断是否存在目录* -e 和! -e 用来判断是否存在文件或目录* -x和!-x 用来判断文件是否可执行 rewrite指令的最后一项参数为flag标记,flag标记有: 1. last 相当于apache里面的[L]标记,表示rewrite。 2. break 本条规则匹配

Apache Flink Client生成StreamGraph - 2016-07-25 04:07:11

概述 上文我们分析提交流程时, RemoteStreamEnvironment 类的 execute 方法的第一步就是生成 StreamGraph 。 StreamGraph 是用于表示流的拓扑结构的数据结构,它包含了生成 JobGraph 的必要信息。它的类继承关系图如下: 如果你按照 StreamGraph 的继承链向上追溯,最终会发现它实现了接口 FlinkPlan 。Flink在这里效仿的是数据库的执行SQL是产生执行计划的机制, FlinkPlan 定义在Flink的优化器相关的包中,针对流应用