@作者 彭海波 转载请注明出处
前言
由于需求的快速迭代和敏捷测试的要求，在测试过程中引入自动化成为必不可少的手段。作为一个互联网测试团队，我们自然也引入了自动化测试这个环节。在众多的测试框架中，我们选取了相对成熟稳定，支持多种平台的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两个动作类型，参数表示要跳转到的步骤来实现判断逻辑。这两个动作类型分别根据检查指定的页面元素，如果存在则跳转到某个步骤以及如果不存在则跳转到某个步骤。
实现方式我们需要在测试步骤的执行过程中，判断如果是该动作类型，而且条件满足的话，直接跳转到指定的步骤开始执行。
手势密码怎么输入
由于Appium自动化一般都是针对单个步骤进行处理，而手势密码的输入是一个连续的过程，我们在处理手势密码的时候，需要对测试步骤特殊处理。但最重要的是，要获取手势密码的路径。手势输入页面一般有九个点。这九个点其实对应了九个控件，而手势的轨迹其实是针对这九个点的坐标绘制出来的连线。比如对于下图这样一个Z字形的密码，我们要经过的点是1235789这七个点。我们分别获取到这七个点的坐标，然后调用Appium的TouchAction进行绘制。
核心代码如下：
1 public void gestureInputAction(List<Point> gesturePoints){ 2 Point prePoint = gesturePoints.get(0); 3 //Point p1 = ae.getLocation(); 4 TouchAction touchAction = new TouchAction(ad); 5 TouchAction cur = touchAction.press(prePoint.getX(),prePoint.getY()).waitAction(2000); 6 for(int i = 1;i<gesturePoints.size();i++){ 7 Point nextPoint = gesturePoints.get(i); 8 cur = cur.moveTo(nextPoint.getX()-prePoint.getX(),nextPoint.getY()-prePoint.getY()).waitAction(2000); 9 prePoint = nextPoint; 10 } 11 cur.release().waitAction(2000).perform(); 12 }
而对应到我们的框架里面，还是要做下特殊处理。我们在动作类型中加入一个actionGesture动作类型，控件标志是每个点的xpath，参数则表示一共有多少个点。我们从第一个点开始调用TouchAction的press方法，一直到最后一个点释放，从而实现连续的手势滑动。
动态验证码如何输入
现在很多App为了安全，尤其是金融类的App，在核心业务场景都需要短信验证码的校验。这对于Appium来说其实是一个无法解决的瓶颈。不幸的是，我们的产品有很多的短信验证环节，解决这个问题势在必行。但幸运的是，在我们的测试环境下面，我们的短信验证码开放了查询接口。因此，我们只需要在输入短信验证码的时候，调用查询接口获取验证码，然后再通过Appium输入到文本框中即可。当然，如果没有开放接口，通过自动识别短信的方式也能解决，但相对复杂很多。
如上图所示，我们也是在测试步骤中加入一个GetVerifyCode的动作类型，在执行步骤执行，先调用接口获取验证码，然后再将返回的验证码作为参数输入。
安全键盘的问题
我们在实施自动化的过程，遇到另外一个比较变态的问题，有些App的密码输入框是用的安全键盘，类似下图这种。Appium自身的API根本无法输入密码。安全键盘的实现方式一般分为两种：native控件绘制和webview动态加载。对于Webview动态加载的安全键盘，我们可以通过调用Appium的JavascriptExecutor类来实现。该类的executeScript方法可以执行一段js脚本。我们可以通过js脚本来模拟出密码的点击事件。但对于native的控件，我们暂时还在调研阶段。基本的思路是通过图像识别的方式获取到键盘上每个字母的位置，然后发送点击事件。具体过程还没有实现，各路大神如果有更好的解决方案，请不吝赐教。
总结
如果你的团队也用的Appium作为自动化测试框架，碰巧也遇到了我们类似的问题，不妨用我们上面介绍的方法试一试。虽然不一定是最好的解决方案，但我们已经通过实践证明，它确实解决了我们的问题。另外，最后一个我们正在尝试解决的梗，欢迎各路大神多多给出建议，参与交流和讨论。