Android App自动化测试实战（基于Python）（一）

1.Hybrid App自动化测试概要

什么是Hybrid App?

Hybrid App（混合模式移动应用）是指介于web-app、native-app这二者之间的app，兼具“Native App良好用户交互体验的优点”和“Web App跨平台开发的优点”。

它虽然看上去是一个Native App，但只有一个UI WebView，里面访问的是一个Web App，好比街旁网最开始的应用就是包了个客户端的壳，其实里面是HTML5的网页，后来才推出真正的原生应用。再完全一点的，如掌上百度和淘宝客户端Android版，走的也是Hybrid App的路线，不过掌上百度里面封装的不是WebView，而是本身的浏览内核，因此体验上更像客户端，更高效。

Hybrid App同时使用网页语言与程序语言开发，整体特性更接近Native App可是和Web App区别较大。只是由于同时使用了网页语言编程，因此开发成本和难度比Native App要小不少。所以说，Hybrid App兼具了Native App的全部优点，也兼具了Web App使用HTML5跨平台开发低成本的优点。

使用python驱动Appium测试Hybrid APP的流程以下图，和Native App相同的是，Hybrid APP原生的自动化框架Selendroid也是基于Java语言开发的；

2.Appium基于Selendroid的原理、元素识别工具、脚本设计原则--SLOVE原则

2.1，Appium原理

 

2.2，Selendroid架构

2.3，元素识别工具

Web App页面部分使用Chrome Inspector；Java实现的框架部分仍然可使用UIAutomatorviewer来定位；

2.4，脚本设计原则

2.5，如下图为例进行后面的介绍

3.基于Appium的Hybrid App自动化环境差别

3.1，Appium的配置如图1；

为何要添加测试app的路径呢？

由于Selendroid是须要把测试app重签名的，既然要进行重签名，那就须要有一个app包在；appium会根据这个路径来把app进行重签名

4.Hybrid App自动化脚本的实现

4.1，脚本的初始化部分

如图2，初始化部分，Hybrid App比Native App多了一个“automationName”=“Selendroid”；Native App初始化时使用的是默认的automationName，即appium，能够省略不写；

4.2，脚本的编写部分

如图3，包含了2种定位方式，一种是经过UIAutomaterviewer，一种要借助于Chrome浏览器的Inspector工具；

如图4，测试app启动后先进入一个搜索界面；

 

如图5，测试app顶端的搜索框和clear、search两个button都是Native框架部分，仍然能够用UIAutomaterviewer来定位；

如图6，整个搜狗搜索的主页是一个元素，名字是webkit.WebView，也就是所整个主页是一个WebView，此时就不能经过UIAutomatorviewer来定位了；

如图七、八、9，展现了经过Chrome浏览器的Inspector工具来获取元素Xpath的步骤；

如图10，能够经过返回结果的第一条做为判断脚本是否跑成功的依据；

如图11，print self.driver.contexts的输出结果是[u'NATIVE_APP'，u'WEBVIEW_0']，说明当前页面既有NATIVE实现部分，也有WEBVIEW实现部分；

5.Appium其余相关API的介绍与实践

上面的脚本实现过程用到了以下的API：

 

下面经过脚本介绍find_elements_by_xpath()的用法，如图12：

如图1三、14，webview页面中，推搜部分的xpath是表格形式的，能够经过“tr/td”来定位全部的推搜元素；

如图15，能够在控制台中看到输出了推搜的文案，说明脚本执行成功了。