AndroidTest.xml का स्ट्रक्चर

मॉड्यूल कॉन्फ़िगरेशन का पूरा स्ट्रक्चर, सामान्य Tradefed एक्सएमएल कॉन्फ़िगरेशन के जैसे ही होता है. हालांकि, इनमें कुछ पाबंदियां होती हैं, क्योंकि ये किसी सुइट के हिस्से के तौर पर काम करते हैं.

इस्तेमाल किए जा सकने वाले टैग की सूची

AndroidTest.xml या उससे ज़्यादा मॉड्यूल में, सिर्फ़ नीचे दिए गए एक्सएमएल टैग शामिल किए जा सकते हैं: target_preparer, multi_target_preparer, test, और metrics_collector.

हालांकि, यह सूची पाबंदी वाली लगती है, लेकिन इससे आपको टेस्ट मॉड्यूल सेटअप करने की ज़रूरतों और टेस्ट को चलाने के बारे में सटीक जानकारी मिलती है.

ध्यान दें: अगर आपको अलग-अलग टैग के बारे में ज़्यादा जानकारी चाहिए, तो Tradefed एक्सएमएल कॉन्फ़िगरेशन देखें.

अगर build_provider या result_reporter जैसे ऑब्जेक्ट को किसी मॉड्यूल कॉन्फ़िगरेशन के अंदर से चलाने की कोशिश की जाएगी, तो वे ConfigurationException जनरेट करेंगे. इसका मकसद, इन ऑब्जेक्ट को किसी मॉड्यूल में कोई टास्क करने से रोकना है.

मॉड्यूल कॉन्फ़िगरेशन का उदाहरण

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />
    </test>
</configuration>

इस कॉन्फ़िगरेशन में, एक टेस्ट के बारे में बताया गया है. इसके लिए, CtsGestureTestCases.apk को इंस्टॉल करना ज़रूरी है. साथ ही, यह android.gesture.cts पैकेज के लिए इंस्ट्रूमेंटेशन चलाएगा.

<include> और <template-include> को शामिल करने से जुड़े टैग

मॉड्यूल कॉन्फ़िगरेशन में <include> और <template-include> का इस्तेमाल करने का सुझाव नहीं दिया जाता. हालांकि, इस बात की कोई गारंटी नहीं है कि ये ऐप्लिकेशन उम्मीद के मुताबिक काम करेंगे.

metrics_collector टैग के लिए खास मामला

metrics_collector का इस्तेमाल करने की अनुमति है, लेकिन यह सिर्फ़ FilePullerLogCollector क्लास के लिए सीमित है. इससे, मॉड्यूल के लिए खींची और लॉग की जाने वाली किसी फ़ाइल या डायरेक्ट्री के बारे में बताया जा सकता है. यह तब काम आता है, जब आपको किसी खास जगह पर लॉग सेव करने हैं और उन्हें अपने-आप वापस पाना है.

कॉन्फ़िगरेशन का उदाहरण:

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

बिल्ड की जानकारी या डाउनलोड के बारे में क्या?

अनुमति वाले टैग की परिभाषा से गलत इंप्रेशन मिल सकता है कि मॉड्यूल को बिल्ड की जानकारी नहीं मिलेगी. यह सही नहीं है.

बिल्ड की जानकारी, सुइट-लेवल के सेटअप से दी जाती है. इसे सुइट के सभी मॉड्यूल शेयर करेंगे. इससे सुइट के सभी मॉड्यूल को चलाने के लिए, एक ही टॉप-लेवल सेटअप की अनुमति मिलती है.

उदाहरण के लिए, हर कंपैटिबिलिटी टेस्ट सुइट (CTS) मॉड्यूल के लिए, डिवाइस की जानकारी, टाइप वगैरह के बारे में अलग-अलग क्वेरी करने के बजाय, CTS सुइट-लेवल सेटअप (cts.xml) एक बार में यह काम करता है. साथ ही, अगर कोई मॉड्यूल इस जानकारी का अनुरोध करता है, तो उसे यह जानकारी मिल जाएगी.

किसी मॉड्यूल के ऑब्जेक्ट को बिल्ड की जानकारी पाने के लिए, उन्हें सामान्य Tradefed कॉन्फ़िगरेशन में किया गया वही काम करना होगा: IBuildInfo पाने के लिए, IBuildReceiver इंटरफ़ेस लागू करें. ज़्यादा जानकारी के लिए, डिवाइस से जांच करना देखें.

मेटाडेटा फ़ील्ड

टेस्ट मॉड्यूल की बड़ी संख्या में कुछ metadata स्पेसिफ़िकेशन शामिल होते हैं, जिनमें से हर एक का एक अलग लक्ष्य होता है.

उदाहरण:

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

कॉम्पोनेंट

component मेटाडेटा, Android के उस सामान्य कॉम्पोनेंट के बारे में बताता है जिसकी जांच मॉड्यूल में करता है. इसका असर, टेस्ट के लागू होने पर सीधे तौर पर नहीं पड़ता. इसका इस्तेमाल मुख्य रूप से संगठन के कामों के लिए किया जाता है.

CTS के लिए इस्तेमाल किए जा सकने वाले कॉम्पोनेंट की अप-टू-डेट सूची, CtsConfigLoadingTest में उपलब्ध है. अगर किसी CTs मॉड्यूल में ऐसा कॉम्पोनेंट जोड़ा जाता है जो मौजूद नहीं है, तो यह जांच सबमिट करने से पहले ही पूरी नहीं हो पाती.

module-metadata-include-filter और module-metadata-exclude-filter का इस्तेमाल करके, कॉम्पोनेंट के आधार पर सुइट चलाने की प्रोसेस को फ़िल्टर किया जा सकता है.

उदाहरण:

  --module-metadata-include-filter component framework

यह उदाहरण, सिर्फ़ framework कॉम्पोनेंट के साथ एनोटेट किए गए टेस्ट मॉड्यूल को चलाता है.

पैरामीटर

parameter मेटाडेटा, जानकारी देने वाला होता है और इससे टेस्ट के लागू होने पर असर पड़ता है. इससे पता चलता है कि टेस्ट मॉड्यूल किस Android मोड पर लागू होता है. इस मामले में, मोड सिर्फ़ Android के हाई लेवल मोड पर लागू होते हैं. जैसे, instant apps, secondary users या different abis.

सुइट में चलने के दौरान, अगर टेस्ट पर मोड लागू होता है, तो मोड के आधार पर टेस्ट मॉड्यूल के कई वैरिएशन बनाए जाते हैं. हर वैरिएंट, मिलते-जुलते टेस्ट चलाता है, लेकिन अलग-अलग मोड में.

• instant_app: उन टेस्ट का वैरिएशन बनाएं जो APKs को इंस्टैंट ऐप्लिकेशन के तौर पर इंस्टॉल करते हैं.
• multi_abi: डिवाइस पर काम करने वाले हर एबीआई के लिए, टेस्ट का वैरिएशन बनाएं.
• secondary_user: उन टेस्ट का वैरिएशन बनाएं जो APKs इंस्टॉल करते हैं और दूसरे उपयोगकर्ता के तौर पर टेस्ट चलाते हैं.

परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए मेट्रिक इकट्ठा करना और पोस्ट-प्रोसेसिंग

परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए, मॉड्यूल-लेवल metrics_collector और metric_post_processor का इस्तेमाल किया जा सकता है, क्योंकि ये परफ़ॉर्मेंस टेस्ट के लिए ज़रूरी हैं. मॉड्यूल-लेवल के मेट्रिक कलेक्टर और पोस्ट-प्रोसेसर, मॉड्यूल के हिसाब से हो सकते हैं. हमारा सुझाव है कि पोस्ट-प्रोसेसर को टॉप-लेवल और मॉड्यूल, दोनों लेवल पर न जोड़ें.

परफ़ॉर्मेंस टेस्ट मॉड्यूल कॉन्फ़िगरेशन में, performance वैल्यू वाला test-type मेटाडेटा शामिल होना ज़रूरी है, जैसे: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> इसके बिना, अगर किसी टेस्ट कॉन्फ़िगरेशन में, FilePullerLogCollector या किसी metric_post_processor के अलावा कोई metric_collector शामिल हो, तो टेस्ट पहले से सबमिट नहीं हो पाएगा.

परफ़ॉर्मेंस टेस्ट मॉड्यूल के कॉन्फ़िगरेशन का उदाहरण:

<configuration description="Runs sample performance test.">
    <!-- Declare as a performance test module -->
    <option name="config-descriptor:metadata" key="test-type" value="performance" />
    <option name="test-tag" value="hello-world-performance-test" />
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
    </test>
    <!-- Add module-level post processor MetricFilePostProcessor -->
    <metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
        <option name="aggregate-similar-tests" value="true" />
        <option name="enable-per-test-log" value="false" />
    </metric_post_processor>
</configuration>