Android Automation Framework

Android Automation Framework

has been read 2,085 times 2014-8-26 12:19 | Android

Several common Android automated testing frameworks and their applications

As Android applications become more widespread, more and more companies are launching their own mobile application testing platform. For example, Baidu's MTC, Neusoft easy-to-measure cloud, Testin cloud testing platform .... As the project team is to do terminal testing tools, so the time to understand the next several common UI-based automated testing tools. Take advantage of the evening to summarize, good mind is not as bad as the written!

A common Android automated testing framework and its application

At present, the Android UI-based automated testing tools can be understood to be based on the Android control level, involving widgets and WebView two major categories. The main test methods are as follows. One is to get the view information of the current window through various services provided by Android. The target control is then found within the current view, and the coordinates of the control's center point are computed based on the control's property information, and an Android input event is constructed to enable automated testing of the application. The main features are: The test code and the application are running in their respective processes, independent of each other. Its representative has uiautomator. The other is based on the instrumentation, by putting the test code and application code, specifically the test apk and the tested APK, running in the same process, through the Java reflection mechanism, to get all the views of the current window, and based on the view to find the target control's property information, and calculates the center point coordinates of the target control. Then, the instrument internal interface is used to achieve the click operation. Its representative has robotium.

Let's look at the first one first. Such methods usually need to meet two functions, one is to get a screen view, and the other is to generate input events. This allows the user to find the target control through a screen view, and then calculates its center point coordinates, resulting in an input event to simulate the user action. Typically, this type of framework provides a screenshot feature for user-friendly comparison. For example, analyze location problems, and so on.

At present, the common application patterns of this kind of test methods are as follows: (1), Hierachyview+monkey, (2), Uiautomator, (3), Accessibilityservice. (4) Other. First of all, the Hierachyview+monkey combination.

Let's start with the first kind, hierachyview+monkey. The implementation principle is as follows:

First, the Hierahcyview connects to the device side viewserver via the socket and the port is 4939. Second, the control property information is obtained by command "Dump-1". The information is deposited in Viewnode. Thirdly, according to Viewnode information, traverse the control tree, find the target control, and calculate its center point coordinates according to its bounds information. Finally, according to the calculated coordinate information, send a click on the point of the Monkey command to the device side of the monkey service. In addition to the click operation, we can also through the Monkey service input, hard key class operation. Thus, an automated operation of the device is completed. It should be explained here that most of the commercial mobile phone Viewserver services require system permissions to open. Therefore, the use of this mode, the phone generally requires root authority. In addition, there is an article on HIERACHYVIEW,CSDN on the Hierachyview implementation principle, the connection address is as follows:

Http://www.cnblogs.com/vowei/archive/2012/08/08/2627614.html. It now extracts some of its content, about the process of getting the control hierarchy diagram from the device side viewserver, so that you can better understand the pattern.

Hierachyviewerdirector.java (that is, controller) communicates with Android devices through Devicebridge.java, and Devicebridge.java is specifically through Androiddebugbridage.java and Deviceconnection.java to communicate with the device. Note: The Hierachyview itself uses the MVC pattern.

AndroidDebugBridge.java:AndroidDebugBridge.java is the ADB API, located in the Ddmlib project. It implements the command line version of the ADB-like function, in the hierarchyviewer mainly used in its connection device, forward port, start viewserver and other operations.

Deviceconnection.java: Responsible for communicating with Viewserver, sending the command to Viewserver and accepting the information it returns. This gets the activity list, the control hierarchy chart, and so on.

The second mode of application is Uiautomator. Uiautomator is a set of automated frameworks Google has modeled on Microsoft UIAutomation, based on Android Accessilibilityservice (note: Android Accessilibilityservice , is an accessible service, an application that enhances the user interface and helps disabled users, or the user may not be able to fully interact with the device. For example, the user is driving. Then the user may need to add additional or alternative user feedback methods. There are several ways to apply them, one is Uiautomatorview+monkey, the other is to call the Uiautomator API directly. The first method is similar to that of Hierachyview+monkey. The difference is that Uiautomatorview sends a dump command to the device side via ADB instead of creating a socket to download an XML file that contains the layout information for the current interface control. This file is much smaller compared to what hierachyview downloads. Thus, in terms of efficiency, this method is much faster than the first application pattern. The second method is to directly invoke the Uiautomator framework to provide external APIs, mainly Uidevice, Uiselector, UIObject and so on. Its principle and the first way, namely Hierachyview+monkey, is similar. The process is basically: first, the Uiautomator test framework obtains the control hierarchy and property information for the current window through Accessibilityservice, and finds the target control. If you click an event, the center point coordinates of the control are calculated. Second, uiautomator through the test framework, inject user events (click, input Class Operations), so as to achieve the simulation of human operations. Uiautomator provides Uiautomatortestcase, Uidevice, Uiselector, UiObject, Uicollection, uiscrollable and other categories, and its functions are as follows:

L Uiautomatortestcase: Inherited from JUnit TestCase (junit), providing external setup, teardown, etc. to initialize the use case, clear the environment, etc.

L Uidevice: This class mainly contains the acquisition of device status information, and analog users as to the operation of the device two types of APIs. Uiselector, mainly through a certain query way, to navigate to the UI elements to manipulate.

L Uiobject:uiobject can represent any element of the page, and its various property positioning is usually done by Uiselector.

L uicollection:uicollection is generally associated with uiselector, as its constructors also require uiselector:uicollection (Uiselector selector). It has fewer APIs and is used primarily to pick out the elements from the uiselector filtered elements: Getchildbydescription (), Getchildbyinstance (), Getchildbytext (), and the number of statistical element sets Getchildcount ().

L uiscrollable:uiscrollable is used to represent interface elements that can be slid, and their inheritance is UIObject, Uicollection->uiscrollable.

But the way of realization of uiautomator is very different from that of Hierachyview+monkey. Take the control click action as an example, the implementation process is as follows:

Defines a Click Object, which is anchored to a specific control through the Uiselector object. The Uiselector is Uiautomatorbridge (it can be seen as a connector between Uiselector and Accesibilityservice), Pass the query content (accessibilitynodeinfo) and input events (accessibilityevent) to Accessibilityservice. The actual business process is much more complicated than this. In this way, you implement a Find or click operation on a control. Note: Accessibilityevent, all the UI elements that can be manipulated are defined as a accessibilityeeventt;accessibilitynodeinfo of the component tree nodes in the window.

The third type is accessibilityservice. First to introduce the next Accessibilityserveice service. As has been said before, it is a service for Android. If we use Accessibilityservice for automation, we need to inherit accessibilityservice to develop a service. This allows us to obtain control property information for the current interface based on this service. Its access to content is the same as Uiautomator, are accessibilitynodeinfo. After the control information is obtained, if you want to click and so on, you can use monkey or other means, such as input, to simulate the click action.

Of the above several Android test methods, Uiautomator is more orthodox, Google is officially launched, but also the widest range of applications. Several other methods, it is not seen much, of which Hierachyview+monkey way, the company's internal Ares adopted. One of the benefits of such a test tool is that it can be applied across applications. But there are many shortcomings, slow, not support webview, etc. (this mode, the WebView control is limited, unable to inject Java Script).

Next, the second framework, instrumentation, is the core of a series of testing methods that Android provides externally. Instumentation can be seen as a collection of control functions that are used between systems and applications, similar to hooks in Windows. Under this test framework, the main program and the test program need to run in the same process, see (Image source Csdn, link address: http://blog.csdn.net/jayfei0308/article/details/7950052).

It should be explained that in Android, the test program is also an application, and we can consider it as an application without a UI.

The implementation process is roughly the following: Instrumentationtestrunner the application by calling instrumentation to kill the application, and then using instrumentation to restart the app. At this point, the test application and the tested application run under the same process. How does the test application know which application to test? Well, this is done by adding <Instrumentation> elements to the Mainfest file in the test project. When the test application and the tested application are running in the same process, they can communicate with each other through instrumentation to achieve the test result. When instrumentation interacts with a program, it generally takes the following steps: (Source:

http://blog.csdn.net/fireworkburn/article/details/20144153).

First, when you start, initialize the test apk profile in the Androidmanifest.xml file. The configuration file identifies the test run class used, the target application being tested, the package name, and so on. Then, activate the activity of the application under test. At the same time, the test activitythread is initialized as a reference. At this point, an error occurs if the target app is not found. Second, execute the test script. During the test, any action on the target application in the test project will be asynchronously used to place the message body in the MessageQueue of the target program. In this way, the target program executes when it checks to see what is in its MessageQueue.

There are a lot of test tools developed based on Android Instrumentiaon, the most famous of which is probably the number of robotium. At present, many mobile application test platform on the network, such as the Baidu Mobile application test platform MTC, all support Robotium.

TestCase inheritance relationship of two kinds of Android test tools

Android offers a lot of testing tools, such as Monkey, instrumentation, uiautomator. There are also many test tools, such as Robotium and Espresso, which are developed two times based on Android test tools. Their inheritance relationships:

The Uiautomator TestCase class inherits from the TestCase class of JUnit. The Robotium and espresso inherit from ActivityInstrumentationTestCase2. From this inheritance, we can also understand why the use of Robotium, the application needs to sign. The use of uiautomator is not required. The reason for this is: in a robotium way, the test code is essentially an APK. Depending on the security mechanism of Android, the application needs to be signed.

Three common Android Automation framework pros and cons relationship

Here we mainly introduce the advantages and disadvantages of several test tools, including Hierachyview+monkey, Uiautomator, Robotium.

	Hierachyview+monkey	Uiautomator + Monkey	Robotium
Permissions	Root	Ordinary	Ordinary
Whether a signature is required	Is	Whether	Whether
Response speed	10s (user test data)	4s (user test data)	1-2s
Whether to support WebView	Whether	Whether	Is
Whether to support cross-app testing	Is	Is	Whether
Android APIs that support this feature	?	API 16	API 7
Whether the control ID is supported	Is	Whether	Is

From the above data, Android provides testing tools have advantages and disadvantages, some support webview testing, and some do not support. Some support cross-application, some do not support. Therefore, a good Android test tool is more compatible with the above several test methods. For example, Appium.

Android Automation Framework