APP UI 真的可以实现自动化测试吗？

本文来自作者 我是坏蛋 在 GitChat 上分享「论 APP UI 自动化测试的可行性」，「阅读原文」查看交流实录

「文末高能」

编辑 | 家辉

背 景

在这个科技时代，app 数量也是逐年递增，只要能想到，大多数都可以在相应的平台找到相关的 app!

那一款 app 在市场上出现之前，会经过哪些「加工锻造」的过程呢？又经过哪些流程，来确保从市场上下载下来的 app 能正常使用呢？

在这里我，以测试的视角来说我对 app 一些粗浅认知,在这过程一些意见，纯属个人臆断，如有不对欢迎指正！

不管是何种事物的产生，都是基于需求，有需求才能存在发展的内在驱动力，因此 app 的产生的第一阶段是需求；

有了需求就要基于该需求，调查市场上的用户的群体，分析获取用户的功能性需求，设计 app 的功能性需求，因此这一阶段为产品设计；

根据产品的文档，开始 app 的制作加工阶段，这个阶段不展开解说，包括内容太多，例如开发框架的选择、UI 设计、编码等等，这个阶段为 app 设计与实现阶段；

根据 app 设计与实现完成，要确保能正常使用，需要进行相应的测试，该阶段称为 app 测试阶段；

测试完成之后，app 上线，至此一个 app 的产生就完成了，至于市场运营，那是以后的事情了！

因此，app 的加工锻造的过程，大致为：获取市场需求、提取需求设计产品文档、根据需求设计并实现 app、app 测试、app 上线！

本篇文章，是针对 app 测试阶段中的 UI 自动化测试的可实施性进行分析作为背景，从需求、技术、维护三个阶段来分析 UI 自动化测试在 app 的可行性！

需求变更频繁

不管是测试还是开发，所有的出发点都是基于需求，那么目前市场上一些app，为了保持用户的新鲜感，不断的更新版本，来确保用户获得更好的体验！

在 App 每个版本更新过程中，一些功能入口会发生变化、页面的一些元素会发生变化、之前有的一些功能会被替换掉、增加新的功能等！

这点对于自动化测试是致命的威胁，目前自动化测试都是通过编码实现的，来实现模拟用户点击行为。

一旦 app 进行版本更新，就要对自动化脚本进行维护，维护成本比较高，由于需求变更频繁，造成开发完成，后期没人维护，被废弃。

不过这可不是来说通我们的 boss，放弃 App UI 自动化测试想法的重要砝码！

他们会给你新的想法，不过这些想法，有时候会让我头疼，但是他们说的确实在理，无法反驳，那就按着他们的想法去试试，万一成功了呢？

这不是发现了测试中的一个新大陆吗，对自己的能力增长那是很大的不是吗？

就以我遇到的一些问题为例，每个 App 产生的时候，都有自己的一些核心业务，后期的版本更新都是基于这些核心业务来扩展设计新的功能。

这些核心业务基本很少甚至不发生变化，那么能不能对于 app 中成熟的业务来设计 UI 自动化测试用例呢？

那么对于这个想法，我做了如下尝试，把遇到坑归纳如下：

· 核心业务是否有单独稳定的UI入口？

核心业务是否有单独稳定的 UI 入口，这是重中之重，这能保证测试的正常进行，自动化测试的初期，都是对业务流进行梳理分析，选择一些成熟稳定的业务流！

这么做的好处主要有：需求变更对业务流影响较少、有效的数据比较多、业务之间的边界清晰！

如果核心业务没有单独稳定的入口，那么 UI 的自动化还没开始就会遭遇滑铁卢，因为入口变更频繁的话的，那么业务流就无法成功走下去，后续的测试用例也无法成功执行！

其实测试做到后期，都有个认识，UI自动化测试都是基于业务流的测试，业务流发生变化，直接影响的是一个测试集的，因此针对 APP 的 UI 自动化测试而言，业务流的选择是基石！

· 一些开发的编码格式是否规范？

开发人员的编码规范与否，对于自动化测试的也是有一定影响的，规范的编码，对于后期的技术实现影响是相当大的。

所以早期，最好能与开发协商，你测试过程中需要的一些元素属性一定不能为空，方便后期元素定位，因此开发人员编码规范也是相当重要的！

· App 开发框架更新？

APP开发框架一般对于业务流影响不大，可能会影响部分测试集中的测试用例，导致测试用例无法正确执行，这个影响程度要看测试用例的数量，因此这个对UI自动化影响大小看情况而定！

因此，根据上述可以看出，APP UI自动化测试可行性在一些场合下是可行，在一些场合下是不可行的！

可行场景：产品变动小、页面UI改动小，这些是可以做的；其他一些可以通过接口测试，来实现业务的自动化！ 

APP UI自动化技术

目前市场上主流的 APP UI 自动化工具包括 Appium、UiAutomator、UIAutomation、XCUITesting 等等。

这些自动工具都是通过页面元素一些属性来定位页面元素，来实现用户一些日常操作行为的模拟操作，元素点击、拖动、截图等！

那下面以 Appium 这个目前最火一款工具，来分析它有哪些弊端。

环境部署

针对 Appium 环境部署，这里不讲如何安装配置，如果想学习 Appium+Python 在 Windows 下面的安装，这里给我之前的一篇博客链接：(http://blog.csdn.net/henni_719/article/details/51682081)

这个安装方法，我试过，是可以成功安装，如果在安装过程遇到一些问题，可以在该博客下留言，我会及时回复的！

本人在刚开始，配置部署这个开发环境时，就踩了好多坑，环境配置是我目前最麻烦的之一，比 Spark 集群稍微简单点，但是它的需求太多，好多想要使用该工具的人，估计 90% 的人被环境配置难住！

环境配置结束之后，那就是需要跑一个测试，来了解下简单的操作流程。本文不做赘述，链接：appium 简单实例( http://blog.csdn.net/henni_719/article/details/51722043 )

示例代码：

元素定位

接触过 selenium 的，对于元素定位，以 Python 语言为例给出方法名称：

• find_element_by_id( )：根据元素的 id 属性进行定位；  

• find_element_by_name( )：根据元素的 name 属性进行定位；

• find_element_by_class_name( )：根据元素的 class 属性值进行定位；

• find_element_by_tag_name( )：根据元素的 tag 名进行定位；

• find_element_by_link_text( )：根据链接文本进行定位；

• find_element_by_partial_link_text( )：根据链接文本中包含的部分文本信息进行定位

• find_element_by_xpath( )：根据 xpath 进行定位；

• find_element_by_css_selector( )：根据 css 进行定位；

关于定位元素组的，只需要把 find_element 改成 find_elements 就可以。

上述是 selenium 的定位方法，目前 IOS 使用 XCUITesting 后，元素定位方法与 selenium 元素定位方法一致。

这是 Appium+XCUITest 的 Python 链接：

Appium+XCUITest 基于 Python 的操作实例以及环境搭建(http://blog.csdn.net/henni_719/article/details/62037676)

那么 appium 如何在安卓设备上进行定位呢？

在安卓设备上使用的是 uiautomator，以 Python 为例，使用方法如下：find_element_by_android_uiautomator ( )，该方法与 Uiautomator 的 UiSelector( ) 联合使用来定位元素。

下面给出一段代码示例截图：

    

可以查看我的博客链接：python 封装安卓查找元素方法V1.0(http://blog.csdn.net/henni_719/article/details/65630889)    

性能

appium 对设备的要求比较高，如果设备配置的比价低的，运行脚本时会相当卡顿，不能及时响应操作，总体来说性能不怎么好！

使用难度

从环境的配置，到编码的使用，都要求较高，需要有一定的编码基础，不然很难入门使用，所需要花费的成本较高！

不过可以与 robot framework 结合使用，使用者不需要关心后台代码逻辑！关于如何与 robot framework 可以从网上查找，比较多的！

针对上述可以发现，app UI自动化测试上技术是可行的，不过对于测试人员的技术要求比较高，学习成本比较大！需要专业的人员指导，才能顺利实施！

关于在 windows 下对安卓进行的自动化测试，我做了做了一个研究，把 adb+python 结合起来，把 adb 的命令和 Python 结合起来，来实现元素点击操作，具体代码链接：通过 adb 与 python 结合创建的设备驱动脚本 deviceDriver.py

部分代码截图：

改脚本实施原理是，通过 adb 命令把设备当前页面的信息 dump 下来保存为 xml 文件，通过 xml 的树定位元素在页面所在的位置，具体可以看上述代码链接。

具体实施是可行的，只要是页面中有都可以定位点击，准确度和性能都不错！

缺点是需要 adb 支持，不支持ios。我把该脚本封装好，与robot framework结合起来，链接：与 robot framework 结合起来( http://blog.csdn.net/henni_719/article/details/73087463 )

自化测试脚本维护

在需求稳定，页面稳定的时候，自动化测试脚本维护成本比较低；在需求变化比较频繁、页面变化比较大，维护成本比较高！

自动化测试脚本，也需要定期的进行迭代管理，需要制定合理规范化的管理流程！

要有规范化的测试用例编写规范、测试集模块功能介绍、各测试集管理人员、操作手册等相关文档，避免人员在流失导致自动化测试脚本废弃！

脚本维护，是保存自动化测试持续的必要条件，人员流失、文档少，是自动化测试脚本废弃的主要问题！

总结

其实，在研究 app UI 自动化测试可行性分析，发现最大的问题是：入口和UI经常变化、时间紧，导致维护成本高！

其实，app UI 自动化脚本开发都是提高工作质量，但是由于 app 更新频次快，时间紧，手动测试比较自由及时，使用脚本还要去调试校验、编写代码，比较耗时！

总而言之，APP UI 自动化因公司而定，如果有规范化的管理流程，自动化测试在回归测试方面还是很高效的！

福利

「阅读原文」看交流实录，你想知道的都在这里