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

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 एटेस्ट को बनाने, इंस्टॉल करने या टेस्ट किए बिना ही उसे ड्राई-रन किया जाता है.
-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 निर्देश का इस्तेमाल करके एवीडी बनाता है.
--[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 का इस्तेमाल करें. मॉड्यूल जैसा कि मॉड्यूल के नाम में बताया गया है. 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

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

तरीका 2: पास होने या दोहराने की अधिकतम सीमा पूरी होने तक केवल विफल परीक्षण चलाएं.

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

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

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

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

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

टेस्ट रन के हिस्से के तौर पर एवीडी की शुरुआत करें:

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

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