既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
测试框架应该独立于应用程序;
测试框架应该易于扩展 、维护和增强;
测试策略/设计应该对测试者隐藏测试框架的复杂性。
四、自动化框架介绍
该框架基于Selenium WebDriver开源技术开发。本框架使用Maven工具进行Project管理,采用TestNG工具组织测试,应用CSV文件存储测试数据,实现测试数据与测试用例的分离,方便测试数据管理,降低自动化脚本的维护成本,实现数据驱动。此外,该框架还封装了丰富的Selenium方法关键字,借鉴了QTP语法结构,实现了直观清晰的结构化代码语法,如:Page.Item.Operate,降低自动化代码的冗余与重复。借助Jenkins 进行CI测试,实现测试任务的Schedule 和Report功能,通过Jenkins Master/Slave模式管理虚拟机节点,实现多任务多机器分布式并发的执行管理,从而提高测试效率。
- 该框架的好处在于: 1、构建可复用的、稳定的代码集。通过封装appium实现用例执行与数据调用分离,参数化配置常用信息,并提供统一接口; 2、模块化管理自动化测试用例。主要根据TestNG工具的支持参数测试和依赖测试的特点实现; 3、测试结果分析和统计。利用jenkins工具建立持续集成,定期运行自动化测试项目,并将测试结果以定制化的形式展现。
测试框架分层
基于UI测试,我们希望除了支持web测试,还能支持app的测试,可能还需要接口测试,我们就需要考虑分层问题,将测试框架分为三层。上层是管理整个自动化测试的开发,执行以及维护,在比较庞大的项目中,它体现重要的作用,它可以管理整个自动测试,包括自动化测试用例执行的次序、测试脚本的维护、以及集中管理测试用例、测试报告和测试任务等。下层主要是测试脚本的开发,充分的使用相关的测试工具,构建测试驱动,并完成测试业务逻辑。
第一层:数据层
即执行用例时所需要的测试数据,如商户名、空间名、URL等,这些数据用来支撑整个脚本的执行。针对数据层,这里采了用数据驱动的方式。
第二层:驱动层
这一层主要封装各种driver。比如我们针对网页测试,使用selenium-webdriver开发包,针对app测试,我们使用appium开发包。我们在这一层进行封装,通过调用selenium-webdriver,appium提供的原生方法,封装成可读性很强的方法且加上容错机制。以后就算我们要换用其他的第三方包,我们的测试案例层和支持层的方法也不需要做任何的修改。只需要修改driver层实现的方式就可以了。在一层,我们主要实现两个方面的封装,一个是driver的封装,一个是基于基类自然语言函数的封装。
driver封装
我们需要封装,根据参数确实是基于web测试还是基于app测试。比如:
基类封装
主要是封装各种可读性很很强的方法以及将元素定位标识及driver也封装进去。为了支持网页测试和app测试,我们需要两个基类,一个是针对网页操作基类,一个是针对app操作基类。同时为了web和app操作的一致性,我们要求对外提供的方法,必须要将常用的方法保持一致的名字和一样的参数类型及参数个数。
APP基类示例如下:
通过对driver和基类的封装,driver层实现了对网页测试和app测试的支持,并且针对两种测试,都提供了统一的方法,能够方便使用者,使用相同的方法,测试app和web。
第三层:测试案例层
该层是测试案例的具体实现,就像上面写的case那样,用接近自然语言的方式,来实现测试案例。
第四层:支持层
该层主要提供workflow,通用工具,元素库的支持,便于测试案例层直接调用。
- Workflow:主要封装测试项目中需要经常使用的针对项目的公用方法,供测试案例层直接调用。比如用户登录,注册一个用户,搜索出用户等等经常使用的动作;
- 通用工具:提供一些通用方法,比如生成指定Page类,文件读取操作,DB操作,http操作支持等等;
- 元素库:每一个页面元素的定位表达式(xpath,id,name,css,link_text等等表达式)。 我们的测试案例,都是针对一个个元素进行操作的。将每一个页面的每一个元素,都看成一个继承了基类的特定类。所以,我们的第一步,就需要找到这个元素,定位到这个元素。测试项目的所有元素都放到这里。
第五层:结果保存层
将测试脚本的日志和结果以自定义的方式展示,这里使用了ReportNG,它可以丰富测试结果的展现形式,帮助团队更快定位和解决问题。
五、框架技术要点解析
5.1、PO模式
5.1.1、遇到的问题
使用webdriver做过一段时间的测试就会发现一个对某一个页面的元素进行定位的时候,程序行间充斥着id()、name()、xpath()等方法,这样会造成测试程序的可读性较差,不便于后期的维护以及修改。
虽然我们可以通过添加注释的方法使程序便于理解,但是还是不可以从根本上解决这种问题。我们可以通过对这些方法进行二次封装来避免每次对这些方法的直接调用,通过方法的封装虽然可以实现复用。但是我们发现通过封装无法实现页面元素的逻辑处理和测试数据的独立。
5.1.2、问题的解决办法:引入PO
Page Object模式是Selenium中的一种测试设计模式,是指UI界面上用于与用户进行交互的对象。主要是将每一个页面设计为一个Class,其中包含页面中需要测试的元素(按钮,输入框,标题 等),这样在Selenium测试页面中可以通过调用页面类来获取页面元素,这样巧妙的避免了当页面元素id或者位置变化时,需要改测试页面代码的情况。 当页面元素id变化时,只需要更改测试页Class中页面的属性即可。通过对界面元素的封装减少冗余代码,提高测试用例的可维护性。
一般情况下,对于一个Page Objects对象,它有两个方面的特征:
- 自身元素(WebElement)
- 实现功能 (Services)
仔细分析测试场景,抽出UI测试的核心行为,无非就是:
1、检查点:
页面元素是否存在;
页面元素显示内容是否正确;
页面元素是否可用;
……
2、辅助功能:
等待元素出现;
点击某页面元素;
给元素输入内容;
……
分析抽出来的核心行为,发现这些行为基本都是针对一个个页面元素进行的操作。那么我们就可以做如下的动作:
将页面元素看成一个对象,封装成一个类;
将上面分析得到的核心行为都封装成基类方法。然后确保,任何一个页面元素都继承该基类;
该基类提供类似于自然语言的方法名字,调用这些方法,就能很明确的知道测试案例在做什检查,在做什么行为,这样就能极大的提高测试案例的可读性。
该基类主要目的是在UI测试中,对元素共性的检查点和辅助方法进行抽取,将它们封装成一个个非常容易读懂的方法,且具有异常处理能力。
经过上述思路的整理,测试用例可以改写成如下:
在实际的使用过程中,可以让不太熟悉代码的QA专门负责测试案例的实现,底层的方法包装可以由经验丰富一些的同学做。
5.2、数据驱动
数据驱动的自动化测试框架是这样的一个框架,从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出的测试数据,然后通过变量传入事先录制好的或手工编写的测试脚本中。其中,这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。在这个过程中,数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里;测试数据只包含在数据文件中,而不是脚本里,测试脚本只是一个“驱动”,或者说是一个传送数据的机制。
- 在数据文件中填写测试数据:
- 生成Page类:
- Page类中初始化页面元素:
基于数据驱动的好处在于:
在应用程序开发的同时就可以同步建立测试脚本,而且当应用功能变动时,只需要修改业务功能部分的脚本;
利用模型化的设计,避免重复的脚本,减少建立或维护脚本的成本。
5.3、失败重跑与失败截图机制
自动化测试过程中,常常由于网络、服务器响应过慢、JS特效及页面渲染时间较长,导致自动化测试失败。针对此类场景,本框架设计了一套NRetry机制,即某个case运行失败后,重跑N次,N可自定义。N次中有一次成功,则继续运行,若N次均失败,则截图、抛错,停止运行。NRetry机制,一定程度上可以降低由于网络、服务器响应过慢导致的自动化执行的不稳定性。
5.3.1、失败自动截图
- 新建一个Java类继承TestListenerAdapter:
- 重写onTestFailure、onTestSkipped等方法,在这些方法中加入截图操作:
- 在testng.xml文件中配置自己编写的监听器类:
5.3.2、失败自动重跑
在运行自动化测试用例的时候,经常会出现一些异常的情况的情况导致用例失败的问题。所以我们可能会希望对于失败的测试用例再重新运行一次,框架中我们结合TestNG来实现这个功能。
- 新建TestNGRetry类,实现用例失败自动重跑逻辑:
- 添加用例重跑监听器RetryListener,用例失败自动重跑功能:
- 在testng.xml文件中配置自己编写的监听器:
5.4、ReportNG
TestNG默认的HTML报表,其默认的报表虽然信息全面,但不易于理解。因此,我们利用ReportNG来替代TestNG默认的report。
ReportNG提供了一种简单的方式来查看测试结果,并能够对结果代码进行着色。还可以通过修改CSS文件来替换默认的输出样式。此外ReportNG还能够生成Junit格式的XML输出。
由于我们使用的是maven,所以我们主要来看看pom.xml的情况:
maven-surefire-plugin 这个插件主要是用于testng的。我们通过该插件,在对应的目录下./target/${timestamp}生成我们的测试报告目录。我们可以看到这个目录的结构。
这里实际上就是reportng的测试报告的生成路径。但是我们想要通过邮件发送会很难,因为html的内容需要加在额外的css,以及js文件。而邮件实际上是不支持外部的css以及js文件的。
HTML的生成
1、定义HTML模版
查看indexMain.html.vm:
在使用ReportNG替换TestNG自带报告时如果报告中含中文,由于ReportNG 里面Log 是不支持中文的,所以通过修改ReportNG.jar源码来支持报告内中文展示。
5.5、日志收集
日志是软件开发的重要组成部分。自动化执行过程的日志信息,对于失败用例的分析定位以及全过程的跟踪记录是十分重要的。
相对于简单的输出打印,本框架集成了主流的日志收集工具log4j。Log4j是高度可配置的,并可通过在运行时的外部文件配置。通过配置log4j.properties文件,定义日志级别内容及日志输出路径收集日志信息(诸如:数据库,文件,控制台,UNIX系统日志等),提供快速的调试,维护方便,以及应用程序的运行时信息结构化存储。
配置文件
Log4j可以通过java程序动态设置,该方式明显缺点是:如果需要修改日志输出级别等信息,则必须修改java文件,然后重新编译,很是麻烦;log4j也可以通过配置文件的方式进行设置,目前支持两种格式的配置文件:
xml文件;
properties文件(推荐)。
5.6、邮件发送
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
70015780)]
[外链图片转存中…(img-jEPqjfE7-1715370015781)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新