Android System/Application development needs to master automation testing knowledge

been in contact with Andorid for several months, always think that do the system, the application development does not need to understand the road of Android automation testing, that is what testers need to master things, we only understand the development, as long as the system to read, according to customer needs can make the corresponding changes can be, as long as the familiar with the API, The application can be written to achieve a function on it. Actually, it's not.

For instance, our great customers, crazy to replace the hardware configuration, then our driver will follow back and forth, the relevant functions of the C implementation also want to change, the upper Java corresponding slightly modified, met griping at everything point of the customer griping at everything demand, then only the good luck ... Fortunately, the whole thing is done. Google in time to release the high version of Android, customers want to follow suit to upgrade, when suddenly found that their own modified system relative to native Android is not just optimize and add xx function, 4 words: Bones. This time, the perfect upgrade is almost equal to rewriting. Avoiding this tragedy is very simple: After completing the development task, use CTS to test compliance with the non-compliant Android compatibility specification. If all pass so OK thank goodness, if there are fail (does not affect system compilation and related functions to achieve, just do not conform to the compatibility specification), it is necessary to check the relevant documents in a timely manner can not be modified to achieve the return to the Android path. If it is really difficult, it is necessary to advance with customers to greet, to avoid being thrown back by them, their own difficult to clean up.

Android Automation testing is not just CTS, but also monkey,ase,robotium,instrumentationd ... are very useful tools. For example, the application of the UI test, a single activity test, Instrumentationd is the biggest contributor.

What did Android.test offer us?

Give an example to boast activityinstrumentationtestcase2<t extends activity>

Public T getactivity () {activity      
        
    a = super.getactivity ();      
        
    if (a = = null) {      
        
        //Set initial touch mode      
        
        getinstrumentation (). Setintouchmode (Minitialtouchmode);      
        
        Final String targetpackage = Getinstrumentation (). Gettargetcontext (). Getpackagename ();      
        
        Inject custom intent, if provided      
        
        if (mactivityintent = = null) {      
        
            a = launchactivity (Targetpackage, MACTIVITYCLA SS, NULL);      
        
        else {      
        
            a = Launchactivitywithintent (Targetpackage, Mactivityclass, mactivityintent);      
        
        }      
        
        Setactivity (a);      
        
    }      
        
    Return (T) A;      
        
}

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/OS/extra/

Through Getactivity () can easily get activity, wanton use of the methods, avoiding the inability to instantiate the object can not use a class of methods. Before get, setactivityintent (Intent) and/or Setactivityinitialtouchmode (Boolean), provide custom setup values to your      Activity. I recently in contact with camera this piece, solved a few bugs, measured CTS, accidentally found CTS, camera's hardware test this piece of the original does not conform to the compatibility of fail, all pass. So immediately very regret, why not first for the CTS results to find the bug export, the target is locked quickly, the efficiency of the solution will be increased by one times.

Let's simply say CTS.

$ make CTS//android source code compiled, in the compilation CTS

Extract the Android-cts.zip from the previous step and then test it. The detailed operation searches the data, the network related resources are many.

The CTS test automatically generates the appropriate test package, which is located in the following directory:

Android-cts/repository/results

Each test package contains the following files;

Cts_result.css

Cts_result.xsl

logo.gif

Newrule-green.png

Testresult.xml

The test case for this package is in the Testresult.xml file, and by looking at the file you can see that those are compatible with Android and, in particular, that the CTS is constantly updating as the Android version is updated.

If you are curious enough, you can try, the same system of the same equipment, from R1 to R5 different versions of the CTS to test again, there will be unexpected harvest!

If you don't know the test, don't say you're a good developer. In particular, Android provides us with a convenient automated testing mechanism, and there is no reason to say no.