一、序言
随着项目版本的快速迭代、APP测试有以下几个特点：
首先，功能点多且细，测试工作量大，容易遗漏；
其次，代码模块常改动，回归测试很频繁，测试重复低效；
最后，数据环境多样，用户场景复杂，功能回归覆盖难全面。
为节省成本，保证高效及高质量迭代，我们需采用更高效的测试方式，App自动化测试是较高效的手段。
之前自动测试实践过程中遇到的诸多问题（代码复用率低，Case开发及数据构造繁琐，问题定位困难，学习成本高等），为解决相关痛点问题，我们重新实现了一套APP自动测试框架。本文将着重介绍技术选型、设计思路及百度外卖App的具体实践。
二、自动化测试框架技术选型
一个项目中自动化测试是否能有效的展开，自动化测试框架是关键所在。因此，如何如何构建稳定的、易扩展的自动化的测试项目对于敏捷测试有重要的意义。在设计框架的时候应该尽可能的沿用自动化测试工具已提供的功能，避免重复开发，以减少开发成本。
通过对现有自动化测试工具的原理进行深入分析及优缺点比较，并基于Appium和TestNG两类自动化测试框架解决上述自动化测试中遇到的问题。
首先，通过利用TestNG结合csv的使用，将测试用例数据转化为测试代码中的数据，减少了测试人员录入数据和准备数据的工具；
再次，通过对appium的封装，按照面向对象的思想将测试中用到的页面元素封装成对象，增强测试代码的复用率，并减轻测试人员对底层代码实现的负担，提高测试代码编写效率；
最后，引入失败重跑、失败截屏，并通过reportng生成测试报告的方式，逐步完善测试过程，提高定位问题的速度；
TestNG
Testng是一个开源自动化测试框架，引入了许多新的创新功能，如依赖测试，分组概念，使测试更强大，更容易做到。旨在涵盖所有类别的测试：单元，功能，端到端，集成等。TestNG框架可以很好地帮我们完成WebDriver+java的页面自动化工作,通过各种注释的灵活运行，可以使你的测试用例更加完美，定制符合要求的测试用例
1.TestNG是一个设计用来简化广泛的测试需求的测试框架，从单元测试到集成测试。这个是TestNG设计的出发点，不仅仅是单元测试，而且可以用于集成测试。设计目标的不同，对比junit的只适合用于单元测试，TestNG无疑走的更远。可以用于集成测试，这个特性是我选择TestNG的最重要的原因。
测试的过程的三个典型步骤，和junit(4.0)相比，多了一个将测试信息添加到testng.xml文件。测试信息尤其是测试数据不再写死在测试代码中，好处就是修改测试数据时不需要修改代码/编译了，从而有助于将测试人员引入单元测试/集成测试。
基本概念，相比junit的TestCase/TestSuite，TestNG有suite/test/testmethod三个级别，即将test/testmethod明确区分开了。
Appium
Appium一个开源、跨平台的测试框架，可以用来测试原生及混合的移动端应用。Appium支持iOS、Android及FirefoxOS平台测试。Appium使用WebDriver的jsonwire协议，来驱动Apple系统的UIAutomation库、Android系统的UIAutomator框架。相比其他的移动自动化测试工具，Appium测试由于调用了Selenium的client库使其可以使用任意的语言，包括Python、Ruby、Node.js、Objective-C等。
三、自动化测试框架的设计思路
测试设计过程和测试自动化框架必须作为两个单独的实体来开发。
测试框架应该独立于应用程序；
测试框架应该易于扩展、维护和增强；
测试策略／设计应该对测试者隐藏测试框架的复杂性。
四、自动化框架介绍
该框架基于SeleniumWebDriver开源技术开发。本框架使用Maven工具进行Project管理，采用TestNG工具组织测试，应用CSV文件存储测试数据，实现测试数据与测试用例的分离，方便测试数据管理，降低自动化脚本的维护成本，实现数据驱动。此外，该框架还封装了丰富的Selenium方法关键字，借鉴了QTP语法结构，实现了直观清晰的结构化代码语法，如：Page.Item.Operate，降低自动化代码的冗余与重复。借助Jenkins进行CI测试，实现测试任务的Schedule和Report功能，通过JenkinsMaster/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操作，