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