CTS framework resolution (13)-task execution process

Because the test task is a complicated process, it should be discussed separately. The content of result_reporter is also involved. So this is a big block. First, place the breakpoint in the run method of ctstest, delete other breakpoints, and restart the debug mode:

First, checkfields is called to check the command line parameters. Then generate the package name information in the plan. (To understand the meaning of plan, plan is the XML file in the plan file under the CTS directory, and the entry configured in it represents a test item, one test item contains multiple test cases ). This program executes the signature plan. Let's take a look at the content in this XML file.

<?xml version="1.0" encoding="UTF-8"?><TestPlan version="1.0">  <Entry uri="android.tests.sigtest"/></TestPlan>

It contains a test item. Then go to the testcases directory to find the configuration file for this test item:

Let's think about how to find the signaturetest. xml file under testcases according to the entry configuration. To understand

<Entry uri="android.tests.sigtest"/>

Looking for a test item does not mean that the XML name of this test item is Android. tests. sigtest, but you need to open the XML file to find an appnamespace attribute name, which is the reference content for entry configuration. At this time, we open signaturetest. XML to verify whether it is the same:

<?xml version="1.0" encoding="UTF-8"?><TestPackage AndroidFramework="Android 1.0" appNameSpace="android.tests.sigtest" appPackageName="android.tests.sigtest" jarPath="" name="SignatureTest" runner=".InstrumentationRunner" signatureCheck="true" targetBinaryName="" targetNameSpace="" version="1.0">  <TestSuite name="android">    <TestSuite name="tests">      <TestSuite name="sigtest">        <TestCase name="SignatureTest">          <Test name="testSignature"/>        </TestCase>      </TestSuite>    </TestSuite>  </TestSuite></TestPackage>

Coincidentally, We will verify this point in the debugging process of the program later. Return to the program.

After checking the parameters, obtain the test items based on the plan:

Go to the buildtesttorun method:

In this method, createtestcaserepo is called first to obtain all the testcases test objects (an XML file represents a test object ).

As shown in the preceding figure, a new testpackagerepo object has the following parameters: file object (pointing to the testcases directory) and Boolean value. Go to the construction method of the testpackagerepo object to see how it obtains information about the XML file.

Directly look at the parse () method

In the parse method, obtain all the XML files in the testcases directory. View the xmlfiles object in the variables column. There are 80 elements, indicating 81 XML files under the testcases directory.

The parse method then traverses these XML files one by one. Go to the parsetestfromxml (xmlfile) method:

First, create a testpackagexmlparser object, which inherits from abstractxmlparser and parses the XML file by using sax. I will not elaborate much on how to parse XML files in Sax. Parser. parse (createstreamfromfile (xmlfile); press F5 to call the startelement method in the testpackagehandler class.

After this method is executed, the information in the XML file is read to the testpackagedef object.

Now let's look at the form in which the XML file parsed by the testpackagexmlparser. parse method is saved.

All corresponding properties exist in the testpackagedef attribute, and the case to be executed is saved in the mtests list.

CTS framework resolution (13)-task execution process