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 पैकेज के विरुद्ध एक उपकरण चलाएगा।

समावेशन टैग <include> और <template-include>

मॉड्यूल कॉन्फ़िगरेशन में <include> और <template-include> का उपयोग हतोत्साहित किया जाता है। उन्हें अपेक्षा के अनुरूप काम करने की गारंटी नहीं है।

मेट्रिक्स_कलेक्टर टैग के लिए विशेष मामला

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

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

आप module-metadata-include-filter और module-metadata-exclude-filter उपयोग करके घटकों के आधार पर एक सूट रन को फ़िल्टर कर सकते हैं।

उदाहरण:

  --module-metadata-include-filter component framework

यह उदाहरण केवल framework घटक के साथ एनोटेट किए गए परीक्षण मॉड्यूल को चलाता है।

पैरामीटर

parameter मेटाडेटा सूचनात्मक है और परीक्षण निष्पादन को प्रभावित करता है। यह निर्दिष्ट करता है कि परीक्षण मॉड्यूल किस एंड्रॉइड मोड पर लागू होता है। इस मामले में, मोड उच्च स्तरीय एंड्रॉइड मोड तक सीमित हैं, जैसे instant apps , secondary users या different abis

सुइट रन के दौरान, यदि मोड परीक्षण पर लागू होता है, तो मोड के आधार पर परीक्षण मॉड्यूल के कई बदलाव बनाए जाते हैं। प्रत्येक भिन्नता समान परीक्षण चलाती है लेकिन विभिन्न मोड के तहत।

  • instant_app : परीक्षणों का एक प्रकार बनाएं जो एपीके को इंस्टेंट ऐप्स के रूप में इंस्टॉल करें।
  • multi_abi : डिवाइस द्वारा समर्थित प्रत्येक एबीआई के लिए परीक्षणों की विविधता बनाएं।
  • secondary_user : परीक्षणों की एक विविधता बनाएं जो एपीके इंस्टॉल करें और द्वितीयक उपयोगकर्ता के रूप में परीक्षण चलाएं।

प्रदर्शन परीक्षण मॉड्यूल के लिए मीट्रिक संग्रह और पोस्ट-प्रोसेसिंग

प्रदर्शन परीक्षण मॉड्यूल के लिए, मॉड्यूल-स्तरीय metrics_collector और metric_post_processor की अनुमति है क्योंकि वे प्रदर्शन परीक्षणों के लिए आवश्यक हैं। मॉड्यूल-स्तरीय मीट्रिक संग्राहक और पोस्ट-प्रोसेसर मॉड्यूल विशिष्ट हो सकते हैं। शीर्ष-स्तर और मॉड्यूल-स्तर दोनों पर पोस्ट-प्रोसेसर निर्दिष्ट करने की अनुशंसा नहीं की जाती है।

एक प्रदर्शन परीक्षण मॉड्यूल कॉन्फ़िगरेशन में मूल्य performance के साथ test-type मेटाडेटा शामिल होना चाहिए, जैसे: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> इसके बिना, यदि कोई परीक्षण config में 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>