The path of "Android test" UI Automation code optimization

Complaints about UI Automation

I've heard a lot of people say, "UI Automation is very unstable, the need to change, the interface once again, all costs." I believe that the people who have done it may agree. Since the problem has always existed, why hasn't anyone carefully analyzed why?

My boss George has given an example: whenever demand changes, development does not jump, instead the test jumps. Then constantly complaining, the interface elements are all changed, and my automated use cases are all discarded. So have we ever wondered why development can be easily broken to respond to the changing needs of products? And we can't?

　　

Many people in the industry have also given up the UI Automation, feel that interface testing is the most meaningful, it is true that interface testing is more stable than UI Automation, but we do not have to test the interface after the UI? UI layer is closest to the user, that is, directly to the user the most direct layer, we really want to give up? In other words, if client-side development is particularly bad at layering, will the client's interface testing be really that good? Press a home button and then come back, OnStop, onresum and other life cycle functions I'm afraid it is difficult to cope with it. Having said that, let's get back to the point and talk about how to write our UI Automation test project. (Note, here is the project, not the script, the script is very casual, write two sentences to test, the project is a can be delivered to the user, we can think that the development of code is we have to pay the user's products, of course, our test code is also to pay the user's products, So the back unified called the test Project)

Crude Test Code

Let's start by looking at how our UI Automation code is written:

　　

Here I use the ESPRESSO+UIAUTOMATOR2 framework for example, ignoring the syntax, only to say that the structure of the word is not familiar with, people at the beginning of the test code should be the same way to do it: in the test function to complete the implementation of all operations, if it is a common operation, It is possible to encapsulate a function and, of course, use the setup to initialize it and use teardown to end it. I would like to say that if this is the case, it is really difficult for us to deal with the changing needs and interface, I am afraid that the testing framework of the replacement, all of our test code to overturn the rewrite. In fact, the combination of our previous code has some problems such as:

1, the use case layer contains too many and source-related content, as long as the source code changes, use case content will be changed.

2, the use case layer directly invoke the original framework content to implement, can not handle some common anomalies, and can not adapt to the change of tool framework.

3. Some common methods (such as login), the use Case (test** () function) in multiple use case sets (**test Class) may need to be reused, and the method of invocation needs to be handled.

4, start activity such operations are not necessary for each use case set is written, you can optimize, abstract out the base class.

So for these places, we need to optimize, and we'll look down.

Keyword driver

Yoyo (GT Development) suggested that I use this set of use case writing scenarios, is based on the keyword-driven scenario, in the use case layer implementation stripping and source code-related parts, using a high degree of abstraction. So as long as the business process is not changed, the interface arbitrarily how to modify, we do not need to modify the use case layer of code. The implementation structure of the entire framework is as follows:

Here if you look at the class diagram a little hard, you can first look at the UML class diagram introduction. Here is a general overview of the role of these class modules:

　　basetest: The base class for all test classes, which is the base class for testing cases, implements activitytestrule to initiate activity and, if necessary, implements Beforeclass and Afterclass, These two are executed only once at the beginning and end of the entire command's run cycle.

　　use casetest: A specific test case implementation class, which can be understood as a test set, each class has a number of test functions, each function represents a test case, the use of a keyword-driven approach.

　　key: All keywords are defined with enumerations.

　　Command: An interface class that is used by word to implement execute (OBJ).

　　Framecommand: The base class, which is inherited by the word layer, encapsulates only one execute (key, OBJ ...), which is used primarily in the AW to invoke the implementation of KW; Here you need to be aware of the difference between execute in the command interface.

　　Word layer : In the diagram, login, enter**page, etc., need to implement the command interface in the Execute function, while inheriting from Framecommand, explaining why the word layer, These implementations need to be abstracted into Actionword (AW), KeyWord (kw), and the difference is that some of the scenarios in KeyWord are implemented in a reusable way, and Actionword can contain KeyWord to implement scenarios that are rarely reused.

　　TestContext: Associates a keyword in key with a specific word-implemented function, constructs a map so that the corresponding function can be called directly from the Execute keyword.

The specific implementation of the code I do not explain in detail, we first look at the use of this framework, before the implementation of the same function code written what it looks like:

　　

As you can see, the test case (where a test*** function is considered a test case) is a high level of abstraction, and there is no information in the Testpublish function that is related to the development of source code or resource ID. Here key.enterpublishpage is our keyword, specifically implemented in Enterpublishpage this AW function, so write use cases, when our interface has changed a lot, such as our version of the iteration from the release of two pages, as follows:

　　

After the new version changes, it is changed to an interface, such as:

　　

Can see the adjustment of the interface element or a lot of, if we may have to discard the previous use case re-write, but using the keyword driver, our use case layer changes do not need to make any changes, and corresponding if the control ID changes, we only need to modify the word layer.

Here is how the AW and kw encapsulation between, on the code level, for the compiler, there is no aw and kw of the points, we abstract these two layers means that when there is a word can be reused by multiple use cases, so we will wrap it up for other word use. Concrete also need in the process of practice slowly experience.

Package Test Framework

After saying the keyword driver, you need to say the package framework this piece. The friends who have read my previous article should know why I choose Espresso and uiautomator, the current Google recommended the use of the two framework, interested to see Google's two original text:

　　

Then two frames added to our test project should be how to integrate the code structure, here I use such a structure, I feel good can refer to, first look at the following class diagram:

　　

After reading the class diagram, some people may have seen it, yes. The Simple factory model is used, and the specific word layer uses the engineered objects, and the specific tool packages are packaged in Frameuiautomator and Frameespresso.

Here is the main point of the package for Uiautomator, if you have read my written "How to Organize your test code", then some of the ideas should be more clear, the main advantages are:

1. Page jump or asynchronous load delay interface, no need to use sleep alone;

2, for the system randomly appear may affect the app interface some factors (such as Android6.0 's authorization frame, call incoming), no need to separate processing;

3, for the application of random appearance may obscure the normal interface of some of the frame, no need to deal with the separate;

4, all calls the package after the framework operation, will record the log;

5, the framework itself has the ability to assert, if the framework to handle abnormal conditions can not find the specified control, this time will and assert;

6, if you need to replace the framework or framework upgrade, you can use the minimum cost to change the framework layer, without the need to change the use case layer and the word layer.

Refine other content

The above is mainly about the UI automation of some behavioral operations, about the assertion of the problem, I do not want to say too much, bTV do interface UI elements of the check, and whether the entire process can be complete to go down, if you need to verify the correctness of the data and other complex content, you can refer to my written " The app is at your mercy (the introduction of reflective technology). Let me talk about it. If UI Automation fails, how do we troubleshoot the problem? Actually very simple I do here is the log +.

The most critical of the log system is the timing of the log, where I bury it in Basetest's execute (), so that every time use case calls AW or aw to call KW, can be recorded, but also buried in the framework of the specific implementation function, so that the framework as long as the operation will record the log. Here's a little tip, I called the following function where I printed the log:

String classname = Thread.CurrentThread (). Getstacktrace () [3].getclassname ();

This allows you to record the name of the current class that called the log function, where I can look at the log I'm outputting:

　　

is more complete, basically all the information you want to know can be obtained through the log content. The following is the same as the overall idea of log, it will be in some key nodes buried at the same time also support the manual call. Because my tool framework supports my own assertions, I will join in the assertion of the tool framework layer, and you can invoke triggers manually if you need special attention in other areas.

　　

The above figure is not very intuitive, when our use cases are abnormal errors, directly through the log and logs can be located to the problem.

Results show

The results of the test are finally connected to the internal continuous integration platform and the result display platform, which looks like this:

　　

This ensures that the results in the compiler are consistent with those shown in the results display platform.

Talk with practice

The speed of iteration of Internet products is fast, you all have deep experience. As a guarantee of product quality, testers often worry about the lack of testing time, how to break the status quo to make it better now, this is the problem we have been thinking. In software engineering, it is mentioned that the sooner a tester is involved in the process of research and development, the sooner the problem can be identified, thus reducing the cost of discovering the problem. So the "left shift" becomes very necessary, of course, there are many ways to move left, such as the last few days to read the "Talk test" left to move "those things" this is mainly said testers by the control needs to achieve the effect of left shift, and I mentioned above can help automate the implementation of the left shift.

Think about how the UI Automation we did before was done? After the release, we started writing automation so that the main functions of automation became regression and smoke. What I want to say here is that when we develop code, we also start to write use-case level code, after the development of the interface layout, we can improve the specific code, when the development of the survey, we can run our use cases to test.

Of course the new and old versions may be slightly different:

If it is the case of new requirements, we can first organize their own use cases in the case of requirements determination, the specific implementation of the development-dependent Word layer code can be empty first, after the development of the determination, we can timely improve our word layer, so do not wait until the development of the test, We are only beginning to design our automated test cases.

For the old demand change, also, the first can look at the previous use cases of the key words are reusable, if you can directly reuse, then continue to use, if there are new steps added, then only need to add the corresponding keywords, and the new requirements of the same approach, the same in the development of the use of test cases before the completion of the writing.

In fact, I was thinking about it before the whole project started. So will this make a profit? Because after all, the whole system is not an easy thing to do, it takes a lot of time cost to go in. So where does the analysis of revenue begin? I decided to start with a bug, so I made a simple bug analysis for the latest version:
　　
As you can see from the data, there are some bugs that can be found in the left shift phase. Here are the use cases for the BVT level of use cases and detailed modules. BVT level use cases to limit the development of the test, before the development of their own to exercise this part of the use case, to be able to be measured; the contents of the detailed modules for the specific functional level are modified or added to the new features specifically for this release.

This is what this section wants to say to you, the whole process, whether it is the benefits of the project or its own growth, I have received goods, and to share with you, hoping to help others.

Category: Software Testing

The path of "Android test" UI Automation code optimization