Android Automated Testing Solution

Desktop applications and browser-side automated testing have experienced ten years of development, and both tools and project management methods have become mature. The automated testing of mobile device applications has just started in the past two years. It seems that everything is still in the stage of discussion and research. However, we seem to have seen explosive growth in demand. It can be analyzed from these two aspects: first, the increase in the number and logic complexity of mobile applications and the tightening of the product release cycle make rapid regression testing imminent; second, the openness of the Android system has led to a fierce competition among hardware manufacturers. The wide range of device styles forces mobile app compatibility tests to be put on the agenda. Looking at the two mainstream camps of smartphones, iPhone and Android, it seems that Android app developers and device manufacturers can better understand the pain points of compatibility testing. In view of this, and combined with automated testing on traditional desktop systems, we will discuss the possibility of driving automated testing based on keywords of Android platform applications, and find a suitable way to implement and implement automated testing effectively and effectively in the real situation that the mobile application development process is changing with each passing day.

Theoretical Basis

In the field of automated testing of traditional desktop and browser applications, there are already quite mature tools available for users to choose from, such as commercial tools hp qtp, IBM Robot/RFT, Borland SilkTest, etc; open-source tools such as Selenium and Watir. Profiling these tools all seem to have the same functional structure:

● Capture and identify the objects and elements of the tested application interface, and manage and operate them;

● Edit the script and parse the syntax;

● Organization and Management of test data;

● Analysis and output of script execution results;

In details, it can also involve content such as the script recording function, plug-in management function, and integration with test management tools and defect tracking tools. All of these are for the purpose of simulating tester behavior to achieve functional regression testing. This article attempts to analyze the core components of automated testing tools from the following key points.

1. keyword-driven

The main idea of keyword testing is to manage the objects, operations, test data, and the composite relationship between the tested applications in an object-oriented manner. Keyword-driven is an effective method in automated testing, it helps test engineers easily maintain test scripts, build complex business logic test cases, and save the execution time of manual tests, especially in the regression test phase ). Keyword-driven systems mainly consist of the following three elements:

1) objects to be tested, that is, elements on the application interface to be tested;

2) operations on these objects, such as clicking the button), filling text), and selecting single-choice or multiple-choice boxes );

3) and the value based on these operations;

The preceding three elements can be described in the following table:

Object	Operation	Value
Text Box	Input	Text Value
Button	Click	None
Select box	Select	Option value

Or it can be expressed in an object-oriented Syntax:

Object. Operation value)

This statement is the basis of the keyword-Driven Script.

2. Object Library

Object Library is used to store the object interface elements of the tested application interface. It is the key point of the keyword-driven testing tool. With this feature, users can easily maintain tested objects and build test scripts more quickly. How does it achieve this? Let's take a look at the following structure:

Practice

After discussing the usage characteristics of different test tools, we can more accurately describe the features of Android Application automated testing tools. We may wish to simulate the testing process of a mobile application. Here we use API Demo as the tested application and DroidPilot as the testing tool.

Analyze tested applications

The tested app API Demo uses the standard Android SDK as the development control without disturbing code. Therefore, all elements on the interface can be identified by DroidPilot.

For applications developed using non-standard Android SDK controls, there are two situations: one is that the controls are fully developed by themselves. In this case, DroidPilot cannot identify objects at all; another case is that the standard control is based on secondary development. In this case, DroidPilot can only identify the layer of the native SDK. For both cases, you can contact the DroidPilot development team to customize the exclusive plug-in for non-standard controls to identify the tested controls.

As described in the preconditions section, DroidPilot itself is powerless and can only ask the development team to remove the scrambling code, package A test package without disturbing code for the test team.

DesignTest Cases

Here, we assume that a test case is to go to the \ App \ Activity \ Animation \ Fade in \ interface, and operate on the Interface Element buttons, text boxes, multiple selection boxes, single selection, and drop-down lists, verify that the text in the text box meets my expected results. The test procedure is as follows:

Test Case 1-verify the \ App \ Activity \ Animation \ Fade in \ Interface Element
Prerequisites: the API Demo has been started and is on the start page.
Procedure	Action	Expected results
1	Click an App item
	Click Activity item
	Click the Animation item
	Click Fade in.
	Enter "put your text here" in the text box"
	Check Checkbox1
	Slide down the screen once
	Click the drop-down list
	Select Venus
	Check text box	TEXT = "textColorPrimary"

Develop test scripts

First, use the DroidPilot script editing tool to capture the objects on each screen, and then select these objects into the script designer and sort them in the order of test cases, such:

For example, in the traditional model, Test engineers may have only one Full Test in the first round of tests. In subsequent regression tests, only partial regression can be achieved.

If an automated testing engineer is introduced and a test script is developed synchronously, the automation ratio of each application reaches 70% ~ 80%, the overall automation rate reaches 60% ~ 70%), which may increase the regression test ratio.

Starting from scratch

In this case, why don't we try to introduce automated testing in the project from the beginning to the beginning, even if we only need some human resources to start automated testing for some applications, at least Daily Build Smoke Test can be achieved. Moreover, the mobile application automated testing industry is in its infancy, and it is also a good time to intervene.

Conclusion

Looking back at the above discussions, we envision continuing the successful desktop system automated testing experience in the mobile application automated testing field, this article discusses the theoretical basis, tool support, and subsequent project management. Although it is mainly confined to the automation of Android applications, it is rarely mentioned in iOS. It is hard to understand that iOS only supports a limited number of models and does not focus on device compatibility testing. In terms of functional regression testing, it also supports related tools. As for platforms like Blackberry, there is no explosive growth in applications, so they are not listed in the scope of discussion. Therefore, this article still uses the Android platform as a breakthrough in automated testing, hoping to combine some commercial tools on the market and try to implement automated testing based on "keyword-driven, instead of the original screen click Test Based on "coordinate points. Open-source tools are not mentioned because popular tools such as Robotium and MonkeyRunner may be closer to development engineers rather than test engineers. Therefore, we hope that the above discussion will give readers new inspiration in the test project.