APP Automation Test Package Structure mode

Original source http://www.toutiao.com/a6268089772108333314/

Have done UI Automation test classmate, will deeply experience a few pain points: the maintenance amount is big, the adaptation quantity is big, the writing code is huge and so on. Based on these problems, everyone will think of abstract encapsulation common common methods, the students who have programmed the program know, how to improve the speed of programming, that is a set of their own familiar and useful library of functions, so programming is a lot like building blocks game, you can quickly build programs. Based on this we have designed the first package structure pattern, as shown in:

From the above structure, it is not difficult to find the application base library is more messy, no classification. If you write your own remember to live, if handed over to others, it seems very bad, others do not want to go to see. Then, the problem that needs to be solved is how to classify more reasonable.

From the test object based on the UI test, we test the object for each activity, then we can use the activity to classify. First, each activity has its own proprietary method, such as the dial-up interface, there will be input numbers, dialing, delete numbers and other functions, we divide each activity into a separate class, the class inside the activity involved in the method is written to provide the use case call, such as the properties of the dial-up interface and the basic decomposition of functionality.

Based on the above activity encapsulation mode, we also need to add a layer of activity function library in the structure, then the new structure diagram is as follows:

Here are a few of the activity's query methods. [LG1]

Method 1: Obtain the manifest file from the development

Method 2: Use the command to query all the activity of the app

ADB Shell Dumpsys Packages < package name >

Method 3: Query the activity at the top of the current activity stack, recommend this method

ADB shell Dumpsys Activity

Find top of stack activity

[LG1] These query methods to do another comparison?

Method 4: Find focus activity

ADB Shell Dumpsys Activity | Find "Mfocusedactivity"

Simplifying Search characters

ADB Shell Dumpsys Activity | Find "MF"

The above method, the quickest is the method four can immediately know the current page information, the most comprehensive is method 1 and Method 2, which method needs to be based on the actual use of the choice.

We have previously introduced a common approach based on the same layout. We put common common methods in common libraries and put each interface method in a class for each individual interface. Here's a look at the basic basic class diagram:

After all the methods are cured, writing the use case becomes a building block game, which can quickly build the necessary use cases. The logic of use case is written in use case, the data of use case is separated out and written in the corresponding activity class. In this way, the main maintenance of the existing various activity within the method and data.

Finally, the use case structure is abstracted into a standard framework layer theory according to the function, which makes it easier for us to understand and understand.

Based on this framework, the basic invariant layers are: layout layer, component layer, general layer. The interface layer will be maintained by changes in the interface. Special attention is paid to the universality of functions, the parameters of functions, the various overloaded functions, and all kinds of abnormal situations which need to be considered and avoided. As a general method, in order to ensure that function calls do not have problems, but also need to test, we must write a use case to test these methods, imitate unit test method to check the availability of these common methods, stability, reliability, so as to ensure the application of change, When the Android version changes, it can quickly find out which functions are incompatible, make timely changes to ensure the normal operation of the business.

All methods of the interface layer are designed based on the interface, and the actual use cases are composed of these interface methods. When the version changes only need to re-implement the interface re-change, the use case only need to transform the instantiated class to complete the switch case. In this way, the fixed steps of the use case can be used without change, only changing the contents of each block.

The following points are summarized as follows:

• Reasonable encapsulation method to optimize engineering structure

• Component of

• Layout of

• interface of

• interface of

APP Automation Test Package Structure mode