[ZZ]Android UI Automated Testing
Google Testing Blog最近发表了一篇Android UI Automated Testing,我把他转载过来,
墙外地址:http://googletesting.blogspot.com/2015/03/android-ui-automated-testing.html
译文见这里:http://testerhome.com/topics/2276
Android UI Automated Testing
by Mona El Mahdy
Overview
This post reviews four strategies for Android UI testing with the goal of creating UI tests that are fast, reliable, and easy to debug.
Before we begin, let’s not forget an import rule: whatever can be unit tested should be unit tested. Robolectric and gradle unit tests support are great examples of unit test frameworks for Android. UI tests, on the other hand, are used to verify that your application returns the correct UI output in response to a sequence of user actions on a device. Espresso is a great framework for running UI actions and verifications in the same process. For more details on the Espresso and UI Automator tools, please see: test support libraries.
The Google+ team has performed many iterations of UI testing. Below we discuss the lessons learned during each strategy of UI testing. Stay tuned for more posts with more details and code samples.
Strategy 1: Using an End-To-End Test as a UI Test
Let’s start with some definitions. A UI test ensures that your application returns the correct UI output in response to a sequence of user actions on a device. An end-to-end (E2E) test brings up the full system of your app including all backend servers and client app. E2E tests will guarantee that data is sent to the client app and that the entire system functions correctly.
Usually, in order to make the application UI functional, you need data from backend servers, so UI tests need to simulate the data but not necessarily the backend servers. In many cases UI tests are confused with E2E tests because E2E is very similar to manual test scenarios. However, debugging and stabilizing E2E tests is very difficult due to many variables like network flakiness, authentication against real servers, size of your system, etc.
When you use UI tests as E2E tests, you face the following problems:
*Very large and slow tests.
*High flakiness rate due to timeouts and memory issues.
*Hard to debug/investigate failures.
*Authentication issues (ex: authentication from automated tests is very tricky).
Let’s see how these problems can be fixed using the following strategies.
Strategy 2: Hermetic UI Testing using Fake Servers
In this strategy, you avoid network calls and external dependencies, but you need to provide your application with data that drives the UI. Update your application to communicate to a local server rather than external one, and create a fake local server that provides data to your application. You then need a mechanism to generate the data needed by your application. This can be done using various approaches depending on your system design. One approach is to record server responses and replay them in your fake server.
Once you have hermetic UI tests talking to a local fake server, you should also have server hermetic tests. This way you split your E2E test into a server side test, a client side test, and an integration test to verify that the server and client are in sync (for more details on integration tests, see the backend testing section of blog).
Now, the client test flow looks like:
While this approach drastically reduces the test size and flakiness rate, you still need to maintain a separate fake server as well as your test. Debugging is still not easy as you have two moving parts: the test and the local server. While test stability will be largely improved by this approach, the local server will cause some flakes.
Let’s see how this could this be improved...
Strategy 3: Dependency Injection Design for Apps.
To remove the additional dependency of a fake server running on Android, you should use dependency injection in your application for swapping real module implementations with fake ones. One example is Dagger, or you can create your own dependency injection mechanism if needed.
This will improve the testability of your app for both unit testing and UI testing, providing your tests with the ability to mock dependencies. In instrumentation testing, the test apk and the app under test are loaded in the same process, so the test code has runtime access to the app code. Not only that, but you can also use classpath override (the fact that test classpath takes priority over app under test) to override a certain class and inject test fakes there. For example, To make your test hermetic, your app should support injection of the networking implementation. During testing, the test injects a fake networking implementation to your app, and this fake implementation will provide seeded data instead of communicating with backend servers.
Strategy 4: Building Apps into Smaller Libraries
If you want to scale your app into many modules and views, and plan to add more features while maintaining stable and fast builds/tests, then you should build your app into small components/libraries. Each library should have its own UI resources and user dependency management. This strategy not only enables mocking dependencies of your libraries for hermetic testing, but also serves as an experimentation platform for various components of your application.
Once you have small components with dependency injection support, you can build a test app for each component.
The test apps bring up the actual UI of your libraries, fake data needed, and mock dependencies. Espresso tests will run against these test apps. This enables testing of smaller libraries in isolation.
For example, let’s consider building smaller libraries for login and settings of your app.
The settings component test now looks like:
Conclusion
UI testing can be very challenging for rich apps on Android. Here are some UI testing lessons learned on the Google+ team:
1.Don’t write E2E tests instead of UI tests. Instead write unit tests and integration tests beside the UI tests.
2.Hermetic tests are the way to go.
3.Use dependency injection while designing your app.
4.Build your application into small libraries/modules, and test each one in isolation. You can then have a few integration tests to verify integration between components is correct .
5.Componentized UI tests have proven to be much faster than E2E and 99%+ stable. Fast and stable tests have proven to drastically improve developer productivity.
[ZZ]Android UI Automated Testing的更多相关文章
- Android UI性能测试——使用 Gfxinfo 衡量性能
Android官方文档翻译 原文地址:https://developer.android.com/training/testing/performance参考:https://www.jianshu. ...
- Android测试:Testing Apps on Android
原文:https://developer.android.com/training/testing/index.html 测试你的App是开发过程中的重要组成部分.通过对应用程序持续的运行测试,你可以 ...
- 【转】Automated Testing Detail Test Plan
Automated Testing Detail Test PlanAutomated Testing DTP Overview This Automated Testing Detail Test ...
- iPhone/iPad/Android UI尺寸规范 UI尺寸规范,UI图标尺寸,UI界面尺寸,iPhone6尺寸,iPhone6 Plus尺寸,安卓尺寸,iOS尺寸
iPhone/iPad/Android UI尺寸规范 UI尺寸规范,UI图标尺寸,UI界面尺寸,iPhone6尺寸,iPhone6 Plus尺寸,安卓尺寸,iOS尺寸 iPhone界面尺寸 设备 分辨 ...
- Android ui 测试课堂笔记
开始接触Android ui测试了,笔记如下 模拟器 Genemotion , the fastest android simulator in the world Android ui 测试工具 S ...
- Android UI 绘制过程浅析(五)自定义View
前言 这已经是Android UI 绘制过程浅析系列文章的第五篇了,不出意外的话也是最后一篇.再次声明一下,这一系列文章,是我在拜读了csdn大牛郭霖的博客文章<带你一步步深入了解View> ...
- 12套有用的免费 PSD 格式 Android UI 素材
在这里,我们向大家呈现一些有用的和免费的 Android 用户界面 PSD 素材.由于 Android 市场迅速增长,设计人员和开发人员正在寻找一些快速和容易的方法来创建 Android 友好的应用和 ...
- Android UI线程和非UI线程
Android UI线程和非UI线程 UI线程及Android的单线程模型原则 当应用启动,系统会创建一个主线程(main thread). 这个主线程负责向UI组件分发事件(包括绘制事件),也是在这 ...
- 免费的Android UI库及组件推荐
短短数年时间Android平台就已经形成了一个庞大而活跃的开发者社区.许多社区开发的项目业已进入成熟阶段,甚至可以用于商业的软件生产中,且不用担心质量问题. 本文编译自androiduipattern ...
随机推荐
- 一个SpringMVC简单Demo中出现的错误
最近在学springmvc 一个简答的Springmvc配置包括如下步骤: 1.在 web.xml 文件中配置 DispatcherServlet (该中央控制器相当于 MVC 模式中的 C),还可以 ...
- [转载]hashmap hashtable 的区别
Hashtable 和 HashMap 做为 Map 的基本特性 两者都实现了Map接口,基本特性相同 - 对同一个Key,只会有一个对应的value值存在 - 如 ...
- Linux 安装 Nginx
1. nginx的安装: 开始学习如何安装nginx,首先安装必要的软件: # yum install libtool # yum install -y gcc-c++ # yum install z ...
- Python for循环内部实现的一个sample
#!/usr/bin/env python # -*- coding: utf-8 -*- it = iter([1,2,3,4,5]) while True: try: x = next(it) p ...
- FPSCalc——简单FPS观测类
利用Unity做的手游项目很多时候要保证流畅度,流畅度最直观的表现就是帧率FPS.Unity编辑器模式下的帧率观测几乎没有意义,所以还是自己实现的好. 这里给一个前人写的类,我几乎原封不动,该类只有一 ...
- offset笔记
1.offsetParent 2.offsetTop 3.offsetLeft 4.offsetWidth 5.offsetHeight offsetWidth是元素的可视宽度,这个宽度包括元素的边框 ...
- JavaScript this特性,静态方法 和实例方法,prototype
<script type="text/javascript"> function logs(str) { document.write(str + "< ...
- .NET 面试题整理
概念类 请你说说.NET中类和结构的区别? 答:结构和类具有大体的语法,但是结构受到的限制比类要多. 结构不能申明有默认的构造函数,为结构的副本是又编译器创建和销毁的,所以不需要默认的构造函数和析构函 ...
- File存储 - 文件存储
博客地址 http://www.cnblogs.com/mmyblogs/p/6107472.html(转载请保留) 文件存储 文件存储是 Android 中最基本的一种数据存储方式,它不对存储的内容 ...
- iOS设计模式之工厂方法模式
工厂方法模式 基本理解 工厂方法模式:定义一个用于创建对象的接口,让子类决定实例化哪一个类.工厂方法使一个类的实例化延迟到其子类. 简单工厂的最大优点就是工厂类中包含了必要的逻辑判断,根据客户端的选择 ...