AOSP में, टेस्ट मॉड्यूल के लिए टेस्ट टेंप्लेट शामिल होते हैं. ये मॉड्यूल, VTS रनर के BaseTest के होस्ट-साइड Python सबक्लास नहीं होते.
डेवलपर, इन टेंप्लेट का इस्तेमाल करके, इस तरह के टेस्ट को इंटिग्रेट करने में लगने वाले समय को कम कर सकते हैं. इस सेक्शन में, टेस्ट टेंप्लेट (ये VTS की testcases/template डायरेक्ट्री में मौजूद होते हैं) को कॉन्फ़िगर करने और इस्तेमाल करने के बारे में बताया गया है. साथ ही, आम तौर पर इस्तेमाल किए जाने वाले टेंप्लेट के उदाहरण भी दिए गए हैं.
BinaryTest टेंप्लेट
BinaryTest टेंप्लेट का इस्तेमाल करके, VTS में टारगेट डिवाइस पर चलने वाले टेस्ट इंटिग्रेट करें. टारगेट-साइड टेस्ट में ये शामिल हैं:
- C++ पर आधारित टेस्ट, डिवाइस पर कंपाइल और पुश किए गए
- टारगेट-साइड Python टेस्ट, बाइनरी के तौर पर कंपाइल किए गए
- डिवाइसों पर चलने वाली शेल स्क्रिप्ट
इन टेस्ट को BinaryTest टेंप्लेट के साथ या उसके बिना, VTS में इंटिग्रेट किया जा सकता है.
टारगेट-साइड टेस्ट को BinaryTest टेंप्लेट के साथ इंटिग्रेट करना
BinaryTest टेंप्लेट को इस तरह से डिज़ाइन किया गया है कि डेवलपर, टारगेट-साइड टेस्ट को आसानी से इंटिग्रेट कर सकें. ज़्यादातर मामलों में, 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एट्रिब्यूट, टेंप्लेट के हिसाब से होते हैं.- टेस्ट बाइनरी सोर्स के रिलेटिव होस्ट पाथ की जानकारी देने पर, टेंप्लेट को तैयारी, फ़ाइल पुश करने, टेस्ट को लागू करने, नतीजे को पार्स करने, और क्लीनअप करने की सुविधा मिलती है.
- टेंप्लेट में, सबक्लास के लिए टेस्ट केस बनाने से जुड़े तरीके शामिल होते हैं, ताकि उन्हें बदला जा सके.
- टेंप्लेट में, हर टेस्ट बाइनरी मॉड्यूल के लिए एक टेस्ट केस माना जाता है. साथ ही, बाइनरी सोर्स फ़ाइल के नाम का इस्तेमाल, डिफ़ॉल्ट रूप से टेस्ट केस के नाम के तौर पर किया जाता है.
कॉन्फ़िगरेशन के विकल्प
BinaryTest टेंप्लेट, कॉन्फ़िगरेशन के इन विकल्पों के साथ काम करता है:
| विकल्प का नाम | वैल्यू टाइप | ब्यौरा |
|---|---|---|
| binary-test-source | स्ट्रिंग | होस्ट पर vts टेस्ट-केस डायरेक्ट्री के हिसाब से, बाइनरी टेस्ट सोर्स पाथ. उदाहरण: DATA/nativetest/test |
| binary-test-working-directory | स्ट्रिंग | वर्किंग डायरेक्ट्री (डिवाइस-साइड पाथ). उदाहरण: /data/local/tmp/testing/ |
| binary-test-envp | स्ट्रिंग | बाइनरी के लिए एनवायरमेंट वैरिएबल. उदाहरण: PATH=/new:$PATH |
| binary-test-args | स्ट्रिंग | आर्ग्युमेंट या फ़्लैग की जांच करना. उदाहरण: --gtest_filter=test1 |
| binary-test-ld-library-path | स्ट्रिंग | LD_LIBRARY_PATH एनवायरमेंट वैरिएबल.उदाहरण: /data/local/tmp/lib |
| binary-test-disable-framework | बूलियन | टेस्ट से पहले Android फ़्रेमवर्क को बंद करने के लिए, adb stop चलाएं.
उदाहरण: true |
| binary-test-stop-native-servers | बूलियन | जांच के दौरान, सही तरीके से कॉन्फ़िगर किए गए सभी नेटिव सर्वर बंद कर दें. उदाहरण:
true |
| binary-test-type | स्ट्रिंग | टेंप्लेट का टाइप. अन्य टेंप्लेट टाइप, इस टेंप्लेट से जुड़े होते हैं. हालांकि, आपको इस टेंप्लेट के लिए यह विकल्प नहीं बताना होगा, क्योंकि आपने पहले ही 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 के तौर पर दिखता है.
BinaryTest टेंप्लेट के बिना टारगेट-साइड टेस्ट इंटिग्रेट करना
VTS में, डिफ़ॉल्ट टेस्ट फ़ॉर्मैट, होस्ट-साइड Python टेस्ट होता है. इसे VTS रनर में BaseTest से एक्सटेंड किया जाता है. टारगेट-साइड टेस्ट इंटिग्रेट करने के लिए, आपको सबसे पहले डिवाइस पर टेस्ट फ़ाइलें पुश करनी होंगी. इसके बाद, शेल कमांड का इस्तेमाल करके टेस्ट चलाने होंगे. इसके बाद, होस्ट-साइड Python स्क्रिप्ट का इस्तेमाल करके नतीजों को पार्स करना होगा.
पुश टेस्ट बाइनरी
हमारा सुझाव है कि आप VtsFilePusher टारगेट तैयार करने वाले टूल का इस्तेमाल करके फ़ाइलें डालें.
उदाहरण:
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
<option name="push" value="DATA/test->/data/local/tmp/test"/>
</target_preparer>
VtsFilePusher ये काम करता है:
- डिवाइस की कनेक्टिविटी की जांच करता है.
- सोर्स फ़ाइल का ऐब्सलूट पाथ तय करता है.
adb pushकमांड का इस्तेमाल करके फ़ाइलों को पुश करता है.- जांच पूरी होने के बाद फ़ाइलों को मिटा देता है.
इसके अलावा, होस्ट-साइड Python टेस्ट स्क्रिप्ट का इस्तेमाल करके, फ़ाइलों को मैन्युअल रूप से भी पुश किया जा सकता है. यह स्क्रिप्ट, इसी तरह की प्रोसेस का पालन करती है.
टेस्ट चलाना
डिवाइस पर फ़ाइलें पुश करने के बाद, होस्ट-साइड Python टेस्ट स्क्रिप्ट में शेल निर्देशों का इस्तेमाल करके टेस्ट चलाएं. उदाहरण:
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 टेस्ट बाइनरी को होस्ट करता है. आम तौर पर, इनमें से हर एक में कई टेस्ट केस होते हैं. यह टेंप्लेट, सेटअप, टेस्ट केस बनाने, और नतीजे को पार्स करने के तरीकों को बदलकर, BinaryTest टेंप्लेट को बड़ा करता है. इससे, BinaryTest के सभी कॉन्फ़िगरेशन इनहेरिट हो जाते हैं.
GtestBinaryTest, gtest-batch-mode विकल्प जोड़ता है:
| विकल्प का नाम | वैल्यू टाइप | ब्यौरा |
|---|---|---|
| binary-test-type | स्ट्रिंग | टेंप्लेट का टाइप. gtest वैल्यू का इस्तेमाल किया गया है. |
| gtest-batch-mode | बूलियन | Gtest बाइनरी को बैच मोड में चलाएं. उदाहरण: true |
आम तौर पर, gtest-batch-mode को true पर सेट करने से परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे भरोसेमंदता थोड़ी कम हो जाती है. वीटीएस के अनुपालन से जुड़ी जांच में, कई मॉड्यूल परफ़ॉर्मेंस को बेहतर बनाने के लिए, बैच मोड का इस्तेमाल करते हैं. हालांकि, अगर मोड की जानकारी नहीं दी गई है, तो डिफ़ॉल्ट रूप से नॉन-बैच मोड लागू होता है.
नॉन-बैच मोड
नॉन-बैच मोड, हर टेस्ट केस के लिए GTest बाइनरी को अलग-अलग कॉल करता है. उदाहरण के लिए, अगर GTest बाइनरी में 10 टेस्ट केस हैं (होस्ट साइड कॉन्फ़िगरेशन के हिसाब से फ़िल्टर करने के बाद), तो डिवाइस शेल पर बाइनरी को 10 बार कॉल किया जाता है. हर बार, अलग-अलग टेस्ट फ़िल्टर का इस्तेमाल किया जाता है. हर टेस्ट केस के लिए, टेंप्लेट की मदद से एक यूनीक GTest नतीजा आउटपुट एक्सएमएल जनरेट और पार्स किया जाता है.
नॉन-बैच मोड का इस्तेमाल करने के फ़ायदे:
- टेस्ट केस को अलग करना. किसी एक टेस्ट केस में क्रैश या हैंग होने का असर, अन्य टेस्ट केस पर नहीं पड़ता.
- ज़्यादा जानकारी. हर टेस्ट केस के लिए प्रोफ़ाइलिंग/कवरेज मेज़रमेंट, systrace, bugreport, logcat वगैरह आसानी से मिल जाता है. हर टेस्ट केस के खत्म होने के तुरंत बाद, टेस्ट के नतीजे और लॉग वापस पा लिए जाते हैं.
बिना बैच मोड का इस्तेमाल करने के नुकसानों में ये शामिल हैं:
- अनावश्यक लोडिंग. GTest बाइनरी को हर बार कॉल करने पर, वह इससे जुड़ी लाइब्रेरी लोड करती है और क्लास के शुरुआती सेटअप करती है.
- कम्यूनिकेशन ओवरहेड. जांच पूरी होने के बाद, होस्ट और टारगेट डिवाइस, नतीजे को पार्स करने और अगले निर्देशों के लिए आपस में बातचीत करते हैं. इससे आने वाले समय में ऑप्टिमाइज़ेशन की संभावना बढ़ती है.
बैच मोड
GTest के बैच मोड में, टेस्ट बाइनरी को सिर्फ़ एक बार लंबी टेस्ट फ़िल्टर वैल्यू के साथ कॉल किया जाता है. इसमें होस्ट-साइड कॉन्फ़िगरेशन से फ़िल्टर किए गए सभी टेस्ट केस शामिल होते हैं. इससे, नॉन-बैच मोड में, बार-बार लोड होने की समस्या से बचा जा सकता है. GTest के लिए, टेस्ट के नतीजों को पार्स करने के लिए, output.xml या टर्मिनल आउटपुट का इस्तेमाल किया जा सकता है.
output.xml (डिफ़ॉल्ट) का इस्तेमाल करते समय:
नॉन-बैच मोड की तरह ही, टेस्ट के नतीजे को GTest आउटपुट एक्सएमएल फ़ाइल के ज़रिए पार्स किया जाता है. हालांकि, सभी टेस्ट पूरे होने के बाद आउटपुट एक्सएमएल जनरेट होता है. इसलिए, अगर किसी टेस्ट केस की वजह से बाइनरी या डिवाइस क्रैश हो जाता है, तो कोई नतीजा एक्सएमएल फ़ाइल जनरेट नहीं होती.
टर्मिनल आउटपुट का इस्तेमाल करते समय:
GTest के चलने के दौरान, यह टेस्ट लॉग और प्रोग्रेस को टर्मिनल पर एक ऐसे फ़ॉर्मैट में प्रिंट करता है जिसे टेस्ट स्टेटस, नतीजों, और लॉग के लिए फ़्रेमवर्क से पार्स किया जा सकता है.
एक साथ कई फ़ाइलें अपलोड करने के मोड के फ़ायदे:
- टेस्ट केस को अलग करना. अगर फ़्रेमवर्क, क्रैश होने के बाद बाइनरी/डिवाइस को कम टेस्ट फ़िल्टर के साथ रीस्टार्ट करता है, तो यह नॉन-बैच मोड के जैसे ही टेस्ट केस अलग करने का लेवल देता है. इसमें पूरे हो चुके और क्रैश हो चुके टेस्ट केस शामिल नहीं होते.
- ज़्यादा जानकारी. यह बैच मोड के मुकाबले, टेस्ट-केस के बारे में उतनी ही जानकारी देता है.
बैच मोड का इस्तेमाल करने के नुकसानों में ये शामिल हैं:
- रखरखाव की लागत. GTest लॉगिंग फ़ॉर्मैट में बदलाव होने पर, सभी टेस्ट बंद हो जाएंगे.
- उलझन. कोई टेस्ट केस, GTest के प्रोग्रेस फ़ॉर्मैट जैसा कुछ प्रिंट कर सकता है. इससे फ़ॉर्मैट में भ्रम हो सकता है.
इन नुकसानों की वजह से, हमने कमांड लाइन आउटपुट का इस्तेमाल करने का विकल्प कुछ समय के लिए हटा दिया है. हम आने वाले समय में इस विकल्प पर फिर से विचार करेंगे, ताकि इस सुविधा को और बेहतर बनाया जा सके.
HostBinaryTest टेंप्लेट
HostBinaryTest टेंप्लेट में, होस्ट-साइड के ऐसे एक्सीक्यूटेबल शामिल होते हैं जो अन्य डायरेक्ट्री या Python स्क्रिप्ट में मौजूद नहीं होते. इन टेस्ट में ये शामिल हैं:
- होस्ट पर एक्ज़ीक्यूट की जा सकने वाली, कंपाइल की गई टेस्ट बाइनरी
- शेल, Python या अन्य भाषाओं में एक्ज़ीक्यूटेबल स्क्रिप्ट
उदाहरण के लिए, वीटीएस के तहत, होस्ट-साइड पर की जाने वाली, सुरक्षा से जुड़ी 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, BinaryTest टेंप्लेट को एक्सटेंड नहीं करता, लेकिन मिलते-जुलते टेस्ट कॉन्फ़िगरेशन का इस्तेमाल करता है. ऊपर दिए गए उदाहरण में, binary-test-source
विकल्प, टेस्ट के लिए इस्तेमाल होने वाले प्रोग्राम के होस्ट-साइड रिलेटिव पाथ की जानकारी देता है और
binary-test-type host_binary_test है. BinaryTest टेंप्लेट की तरह ही, बाइनरी फ़ाइल के नाम का इस्तेमाल डिफ़ॉल्ट रूप से, टेस्ट केस के नाम के तौर पर किया जाता है.
मौजूदा टेंप्लेट का इस्तेमाल करना
टेस्ट कॉन्फ़िगरेशन में टेंप्लेट का इस्तेमाल करके, नॉन-Python टेस्ट शामिल किए जा सकते हैं. इसके अलावा, टेस्ट की खास ज़रूरतों को पूरा करने के लिए, उन्हें किसी सबक्लास में भी शामिल किया जा सकता है. VTS repo में मौजूद टेंप्लेट के ये एक्सटेंशन हैं:
डेवलपर को किसी खास जांच की ज़रूरतों के लिए, किसी भी मौजूदा टेंप्लेट को बढ़ाने का सुझाव दिया जाता है. टेंप्लेट का इस्तेमाल ज़्यादा समय तक करने की सामान्य वजहें ये हैं:
- टेस्ट सेटअप करने के खास तरीके, जैसे कि खास निर्देशों की मदद से डिवाइस को तैयार करना.
- अलग-अलग टेस्ट केस और टेस्ट के नाम जनरेट करना.
- कमांड के आउटपुट को पढ़कर या अन्य शर्तों का इस्तेमाल करके, नतीजों को पार्स करना.
मौजूदा टेंप्लेट को आसानी से बड़ा करने के लिए, टेंप्लेट में हर फ़ंक्शन के लिए खास तरीके शामिल होते हैं. अगर आपने मौजूदा टेंप्लेट के डिज़ाइन को बेहतर बनाया है, तो हमारा सुझाव है कि आप VTS कोड बेस में योगदान दें.