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

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

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

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

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

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

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

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

उदाहरण:

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

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

ट्रेडFed (नॉन-मॉड्यूल) में सीधे तौर पर इंटिग्रेट किए गए टेस्ट चलाने के लिए, नाम जैसा कि 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 के साथ होने पर, --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 को और तेज़ी से टेस्ट कर सकते हैं.

मॉड्यूल:क्लास का इस्तेमाल करना:

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

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

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

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

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