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

640.gif?wxfrom=5&wx_lazy=1

本文来自作者 我是坏蛋 在 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 )

示例代码:

APP UI 真的可以实现自动化测试吗?_第1张图片

元素定位

接触过 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( ) 联合使用来定位元素。

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

APP UI 真的可以实现自动化测试吗?_第2张图片    

可以查看我的博客链接: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

部分代码截图:

APP UI 真的可以实现自动化测试吗?_第3张图片

改脚本实施原理是,通过 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 自动化因公司而定,如果有规范化的管理流程,自动化测试在回归测试方面还是很高效的!

福利

APP UI 真的可以实现自动化测试吗?_第4张图片

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

你可能感兴趣的:(APP UI 真的可以实现自动化测试吗?)