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
सिर्फ़ जांच के विकल्पों के बारे में ज़्यादा जानकारी के लिए, यहां देखें मॉड्यूल के लिए विकल्पों को पास करें.