发布时间：2022-08-19 13:10
随着项目版本的快速迭代、APP测试有以下几个特点：
1. 首先，功能点多且细，测试工作量大，容易遗漏；
2. 其次，代码模块常改动，回归测试很频繁，测试重复低效；
3. 最后，数据环境多样，用户场景复杂，功能回归覆盖难全面。
为节省成本，保证高效及高质量迭代，我们需采用更高效的测试方式，App自动化测试是较高效的手段。
之前自动测试实践过程中遇到的诸多问题（代码复用率低，Case开发及数据构造繁琐，问题定位困难，学习成本高等），为解决相关痛点问题，我们重新实现了一套APP自动测试框架。本文将着重介绍技术选型、设计思路及百度外卖App的具体实践。
一个项目中自动化测试是否能有效的展开，自动化测试框架是关键所在。因此，如何构建稳定的、易扩展的自动化的测试项目对于敏捷测试有重要的意义。在设计框架的时候应该尽可能的沿用自动化测试工具已提供的功能，避免重复开发，以减少开发成本。
通过对现有自动化测试工具的原理进行深入分析及优缺点比较，并基于Appium和TestNG两类自动化测试框架解决上述自动化测试中遇到的问题。
1. 首先，通过利用TestNG结合csv的使用，将测试用例数据转化为测试代码中的数据，减少了测试人员录入数据和准备数据的工作；
2. 再次，通过对appium的封装，按照面向对象的思想将测试中用到的页面元素封装成对象，增强测试代码的复用率，并减轻测试人员对底层代码实现的负担，提高测试代码编写效率；
3. 最后，引入失败重跑、失败截屏，并通过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等。
测试设计过程和测试自动化框架必须作为两个单独的实体来开发。
测试框架应该独立于应用程序；
测试框架应该易于扩展 、维护和增强；
测试策略／设计应该对测试者隐藏测试框架的复杂性。
该框架基于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.1、遇到的问题
使用webdriver做过一段时间的测试就会发现对某一个页面的元素进行定位的时候，程序行间充斥着id()、name()、xpath()等方法，这样会造成测试程序的可读性较差，不便于后期的维护以及修改。
虽然我们可以通过添加注释的方法使程序便于理解，但是还是不可以从根本上解决这种问题。我们可以通过对这些方法进行二次封装来避免每次对这些方法的直接调用，通过方法的封装虽然可以实现复用。但是我们发现通过封装无法实现页面元素的逻辑处理和测试数据的独立。
5.1.2、问题的解决办法：引入PO
Page Object模式是Selenium中的一种测试设计模式，是指UI界面上用于与用户进行交互的对象。主要是将每一个页面设计为一个Class，其中包含页面中需要测试的元素（按钮，输入框，标题 等），这样在Selenium测试页面中可以通过调用页面类来获取页面元素，这样巧妙的避免了当页面元素id或者位置变化时，需要改测试页面代码的情况。 当页面元素id变化时，只需要更改测试页Class中页面的属性即可。通过对界面元素的封装减少冗余代码，提高测试用例的可维护性。
一般情况下，对于一个Page Objects对象，它有两个方面的特征：
1. 自身元素(WebElement)
2. 实现功能 (Services)
仔细分析测试场景，抽出UI测试的核心行为，无非就是：
1、检查点：
页面元素是否存在；
页面元素显示内容是否正确；
页面元素是否可用；
……
2、辅助功能：
等待元素出现；
点击某页面元素；
给元素输入内容；
……
分析抽出来的核心行为，发现这些行为基本都是针对一个个页面元素进行的操作。那么我们就可以做如下的动作：
将页面元素看成一个对象，封装成一个类；
将上面分析得到的核心行为都封装成基类方法。然后确保，任何一个页面元素都继承该基类；
该基类提供类似于自然语言的方法名字，调用这些方法，就能很明确的知道测试案例在做什检查，在做什么行为，这样就能极大的提高测试案例的可读性。
该基类主要目的是在UI测试中，对元素共性的检查点和辅助方法进行抽取，将它们封装成一个个非常容易读懂的方法，且具有异常处理能力。
经过上述思路的整理，测试用例可以改写成如下：
在实际的使用过程中，可以让不太熟悉代码的QA专门负责测试案例的实现，底层的方法包装可以由经验丰富一些的同学做。
数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。在这个过程中，数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里；测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数据的机制。
1. 在数据文件中填写测试数据：
2. 生成Page类：
3. Page类中初始化页面元素：
基于数据驱动的好处在于：
在应用程序开发的同时就可以同步建立测试脚本，而且当应用功能变动时，只需要修改业务功能部分的脚本；
利用模型化的设计，避免重复的脚本，减少建立或维护脚本的成本。
自动化测试过程中，常常由于网络、服务器响应过慢、JS特效及页面渲染时间较长，导致自动化测试失败。针对此类场景，本框架设计了一套NRetry机制，即某个case运行失败后，重跑N次，N可自定义。N次中有一次成功，则继续运行，若N次均失败，则截图、抛错，停止运行。NRetry机制，一定程度上可以降低由于网络、服务器响应过慢导致的自动化执行的不稳定性。
5.3.1、失败自动截图
1. 新建一个Java类继承TestListenerAdapter：
2. 重写onTestFailure、onTestSkipped等方法，在这些方法中加入截图操作：
3. 在testng.xml文件中配置自己编写的监听器类：
5.3.2、失败自动重跑
在运行自动化测试用例的时候，经常会出现一些异常的情况的情况导致用例失败的问题。所以我们可能会希望对于失败的测试用例再重新运行一次，框架中我们结合TestNG来实现这个功能。
1. 新建TestNGRetry类，实现用例失败自动重跑逻辑：
2. 添加用例重跑监听器RetryListener，用例失败自动重跑功能：
3. 在testng.xml文件中配置自己编写的监听器：
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源码来支持报告内中文展示。
日志是软件开发的重要组成部分。自动化执行过程的日志信息，对于失败用例的分析定位以及全过程的跟踪记录是十分重要的。
相对于简单的输出打印，本框架集成了主流的日志收集工具log4j。Log4j是高度可配置的，并可通过在运行时的外部文件配置。通过配置log4j.properties文件，定义日志级别内容及日志输出路径收集日志信息（诸如：数据库，文件，控制台，UNIX系统日志等），提供快速的调试，维护方便，以及应用程序的运行时信息结构化存储。
配置文件
Log4j可以通过java程序动态设置，该方式明显缺点是：如果需要修改日志输出级别等信息，则必须修改java文件，然后重新编译，很是麻烦；log4j也可以通过配置文件的方式进行设置，目前支持两种格式的配置文件：
xml文件；
properties文件（推荐）。
测试报告的发送可以结合Jenkins来实现，通过简单的配置即可实现。可是如果团队没有搭建jenkins或者有时jenkins不可用，我们应该如何去处理这部分的内容呢？
既然邮件不能够依赖jenkins,那肯定得自己去实现这部分的内容了。所以我们还是得依赖一些第三方的jar包。我们在pom.xml配置。
在后续的版本演进中，将把自动化测试、代码安全扫描、多机并行测试、持续发布都加入了整体过程，真正的做到全过程持续交付。
夜间构建会按计划定期触发自动化构建过程，但这种构建只是简单的代码编译，没有可靠的或可重复的功能测试。后续考虑Appium结合Jenkins来实现构建后自动化测试工作。
无论任何时候，只要代码更新提交到git中，构建服务器就会触发一个构建，构建运行脚本去编译应用程序并且运行一系列的自动化单元测试和/或集成测试。通过自动化测试结果能够清晰的展示出那些功能特性是通过的，哪些是失败的。不管是有改动提交，还是定期在夜间触发构建，应用程序都会被自动部署到测试环境当中以便QA团队进行测试。
Jenkins构建脚本完成后，将没有安装stf组件电脑上连接的android设备，添加映射到装有stf平台服务的机器上，将集成测试用例push到STF平台，再由STF分发到可运行设备上，进行多机并行测试。
STF执行APPIUM测试带来的优势
第一、可以在真机上执行并行的Appium测试。由于最初的Appium使用对象是模拟器上或只是以每次一台设备的测试方法执行测试，而STF在原有的基础上扩展了Appium，最多可在数百台真机上同时执行测试的能力。
第二，不需要配置任何设备的Desired Capabilities。这种方式既简便，且减少了因为编辑脚本而产生的不同类型的错误。
第三，在STF上执行测试可以让用户即时浏览测试状况。也就是说，可以查看到测试执行的进度，即时的错误反馈，以及保留和查阅所有测试项目，测试脚本和测试结果（测试截图，测试日志，性能数据等）
6.3.1、为什么要分析代码
对代码质量关注时，安排人工进行code review是需要的，但100%的code review却需要投入人员，消耗大量的工作量，而工具自动检查只需少量人工配置。
最主要的原因就是提高代码质量，了解RD在编码过程中犯过的错误可能对功能逻辑产生的影响，同时也推动RD让自己的代码更具有可读性和维护性，所以我们借鉴持续改进的流程，希望能够在这个过程中有所收获。
6.3.2、Jenkins引入Sonarqube进行代码持续审查
Sonar是一个用于代码质量管理的开源平台，用于管理Java源代码的质量。通过插件机制，Sonar 可以集成不同的测试工具，代码分析工具，以及持续集成工具，比如pmd-cpd、checkstyle、findbugs、Jenkins。通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。
在Jenkins中配置实现邮件通知，Jenkins提供了两种方式的配置。
一种是Jenkins内置默认的邮件通知，但是它本身有很多局限性，比如它的邮件通知无法提供详细的邮件内容、无法定义发送邮件的格式、无法定义灵活的邮件接收配置等等。
在这样的情况下，后续考虑可以通过Email Extension Plugin来实现自定义邮件通知的方方面面，比如在发送邮件的同时可以自定义发送给谁，发送具体什么内容等等。