广州h5网站建设,WordPress 302重定向,网站开发预算怎么算,设计师网站欣赏一、序言
随着项目版本的快速迭代、APP测试有以下几个特点#xff1a;
首先#xff0c;功能点多且细#xff0c;测试工作量大#xff0c;容易遗漏#xff1b;其次#xff0c;代码模块常改动#xff0c;回归测试很频繁#xff0c;测试重复低效#xff1b;最后#x… 一、序言
随着项目版本的快速迭代、APP测试有以下几个特点
首先功能点多且细测试工作量大容易遗漏其次代码模块常改动回归测试很频繁测试重复低效最后数据环境多样用户场景复杂功能回归覆盖难全面。
为节省成本保证高效及高质量迭代我们需采用更高效的测试方式App自动化测试是较高效的手段。 之前自动测试实践过程中遇到的诸多问题代码复用率低Case开发及数据构造繁琐问题定位困难学习成本高等为解决相关痛点问题我们重新实现了一套APP自动测试框架。本文将着重介绍技术选型、设计思路及百度外卖App的具体实践。二、自动化测试框架技术选型
一个项目中自动化测试是否能有效的展开自动化测试框架是关键所在。因此如何如何构建稳定的、易扩展的自动化的测试项目对于敏捷测试有重要的意义。在设计框架的时候应该尽可能的沿用自动化测试工具已提供的功能避免重复开发以减少开发成本。 通过对现有自动化测试工具的原理进行深入分析及优缺点比较并基于Appium和TestNG两类自动化测试框架解决上述自动化测试中遇到的问题。首先通过利用TestNG结合csv的使用将测试用例数据转化为测试代码中的数据减少了测试人员录入数据和准备数据的工具再次通过对appium的封装按照面向对象的思想将测试中用到的页面元素封装成对象增强测试代码的复用率并减轻测试人员对底层代码实现的负担提高测试代码编写效率最后引入失败重跑、失败截屏并通过reportng生成测试报告的方式逐步完善测试过程提高定位问题的速度
TestNG
Testng是一个开源自动化测试框架引入了许多新的创新功能如依赖测试分组概念使测试更强大更容易做到。 旨在涵盖所有类别的测试单元功能端到端集成等。TestNG框架可以很好地帮我们完成WebDriverjava的页面自动化工作,通过各种注释的灵活运行可以使你的测试用例更加完美定制符合要求的测试用例TestNG是一个设计用来简化广泛的测试需求的测试框架从单元测试到集成测试。 这个是TestNG设计的出发点不仅仅是单元测试而且可以用于集成测试。设计目标的不同对比junit的只适合用于单元测试TestNG无疑走的更远。可以用于集成测试这个特性是我选择TestNG的最重要的原因。测试的过程的三个典型步骤和junit(4.0)相比多了一个将测试信息添加到testng.xml文件。 测试信息尤其是测试数据不再写死在测试代码中好处就是修改测试数据时不需要修改代码/编译了从而有助于将测试人员引入单元测试/集成测试。基本概念相比junit的TestCase/TestSuiteTestNG有suite/test/test method三个级别即将test/test method明确区分开了。
Appium
Appium一个开源、跨平台的测试框架可以用来测试原生及混合的移动端应用。Appium支持iOS、Android及FirefoxOS平台测试。Appium使用WebDriver的json wire协议来驱动Apple系统的UIAutomation库、Android系统的UIAutomator框架。相比其他的移动自动化测试工具Appium测试由于调用了Selenium的client库使其可以使用任意的语言包括Python、Ruby、Node.js、Objective-C等。
三、自动化测试框架的设计思路
测试设计过程和测试自动化框架必须作为两个单独的实体来开发。
测试框架应该独立于应用程序
测试框架应该易于扩展 、维护和增强
测试策略设计应该对测试者隐藏测试框架的复杂性。
四、自动化框架介绍
该框架基于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-webdriverappium提供的原生方法封装成可读性很强的方法且加上容错机制。以后就算我们要换用其他的第三方包我们的测试案例层和支持层的方法也不需要做任何的修改。只需要修改driver层实现的方式就可以了。在一层我们主要实现两个方面的封装一个是driver的封装一个是基于基类自然语言函数的封装。
driver封装
我们需要封装根据参数确实是基于web测试还是基于app测试。比如
基类封装
主要是封装各种可读性很很强的方法以及将元素定位标识及driver也封装进去。为了支持网页测试和app测试我们需要两个基类一个是针对网页操作基类一个是针对app操作基类。同时为了web和app操作的一致性我们要求对外提供的方法必须要将常用的方法保持一致的名字和一样的参数类型及参数个数。APP基类示例如下
通过对driver和基类的封装driver层实现了对网页测试和app测试的支持并且针对两种测试都提供了统一的方法能够方便使用者使用相同的方法测试app和web。
第三层测试案例层
该层是测试案例的具体实现就像上面写的case那样用接近自然语言的方式来实现测试案例。
第四层支持层
该层主要提供workflow通用工具元素库的支持便于测试案例层直接调用。
Workflow主要封装测试项目中需要经常使用的针对项目的公用方法供测试案例层直接调用。比如用户登录注册一个用户搜索出用户等等经常使用的动作通用工具提供一些通用方法比如生成指定Page类文件读取操作DB操作http操作支持等等元素库每一个页面元素的定位表达式xpathidnamecsslink_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文件推荐。
下面是一个log4j配置文件的完整内容
5.6、邮件发送
测试报告的发送可以结合Jenkins来实现通过简单的配置即可实现。可是如果团队没有搭建jenkins或者有时jenkins不可用我们应该如何去处理这部分的内容呢
既然邮件不能够依赖jenkins,那肯定得自己去实现这部分的内容了。所以我们还是得依赖一些第三方的jar包。我们在pom.xml配置。
具体的发送邮件的部分代码如下
六、后续TODO
在后续的版本演进中将把自动化测试、代码安全扫描、多机并行测试、持续发布都加入了整体过程真正的做到全过程持续交付。
6.1、夜间构建加入自动化测试
夜间构建会按计划定期触发自动化构建过程但这种构建只是简单的代码编译没有可靠的或可重复的功能测试。后续考虑Appium结合Jenkins来实现构建后自动化测试工作。无论任何时候只要代码更新提交到git中构建服务器就会触发一个构建构建运行脚本去编译应用程序并且运行一系列的自动化单元测试和/或集成测试。通过自动化测试结果能够清晰的展示出那些功能特性是通过的哪些是失败的。不管是有改动提交还是定期在夜间触发构建应用程序都会被自动部署到测试环境当中以便QA团队进行测试。
6.2、Jenkins与STF结合实现多机并行测试
Jenkins构建脚本完成后将没有安装stf组件电脑上连接的android设备添加映射到装有stf平台服务的机器上将集成测试用例push到STF平台再由STF分发到可运行设备上进行多机并行测试。
STF执行APPIUM测试带来的优势
第一、可以在真机上执行并行的Appium测试。由于最初的Appium使用对象是模拟器上或只是以每次一台设备的测试方法执行测试而STF在原有的基础上扩展了Appium最多可在数百台真机上同时执行测试的能力。
第二不需要配置任何设备的Desired Capabilities。这种方式既简便且减少了因为编辑脚本而产生的不同类型的错误。
第三在STF上执行测试可以让用户即时浏览测试状况。也就是说可以查看到测试执行的进度即时的错误反馈以及保留和查阅所有测试项目测试脚本和测试结果测试截图测试日志性能数据等
6.3、代码质量度量
6.3.1、为什么要分析代码
对代码质量关注时安排人工进行code review是需要的但100%的code review却需要投入人员消耗大量的工作量而工具自动检查只需少量人工配置。最主要的原因就是提高代码质量了解RD在编码过程中犯过的错误可能对功能逻辑产生的影响同时也推动RD让自己的代码更具有可读性和维护性所以我们借鉴持续改进的流程希望能够在这个过程中有所收获。
6.3.2、Jenkins引入Sonarqube进行代码持续审查
Sonar是一个用于代码质量管理的开源平台用于管理Java源代码的质量。通过插件机制Sonar 可以集成不同的测试工具代码分析工具以及持续集成工具比如pmd-cpd、checkstyle、findbugs、Jenkins。通过不同的插件对这些结果进行再加工处理通过量化的方式度量代码质量的变化从而可以方便地对不同规模和种类的工程进行代码质量管理。
6.4、email-ext实现Jenkins邮件通知功能
在Jenkins中配置实现邮件通知Jenkins提供了两种方式的配置。
一种是Jenkins内置默认的邮件通知但是它本身有很多局限性比如它的邮件通知无法提供详细的邮件内容、无法定义发送邮件的格式、无法定义灵活的邮件接收配置等等。
在这样的情况下后续考虑可以通过Email Extension Plugin来实现自定义邮件通知的方方面面比如在发送邮件的同时可以自定义发送给谁发送具体什么内容等等。 绵薄之力【资源分享】
最后感谢每一个认真阅读我文章的人看着粉丝一路的上涨和关注礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码朋友们如果需要可以自行免费领取 【保证100%免费】 这些资料对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。希望对大家有所帮助……基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等配套学习资源免费分享~
