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

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

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

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

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

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 के बारे में ज़्यादा जानकारी के लिए, सिलसिलेवार निर्देश दें: बिल्ड, इंस्टॉल या चलाएं सेक्शन देखें.

जांच के बारे में बताएं

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

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

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

atest test-identifier-1 test-identifier-2

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

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

उदाहरण:

atest FrameworksServicesTests
atest CtsVideoTestCases

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

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

उदाहरण:

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

क्लास का नाम

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

उदाहरण:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

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

सीधे 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

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

एवीडी पर टेस्ट चलाना

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

एवीडी की शुरुआत करें और इस पर टेस्ट करें:

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, टेस्ट मॉड्यूल को विकल्प पास कर सकता है. अपने टेस्ट रन में, TreFed कमांड लाइन के विकल्प जोड़ने के लिए, यहां दिए गए स्ट्रक्चर का इस्तेमाल करें. साथ ही, पक्का करें कि आपके कस्टम आर्ग्युमेंट, Trefed कमांड लाइन के फ़ॉर्मैट के हिसाब से हों.

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

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