前言
由于需求的快速迭代和敏捷测试的要求，在测试过程中引入自动化成为必不可少的手段。作为一个互联网测试团队，我们自然也引入了自动化测试这个环节。在众多的测试框架中，我们选取了相对成熟稳定，支持多种平台的Appium框架。虽然Appium自身的Api能解决大多数的测试场景，但总有漏网之鱼。不巧，就是这些漏网之鱼往往成为我们自动化实施中的那些梗。本文主要介绍我们测试团队在Appium UI自动化实施过程遇到的梗，以及对应的解决方法。
自动化测试
Appium自动化框架
我们这里先简单介绍下Appium。Appium是一个移动端的自动化框架，可用于测试原生应用，移动网页应用和混合型应用。Appium的核心是一个遵守REST设计风格的web 服务器，它接受客户端的连接，接收客户端的命令，在手机设备上执行命令，然后通过HTTP的响应收集命令执行的结果。这种架构给我们提供了很好的开放特性：只要某种语言有http 客户端的api，我们就可以通过这个语言写我们的测试代码。
自动化过程
自动化过程广义上来讲是对测试过程的一个建模，就是说通过测试脚本来模拟手工测试的过程。测试过程的三要素是：前提条件，测试步骤，结果校验。那么对应的自动化测试过程也应该包含这三个要素。我们在实施自动化的过程是怎么体现这三个要素的呢？这里可以看下一个典型的测试脚本。
测试过程
从上面的测试脚本我们可以看出，我们自动化测试是通过找到对应的元素，然后执行相应的动作，即可达到自动化的效果。但这个过程只是最基本的，实际项目过程中，我们会遇到很多更复杂的过程。下面，我为大家介绍几个我们项目过程中遇到的问题以及解决方案。
Appium自动化常见问题分析
由于我们的框架对Appium的API进行了二次封装，通过在Web端录入“伪代码”的方式提供给用户。很多问题，我们解决起来的成本更加高，这里主要分析几个典型的案例。
结果校验的问题
我们知道，测试步骤执行完成之后，要判断是否达到预期结果。在实际的测试过程中，我们判断是否执行通过，一般判断是否跳转到预期页面，页面上是否有预期元素或者文案。那自动化过程中其实也是类似的处理方式。我们在测试步骤的最后，加上一个或者多个判断某个页面元素是否存在的步骤即可。如果通过，则表示测试用例执行成功。比如判断登录成功，我们通过检查当前页面是否出现登录的账号名称来校验。
检查登录
具体实现方式，我们可以调用Appium查找元素的API，将查找方式和元素标识作为参数，如果查询成功，则说明校验成功，否则校验失败。
脚本复用的问题
在测试过程中，很多测试步骤都是通用的，比如登录。因此，我们要引入脚本复用的概念。在我们的自动化实施过程中，我们有三种方式来实现脚本复用：前置脚本，脚本复制，脚本引用。下面分别介绍这三种方式的实现过程。
前置脚本
前置脚本一般是用在一些用于初始化或者实现前提条件的地方，比如App启动初始化。我们通过指定某个脚本为前置脚本，然后在录入其他脚本的时候，将前置脚本的ID作为录入前置。在执行脚本的时候，我们先执行前置脚本，再执行自身脚本。从而达到复用的效果。
前置脚本
脚本复制
脚本复制是为了提高写脚本的效率。我们在写代码或者写文章的过程中，如果发现一些相似的内容，我们喜欢复制过来，然后修改一下。同样，我们写测试脚本的过程中，很多测试步骤都非常类似，我们也需要将以前的测试脚本复制过来，修改后变成一条新的测试脚本，节约大量重复工作。
脚本复制
具体实现过程，我们只是针对我们自身框架的特点设计，通过前端js的方式，将要复制的测试脚本全部渲染到web页面。如果是通过代码方式实现的自动化过程，其实是不存在该问题的。
脚本引用
类似前置脚本，有些脚本，我们不一定是作为前置脚本去引用，我们可能在脚本中间引用，在脚本结尾引用。那就需要一个脚本引入的过程。我们通过在测试步骤中增加一个动作类型，该动作类型的参数是待引用脚本的ID。在执行测试的过程中，遇到该类型，我们就先执行引用脚本的步骤，然后再继续执行下面的步骤。该方式支持嵌套。
脚本引用
分支逻辑的问题
前面提到的脚本复用问题，是为了解决脚本之间的相互关联。那么脚本内部的各个步骤之间关联怎么解决呢，比如分支逻辑的问题。该问题就类似于代码中的if语句，由于我们框架并不是纯粹的代码，所以我们要模拟代码的方式解决该问题。我们通过引入ExistGoto和NotExistGoto两个动作类型，参数表示要跳转到的步骤来实现判断逻辑。这两个动作类型分别根据检查指定的页面元素，如果存在则跳转到某个步骤以及如果不存在则跳转到某个步骤。
