The simplest practice of cross-process operations in Robotium in history -- Based on the ADB framework, robotiumadb

The simplest practice of cross-process operations in Robotium in history -- Based on the ADB framework, robotiumadb

Original Author, not easy to share, please indicate the source for reprinting, thank you.

Robotium is an excellent automated testing framework on the Android platform. The advantages of its automation on the android platform must be clear to anyone who has read this article. However, there are many advantages and disadvantages. The two most obvious disadvantages are: first, they must be consistent with the tested system signature, and second, they cannot perform any cross-process operations.

 

Many of our friends know how to use robotium, and they know that it has these restrictions, but they do not know the reasons. Here, the main reason for these inherent defects of robotium is that it is based on the instrumentation mechanism, which has both advantages and disadvantages. The advantage is that the instrumentation is injected into the tested process and runs in the same process space as the tested process, so that it can easily identify the tested objects in the tested application, and perform operations on these objects. The disadvantage is that, since robotium has already been integrated with the tested application, it is naturally isolated from other processes by the system based on the android process isolation mechanism and cannot operate any objects across processes, (1.

 

Figure (1) Android process sandbox

 

In fact, using the same signature is not difficult for the test of a single application. There are many methods and tools on the Internet that use the same signature for your use. However, the inability to perform cross-process operations has indeed become the biggest weakness of robotium. Many third-party application tests have more or less some cross-process operation test scenarios, so many people have abandoned robotium due to this problem, it's a pity.

 

As one of robotium's hardcore fans (I first came into contact with android automated testing and used robotium), it has been used intermittently for several years and has always been regarded as one of the best automated testing tools for the android platform. I have also done some research on how robotium breaks through the process restrictions. Many online solutions are similar to the following:

1. write services as servers by yourself, communicate with monkeyserver Based on AIDL or write socket, and call interface methods in the robotium test script to indirectly perform cross-process operations, for more information about this method, see http://www.robotium.cn/archives/584. The author of this article only gave me some ideas. I have implemented this method myself and found that the advantage of this method is relatively stable. The disadvantage is that it is indeed complicated to implement, in addition, some operations cannot be performed through the existing system aidl interface, such as calling the photo taking operation. In fact, there are not many examples and there are many technical limitations.

2. Based on broadcast and service services. For more information about how to implement this method, see explain. I have not tried this method myself, but it is not difficult to find that this method is a little simple. However, this method seems to require a system signature and write broadcast and service to call the system api, this method is not difficult, so it is generally not recommended.

 

In fact, the above cross-process solutions are not ideal. For many beginners, it is not too difficult to implement, but the limitations are relatively large. They have never found an ideal solution. It was not until later that we saw a very powerful technical brother on testerhome who made a very complete encapsulation of the commonly used adb commands (PS: It is really full, at least the commonly used adb commands are all there, I didn't even think that the adb command could do so many things before.) I made an independent test auxiliary tool. I suddenly wondered why I couldn't use the adb command to assist robotium in cross-process operations? Since the framework has encapsulated all the operations based on adb, and adb is not subject to system restrictions, there is no problem in conducting cross-process operations based on this framework theoretically. After tests, the results were really good, lightweight, simple to operate, easy to use, and easy cross-process. It was really a must-have tool for home testing and yundun attacks. Well, I will not talk much about it. Next, let's take a detailed look at how to use it.

 

First, we will briefly introduce the common interfaces of this adb command framework. There are three major packages in this framework, which are described as follows:

 

Xuxu. the autotest package contains two main classes: AdbDevice, which encapsulates some common operations in function testing, for example, it is very useful to obtain the name and package name of the current activity, get the device resolution, disable the application, and click an object. The other class is XuImage. as its name implies, it encapsulates some common image operations, such as obtaining images with the specified boundary, comparing images with the same image, and capturing images.

 

Xuxu. autotest. the element package is mainly used to obtain the object to be tested. It encapsulates a Position object and is used to obtain a tested object through attributes such as Class Name, Id, and Contentdesc, at the underlying layer, the system uses uiautomator to dump the xml file of the current ui and obtains the xml file of all object nodes.

 

The xuxu. autotest. utils package mainly provides Date and Time operations. ImageUtil encapsulates image operations, regular expressions, and shell statements for your convenience. In general, the interface design of the entire framework is still very complete, and many common functions can be implemented. For specific functions, you can refer to the source code and help documentation for exploration.

 

Next we will go to our topic-Cross-process. To facilitate your understanding, I will select two very common cross-Process Operation scenarios in this article to illustrate how to cross-process, that is, what you like.Camera photoAndCall.

 

Example 1: take a photo with a cross-process camera.

The tested program is very simple. The program interface is shown in (2:

Figure (2)

 

Click the "take photo" button on the first page to Go to page 2. Click "Take a photo" to start the System camera. When you press the photo button, the system can display users' photos in applications for later browsing or uploading. Because the camera application and the tested application are two different applications, this is a typical cross-process operation. The Robotium framework itself cannot operate on this camera interface.

 

Next, let's take a look at how to create a key test project. The method for creating a test project is very simple. The procedure is as follows:

1. First, create a general test project according to the method of creating a general android test project.

2. Introduce the jar packages of robotium and adbForAndroid in the project.

In this way, our test project is ready.

The next step is to write the test script. Because the AdbForAndroid framework searches for and locates the objects to be tested based on the relevant attributes of the elements, it is necessary to first find out the information of the objects on the Cross-process interface to be operated, we can use many ready-made tools to see this information. Here I choose the uiautomatorviewer that comes with android. First, manually open the program to be tested on the simulator, go to the camera page for taking the photo, and use uiautomatorviewer to view the Interface Element Information, as shown in (3:

Figure (3)

 

We can see that the attributes of the photo button to be clicked are all displayed in the list in the lower right corner of figure (3. Which one should we choose? This problem depends on the attributes that the adbForAndroid framework supports to obtain elements. By querying its help documentation, we know that the common methods for searching elements in this framework are as follows:

• FindElementByContentdesc

• FindElementByClass

• FindElementByText

• FindElementById

Because the current Simulator version is 4.2.2, uiautomatorviewer cannot display the id attribute. If you use version 4.3 or later, you can see the id attribute of the element.

 

In this case, we 'd better select the Contentdesc attribute to locate the object. The Code is as follows:

Element element = position. findElementByContentdesc ("Shutter button"); adbDevice. tap (element); // click the photo button

OK. After you click the photo button, the photo taking function will also allow you to choose whether to confirm or cancel the operation, as shown in (4:

Figure (4)

As a result, we know through the query that this "√" button is used to determine, and its attribute can be used to locate only the class attribute. However, it should be noted that at this time, because we use the class attribute, you can see that the class attribute on the interface is the same as the object we want to click "√, therefore, we must use the findElementsByClass method. This method returns an ArrayList <Element>, so we can write the following code to obtain a list of all the elements whose class attribute is "android. widget. ImageView.

ArrayList<Element> imageViews =position.findElementsByClass("android.widget.ImageView");

Okay. Now the question is, which index in the array is the corresponding "√" button we want to click? After the experiment, I found that when multiple identical elements on the interface are returned to the array, the corresponding element position is from top to bottom, from left to right, according to the position on the interface, therefore, the index of the button to be clicked should be 4. The code for clicking it is as follows:

AdbDevice. tap (imageViews. get (4); // 2 is x, 3 is a remake, and 4 is √

After the above Code is run, the interface will return to our tested program, and the subsequent operations will no longer need to be mentioned. Can you see if it is very simple?

 

Example 2. Cross-process call

With the foundation of the first example, the second example is actually well implemented. The tested procedure is very simple, as shown in (5:

Figure (5)

After you click "Call this number", the system automatically enters the dialing interface, which is also a typical cross-process test scenario.

 

The implementation method is the same as in Example 1. First, use uiautomatorviewer to view the object information on the interface, and then use the corresponding method to operate the object. In addition, in this example, I also demonstrated another situation, that is, some cross-process operations require not only operations, but also some object attributes for verification, this is also basic. Here I will provide my test code (slightly encapsulated ):

Public boolean CallUtil (String callNumber) {Element element; boolean result; // verify whether the correct number is called if (callNumber. length () = 11) {// normal number needs to be converted to the format of x xxx-xxxx StringformatCallNumber = callNumber. substring (0, 1) + "" + callNumber. substring (1, 4) + "-" + callNumber. substring (4, 7) + "-" + callNumber. substring (7, callNumber. length (); element = position. findElementByText (formatCallNumber); try {Thread. sleep (200 0); // thread sleep for 2 seconds} catch (InterruptedException e) {e. printStackTrace () ;}} else {element = position. findElementByText (callNumber); // numbers in other formats are not converted except normal numbers.} if (element! = Null) {result = true;} else {result = false;} element = position. findElementByContentdesc ("End"); // call if (element! = Null) adbDevice. tap (element); return result ;}

Well, the entire process is very simple. I believe that robots can be used with kids shoes without any problems. All the code is easy to use and easy to understand.

 

I believe that through the previous examples, we can find that this is the "most simple in history" Robotium cross-Process Operation solution. I don't expect anyone to disagree with it. This is not an exaggerated fact or an eye-catching figure, it is really simple and powerful. I don't need to talk about anything else. Finally, let's summarize the framework:

Advantages:

1. It is indeed very comprehensive. It basically encapsulates all the Common commands of adb. It is an adb command.

2. The framework interface design is clear and easy to understand. It is easy to use and encapsulated into a jar package. In addition, I hope everyone can look at its source code and understand its implementation details. The author has encapsulated it well and is worth learning, not just simply using it.

3. root permissions are not required. In fact, this is very important. Some companies do not have the root permission for testing machines, so it is very convenient to use adb. It is a very practical framework for children who do not want to give up robotium and have cross-process operation requirements.

 

Currently known deficiencies:

1. the mobile phone version must be later than 4.1, that is, the mobile phone that supports uiautomator must be supported at least, because the underlying layer of the framework itself depends on uiautomator to dump the xml file of the object layout, finally, you can get the coordinates of the object for operations. Therefore, if your mobile phone version does not support uiautomator, you cannot perform the dump operation.

2. Some objects cannot be identified or operated by uiautomator, of course, this framework is powerless. For example, the objects in the notification message bar at the top of the screen cannot be displayed and identified by all tools. This is certainly no way. In addition, the buttons on the keyboard are displayed when text is input, it cannot be identified. You can try it.

 

Improvements to be made in the future:

1. I personally think there is a curve to save the country for the support of the mobile phone version. That is, We Can slightly modify the source code and add the code to determine the mobile phone version. If the current mobile phone version is higher than 4.1, we can directly use uiautomator to dump. if the version is lower than 4.1, read the xml file exported to the specified position on the PC in advance. In this case, if the mobile phone you are using is not a version later than 4.1, you only need to first dump the tested app to a specified path on the PC using a mobile phone of Version 4.1 or later through uiautomator. The effect should be the same, as long as the object coordinates are obtained, OK is obtained.

2. Add some more practical functions. For example, we can search for objects based on text, but in fact we may get objects many times, but we want to get other attributes of objects through this object, we recommend that you add methods like getXXXXByElement (Element e). If you have time, try it.

 

The above are just some of my personal ideas. If you have any other suggestions, you are welcome to come up with them to improve this very practical framework.

 

Finally, I would like to thank the author of the AdbForAndroid framework: xuxu.

Framework source code github address: https://github.com/gb112211/Adb-For-Test

Download the sample project Source Code (including the tested and tested programs) in this article.