टेस्ट चलाना (Atest)

Atest, कमांड लाइन टूल है. इसकी मदद से उपयोगकर्ता, Android टेस्ट को स्थानीय तौर पर बना सकते हैं, इंस्टॉल कर सकते हैं, और चला सकते हैं. इससे टेस्ट को फिर से चलाने की प्रोसेस बहुत तेज़ हो जाती है. इसके लिए, Trade Federation test harness के कमांड लाइन विकल्पों के बारे में जानकारी होना ज़रूरी नहीं है. इस पेज पर, Android टेस्ट चलाने के लिए Atest का इस्तेमाल करने का तरीका बताया गया है.

Android के लिए टेस्ट लिखने के बारे में सामान्य जानकारी के लिए, Android प्लैटफ़ॉर्म टेस्टिंग देखें.

Atest के पूरे स्ट्रक्चर के बारे में जानने के लिए, Atest की डेवलपर गाइड देखें.

Atest के ज़रिए TEST_MAPPING फ़ाइलों में टेस्ट चलाने के बारे में जानकारी पाने के लिए, TEST_MAPPING फ़ाइलों में टेस्ट चलाना लेख पढ़ें.

Atest में कोई सुविधा जोड़ने के लिए, Atest डेवलपर वर्कफ़्लो का पालन करें.

अपना एनवायरमेंट सेट अप करना

Atest एनवायरमेंट सेट अप करने के लिए, एनवायरमेंट सेट अप करना, टारगेट चुनना, और कोड बनाना में दिए गए निर्देशों का पालन करें.

बुनियादी इस्तेमाल

Atest कमांड इस तरह से होती हैं:

atest test-to-run [optional-arguments]

वैकल्पिक आर्ग्युमेंट

यहां दी गई टेबल में, सबसे ज़्यादा इस्तेमाल किए जाने वाले आर्ग्युमेंट दिए गए हैं. पूरी सूची atest --help पर उपलब्ध है.

विकल्प ज़्यादा समय लेने वाली फ़्लाइट/ट्रेन ब्यौरा
-b --build यह टेस्ट टारगेट बनाता है. (डिफ़ॉल्ट)
-i --install यह डिवाइस पर टेस्ट आर्टफ़ैक्ट (APK) इंस्टॉल करता है. (डिफ़ॉल्ट)
-t --test जांच करता है. (डिफ़ॉल्ट)
-s --serial यह विकल्प, चुने गए डिवाइस पर टेस्ट चलाता है. एक बार में सिर्फ़ एक डिवाइस की जांच की जा सकती है.
-d --disable-teardown यह विकल्प, टेस्ट को बंद करने और उसे हटाने की सुविधा बंद कर देता है.
--dry-run टेस्ट को बनाए, इंस्टॉल किए या चलाए बिना, Atest के ड्राई-रन किए जा सकते हैं.
-m --rebuild-module-info इस विकल्प से, module-info.json फ़ाइल को फिर से बनाया जाता है.
-w --wait-for-debugger यह कुकी, डीबगर के पूरा होने का इंतज़ार करती है, ताकि उसे लागू किया जा सके.
-v --verbose यह कुकी, डीबग लेवल की लॉगिंग दिखाती है.
--iterations यह टेस्ट को तब तक चलाता है, जब तक कि तय की गई ज़्यादा से ज़्यादा संख्या पूरी नहीं हो जाती. (डिफ़ॉल्ट रूप से 10)
--rerun-until-failure [COUNT=10] यह विकल्प, सभी टेस्ट को तब तक फिर से चलाता है, जब तक कोई गड़बड़ी नहीं होती या ज़्यादा से ज़्यादा बार टेस्ट नहीं हो जाता. (डिफ़ॉल्ट रूप से 10)
--retry-any-failure [COUNT=10] यह विकल्प, फ़ेल हो चुके टेस्ट को तब तक फिर से चलाता है, जब तक वे पास नहीं हो जाते या ज़्यादा से ज़्यादा बार चलाने की सीमा पूरी नहीं हो जाती. (डिफ़ॉल्ट रूप से 10)
--start-avd यह सुविधा, एवीडी को अपने-आप बनाती है और वर्चुअल डिवाइस पर जांच करती है.
--acloud-create acloud कमांड का इस्तेमाल करके, AVD बनाता है.
--[CUSTOM_ARGS] यह टेस्ट रनर के लिए कस्टम आर्ग्युमेंट तय करता है.
-a --all-abi यह उपलब्ध सभी डिवाइस आर्किटेक्चर के लिए टेस्ट चलाता है.
--host यह टेस्ट, डिवाइस के बिना होस्ट पर पूरी तरह से चलता है.
ध्यान दें: --host की ज़रूरत वाले होस्ट टेस्ट को चलाने पर, गड़बड़ी होगी.
--history इसमें टेस्ट के नतीजे, समय के हिसाब से क्रम में दिखाए जाते हैं.
--latest-result जांच का सबसे नया नतीजा प्रिंट करता है.

-b, -i, और -t के बारे में ज़्यादा जानने के लिए, चरणों के बारे में जानकारी देना: बनाना, इंस्टॉल करना या चलाना सेक्शन देखें.

टेस्ट तय करना

टेस्ट चलाने के लिए, यहां दिए गए किसी एक आइडेंटिफ़ायर का इस्तेमाल करके, एक या एक से ज़्यादा टेस्ट तय करें:

  • मॉड्यूल का नाम
  • मॉड्यूल:क्लास
  • क्लास का नाम
  • Tradefed इंटिग्रेशन टेस्ट
  • फ़ाइल का पाथ
  • पैकेज का नाम

एक से ज़्यादा टेस्ट के रेफ़रंस को स्पेस देकर अलग करें. जैसे:

atest test-identifier-1 test-identifier-2

मॉड्यूल का नाम

पूरे टेस्ट मॉड्यूल को चलाने के लिए, उसके मॉड्यूल के नाम का इस्तेमाल करें. Android.mk या Android.bp फ़ाइल में मौजूद LOCAL_MODULE या LOCAL_PACKAGE_NAME वैरिएबल में दिखने वाला नाम डालें.

उदाहरण:

atest FrameworksServicesTests
atest CtsVideoTestCases

मॉड्यूल:क्लास

किसी मॉड्यूल में एक क्लास चलाने के लिए, Module:Class का इस्तेमाल करें. मॉड्यूल, मॉड्यूल के नाम में बताए गए मॉड्यूल के जैसा ही होता है. Class, .java फ़ाइल में टेस्ट क्लास का नाम है. यह पूरी तरह क्वालिफ़ाइड क्लास का नाम या सामान्य नाम हो सकता है.

उदाहरण:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

क्लास का नाम

मॉड्यूल का नाम साफ़ तौर पर बताए बिना किसी क्लास को चलाने के लिए, क्लास के नाम का इस्तेमाल करें.

उदाहरण:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Tradefed इंटिग्रेशन टेस्ट

TradeFed (नॉन-मॉड्यूल) में सीधे तौर पर इंटिग्रेट किए गए टेस्ट चलाने के लिए, tradefed.sh list configs कमांड के आउटपुट में दिखने वाला नाम डालें. उदाहरण के लिए:

reboot.xml टेस्ट चलाने के लिए:

atest example/reboot

native-benchmark.xml टेस्ट चलाने के लिए:

atest native-benchmark

फ़ाइल का पाथ

Atest, मॉड्यूल और इंटिग्रेशन, दोनों तरह के टेस्ट चलाने की सुविधा देता है. इसके लिए, टेस्ट फ़ाइल या डायरेक्ट्री का पाथ डालना होता है. यह क्लास के Java फ़ाइल का पाथ तय करके, किसी एक क्लास को चलाने की सुविधा भी देता है. रेलेटिव और ऐब्सलूट पाथ, दोनों का इस्तेमाल किया जा सकता है.

मॉड्यूल चलाना

नीचे दिए गए उदाहरणों में, फ़ाइल पाथ का इस्तेमाल करके CtsVideoTestCases मॉड्यूल को चलाने के दो तरीके दिखाए गए हैं.

Android repo-root से रन किया गया:

atest cts/tests/video

Android repo-root/cts/tests/video से रन किया गया:

    atest .

टेस्ट क्लास चलाना

यहां दिए गए उदाहरण में, फ़ाइल पाथ का इस्तेमाल करके, CtsVideoTestCases मॉड्यूल में किसी क्लास को चलाने का तरीका बताया गया है.

Android repo-root से:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

इंटिग्रेशन टेस्ट चलाना

यहां दिए गए उदाहरण में, Android repo-root से फ़ाइल पाथ का इस्तेमाल करके, इंटिग्रेशन टेस्ट चलाने का तरीका बताया गया है:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

पैकेज का नाम

Atest, पैकेज के नाम से टेस्ट खोजने की सुविधा देता है.

उदाहरण:

    atest com.android.server.wm
    atest com.android.uibench.janktests

चरणों के बारे में बताएं: बनाएं, इंस्टॉल करें या चलाएं

-b, -i, और -t विकल्पों का इस्तेमाल करके यह तय करें कि कौनसे चरण चलाने हैं. अगर कोई विकल्प नहीं चुना जाता है, तो सभी चरण पूरे किए जाते हैं.

  • सिर्फ़ टारगेट बनाएं: atest -b test-to-run
  • सिर्फ़ इन टेस्ट को चलाएं: atest -t test-to-run
  • APK इंस्टॉल करें और टेस्ट चलाएं: atest -it test-to-run
  • बनाएं और चलाएं, लेकिन इंस्टॉल न करें: atest -bt test-to-run

Atest, टेस्ट को क्लीनअप या टियरडाउन चरण को छोड़ने के लिए मजबूर कर सकता है. कई टेस्ट, जैसे कि सीटीएस, टेस्ट पूरा होने के बाद डिवाइस को क्लीन अप कर देते हैं. इसलिए, --disable-teardown पैरामीटर के बिना -t के साथ टेस्ट को फिर से चलाने की कोशिश करने पर, टेस्ट पूरा नहीं होगा. टेस्ट को बार-बार करने के लिए, टेस्ट के डेटा को मिटाने वाले चरण को स्किप करने के लिए, -d से पहले -t का इस्तेमाल करें.

atest -d test-to-run
atest -t test-to-run

खास तरीके लागू करना

Atest, टेस्ट क्लास में कुछ खास तरीकों को चलाने की सुविधा देता है. हालांकि, पूरे मॉड्यूल को बनाने की ज़रूरत होती है, लेकिन इससे टेस्ट चलाने में लगने वाला समय कम हो जाता है. किसी खास तरीके को चलाने के लिए, क्लास की पहचान करें. इसके लिए, क्लास की पहचान करने के लिए इस्तेमाल किए जाने वाले किसी भी तरीके (मॉड्यूल:क्लास, फ़ाइल पाथ वगैरह) का इस्तेमाल करें. इसके बाद, तरीके का नाम जोड़ें:

atest reference-to-class#method1

एक से ज़्यादा तरीके बताने पर, उन्हें कॉमा लगाकर अलग करें:

atest reference-to-class#method1,method2,method3

उदाहरण:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

यहां दिए गए दो उदाहरणों में, testFlagChange तरीके को चलाने के सबसे सही तरीके बताए गए हैं. सिर्फ़ क्लास के नाम का इस्तेमाल करने के बजाय, इन उदाहरणों का इस्तेमाल करना बेहतर होता है. इसकी वजह यह है कि मॉड्यूल या Java फ़ाइल की जगह की जानकारी देने से, Atest को टेस्ट का पता बहुत तेज़ी से चल जाता है.

Module:Class का इस्तेमाल करना:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Android repo-root से:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

अलग-अलग क्लास और मॉड्यूल से कई तरीके चलाए जा सकते हैं:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

एक से ज़्यादा क्लास चलाना

एक से ज़्यादा क्लास चलाने के लिए, उन्हें स्पेस से अलग करें. ऐसा ही तरीका एक से ज़्यादा टेस्ट चलाने के लिए भी इस्तेमाल किया जाता है. Atest, क्लास को कुशलता से बनाता और चलाता है. इसलिए, किसी मॉड्यूल में क्लास का सबसेट तय करने से, पूरे मॉड्यूल को चलाने की तुलना में परफ़ॉर्मेंस बेहतर होती है.

एक ही मॉड्यूल में दो क्लास चलाने के लिए:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

अलग-अलग मॉड्यूल में दो क्लास चलाने के लिए:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

GTest बाइनरी चलाएं

Atest, GTest बाइनरी चला सकता है. सभी उपलब्ध डिवाइस आर्किटेक्चर के लिए इन टेस्ट को चलाने के लिए, -a का इस्तेमाल करें. इस उदाहरण में, ये armeabi-v7a (ARM 32-बिट) और arm64-v8a (ARM 64-बिट) हैं.

इनपुट टेस्ट का उदाहरण:

atest -a libinput_tests inputflinger_tests

चलाने के लिए कोई खास GTest बाइनरी चुनने के लिए, टेस्ट का नाम बताने के लिए कोलन (:) और किसी एक तरीके के बारे में ज़्यादा जानकारी देने के लिए हैशटैग (#) का इस्तेमाल करें.

उदाहरण के लिए, टेस्ट की इस परिभाषा के लिए: 

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

पूरे टेस्ट के बारे में बताने के लिए, यह कमांड चलाएं: 

atest inputflinger_tests:InputDispatcherTest

इसके अलावा, यहां दिए गए तरीकों का इस्तेमाल करके अलग-अलग टेस्ट चलाएं: 

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

TEST_MAPPING में टेस्ट चलाना

Atest, TEST_MAPPING फ़ाइलों में टेस्ट चला सकता है.

सबमिट करने से पहले की जाने वाली जांचों को अपने-आप चलाना

मौजूदा और पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने से पहले किए जाने वाले टेस्ट चलाएं:

atest

/path/to/project और इसकी पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने से पहले किए जाने वाले टेस्ट चलाएं:

atest --test-mapping /path/to/project

किसी टेस्ट ग्रुप को चलाना

ये टेस्ट ग्रुप उपलब्ध हैं: presubmit(डिफ़ॉल्ट), postsubmit, mainline-presubmit, और all.

मौजूदा और पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने के बाद किए जाने वाले टेस्ट चलाएं:

atest :postsubmit

TEST_MAPPING फ़ाइलों में मौजूद सभी ग्रुप से टेस्ट चलाएं:

atest :all

/path/to/project और इसकी पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने के बाद किए जाने वाले टेस्ट चलाएं:

atest --test-mapping /path/to/project:postsubmit

/path/to/project और इसकी पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, मेनलाइन टेस्ट चलाएं:

atest --test-mapping /path/to/project:mainline-presubmit

सबडायरेक्ट्री में टेस्ट चलाना

डिफ़ॉल्ट रूप से, Atest सिर्फ़ TEST_MAPPING फ़ाइलों में टेस्ट खोजता है. ये फ़ाइलें, मौजूदा या दी गई डायरेक्ट्री से लेकर इसकी पैरंट डायरेक्ट्री तक होती हैं. अगर आपको सबडाइरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में भी जांचें चलानी हैं, तो --include-subdirs का इस्तेमाल करके, Atest को उन जांचों को भी शामिल करने के लिए मजबूर करें:

atest --include-subdirs /path/to/project

इटरेशन में टेस्ट चलाना

--iterations आर्ग्युमेंट पास करके, एक से ज़्यादा बार टेस्ट चलाएं. टेस्ट पास हो या फ़ेल, Atest टेस्ट को तब तक दोहराता रहेगा, जब तक कि ज़्यादा से ज़्यादा बार दोहराने की सीमा पूरी नहीं हो जाती.

उदाहरण:

डिफ़ॉल्ट रूप से, Atest 10 बार दोहराता है. इटरेशन की संख्या, धनात्मक पूर्णांक होनी चाहिए.

atest test-to-run --iterations
atest test-to-run --iterations 5

इन तरीकों से, फ़्लेकी टेस्ट का पता लगाना आसान हो जाता है:

पहला तरीका: सभी टेस्ट तब तक चलाएं, जब तक कोई गड़बड़ी न हो या ज़्यादा से ज़्यादा बार टेस्ट न हो जाए.

  • जब कोई गड़बड़ी होती है या जब इटरेशन डिफ़ॉल्ट रूप से 10वें राउंड पर पहुंच जाता है, तब रुक जाता है. 
    atest test-to-run --rerun-until-failure
  • जब कोई गड़बड़ी होती है या जब इटरेशन 100वें राउंड पर पहुंच जाता है, तब रोकें. 
    atest test-to-run --rerun-until-failure 100

दूसरा तरीका: सिर्फ़ उन टेस्ट को तब तक चलाएं जब तक वे पास न हो जाएं या ज़्यादा से ज़्यादा बार न चल जाएं.

  • मान लें कि test-to-run में कई टेस्ट केस हैं और उनमें से एक टेस्ट पूरा नहीं हो सका. सिर्फ़ फ़ेल हुए टेस्ट को 10 बार (डिफ़ॉल्ट रूप से) या तब तक चलाएं, जब तक टेस्ट पास न हो जाए. 
    atest test-to-run --retry-any-failure
  • जब टेस्ट पास हो जाए या 100वें राउंड तक पहुंच जाए, तो उसे चलाना बंद कर दें. 
    atest test-to-run --retry-any-failure 100

AVD पर टेस्ट चलाना

Atest, नए बनाए गए एवीडी पर टेस्ट चला सकता है. AVD और बिल्ड आर्टफ़ैक्ट बनाने के लिए, acloud create चलाएं. इसके बाद, अपनी जांच चलाने के लिए यहां दिए गए उदाहरणों का इस्तेमाल करें.

AVD शुरू करें और उस पर टेस्ट चलाएं:

acloud create --local-instance --local-image && atest test-to-run

टेस्ट रन के हिस्से के तौर पर, AVD शुरू करें:

atest test-to-run --acloud-create "--local-instance --local-image"

ज़्यादा जानकारी के लिए, acloud create --help चलाएँ.

मॉड्यूल को विकल्प पास करना

Atest, टेस्ट मॉड्यूल को विकल्प पास कर सकता है. अपने टेस्ट रन में TradeFed कमांड लाइन के विकल्प जोड़ने के लिए, इस स्ट्रक्चर का इस्तेमाल करें. साथ ही, पक्का करें कि आपके कस्टम आर्ग्युमेंट, Tradefed कमांड लाइन के विकल्प के फ़ॉर्मैट के मुताबिक हों.

atest test-to-run -- [CUSTOM_ARGS]

टेस्ट कॉन्फ़िगरेशन फ़ाइल में तय किए गए, टेस्ट तैयार करने वालों या टेस्ट रनर को टेस्ट मॉड्यूल के विकल्प पास करें:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

किसी रनर टाइप या क्लास को विकल्प पास करें:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

सिर्फ़ टेस्ट करने के विकल्पों के बारे में ज़्यादा जानने के लिए, मॉड्यूल को विकल्प पास करना लेख पढ़ें.