AndroidTest.xml संरचना

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

मॉड्यूल कॉन्फ़िगरेशन की समग्र संरचना नियमित ट्रेडफेड एक्सएमएल कॉन्फ़िगरेशन के समान पैटर्न का अनुसरण करती है लेकिन कुछ प्रतिबंधों के साथ इस तथ्य के कारण कि वे एक सूट के हिस्से के रूप में चलते हैं।

अनुमत टैग की सूची

AndroidTest.xml या अधिक मोटे तौर पर मॉड्यूल कॉन्फ़िगरेशन में केवल निम्नलिखित 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 पैकेज के विरुद्ध एक इंस्ट्रूमेंटेशन चलाएगा।

"metrics_collector" टैग के लिए विशेष मामला

मेट्रिक्स_कलेक्टर की अनुमति है लेकिन metrics_collector क्लास तक सीमित है ताकि किसी दी गई फ़ाइल या निर्देशिका को मॉड्यूल के लिए खींचा और लॉग किया जा सके। यह उपयोगी है यदि आप किसी विशेष स्थान पर लॉग छोड़ रहे हैं और उन्हें स्वचालित रूप से पुनर्प्राप्त करना चाहते हैं।

उदाहरण विन्यास:

<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 मेटाडेटा सामान्य एंड्रॉइड घटक का वर्णन करता है जिसे मॉड्यूल परीक्षण करना चाहता है। इसका परीक्षण निष्पादन पर कोई सीधा प्रभाव नहीं पड़ता है; यह मुख्य रूप से संगठनात्मक उद्देश्यों के लिए उपयोग किया जाता है।

CTS के लिए अनुमत घटकों की अप-टू-डेट सूची 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 : instant_app को झटपट ऐप के रूप में इंस्टॉल करने वाले परीक्षणों की विविधता बनाएं।
  • multi_abi : डिवाइस द्वारा समर्थित प्रत्येक एबीआई के लिए परीक्षणों की विविधता बनाएं।
  • secondary_user : एपीके इंस्टॉल करने वाले और सेकेंडरी यूजर के रूप में टेस्ट चलाने वाले परीक्षणों की विविधता बनाएं।