टेस्ट टेम्प्लेट

एओएसपी में परीक्षण मॉड्यूल के लिए परीक्षण टेम्पलेट शामिल हैं जो वीटीएस धावक के बेसटेस्ट के होस्ट-साइड पायथन उपवर्ग नहीं हैं।

चित्र 1. टेम्प्लेट आर्किटेक्चर का परीक्षण करें।

ऐसे परीक्षणों को एकीकृत करने में शामिल प्रयास को कम करने के लिए डेवलपर्स इन टेम्पलेट्स का उपयोग कर सकते हैं। यह अनुभाग परीक्षण टेम्प्लेट को कॉन्फ़िगर करना और उनका उपयोग करना (वीटीएस टेस्टकेस/टेम्पलेट निर्देशिका में स्थित) को कवर करता है और आमतौर पर उपयोग किए जाने वाले टेम्प्लेट के लिए उदाहरण प्रदान करता है।

बाइनरीटेस्ट टेम्पलेट

वीटीएस में लक्ष्य डिवाइस पर निष्पादित परीक्षणों को एकीकृत करने के लिए बाइनरीटेस्ट टेम्पलेट का उपयोग करें। लक्ष्य-पक्ष परीक्षणों में शामिल हैं:

  • C++ आधारित परीक्षणों को संकलित किया गया और डिवाइस पर भेजा गया
  • लक्ष्य-पक्ष पायथन परीक्षण बायनेरिज़ के रूप में संकलित
  • डिवाइसों पर निष्पादन योग्य शैल स्क्रिप्ट

इन परीक्षणों को बाइनरीटेस्ट टेम्पलेट के साथ या उसके बिना वीटीएस में एकीकृत किया जा सकता है।

लक्ष्य-पक्ष परीक्षणों को बाइनरीटेस्ट टेम्पलेट के साथ एकीकृत करें

बाइनरीटेस्ट टेम्पलेट डेवलपर्स को लक्ष्य-पक्ष परीक्षणों को आसानी से एकीकृत करने में मदद करने के लिए डिज़ाइन किया गया है। ज्यादातर मामलों में, आप AndroidTest.xml में कॉन्फ़िगरेशन की कुछ सरल पंक्तियाँ जोड़ सकते हैं। VtsDeviceTreeEarlyMountTest से उदाहरण कॉन्फ़िगरेशन:

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

इस कॉन्फ़िगरेशन में:

  • binary-test-source और binary-test-type टेम्पलेट-विशिष्ट हैं।
  • परीक्षण बाइनरी स्रोत के सापेक्ष होस्ट पथ को निर्दिष्ट करना टेम्पलेट को तैयारी, फ़ाइल पुशिंग, परीक्षण निष्पादन, परिणाम पार्सिंग और क्लीनअप को संभालने में सक्षम बनाता है।
  • टेम्प्लेट में उपवर्गों को ओवरराइड करने के लिए टेस्ट केस निर्माण-संबंधित तरीके शामिल हैं।
  • टेम्प्लेट प्रति परीक्षण बाइनरी मॉड्यूल में एक टेस्ट केस मानता है, और बाइनरी स्रोत फ़ाइल नाम को डिफ़ॉल्ट रूप से टेस्ट केस नाम के रूप में उपयोग किया जाता है।

कॉन्फ़िगरेशन विकल्प

बाइनरीटेस्ट टेम्पलेट निम्नलिखित कॉन्फ़िगरेशन विकल्पों का समर्थन करता है:

विकल्प का नाम मान प्रकार विवरण
बाइनरी-परीक्षण-स्रोत तार होस्ट पर वीटीएस टेस्ट-केस निर्देशिका से संबंधित बाइनरी परीक्षण स्रोत पथ।
उदाहरण: DATA/nativetest/test
बाइनरी-टेस्ट-वर्किंग-डायरेक्टरी तार कार्यशील निर्देशिकाएँ (डिवाइस-साइड पथ)।
उदाहरण: /data/local/tmp/testing/
बाइनरी-टेस्ट-एनवीपी तार बाइनरी के लिए पर्यावरण चर।
उदाहरण: PATH=/new:$PATH
बाइनरी-परीक्षण-तर्क तार परीक्षण तर्क या झंडे.
उदाहरण: --gtest_filter=test1
बाइनरी-टेस्ट-एलडी-लाइब्रेरी-पथ तार LD_LIBRARY_PATH पर्यावरण चर.
उदाहरण: /data/local/tmp/lib
बाइनरी-परीक्षण-अक्षम-ढांचा बूलियन परीक्षण से पहले एंड्रॉइड फ्रेमवर्क को बंद करने के लिए adb stop चलाएँ। उदाहरण: true
बाइनरी-टेस्ट-स्टॉप-नेटिव-सर्वर बूलियन परीक्षण के दौरान सभी उचित रूप से कॉन्फ़िगर किए गए मूल सर्वर बंद कर दें। उदाहरण: true
बाइनरी-टेस्ट-प्रकार डोरी टेम्पलेट प्रकार. अन्य टेम्प्लेट प्रकार इस टेम्प्लेट से विस्तारित होते हैं, लेकिन आपको इस टेम्प्लेट के लिए यह विकल्प निर्दिष्ट करने की आवश्यकता नहीं है क्योंकि आपने पहले ही binary-test-source निर्दिष्ट कर दिया है।

मान प्रकार strings वाले विकल्पों के लिए, आप कॉन्फ़िगरेशन में विकल्पों को दोहराकर एकाधिक मान जोड़ सकते हैं। उदाहरण के लिए, binary-test-source दो बार सेट करें (जैसा कि VtsDeviceTreeEarlyMountTest उदाहरण में दिखाया गया है)।

परीक्षण टैग

आप परीक्षण टैग को strings मान वाले विकल्पों में उपसर्ग लगाकर और सीमांकक के रूप में :: का उपयोग करके जोड़ सकते हैं। परीक्षण टैग विशेष रूप से तब उपयोगी होते हैं जब समान नाम वाले लेकिन अलग-अलग बिटनेस या मूल निर्देशिका वाले बाइनरी स्रोतों को शामिल किया जाता है। उदाहरण के लिए, समान नाम वाले लेकिन विभिन्न स्रोत निर्देशिकाओं वाले स्रोतों के लिए फ़ाइल पुश या परिणाम नाम टकराव से बचने के लिए, आप इन स्रोतों के लिए अलग-अलग टैग निर्दिष्ट कर सकते हैं।

जैसा कि दो dt_early_mount_test स्रोतों के साथ VtsDeviceTreeEarlyMountTest उदाहरण में दिखाया गया है, परीक्षण टैग binary-test-source पर _32bit:: और _64bit:: उपसर्ग हैं। 32bit या 64bit पर समाप्त होने वाले टैग स्वचालित रूप से परीक्षणों को एक एबीआई बिटनेस के लिए उपलब्ध के रूप में चिह्नित करते हैं; यानी _32bit टैग वाले परीक्षण 64-बिट एबीआई पर निष्पादित नहीं होते हैं। टैग निर्दिष्ट न करना खाली स्ट्रिंग वाले टैग का उपयोग करने के बराबर है।

समान टैग वाले विकल्पों को समूहीकृत किया जाता है और अन्य टैग से अलग किया जाता है। उदाहरण के लिए, _32bit टैग के साथ binary-test-args केवल उसी टैग के साथ binary-test-source पर लागू किया जाता है और उसी टैग के साथ binary-test-working-directory में निष्पादित किया जाता है। binary-test-working-directory विकल्प बाइनरी परीक्षणों के लिए वैकल्पिक है, जो आपको टैग के लिए एकल वर्किंग डायरेक्टरी निर्दिष्ट करने की अनुमति देता है। जब binary-test-working-directory विकल्प को अनिर्दिष्ट छोड़ दिया जाता है, तो प्रत्येक टैग के लिए डिफ़ॉल्ट निर्देशिकाओं का उपयोग किया जाता है।

परिणाम रिपोर्ट में टैग नाम सीधे परीक्षण केस नाम से जोड़ा जाता है। उदाहरण के लिए, टैग _32bit के साथ टेस्ट केस testcase1 परिणाम रिपोर्ट में testcase1_32bit के रूप में दिखाई देता है।

बाइनरीटेस्ट टेम्पलेट के बिना लक्ष्य-पक्ष परीक्षणों को एकीकृत करें

वीटीएस में, डिफ़ॉल्ट परीक्षण प्रारूप वीटीएस रनर में बेसटेस्ट से विस्तारित होस्ट-साइड पायथन परीक्षण है। लक्ष्य-पक्ष परीक्षणों को एकीकृत करने के लिए, आपको पहले परीक्षण फ़ाइलों को डिवाइस पर धकेलना होगा, शेल कमांड का उपयोग करके परीक्षण निष्पादित करना होगा, फिर होस्ट-साइड पायथन स्क्रिप्ट का उपयोग करके परिणामों को पार्स करना होगा।

परीक्षण बायनेरिज़ पुश करें

हम VtsFilePusher लक्ष्य तैयारकर्ता का उपयोग करके फ़ाइलों को आगे बढ़ाने की अनुशंसा करते हैं। उदाहरण:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

VtsFilePusher निम्नलिखित कार्य करता है:

  1. डिवाइस कनेक्टिविटी की जाँच करता है।
  2. पूर्ण स्रोत फ़ाइल पथ निर्धारित करता है।
  3. adb push कमांड का उपयोग करके फ़ाइलों को पुश करता है।
  4. परीक्षण पूरा होने के बाद फ़ाइलें हटा देता है।

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

परीक्षण चलाएँ

डिवाइस पर फ़ाइलें भेजने के बाद, होस्ट-साइड पायथन परीक्षण स्क्रिप्ट में शेल कमांड का उपयोग करके परीक्षण चलाएं। उदाहरण:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

GtestBinaryTest टेम्पलेट

GtestBinaryTest टेम्प्लेट GTest परीक्षण बायनेरिज़ को होस्ट करता है, जिनमें से प्रत्येक में आमतौर पर कई परीक्षण मामले होते हैं। यह टेम्प्लेट सेटअप, टेस्ट केस निर्माण और परिणाम पार्सिंग विधियों को ओवरराइड करके बाइनरीटेस्ट टेम्प्लेट का विस्तार करता है, इसलिए सभी बाइनरीटेस्ट कॉन्फ़िगरेशन विरासत में मिलते हैं।

GtestBinaryTest विकल्प gtest-batch-mode जोड़ता है:

विकल्प का नाम मान प्रकार विवरण
बाइनरी-टेस्ट-प्रकार डोरी टेम्पलेट प्रकार. gtest मान का उपयोग करता है।
gtest-बैच-मोड बूलियन Gtest बायनेरिज़ को बैच मोड में चलाएँ। उदाहरण: true

सामान्य तौर पर, gtest-batch-mode true पर सेट करने से प्रदर्शन में वृद्धि होती है जबकि विश्वसनीयता थोड़ी कम हो जाती है। वीटीएस अनुपालन परीक्षणों में, कई मॉड्यूल प्रदर्शन में सुधार के लिए बैच मोड का उपयोग करते हैं। हालाँकि विश्वसनीयता के लिए, यदि मोड अनिर्दिष्ट है तो यह गैर-बैच में डिफ़ॉल्ट हो जाता है।

गैर-बैच मोड

गैर-बैच मोड प्रत्येक परीक्षण मामले के लिए GTest बाइनरी पर अलग-अलग कॉल करता है। उदाहरण के लिए, यदि GTest बाइनरी में 10 परीक्षण मामले हैं (होस्ट साइड कॉन्फ़िगरेशन द्वारा फ़िल्टर करने के बाद), तो बाइनरी को हर बार एक अलग परीक्षण फ़िल्टर के साथ डिवाइस शेल पर 10 बार कॉल किया जाता है। प्रत्येक परीक्षण मामले के लिए, एक अद्वितीय GTest परिणाम आउटपुट XML उत्पन्न होता है और टेम्पलेट द्वारा पार्स किया जाता है।

चित्र 2. गैर-बैच मोड।

गैर-बैच मोड का उपयोग करने के लाभों में शामिल हैं:

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

गैर-बैच मोड का उपयोग करने के नुकसान में शामिल हैं:

  • अनावश्यक लोड हो रहा है . हर बार जब GTest बाइनरी को कॉल किया जाता है, तो यह संबंधित लाइब्रेरीज़ को लोड करता है और प्रारंभिक क्लास सेटअप करता है।
  • संचार उपरि . परीक्षण पूरा होने के बाद, होस्ट और लक्ष्य डिवाइस परिणाम पार्सिंग और अगले आदेशों (भविष्य में अनुकूलन संभव) के लिए संचार करते हैं।

बैच मोड

जीटीएस्ट बैच मोड में, परीक्षण बाइनरी को केवल एक बार लंबे परीक्षण फ़िल्टर मान के साथ कॉल किया जाता है जिसमें होस्ट-साइड कॉन्फ़िगरेशन द्वारा फ़िल्टर किए गए सभी परीक्षण मामले शामिल होते हैं (यह गैर-बैच मोड में अनावश्यक लोडिंग समस्या से बचाता है)। आप आउटपुट.xml का उपयोग करके या टर्मिनल आउटपुट का उपयोग करके GTest के परीक्षण परिणामों को पार्स कर सकते हैं।

आउटपुट.xml (डिफ़ॉल्ट) का उपयोग करते समय:

चित्र 3. बैच मोड, आउटपुट.एक्सएमएल।

गैर-बैच मोड की तरह, परीक्षण परिणाम को GTest आउटपुट xml फ़ाइल के माध्यम से पार्स किया जाता है। हालाँकि, क्योंकि आउटपुट xml सभी परीक्षण पूरे होने के बाद उत्पन्न होता है, यदि कोई परीक्षण केस बाइनरी या डिवाइस को क्रैश कर देता है तो कोई परिणाम xml फ़ाइल उत्पन्न नहीं होती है।

टर्मिनल आउटपुट का उपयोग करते समय:

चित्र 4. बैच मोड, टर्मिनल आउटपुट।

जब GTest चल रहा होता है, तो यह परीक्षण लॉग और प्रगति को टर्मिनल पर एक प्रारूप में प्रिंट करता है जिसे परीक्षण स्थिति, परिणाम और लॉग के लिए ढांचे द्वारा पार्स किया जा सकता है।

बैच मोड का उपयोग करने के लाभों में शामिल हैं:

  • टेस्ट केस अलगाव . यदि फ्रेमवर्क कम परीक्षण फ़िल्टर (समाप्त और दुर्घटनाग्रस्त परीक्षण मामलों को छोड़कर) के साथ क्रैश के बाद बाइनरी/डिवाइस को पुनरारंभ करता है, तो गैर-बैच मोड के समान परीक्षण केस अलगाव प्रदान करता है।
  • ग्रैन्युलैरिटी । गैर-बैच मोड के समान ही टेस्ट-केस ग्रैन्युलैरिटी प्रदान करता है।

बैच मोड का उपयोग करने के नुकसान में शामिल हैं:

  • मेंटेनेन्स कोस्ट । यदि GTest लॉगिंग प्रारूप बदल जाता है, तो सभी परीक्षण विफल हो जाएंगे।
  • भ्रम । एक परीक्षण केस GTest प्रगति प्रारूप के समान कुछ प्रिंट कर सकता है, जो प्रारूप को भ्रमित कर सकता है।

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

होस्टबाइनरीटेस्ट टेम्पलेट

HostBinaryTest टेम्पलेट में होस्ट-साइड निष्पादन योग्य शामिल हैं जो अन्य निर्देशिकाओं या पायथन स्क्रिप्ट में मौजूद नहीं हैं। इन परीक्षणों में शामिल हैं:

  • संकलित परीक्षण बायनेरिज़ होस्ट पर निष्पादन योग्य
  • शेल, पायथन या अन्य भाषाओं में निष्पादन योग्य स्क्रिप्ट

एक उदाहरण VTS सुरक्षा SELinux नीति होस्ट-साइड परीक्षण है:

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest बाइनरीटेस्ट टेम्पलेट का विस्तार नहीं करता है लेकिन समान परीक्षण कॉन्फ़िगरेशन का उपयोग करता है। उपरोक्त उदाहरण में, binary-test-source विकल्प परीक्षण निष्पादन योग्य के लिए होस्ट-साइड सापेक्ष पथ निर्दिष्ट करता है, और binary-test-type host_binary_test है। बाइनरीटेस्ट टेम्पलेट के समान, बाइनरी फ़ाइल नाम का उपयोग डिफ़ॉल्ट रूप से परीक्षण केस नाम के रूप में किया जाता है।

मौजूदा टेम्पलेट्स का विस्तार करें

आप गैर-पायथन परीक्षणों को शामिल करने के लिए या विशिष्ट परीक्षण आवश्यकताओं को संभालने के लिए उन्हें उपवर्ग में विस्तारित करने के लिए सीधे परीक्षण कॉन्फ़िगरेशन में टेम्पलेट्स का उपयोग कर सकते हैं। वीटीएस रेपो में टेम्पलेट्स में निम्नलिखित एक्सटेंशन हैं:

चित्र 5. वीटीएस रेपो में मौजूदा टेम्पलेट्स का विस्तार।

डेवलपर्स को किसी भी विशिष्ट परीक्षण आवश्यकताओं के लिए किसी भी मौजूदा टेम्पलेट का विस्तार करने के लिए प्रोत्साहित किया जाता है। टेम्प्लेट का विस्तार करने के सामान्य कारणों में शामिल हैं:

  • विशेष परीक्षण सेटअप प्रक्रियाएँ, जैसे विशेष आदेशों के साथ एक उपकरण तैयार करना।
  • विभिन्न परीक्षण मामले और परीक्षण नाम उत्पन्न करना।
  • कमांड आउटपुट को पढ़कर या अन्य शर्तों का उपयोग करके परिणामों को पार्स करना।

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