Cts框架解析(13)-任务执行过程

因为测试任务是个很复杂的过程，所以要单独拿出来讲，里面还涉及了result_reporter的内容。所以这是一个大块。首先把断点打在CtsTest的run方法中，删除其他断点，重新启动debug模式：



首先会调用checkFields检查一下命令行参数。然后生成plan里的包名信息。（要理解plan的意思，plan就是cts目录下plan文件下的xml文件，它里面配置的entry代表一个测试项，一个测试项里又包含多个测试的case）。本程序执行的是Signature计划，我们就来看看这个xml文件中的内容。

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

里面就包含一个测试项。再通过这个去testcases目录去找这个测试项的配置文件：



思考一个问题，我们是如何根据Entry的配置找到testcases下的SignatureTest.xml文件的。要理解通过

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

找测试项，并不是说这个测试项的xml名为android.tests.sigtest，而是你要打开xml文件去里面找一个叫appNameSpace属性名，这个名称才是Entry配置时参照的内容，这个时候我们打开SignatureTest.xml，来验证一下是否相同：

<?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>

很巧，刚好一样，一会我们会在程序的debug过程中，验证这一点。再回到程序中。

检查完参数后，就要根据plan获取测试项：



进入buildTestToRun方法中：



该方法中会先调用createTestCaseRepo得到testcases所有的测试对象（一个xml文件代表一个测试对象）。



如上，new一个TestPackageRepo对象，参数为File对象（指向testcases目录）和boolean值。进入TestPackageRepo对象的构造方法，看其如何获得xml文件的信息的。



直接看parse()方法



parse方法中，首先获得testcases目录中所有的xml文件。查看Variables一栏中xmlFiles对象。有80个元素，说明testcases目录下有81个xml文件。



然后parse方法会逐个遍历这些xml文件。转到parseTestFromXml(xmlFile)方法中：



先创建一个TestPackageXmlParser对象，该对象继承于AbstractXmlParser，通过SAX的方式解析xml文件。有关SAX如何解析xml文件的内容我就不多阐述了。parser.parse(createStreamFromFile(xmlFile));按F5，调用的是TestPackageHandler类中的startElement方法。



该方法执行完成后，xml文件里的信息都读到了TestPackageDef对象中了。



此时我们来看经过TestPackageXmlParser.parse方法解析的xml文件是以什么形式保存的。



对应的属性都存在了TestPackageDef对应的属性中，要执行的case保存在mTests的列表中。