स्थापना परीक्षण

परीक्षण सूट

किसी परीक्षण को वीटीएस का हिस्सा बनने के लिए, इसमें Android.bp में निम्नलिखित सेटिंग होनी चाहिए।

test_suites: ["vts"],

इसके अतिरिक्त, परीक्षण को general-tests सूट में जोड़ने से यह प्रीसबमिट चेक में उपयोग किए जाने वाले टेस्ट मैपिंग सूट का हिस्सा बन जाता है।

परीक्षण विन्यास

ज्यादातर मामलों में, परीक्षण कॉन्फ़िगरेशन, जो एक XML फ़ाइल है जिसका उपयोग ट्रेड फेडरेशन द्वारा वीटीएस परीक्षण चलाने के लिए किया जाता है, निर्माण के दौरान स्वचालित रूप से उत्पन्न होता है। हालाँकि, आप परीक्षण कॉन्फ़िगरेशन को अनुकूलित कर सकते हैं।

एक अनुकूलित परीक्षण कॉन्फ़िगरेशन फ़ाइल बनाएँ

शुरुआत से एक नई परीक्षण XML फ़ाइल बनाना जटिल हो सकता है, क्योंकि इसमें यह समझना शामिल है कि परीक्षण हार्नेस कैसे काम करता है, साथ ही प्रत्येक परीक्षण धावक के बीच अंतर भी शामिल है। ऑटोजेनरेटेड टेस्ट कॉन्फिग फ़ाइल इस प्रक्रिया को आसान बनाने के लिए डिज़ाइन की गई है।

यदि आपको परीक्षण XML फ़ाइल को अनुकूलित करना है, तो आप स्वत: जेनरेट की गई फ़ाइल को शुरुआती बिंदु के रूप में उपयोग कर सकते हैं।

ऑटोजेनरेटेड टेस्ट कॉन्फ़िगरेशन फ़ाइल का पता लगाने के लिए, कॉन्फ़िगरेशन बनाने के लिए पहले make कमांड चलाएँ, जैसा कि नीचे दिखाया गया है।

$ m VtsHalUsbV1_1TargetTest

अपनी बिल्ड आउट निर्देशिका में, आप मॉड्यूल नाम के आधार पर कॉन्फ़िगरेशन फ़ाइल खोज सकते हैं, जैसा कि नीचे दिखाया गया है।

$ find out/ -name VtsHalUsbV1_1TargetTest.config

फ़ाइल की कई प्रतियां हो सकती हैं और आप उनमें से किसी का भी उपयोग कर सकते हैं। .config फ़ाइल को उस निर्देशिका में कॉपी करें जहां Android.bp फ़ाइल है।

यदि Android.bp फ़ाइल में केवल एक परीक्षण मॉड्यूल है, तो आप XML फ़ाइल का नाम बदलकर AndroidTest.xml कर सकते हैं, और बिल्ड सिस्टम स्वचालित रूप से परीक्षण मॉड्यूल की कॉन्फ़िगरेशन फ़ाइल के रूप में इसका उपयोग करता है। अन्यथा, मॉड्यूल में test_config विशेषता जोड़ें, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है।

test_config: "VtsHalUsbV1_1TargetTest.xml",

अब आपके पास काम करने और अनुकूलन को लागू करने के लिए एक परीक्षण कॉन्फ़िगरेशन फ़ाइल है।

परीक्षण को एडीबी रूट के साथ चलने के लिए बाध्य करें

अधिकांश वीटीएस परीक्षणों को चलाने के लिए रूट विशेषाधिकार की आवश्यकता होती है। यदि परीक्षण कॉन्फ़िगरेशन फ़ाइल स्वचालित रूप से जेनरेट की गई है, तो आप Android.bp में निम्नलिखित विशेषता जोड़ सकते हैं।

require_root: true,

यदि परीक्षण कॉन्फ़िगरेशन फ़ाइल अनुकूलित है, तो परीक्षण XML फ़ाइल में निम्नलिखित जोड़ें।

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

परीक्षण के दौरान फ्रेमवर्क रोकें

कई वीटीएस परीक्षणों को चलाने के लिए एंड्रॉइड फ्रेमवर्क की आवश्यकता नहीं होती है, और फ्रेमवर्क बंद होने पर परीक्षण चलाने से परीक्षण डिवाइस फ्लेक्स से प्रभावित हुए बिना स्थिरता के साथ चल सकता है। यदि परीक्षण कॉन्फ़िगरेशन फ़ाइल स्वचालित रूप से जेनरेट की गई है, तो आप Android.bp में निम्नलिखित विशेषता जोड़ सकते हैं।

disable_framework: true,

यदि परीक्षण कॉन्फ़िगरेशन फ़ाइल अनुकूलित है, तो परीक्षण XML फ़ाइल में निम्नलिखित जोड़ें।

<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>

अतिरिक्त परीक्षण तर्क जोड़ें

कुछ gtest परीक्षणों को चलाने के लिए अधिक समय की आवश्यकता हो सकती है। ऐसे मामलों में, आप XML फ़ाइल में टेस्ट रनर विकल्प जोड़ सकते हैं।

उदाहरण के लिए, निम्नलिखित प्रविष्टि में native-test-timeout सेटिंग परीक्षण को 1 मिनट के डिफ़ॉल्ट के बजाय 3 मिनट के टाइमआउट के साथ चलाने की अनुमति देती है।

   <test class="com.android.tradefed.testtype.GTest" >
       <option name="native-test-device-path" value="/data/local/tmp" />
       <option name="module-name" value="VtsHalNfcV1_0TargetTest" />
       <option name="native-test-timeout" value="180000"/>
   </test>

न्यूनतम एपीआई स्तर की आवश्यकता है

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

test_min_api_level: 29,

यदि परीक्षण कॉन्फ़िगरेशन फ़ाइल अनुकूलित है, तो परीक्षण XML फ़ाइल में निम्न आदेश जोड़ें।

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

एंड्रॉइड 12 इन उपकरणों पर विक्रेता छवियों के एपीआई स्तर को दिखाने के लिए ro.board.first_api_level और ro.board.api_level गुणों को परिभाषित करता है। इन गुणों को ro.product.first_api_level के साथ जोड़कर, परीक्षण सूट उपकरणों के लिए उचित परीक्षण मामलों का चयन करते हैं।

एंड्रॉइड 13 ro.vendor.api_level परिभाषित करता है जो ro.product.first_api_level , ro.board.first_api_level , और ro.board.api_level गुणों का उपयोग करके आवश्यक विक्रेता एपीआई स्तर की गणना करके स्वचालित रूप से सेट किया जाता है।

ro.board.first_api_level

ro.board.first_api_level संपत्ति एपीआई स्तर है जब SoC के लिए विक्रेता छवियां पहली बार इस संपत्ति के साथ जारी की जाती हैं। यह डिवाइस के लॉन्चिंग एपीआई स्तर पर निर्भर नहीं करता है बल्कि केवल एसओसी के पहले एपीआई स्तर पर निर्भर करता है जो इस मान को परिभाषित करता है। मान SoC के जीवनकाल के लिए स्थायी है।

ro.board.first_api_level सेट करने के लिए, डिवाइस निर्माता अपनी device.mk फ़ाइल में BOARD_SHIPPING_API_LEVEL परिभाषित कर सकते हैं, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:

  # BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
  # the first api level that the device has been commercially launched on.
  BOARD_SHIPPING_API_LEVEL := 23

यह स्वचालित रूप से डिवाइस पर ro.board.first_api_level प्रॉपर्टी को vendor/build.prop में परिभाषित करेगा। संपत्ति विक्रेता init प्रक्रिया द्वारा निर्धारित की जाती है।

ro.board.api_level

ro.board.api_level संपत्ति SoC के लिए विक्रेता छवियों का वर्तमान API स्तर है। जब विक्रेता छवि का एपीआई स्तर जिसमें ro.board.first_api_level है, अपडेट किया जाता है, तो SoC का उपयोग करने वाले डिवाइस को ro.board.api_level को अपडेट करने के बजाय विक्रेता छवि के वर्तमान एपीआई स्तर के साथ ro.board.first_api_level प्रॉपर्टी को परिभाषित करना होगा . यदि यह प्रॉपर्टी सेट नहीं है, तो डिफ़ॉल्ट रूप से ro.board.first_api_level का उपयोग किया जाएगा।

ro.board.api_level सेट करने के लिए, वांछित मान के साथ device.mk फ़ाइल में BOARD_API_LEVEL परिभाषित करें।

ro.vendor.api_level

ro.vendor.api_level संपत्ति को एपीआई स्तर दिखाने के लिए एंड्रॉइड 13 में पेश किया गया था जिसका समर्थन करने के लिए विक्रेता छवियों की आवश्यकता होती है। यह स्वचालित रूप से न्यूनतम ro.board.api_level (या ro.board.first_api_level यदि ro.board.api_level परिभाषित नहीं है) और ro.product.first_api_level पर सेट हो जाता है। विक्रेता कार्यान्वयन के लिए परीक्षण जिनके लिए विक्रेता छवि उन्नयन की आवश्यकता होती है, उन्हें इस संपत्ति का संदर्भ देकर एसओसी के लिए विक्रेता आवश्यकताओं से बाहर रखा जा सकता है।

वीटीएस का उपयोग करके साझाकरण प्रक्रिया

एंड्रॉइड संस्करण 10 या उच्चतर के लिए, आप नीचे दिए गए निर्देशों का पालन करके वीटीएस और सीटीएस-ऑन-जीएसआई दोनों योजनाओं के साथ परीक्षण करते समय कई उपकरणों पर शार्डिंग प्रक्रिया कर सकते हैं।

run vts --shard-count <number of devices> -s <device serial> ...

यह कमांड वीटीएस योजना को टुकड़ों में विभाजित करता है और उन्हें कई उपकरणों पर चलाता है।

run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...

यह कमांड सीटीएस-ऑन-जीएसआई योजना को टुकड़ों में विभाजित करता है और उन्हें कई उपकरणों पर चलाता है।