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

Atest एक कमांड-लाइन टूल है. इसकी मदद से, उपयोगकर्ता स्थानीय तौर पर Android टेस्ट बना सकते हैं, इंस्टॉल कर सकते हैं, और चला सकते हैं. इससे टेस्ट को फिर से चलाने में काफ़ी कम समय लगता है. इसके लिए, Trade Federation टेस्ट हार्नेस के कमांड-लाइन विकल्पों के बारे में जानने की ज़रूरत नहीं होती. इस पेज पर, 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 डिवाइस पर टेस्ट आर्टफ़ैक्ट (APKs) इंस्टॉल करता है. (डिफ़ॉल्ट)
-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 यह AVD अपने-आप बनाता है और वर्चुअल डिवाइस पर टेस्ट चलाता है.
--acloud-create acloud कमांड का इस्तेमाल करके, AVD बनाता है.
--[CUSTOM_ARGS] टेस्ट रन करने वालों के लिए कस्टम आर्ग्युमेंट तय करता है.
-a --all-abi यह सभी उपलब्ध डिवाइस आर्किटेक्चर के लिए टेस्ट चलाता है.
--host यह टेस्ट, डिवाइस के बिना होस्ट पर पूरी तरह से चलता है.
ध्यान दें: --host के साथ काम करने वाले डिवाइस की ज़रूरत वाले होस्ट टेस्ट को चलाने पर, वह काम नहीं करेगा.
--history टेस्ट के नतीजों को समय के हिसाब से क्रम में दिखाता है.
--latest-result जांच का नया नतीजा प्रिंट करता है.

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

टेस्ट तय करना

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

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

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

atest test-identifier-1 test-identifier-2

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

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

उदाहरण:

atest FrameworksServicesTests
atest CtsVideoTestCases

Module:Class

किसी मॉड्यूल में एक क्लास चलाने के लिए, Module: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, किसी टेस्ट को क्लीनअप या टियरडाउन चरण को छोड़ने के लिए मजबूर कर सकता है. सीटीएस जैसे कई टेस्ट, टेस्ट पूरा होने के बाद डिवाइस को साफ़ कर देते हैं. इसलिए, -t पैरामीटर के बिना -t के साथ अपना टेस्ट फिर से चलाने की कोशिश करने पर, टेस्ट पूरा नहीं होगा.--disable-teardown टेस्ट को क्लीन अप करने के चरण को छोड़ने और बार-बार टेस्ट करने के लिए, -d के पहले -t का इस्तेमाल करें.

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

खास तरीके चलाना

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

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 पर टेस्ट चला सकता है. 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

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