First, packaging method1. How to program more and more quickly:first of all, the need for experience, knowledge is broad. Second, every skilled programmer will have a library of their own, to solve various problems, a variety of common method functions. in the same vein, automation scripts are also programming, test cases are requirements, UI Automation is easy to write, but the interface changes fast and maintenance is huge. So encapsulating the general method is the quickest and easiest way. 2. Which methods need encapsulation:common methods of Operationfrequently used steps: More than two timesfrequently Used components: input box, text box, listfrequently-operated layouts: multiple components make up a common layoutfrequently-Used pages: The UI page consists of a single activity that encapsulates the activity into a separate classCommon tool Functions: file operations, time operations, and so on3, the primary package:Common Method Library: Encapsulates a common method in a Java file, such as login, file operation, time OperationSpecial Method Library: such as login-specific method: QQ Landing, Weibo landing, etc.use case sets: This looks concise and clear by invoking the methods in the method library to implement the use cases. 4, the process of designing a use case:First, edit good examples to perform steps, orderand then design the corresponding method name.then create a new class to write these, to edit the use case steps, method names, etc. as a comment, so that clearer For example, design simple use cases are as follows:cer_mtbf_01: Adding and removing contactsPreset conditions: 1, no contacts in the Address Book before adding contacts
| Perform steps |
Correspondence method |
| Open Contacts |
Opencontent |
| Clear Contacts |
ClearContent |
| New Contact |
Newcontent |
| Confirm Contact New Success |
Confirmcontents |
| Delete a contact |
Deletecontens |
| Confirm Contact Deletion succeeded |
Confirmdelcontents |
| Exit Contacts |
Exitcontent |
second, the interface of1, interface-oriented can also be introduced into the automation of use case writing. can use the design core use case, the basic core use case 20-30, the core function basically will not change, but the UI changes relatively big, so we do not need to write the use case again, as long as the method to re-implement. Design use case and implementation use case separationNormalize Use casesPolymorphic -Multiple versions of the application
third, component and layout1, the commonly used components to write components commonly used methods. Each object that we finally get is a component of one typeFor example: a common approach to editview design, first think about how you test the edit box, all of these methods are written in the abstract EditView classget EditView ObjectEnter textClear Datadetermine the type of edit boxJudging the edit boxvarious anomalies and special method presets,
four, the interface of1, the interface knowledge application consists of different activity, we can encapsulate each interface into a class, operations, methods, variables, that is, properties and methods are encapsulated separately. so as long as the interface changes, and then modify the corresponding activity is possible. Example:Dial PageProperties:Common fixed numbers, such as: 10086,10010,10000Common cipher: * #06 #, *#* #4636 #*#*Component ID: page Each component ID is named by functionPage Objects: Page individual UI ObjectsMethod:Enter NumberClear number, delete numberdialingOther settings (add contacts, pause, wait, send SMS)Select number2. Activity Query MethodMethod 1: Source code, obtained from the manifest fileMethod 2: Use the command to query all the activity of the appadb shell Dumpsys package< Package name >Method 3: Query the activity on the current activity stackadb shell Dumpsys activityMethod 4: Locate the focus activityadb shell Dumpsys activity | find "Mfocusedactivity"Simplifying Search charactersadb shell Dumpsys activity | find "MF"
v. Separation of logic and data1, the actual use case writing process has a lot of data is not fixed but variablesuch as:account information: email account, wireless login account, Instant Messenger softwarelogic Control: Log output, code branch switchPhone number..... for mutable data, we should peel it off and use a data class to control and getIdeas:we individually design a class that reads variables from somewhere and assigns them to the variables we have designed. 2. Data acquisition Method1) incoming parameter from command:-e key value pair2) Incoming parameters from the file: Write a configuration file, the file contains the configuration variable information, placed in the phone directory, and then the file read, assigned to our variables. 3) Incoming parameters from the cloud: there needs to be a cloud service test system, use cases through post requests, request servers, set up information on the server, return the information to use cases, use cases to assign the information to the corresponding variables, and then other use cases to read from the data class. Simple example:build a package that manages your databuild a data classSetting Variableswriting some methods to get the value of a variable
Public class extends uiautomatorbase{ publicstatic String wlan= ""; Public Static String qq= ""; Public Static String phone= ""; } Public void GetConfig () { WLAN= ""; QQ= ""; Phone= ""; } }
Android UI Automation use case design tips
