从0到1开发自动化测试框架

1、序言

随着项目版本的快速迭代、APP测试有如下几个特色：

• 首先，功能点多且细，测试工做量大，容易遗漏；
• 其次，代码模块常改动，回归测试很频繁，测试重复低效；
• 最后，数据环境多样，用户场景复杂，功能回归覆盖难全面。

为节省成本，保证高效及高质量迭代，咱们需采用更高效的测试方式，App自动化测试是较高效的手段。
以前自动测试实践过程当中遇到的诸多问题（代码复用率低，Case开发及数据构造繁琐，问题定位困难，学习成本高等），为解决相关痛点问题，咱们从新实现了一套APP自动测试框架。本文将着重介绍技术选型、设计思路及百度外卖App的具体实践。

 

2、自动化测试框架技术选型

一个项目中自动化测试是否能有效的展开，自动化测试框架是关键所在。所以，如何如何构建稳定的、易扩展的自动化的测试项目对于敏捷测试有重要的意义。在设计框架的时候应该尽量的沿用自动化测试工具已提供的功能，避免重复开发，以减小开发成本。
经过对现有自动化测试工具的原理进行深刻分析及优缺点比较，并基于Appium和TestNG两类自动化测试框架解决上述自动化测试中遇到的问题。

• 首先，经过利用TestNG结合csv的使用，将测试用例数据转化为测试代码中的数据，减小了测试人员录入数据和准备数据的工具；
• 再次，经过对appium的封装，按照面向对象的思想将测试中用到的页面元素封装成对象，加强测试代码的复用率，并减轻测试人员对底层代码实现的负担，提升测试代码编写效率；
• 最后，引入失败重跑、失败截屏，并经过reportng生成测试报告的方式，逐步完善测试过程，提升定位问题的速度；

TestNG

Testng是一个开源自动化测试框架，引入了许多新的创新功能，如依赖测试，分组概念，使测试更强大，更容易作到。 旨在涵盖全部类别的测试：单元，功能，端到端，集成等。TestNG框架能够很好地帮咱们完成WebDriver+java的页面自动化工做,经过各类注释的灵活运行，可使你的测试用例更加完美，定制符合要求的测试用例

1. TestNG是一个设计用来简化普遍的测试需求的测试框架，从单元测试到集成测试。 这个是TestNG设计的出发点，不只仅是单元测试，并且能够用于集成测试。设计目标的不一样，对比junit的只适合用于单元测试，TestNG无疑走的更远。能够用于集成测试，这个特性是我选择TestNG的最重要的缘由。
2. 测试的过程的三个典型步骤，和junit(4.0)相比，多了一个将测试信息添加到testng.xml文件。 测试信息尤为是测试数据再也不写死在测试代码中，好处就是修改测试数据时不须要修改代码/编译了，从而有助于将测试人员引入单元测试/集成测试。
3. 基本概念，相比junit的TestCase/TestSuite，TestNG有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等。

 

3、自动化测试框架的设计思路

测试设计过程和测试自动化框架必须做为两个单独的实体来开发。

测试框架应该独立于应用程序；

测试框架应该易于扩展 、维护和加强；

测试策略／设计应该对测试者隐藏测试框架的复杂性。

 

4、自动化框架介绍

该框架基于Selenium WebDriver开源技术开发。本框架使用Maven工具进行Project管理，采用TestNG工具组织测试，应用CSV文件存储测试数据，实现测试数据与测试用例的分离，方便测试数据管理，下降自动化脚本的维护成本，实现数据驱动。此外，该框架还封装了丰富的Selenium方法关键字，借鉴了QTP语法结构，实现了直观清晰的结构化代码语法，如：Page.Item.Operate，下降自动化代码的冗余与重复。借助Jenkins 进行CI测试，实现测试任务的Schedule 和Report功能，经过Jenkins Master/Slave模式管理虚拟机节点，实现多任务多机器分布式并发的执行管理，从而提升测试效率。

• 该框架的好处在于： 一、构建可复用的、稳定的代码集。经过封装appium实现用例执行与数据调用分离，参数化配置经常使用信息，并提供统一接口； 二、模块化管理自动化测试用例。主要根据TestNG工具的支持参数测试和依赖测试的特色实现； 三、测试结果分析和统计。利用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、框架技术要点解析

5.一、PO模式

 

5.1.一、遇到的问题

使用webdriver作过一段时间的测试就会发现一个对某一个页面的元素进行定位的时候，程序行间充斥着id()、name()、xpath()等方法，这样会形成测试程序的可读性较差，不便于后期的维护以及修改。

虽然咱们能够经过添加注释的方法使程序便于理解，可是仍是不能够从根本上解决这种问题。咱们能够经过对这些方法进行二次封装来避免每次对这些方法的直接调用，经过方法的封装虽然能够实现复用。可是咱们发现经过封装没法实现页面元素的逻辑处理和测试数据的独立。

 

5.1.二、问题的解决办法：引入PO

Page Object模式是Selenium中的一种测试设计模式，是指UI界面上用于与用户进行交互的对象。主要是将每个页面设计为一个Class，其中包含页面中须要测试的元素（按钮，输入框，标题 等），这样在Selenium测试页面中能够经过调用页面类来获取页面元素，这样巧妙的避免了当页面元素id或者位置变化时，须要改测试页面代码的状况。 当页面元素id变化时，只须要更改测试页Class中页面的属性便可。经过对界面元素的封装减小冗余代码，提升测试用例的可维护性。

通常状况下，对于一个Page Objects对象，它有两个方面的特征：

• 自身元素(WebElement)
• 实现功能 (Services)

仔细分析测试场景，抽出UI测试的核心行为，无非就是：

一、检查点：

页面元素是否存在；

页面元素显示内容是否正确；

页面元素是否可用；

……

二、辅助功能：

等待元素出现；

点击某页面元素；

给元素输入内容；

……

 

分析抽出来的核心行为，发现这些行为基本都是针对一个个页面元素进行的操做。那么咱们就能够作以下的动做：

 

将页面元素当作一个对象，封装成一个类；

将上面分析获得的核心行为都封装成基类方法。而后确保，任何一个页面元素都继承该基类；
该基类提供相似于天然语言的方法名字，调用这些方法，就能很明确的知道测试案例在作什检查，在作什么行为，这样就能极大的提升测试案例的可读性。

该基类主要目的是在UI测试中，对元素共性的检查点和辅助方法进行抽取，将它们封装成一个个很是容易读懂的方法，且具备异常处理能力。

 

通过上述思路的整理，测试用例能够改写成以下：

在实际的使用过程当中，可让不太熟悉代码的QA专门负责测试案例的实现，底层的方法包装能够由经验丰富一些的同窗作。

 

5.二、数据驱动

数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出的测试数据，而后经过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用做传递(输入/输出)用来验证应用程序的测试数据。在这个过程当中，数据文件的读取、测试状态和全部测试信息都被编写进测试脚本里;测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数据的机制。

1. 在数据文件中填写测试数据：
2. 生成Page类：
3. Page类中初始化页面元素：

基于数据驱动的好处在于：

在应用程序开发的同时就能够同步创建测试脚本，并且当应用功能变更时，只须要修改业务功能部分的脚本；

利用模型化的设计，避免重复的脚本，减小创建或维护脚本的成本。

 

5.三、失败重跑与失败截图机制

自动化测试过程当中，经常因为网络、服务器响应过慢、JS特效及页面渲染时间较长，致使自动化测试失败。针对此类场景，本框架设计了一套NRetry机制，即某个case运行失败后，重跑N次，N可自定义。N次中有一次成功，则继续运行，若N次均失败，则截图、抛错，中止运行。NRetry机制，必定程度上能够下降因为网络、服务器响应过慢致使的自动化执行的不稳定性。

 

5.3.一、失败自动截图

1. 新建一个Java类继承TestListenerAdapter：
2. 重写onTestFailure、onTestSkipped等方法，在这些方法中加入截图操做：
3. 在testng.xml文件中配置本身编写的监听器类：

 

5.3.二、失败自动重跑

在运行自动化测试用例的时候，常常会出现一些异常的状况的状况致使用例失败的问题。因此咱们可能会但愿对于失败的测试用例再从新运行一次，框架中咱们结合TestNG来实现这个功能。

1. 新建TestNGRetry类，实现用例失败自动重跑逻辑：
2. 添加用例重跑监听器RetryListener，用例失败自动重跑功能：
3. 在testng.xml文件中配置本身编写的监听器：

 

5.四、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的生成

一、定义HTML模版

查看indexMain.html.vm：

在使用ReportNG替换TestNG自带报告时若是报告中含中文，因为ReportNG 里面Log 是不支持中文的，因此经过修改ReportNG.jar源码来支持报告内中文展现。

 

5.五、日志收集

日志是软件开发的重要组成部分。自动化执行过程的日志信息，对于失败用例的分析定位以及全过程的跟踪记录是十分重要的。

相对于简单的输出打印，本框架集成了主流的日志收集工具log4j。Log4j是高度可配置的，并可经过在运行时的外部文件配置。经过配置log4j.properties文件，定义日志级别内容及日志输出路径收集日志信息（诸如：数据库，文件，控制台，UNIX系统日志等），提供快速的调试，维护方便，以及应用程序的运行时信息结构化存储。

配置文件

Log4j能够经过java程序动态设置，该方式明显缺点是：若是须要修改日志输出级别等信息，则必须修改java文件，而后从新编译，非常麻烦；log4j也能够经过配置文件的方式进行设置，目前支持两种格式的配置文件：

xml文件；

properties文件（推荐）。

 

5.六、邮件发送

测试报告的发送能够结合Jenkins来实现，经过简单的配置便可实现。但是若是团队没有搭建jenkins或者有时jenkins不可用，咱们应该如何去处理这部分的内容呢？

既然邮件不可以依赖jenkins,那确定得本身去实现这部分的内容了。因此咱们仍是得依赖一些第三方的jar包。咱们在pom.xml配置。

 

6、后续TODO

在后续的版本演进中，将把自动化测试、代码安全扫描、多机并行测试、持续发布都加入了总体过程，真正的作到全过程持续交付。

 

6.一、夜间构建加入自动化测试

夜间构建会按计划按期触发自动化构建过程，但这种构建只是简单的代码编译，没有可靠的或可重复的功能测试。后续考虑Appium结合Jenkins来实现构建后自动化测试工做。
不管任什么时候候，只要代码更新提交到git中，构建服务器就会触发一个构建，构建运行脚本去编译应用程序而且运行一系列的自动化单元测试和/或集成测试。经过自动化测试结果可以清晰的展现出那些功能特性是经过的，哪些是失败的。无论是有改动提交，仍是按期在夜间触发构建，应用程序都会被自动部署到测试环境当中以便QA团队进行测试。

 

6.二、Jenkins与STF结合，实现多机并行测试

Jenkins构建脚本完成后，将没有安装stf组件电脑上链接的android设备，添加映射到装有stf平台服务的机器上，将集成测试用例push到STF平台，再由STF分发到可运行设备上，进行多机并行测试。

STF执行APPIUM测试带来的优点

第1、能够在真机上执行并行的Appium测试。因为最初的Appium使用对象是模拟器上或只是以每次一台设备的测试方法执行测试，而STF在原有的基础上扩展了Appium，最多可在数百台真机上同时执行测试的能力。

第二，不须要配置任何设备的Desired Capabilities。这种方式既简便，且减小了由于编辑脚本而产生的不一样类型的错误。

第三，在STF上执行测试可让用户即时浏览测试情况。也就是说，能够查看到测试执行的进度，即时的错误反馈，以及保留和查阅全部测试项目，测试脚本和测试结果（测试截图，测试日志，性能数据等）

 

6.三、代码质量度量

 

6.3.一、为何要分析代码

对代码质量关注时，安排人工进行code review是须要的，但100%的code review却须要投入人员，消耗大量的工做量，而工具自动检查只需少许人工配置。

最主要的缘由就是提升代码质量，了解RD在编码过程当中犯过的错误可能对功能逻辑产生的影响，同时也推进RD让本身的代码更具备可读性和维护性，因此咱们借鉴持续改进的流程，但愿可以在这个过程当中有所收获。

 

6.3.二、Jenkins引入Sonarqube进行代码持续审查

Sonar是一个用于代码质量管理的开源平台，用于管理Java源代码的质量。经过插件机制，Sonar 能够集成不一样的测试工具，代码分析工具，以及持续集成工具，好比pmd-cpd、checkstyle、findbugs、Jenkins。经过不一样的插件对这些结果进行再加工处理，经过量化的方式度量代码质量的变化，从而能够方便地对不一样规模和种类的工程进行代码质量管理。

 

6.四、email-ext实现Jenkins邮件通知功能

在Jenkins中配置实现邮件通知，Jenkins提供了两种方式的配置。

一种是Jenkins内置默认的邮件通知，可是它自己有不少局限性，好比它的邮件通知没法提供详细的邮件内容、没法定义发送邮件的格式、没法定义灵活的邮件接收配置等等。

在这样的状况下，后续考虑能够经过Email Extension Plugin来实现自定义邮件通知的方方面面，好比在发送邮件的同时能够自定义发送给谁，发送具体什么内容等等。