背 景

在这个科技时代,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下面的安装,这里给我之前的一篇博客链接:Appium+Python在Windows下面的安装

这个安装方法,我试过,是可以成功安装,如果在安装过程遇到一些问题,可以在该博客下留言,我会及时回复的!本人在刚开始,配置部署这个开发环境时,就踩了好多坑,环境配置是我目前最麻烦的之一,比Spark集群稍微简单点,但是它的需求太多,好多想要使用该工具的人,估计90%的人被环境配置难住!

环境配置结束之后,那就是需要跑一个测试,来了解下简单的操作流程。本文不做赘述,链接:appium简单实例

示例代码:

`from appium import webdriver  
    import time  
    desired_caps = {}  
    desired_caps['deviceName'] = 'GT-N7100'  
    desired_caps['platformName'] = 'Android'  
    desired_caps['browserName'] = ''  
    desired_caps['version'] = '4.3'  
    desired_caps['appPackage'] = 'com.job.android'  
    driver = webdriver.Remote('http://127.0.0.1:4723/wd/hub', desired_caps)  
    time.sleep(5)  
    driver.find_element_by_id("com.job.android:id/closebtn").click()  
    time.sleep(10)  
    driver.find_element_by_id("com.job.android:id/tv_msg_remind_right").click()  
    time.sleep(10)  
    driver.find_element_by_id("com.job.android:id/loginbutton").click()  
    time.sleep(5)  
    driver.find_element_by_id("com.job.android:id/login_username").send_keys("123456")  
    driver.find_element_by_id("com.job.android:id/login").click()

元素定位

接触过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的操作实例以及环境搭建

那么appium如何在安卓设备上进行定位呢?在安卓设备上使用的是uiautomator,以Python为例,使用方法如下:find_element_by_android_uiautomator(),该方法与Uiautomator的UiSelector()联合使用来定位元素。下面给出一段代码示例截图:

enter image description here

可以查看我的博客链接:python封装安卓查找元素方法V1.0

性能

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

使用难度

从环境的配置,到编码的使用,都要求较高,需要有一定的编码基础,不然很难入门使用,所需要花费的成本较高!不过可以与robot framework结合使用,使用者不需要关心后台代码逻辑!关于如何与robot framework可以从网上查找,比较多的!

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

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

部分代码截图:

enter image description here

改脚本实施原理是,通过adb命令把设备当前页面的信息dump下来保存为xml文件,通过xml的树定位元素在页面所在的位置,具体可以看上述代码链接,具体实施是可行的,只要是页面中有都可以定位点击,准确度和性能都不错!

缺点是需要adb支持,不支持ios。我把该脚本封装好,与robot framework结合起来,链接:与robot framework结合起来

自化测试脚本维护

在需求稳定,页面稳定的时候,自动化测试脚本维护成本比较低;在需求变化比较频繁、页面变化比较大,维护成本比较高!自动化测试脚本,也需要定期的进行迭代管理,需要制定合理规范化的管理流程!要有规范化的测试用例编写规范、测试集模块功能介绍、各测试集管理人员、操作手册等相关文档,避免人员在流失导致自动化测试脚本废弃!

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

总结

其实,在研究app UI自动化测试可行性分析,发现最大的问题是:入口和UI经常变化、时间紧,导致维护成本高!其实,app UI自动化脚本开发都是提高工作质量,但是由于app更新频次快,时间紧,手动测试比较自由及时,使用脚本还要去调试校验、编写代码,比较耗时!

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

发表评论

电子邮件地址不会被公开。