Android automated testing (I): Capturing elements on an activity
Part 1: Preface
AndroidTheTestNow it should be regarded as a new field. Many of the information on this field on the internet is based onWhite box testingIs generally based onJUnitFramework and Android
Android. but there is a premise that the source code of the application must be available to provide the test access point, which is unrealistic in many software companies. Many test engineers doWorkIt is completely black box, basically unable to access the source code, and most white box testing is done by developers themselves.
ReviewWindowsUnderBlack box testingAutomated, previously usedMicrosoftThe provided. NET Framework-based UI automation testing framework (required version in. NET Framework
More than 3.0, namely the Vs. net 2008 Development Environment), it is easier for people who are good at C # to use it. I have also written a lightweight automation framework based on UI automation, which will be introduced in future blog posts.
So can I do something similar to UI automation in the Android operating system? Unfortunately, the permission control points of Android are very clear. Data Access between different programs can only be achieved through functions similar to intent and content provider. That is to say, the automation program you developed in Android wants to capture the currently running Aut (application under
Test) Controls and other elements on the interface (this term is derived from UI automation and it is hard to translate elements into elements, so it is basically impossible to translate them, you cannot get the reference of the current active activity. (as of the end of this article, I have not found a way to get this reference ).
No way to go? The simulator cannot go. Can it go outside? Maybe.
Part 2: capture the element on the Activity
In the android SDK, you have a pairAutomated TestingUseful Tool: hierarchyviewer (in the tools directory of the SDK ). When the simulator is running, this tool can be used to display the elements in the current activity in the form of an object tree, and the attributes contained in each element can also be displayed one by one. This is a bit like the UI spy running on Windows. The only pity is that it does not support event triggering. But it doesn't matter. You can find a way to bypass it. The top priority is to find the element on the activity in the Self-compiled automated test code.
The first thought was to look at the hierarchyviewer source code. Unfortunately, I searched the internet and found no resources. MaybeGoogleOn the official website, but not on. It seems that it can only be decompiled. xjad is a brute force attack. Although the decompiled code prompts a lack of import in many places, the code is basically correct. After reading it, I know a lot. Later, during the code writing process, it proved that if you want to reference the hierarchyviewer. jar package and debug it, you still need to know some settings in it.
Create hierarchyviewer-based. to call the jar package, you need to call it with the other two packages, ddmlib. jar (in hierarchyviewer. jar has the same directory) and org-netbeans-api-visual.jar (you need to download and install netbeans, in its installation directory) are imported into the project together, because the implementation of hierarchyviewer is attached to these two packages.
To obtain the element on the activity in the code, you need to perform the following steps (if you have used the hierarchyviewer tool, you will find that the automated code must write the steps used on the tool ):
1. Ensure ADB running
2. set ADB location (because the communication between hierarchyviewer and simulator relies entirely on ADB, it is vital to set the correct location of the ADB program. I have planted this issue for more than half a day)
3. Get Active device (this equivalent action occurs when the hierarchyviewer tool is started)
4. Start view server (equivalent to the start server menu trigger event on the tool)
5. Load scene (equivalent to the load view hierarchy menu trigger event on the tool)
6. Get Root View node (get the root node of the object tree. This action is automatically loaded after you click the load view hierarchy menu on the tool)
7. Get sub view node (obtain the view node you want to search for. This action is automatically loaded after you click the load view hierarchy menu on the tool)
Note: The names in the above steps are actually the names of accessible methods provided in hierarchyviewer, such as startviewserver, loadscene, and rootnode. In addition, view node is actually a class in hierarchyviewer, indicating an element in the object tree.
Paste some core Code as follows:
1. Set ADB location
System. setproperty ("hierarchyviewer. ADB", "E :\\
\ Android-SDK-Windows \ tools ");
The key "hierarchyviewer. ADB" is specified in hierarchyviewer. jar, and the following value is the path for storing the android SDK. This directory must be the directory of ADB corresponding to the current running simulator. You cannot use ADB in other directories. Otherwise, the ADB process may exit abnormally.
2. Get Active device
Idevice [] devices = NULL;
Devicebridge. Terminate ();
While (null = devices | 0 = devices. Length ){
Devicebridge. initdebugbridge ();
// It must wait for some time, otherwise will throw exception
Try {
Thread. Sleep (1000 );
} Catch (interruptedexception e ){
E. printstacktrace ();
}
Devices = devicebridge. getdevices ();
}
Return devices;
The above method returns the list of all currently running devices.
3. Start view Server
Devicebridge. startviewserver (device );
4. Load scene
Viewhierarchyloader. loadscene (device, window. focused_window );
5. Get Root View Node
VHS. getroot ();
VHS is the Instance Object of viewhierarchyscene.
6. Get sub view Node
Public viewnode findfirstchildrenelement (idevice device, viewnode entryviewnode, string elementid ){
Viewnode node = NULL;
If (0! = Entryviewnode. Children. Size ()){
For (INT I = 0; I <entryviewnode. Children. Size (); I ++ ){
Node = entryviewnode. Children. Get (I );
If (node. ID = elementid)
Return node;
Else
Continue;
}
}
Return node ;}
Although the above steps involve a small amount of code, it took more than a day to study it. I wrote this article to help students who are studying Android automated testing.
So far, the element has been obtained, and the next step is how to trigger these elements, such as click button and enter text. We need to study these elements and share them later!