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