转自微信公众号:腾讯移动品质中心TMQ

移动APP的UI自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护。从分层测试的角度,自动化测试应该逐层进行。最大量实现自动化测试的应该是单元测试,最容易实现也最容易在早期发现问题;其次是接口级测试,以验证逻辑为目的进行自动化,由于接口的相对稳定,自动化测试成本相对也可以接受;自动化成本最大的便是UI级自动化测试,然而UI界面是直接反馈给用户的效果展示,适度的尤其是BVT级的自动化测试也是非常必要的。本文通过分析几种自动化框架的异同,使测试人员在选择自动化框架时有所参考。

Android自动化框架

1、Instrumentation

https://developer.android.com/reference/android/app/Instrumentation.html

Instrumentaion是Android自带的一个测试框架,是很多其它测试框架的基础,可以在同进程中加载被测组件。它有很多丰富的高层封装,使用者可以使用基于instrumentation的其他框架,避免过多二次开发量。但Instrumentation不支持跨应用,导致基于instrumentation的框架都继承了这个缺点。

2、Robotium 

https://github.com/robotiumtech/robotium

Robotium是基于Instrumentation框架开发的一个更强的框架。对常用的操作进行了易用性的封装。用于开发功能性、系统和验收测试场景。它运行时绑定到GUI组件。它安装了一个测试用例套件作为在Android设备或仿真器上的应用程序,并提供用于执行测试的真实环境。

优点:容易在最短的时间内编写测试脚本,易用性高。自动跟随当前activity。由于运行时绑定到GUI组件,所以相比Appium,它的测试执行更快,更强大。不访问代码或不了解app实现,也可以工作。支持Activities、Dialogs、Toasts、Menus、Context Menus和其他Android SDK控件。

缺点:不能处理flash和web组件。在旧设备上会变得很慢。 由于不支持iOS设备,当自动化测试同时覆盖android与iOS的情况时,测试会被中断。没有内置的记录和回放功能,使用记录功能需要TestDroid和Robotium Recorder这样的收费工具。

3、UIAutomator

https://google.github.io/android-testing-support-library/docs/uiautomator/

UIAutomator是由谷歌提供的测试框架,它提供了原生Android app和游戏的高级UI测试。这是一个包含API的Java库,用来创建功能性UI测试,还有运行测试的执行引擎。该库自带Android SDK。

优点:它在运行访问不同的进程时,会给JUnit测试案例特权。库由谷歌社区支持和维护。

缺点:仅支持android4.1(API level 16)及以上。不支持脚本记录。支持的重点是Java。你不能获得当前活动或仪表化。目前不支持web视图。库仅支持使用Java,因此很难和使用Ruby的cucumber混合。如想支持BDD框架,建议使用Java自己的BDD框架,例如Jbehave。

4、Espresso

https://google.github.io/android-testing-support-library/docs/espresso/index.html

Espresso是Google的开源自动化测试框架。相对于Robotium和UIAutomator,它的特点是规模更小、更简洁、API更加精确、编写测试代码简单、容易快速上手。因为是基于Instrumentation的,所以不能跨App。

5、Calabash

https://github.com/calabash

Calabash是一个适用于iOS和Android开发者的跨平台app测试框架,可用来测试屏幕截图、手势和实际功能代码。Calabash开源免费并支持Cucumber语言,Cucumber能让你用自然的英语语言表述app的行为,实现BDD(Behavior Driven Development,行为驱动开发)。Cucumber中的所有语句使用Ruby定义。

优点: 有大型社区支持。列表项简单,类似英语表述的测试语句支持在屏幕上的所有动作,如滑动,缩放,旋转,敲击等。跨平台开发支持(同样的代码在Android和iOS设备中都适用)。

缺点:测试步骤失败后,将跳过所有的后续步骤,这可能会导致错过更严重的产品问题。测试耗费时间,因为它总是默认先安装app。需要Calabash框架安装在ios的ipa文件中,因此测试人员必须要有iOS的app源码。除了Ruby,对其他语言不友好。

6、Appium

http://appium.io/

Appium是一个开源的、跨平台的自动化测试工具,支持IOS、Android和FirefoxOS平台。通过Appium,开发者无需重新编译app或者做任何调整,就可以测试移动应用,可以使测试代码访问后端API和数据库。它是通过驱动苹果的UIAutomation和Android的UiAutomator框架来实现的双平台支持,同时绑定了Selenium Web Driver用于老的Android平台测试。开发者可以使用Web Driver兼容的任何语言编写测试脚本,如Java,OC,JS, PHP,Python,Ruby,C#,Clojure和Perl语言。

7、Selendroid

https://www.gitbook.com/book/lihuazhang/selendroid/details

Selendroid是一个基于Instrumentation的一个框架。完全兼容Webdriver协议。Selendroid可以在模拟器和实际设备上使用,也可以集成网格节点作为缩放和并行测试。

8、Robolectric

http://robolectric.org/

Robolectric是一款Android单元测试框架,但它并不依赖于Android提供的测试功能,它通过实现一套JVM能运行的Android代码,然后在unit test运行的时候去截取android相关的代码调用,然后转到Robolectric实现的代码(shadow objects)去执行这个调用的过程。因此它不像模拟器或设备需要dexing(Android dex编译器将类文件编译成Android设备上的Dalvik VM使用的格式)、打包、部署和运行的过程,大大减少了测试执行的时间。Pivotal实验室声称使用Robolectric可以在28秒内运行1047个测试。

除了实现Android里面的类的现有接口,Robolectric还给每个Shadow类额外增加了很多接口,可以读取对应的Android类的一些状态。比如它为ImageView提供了getImage ResourceId()方法,测试者可以通过getImage ResourceId()接口来确定是不是正确显示了期望的Image。

9、RoboSpock

http://robospock.org/

RoboSpock是一个开源的Android测试框架,它提供了简单的编写BDD行为驱动开发规范的方法,使用Groovy语言,支持Google Guice库。RoboSpock合并了Robolectic和Spock的功能。

10、Cafe

http://cafe.baidu.com/#panel1

Cafe是百度出品的一个基于Robotium的测试框架,它提供了跨进程的测试解决方案。

11、Athrun

http://code.taobao.org/p/athrun/wiki/index/

Athrun是taobao出的一个移动测试框架,它支持Android和IOS。Android部分是基于Instrumentation,在Android原有的Activity Instrumentation Test Case2类基础上进行了扩展,提供了一整套面向对象的API。IOS上的自动化测试包括注入式自动化框架AppFramework,和基于录制的自动化框架Athrun_IOS,InstrumentDriver。

12、其他

 

其他自动化框架还有应用于稳定性测试的Monkey系列(Monkey,Monkeyrunner,MonkeyTalk),其中MonkeyTalk支持iOS和Android,它可以为应用进行真实的,功能性交互测试。MonkeyTalk提供简单的 "smoke tests",复杂数据驱动的测试套件。MonkeyTalk 支持原生,移动和混合应用,真实设备或者模拟器。

MonkeyTalk使得场景捕获非常容易,可以记录高级别,可读的测试脚本。还有适用于浏览器自动测试的Selenium WebDriver,可以真实测试用户行为,用户交互如触摸、手指滚动、长按等,还支持HTML5的一些特性,比如本地存储、session存储、应用缓存等。而CTS则是应用于兼容性测试的自动化工具,CTS大部分是基于Junit和仪表盘技术编写的。还扩展了自动化测试过程,可以自动执行用例,自动收集和汇总测试结果。CTS采用XML配置文件的方式将这些测试用例分组成多个测试计划(plan),第三方也可以创建自己的plan。

总结(Android)

各个测试框架的继承关系如下,继承关系决定了有些框架的先天优势或先天不足。在实际应用中可以集成多个框架。

  • 基于Instrumentation的测试框架,比如Espresso,Robotium,Selendroid等,都不能支持跨APP使用。如自动化测试中有跨APP操作,可以结合UiAutomator实现。

  • 支持BDD的自动化框架比较少,可以在calabash和RoboSpock及Jbehave之间选择。

  • 若想同时支持Android和IOS,可选框架有Appium和Calabash,或AthRun。

  • 若为单元测试选择框架,可选Instrumentation或Robolectric。Robolectric实现了shadow object类,耗时短。

IOS自动化框架

1、XCTest

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/01-introduction.html

XCTest是苹果在iOS 7和Xcode5引入的一个简单而强大的测试框架,它的测试编写起来非常简单,并且遵循xUnit风格。XCTest的优点是与Xcode深度集成,有专门的Test导航栏,但因为受限于官方测试API,因此功能不是很丰富。

2、UIAutomation

https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html

UIAutomation是苹果提供的UI自动化测试框架,使用Javascript编写。基于UIAutomation有扩展型的工具框架和驱动型的框架。扩展型框架以Java Script扩展库方法提供了很多好用js工具,注入式的框架通常会提供一些Lib或者是Framework,要求测试人员在待测应用的代码工程中导入这些内容,框架可以通过他们完成对app的驱动。驱动型UI Automation 在自动化测试底层使用了UI Automation库,通过TCP通信的方式驱动UI Automation来完成自动化测试,通过这种方式,编辑脚本的语言不再局限于Java Script。

3、Frank

http://www.testingwithfrank.com/

Frank是iOS平台一款非常受欢迎的app测试框架,它使用Cucumber语言来编写测试用例,Frank包含一个强大的“app inspector”—Symbiote,可以用它来获得运行中app的详细信息,便于开发者将来进行测试回顾。它允许使用Cucumber编写结构化英语句子的测试场景。Frank要求测试时在应用程序内部编译,这意味着对源代码的改变是强制性的。操作方式为使用Cucumber和JSON组合命令,将命令发送到在本地应用程序内部运行的服务器上,并利用UISpec运行命令。

优点:测试场景是在Cucumber的帮助下,用可理解的英语句子写的。强大的Symbiote实时检查工具。活跃的社区支持,不断扩大中的库。

缺点:对手势的支持有限。在设备上运行测试有点难。修改配置文件需要在实际设备上运行。记录功能不可用。

4、KIF

http://www.oschina.net/translate/ios-ui-testing-with-kif

KIF是Keep It Functional项目的缩写,是一款iOS app功能性测试框架,使用Objective-C语言编写,对苹果开发者来说非常容易上手,更是一款开发者广为推荐的测试工具。KIF tester使用私有API来了解App中的视图层级。但缺点是运行较慢。

5、Calabash-ios

详见Calabash-android 描述。

6、Subliminal

http://inkling.github.io/Subliminal/

Subliminal是另一款与XCTest集成的框架。与KIF不同的是,它基于UIAutomation编写,旨在对开发者隐藏UIAutomation中一些复杂的细节。

7、Kiwi

https://github.com/kiwi-bdd/Kiwi/wiki/Getting-Started-with-Kiwi-2.0

Kiwi是对XCTest的一个完整替代,使用xSpec风格编写测试。Kiwi带有自己的一套工具集,包括expectations、mocks、stubs,甚至还支持异步测试。它是一个适用于iOS 开发的Behavior Driven Development(BDD)库,优点在于其简洁的接口和可用性,易于设置和使用,非常适合新手开发者。Kiwi使用Objective-C语言编写,易于IOS开发人员上手。

总结(IOS)

IOS自动化测试框架继承关系如下:XCTest与Xcode的IDE直接集成,使用简单,但其不支持stub和mock,所以单使用XCTest框架的较少。Kiwi是一个iOS平台十分好用的行为驱动开发BDD的测试框架,有着非常漂亮的语法,可以写出结构性强,非常容易读懂的测试。UI Automation是Apple官方提供的UI自动化测试的解决方法,但接口不够丰富。

  • KIF、Frank、Calabash都是通过使用代码的形式来模拟事件触发,使得被测代码就像是由用户行为所触发的一样。但这样的代价是插入一个额外层的复杂度。

  • IOS测试框架中支持BDD的有calabash和Kiwi。

  • 可选用的单元测试框架有Kiwi,Specta,Quick等,而KIF,Subliminal和calabash更适用于UI级验收测试。

一些有趣的自动化测试框架

1、Sikuli 图形化编程技术

http://www.sikuli.org/

Sikuli是由MIT的研究团队发布的新型图形化编程技术。它以图像检索技术为基础,提供了一套基于Python的脚本语言以及集成开发环境。使用者可利用屏幕截图直接引用GUI元素进行编程,完成交互操作。Sikuli的脚本编写遵循 Python语法规范。由于Sikuli基于Python,其核心代码由Java编写,可在用户自定义的Java工程中将其作为Java标准类库进行引用。

它的脚本是这样式的:

Sikuli将GUI对象的屏幕截图作为函数的参数直接引用,整个代码的语义清晰明了,可读性极强。脚本执行过程中,利用图像检索算法分析匹配当前屏幕中对应的控件,并对其应用相应的鼠标或键盘操作。这种方式使得我们在脚本编写时,既无需关心繁琐的应用程序相关API亦不用获取Web内容对象。

缺点:

(1)仅支持windows,MACOSX,和Linux平台,还不支持移动平台。

(2)依赖屏幕截图,使得

1)在不同平台,不同分辨率,不同操作系统上需要维护一套图形源文件,不利于跨平台移植;

2)若出现程序逻辑外的界面遮挡,则影响程序执行。

但作为现有自动化测试工具的补充,尤其是对无法获取API的工程,比如flash动画,是非常有效的。

2、A/B test框架AppGrader

https://www.utest.com/articles/utest-launches-appgrader-for-android

虽然AppGrader不是一流的测试框架,但也有所长。它可以帮开发者将自己的应用与其他众多同类型应用进行多方面比较,比如图形和功能。通过对比结果,开发者可以更有针对性地提高和改进自己的应用。目前AppGrader仅支持Android平台。

3、IOS A/B test 框架 FlipTest

http://www.fliptest.co.uk/

FlipTest是一个优秀的iOS app A/B测试框架,可为app挑选最佳的UI。

Flip Test会基于外观和易用性等众多因素返回测试结果,进而帮开发者解决UI问题。用Flip Test进行测试无需向App Store重新提交应用或者大幅更改代码,只需要在app中添加一行代码,节省了不少时间

移动APP自动化测试框架对比的更多相关文章

  1. 主流App自动化测试框架对比

        1.主流App自动化测试框架对比 2.Appium自动化测试框架 官方网址:http://appium.io/ 跨架构:支持原生.混合以及web移动应用 跨平台:Android & I ...

  2. Android自动化测试框架对比

    1.Monkeyrunner:优点:操作最为简单,可以录制测试脚本,可视化操作:缺点:主要生成坐标的自动化操作,移植性不强,功能最为局限:2.Rubotium:主要针对某一个APK进行自动化测试,AP ...

  3. 通过实例介绍Android App自动化测试框架--Unittest

    1.为什么需要使用框架实现自动化测试 作为测试工程师,可能在代码能力上相比开发工程师要弱一点,所以我们在写脚本的时候就会相对容易的碰到更多的问题,如果有一个成熟的框架供给我们使用的话,可以帮助我们避免 ...

  4. App自动化测试框架学习探索--从零开始设计

    App自动化测试框架学习探索--从零开始设计---持续更新中,敬请关注 1 批量执行app自动化测试使用多线程设计思路: 1)并发级别选择用methods 2)采用@Test多线程,数据提供类dp单线 ...

  5. 移动APP自动化测试框架

    简介 移动APP的UI自动化测试长久以来一直是一个难点,难点在于UI的”变”, 变化导致自动化用例的大量维护.从分层测试的角度,自动化测试应该逐层进行.最大量实现自动化测试的应该是单元测试,最容易实现 ...

  6. Windows下部署Appium教程(Android App自动化测试框架搭建)

    摘要: 1,appium是开源的移动端自动化测试框架: 2,appium可以测试原生的.混合的.以及移动端的web项目: 3,appium可以测试ios.android.firefox os: 4,a ...

  7. 自动化测试框架对比(UIAutomator、Appium)

    在Android端,appium基于WebDriver协议,利用Bootstrap.jar,最后通过调⽤用UiAutomator的命令,实现App的自动化测试. UiAutomator测试框架是And ...

  8. 基于appium的app自动化测试框架

    基于appium框架的app自动化测试 App自动化测试主要难点在于环境的搭建,appium完全是基于selenium进行的扩展,所以app测试框架也是基于web测试框架开发的 一.设备连接 (即构建 ...

  9. 初识Android App自动化测试框架--Unittest

    1.为什么需要使用框架实现自动化测试 作为测试工程师,可能在代码能力上相比开发工程师要弱一点,所以我们在写脚本的时候就会相对容易的碰到更多的问题,如果有一个成熟的框架供给我们使用的话,可以帮助我们避免 ...

随机推荐

  1. Ubuntu 如何将桌面上的Home中的文件夹除去

    安装Ubuntu后, 由于无法用Terminal(终端)进入带中文的文件夹,会引起很多操作不便.很多朋友想到了将它们都改成中文,但是当再次开机重启使却会发现,原本光洁的桌面现在竟然出现了一堆文件夹?? ...

  2. *15. 3Sum (three pointers to two pointers), hashset

    Given an array nums of n integers, are there elements a, b, c in nums such that a + b + c = 0? Find ...

  3. QT OpenGL中文教程在QT4版本后的错误代码更改(一)

    由于教程中说的已经够可以了,这里就不对代码进行分析了,有兴趣可以自己去看看.这个教程来源于原来的NeHeOpenGL中文教程 (http://www.yakergong.net/nehe/) ,但其有 ...

  4. IOS 打开照相机 打开相册

    /** * 打开照相机 */ - (void)openCamera { if (![UIImagePickerController isSourceTypeAvailable:UIImagePicke ...

  5. Codeforces 760A Petr and a calendar

    题目链接:http://codeforces.com/problemset/problem/760/A 题意:日历需要多少列. #include <bits/stdc++.h> using ...

  6. querystring处理参数小利器

    相信上一章的讲解,相信大家对url地址有一个更直观的认识,在url解析的时候可以用querystring这样一个module替换,然后对这个query集成一个对象,这里不管是前端开发还是后端开发,都常 ...

  7. 继续折腾LNK 2005错误

    这次是因为要把一个很久的老项目改成使用Unicode字符集,又一次遇到了LNK 2005错误 先说说怎么把老项目改成Unicode字符集吧,首先要有足够的信心能把项目改好,比如我这次改的项目,也不算很 ...

  8. Network in Network 笔记

    传统CNN里的卷积核是一个generalized linear model(GLM)之后经过一个sigmoid(现在通常是ReLu)的非线性激励函数,假设卷积有K个filter,那么这K个filter ...

  9. Http之基础

    简介 HTTP协议(HyperText Transfer Protocol,超文本传输协议)是因特网上应用最为广泛的一种网络传输协议,所有的WWW文件都必须遵守这个标准. HTTP是一个基于TCP/I ...

  10. Python爬虫,看看我最近博客都写了啥,带你制作高逼格的数据聚合云图

    转载请标明出处: http://blog.csdn.net/forezp/article/details/70198541 本文出自方志朋的博客 今天一时兴起,想用python爬爬自己的博客,通过数据 ...