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

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

अनुमति वाले टैग की सूची

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

हालांकि वह सूची प्रतिबंधित लगती है, फिर भी वह आपको के लिए टेस्ट मॉड्यूल सेटअप की ज़रूरत है.

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

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.xml) में यह काम सिर्फ़ एक बार किया जाता है और हर मॉड्यूल को वह मिलता है जानकारी मांगी जाएगी.

मॉड्यूल में मौजूद ऑब्जेक्ट को बिल्ड की जानकारी मिल सके, इसके लिए उन्हें इन चीज़ों की ज़रूरत होती है इसे सामान्य ट्रेडेड कॉन्फ़िगरेशन की तरह ही इस्तेमाल करना होगा: अपने 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 कॉम्पोनेंट के बारे में बताता है परीक्षण करना चाहता है. टेस्ट के निष्पादन पर इसका कोई सीधा असर नहीं होता है; यह इसका इस्तेमाल मुख्य रूप से संगठन से जुड़े कामों के लिए किया जाता है.

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

कॉम्पोनेंट के हिसाब से, सुइट के रन को फ़िल्टर किया जा सकता है 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: अलग-अलग टेस्ट के ऐसे वैरिएशन बनाएं जो APK को इस रूप में इंस्टॉल करें इंस्टैंट ऐप्लिकेशन.
• multi_abi: डिवाइस.
• secondary_user: APK और APK इंस्टॉल करने वाले टेस्ट के अलग-अलग वर्शन बनाएं सेकंडरी उपयोगकर्ता के तौर पर टेस्ट करता है.

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

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

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

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

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