एटेस्ट एक कमांड लाइन टूल है जो उपयोगकर्ताओं को स्थानीय स्तर पर एंड्रॉइड टेस्ट बनाने, इंस्टॉल करने और चलाने की अनुमति देता है, ट्रेड फेडरेशन टेस्ट हार्नेस कमांड लाइन विकल्पों के ज्ञान की आवश्यकता के बिना टेस्ट री-रन को बहुत तेज करता है। यह पृष्ठ बताता है कि एंड्रॉइड परीक्षण चलाने के लिए एटेस्ट का उपयोग कैसे करें।
Android के लिए परीक्षण लिखने की सामान्य जानकारी के लिए, Android प्लेटफ़ॉर्म परीक्षण देखें।
एटेस्ट की समग्र संरचना के बारे में जानकारी के लिए, एटेस्ट डेवलपर गाइड देखें।
Atest के माध्यम से TEST_MAPPING फ़ाइलों में परीक्षण चलाने की जानकारी के लिए, TEST_MAPPING फ़ाइलों में परीक्षण चलाना देखें।
Atest में एक सुविधा जोड़ने के लिए, Atest डेवलपर वर्कफ़्लो का पालन करें।
अपना परिवेश स्थापित करें
अपना एटेस्ट वातावरण स्थापित करने के लिए, पर्यावरण स्थापित करना , लक्ष्य चुनना और कोड बनाना में दिए गए निर्देशों का पालन करें।
बुनियादी उपयोग
अटेस्ट कमांड निम्नलिखित रूप लेते हैं:
atest test-to-run [optional-arguments]
वैकल्पिक तर्क
निम्न तालिका सबसे अधिक उपयोग किए जाने वाले तर्कों को सूचीबद्ध करती है। पूरी सूची atest --help
के माध्यम से उपलब्ध है।
विकल्प | लंबा विकल्प | विवरण |
---|---|---|
-b | --build | परीक्षण लक्ष्य बनाता है. (गलती करना) |
-i | --install | डिवाइस पर परीक्षण कलाकृतियाँ (एपीके) स्थापित करता है। (गलती करना) |
-t | --test | परीक्षण चलाता है. (गलती करना) |
-s | --serial | निर्दिष्ट डिवाइस पर परीक्षण चलाता है। एक समय में एक डिवाइस का परीक्षण किया जा सकता है। |
-d | --disable-teardown | परीक्षण विच्छेदन और सफ़ाई को अक्षम करता है। |
| --info | निर्दिष्ट लक्ष्यों के बारे में प्रासंगिक जानकारी दिखाता है, फिर बाहर निकल जाता है। |
| --dry-run | वास्तव में निर्माण, स्थापना या परीक्षण चलाए बिना एटेस्ट को ड्राई-रन करता है। |
-m | --rebuild-module-info | module-info.json फ़ाइल के पुनर्निर्माण को बाध्य करता है। |
-w | --wait-for-debugger | निष्पादित करने से पहले डिबगर के समाप्त होने की प्रतीक्षा करता है। |
-v | --verbose | DEBUG स्तर लॉगिंग प्रदर्शित करता है। |
| --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
मॉड्यूल: कक्षा
मॉड्यूल के भीतर एकल कक्षा चलाने के लिए, मॉड्यूल: क्लास का उपयोग करें। मॉड्यूल वैसा ही है जैसा मॉड्यूल नाम में वर्णित है। क्लास .java
फ़ाइल में टेस्ट क्लास का नाम है, और पूरी तरह से योग्य क्लास का नाम या मूल नाम हो सकता है।
उदाहरण:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
कक्षा का नाम
मॉड्यूल नाम को स्पष्ट रूप से बताए बिना एकल क्लास चलाने के लिए, क्लास नाम का उपयोग करें।
उदाहरण:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
ट्रेडफेड एकीकरण परीक्षण
उन परीक्षणों को चलाने के लिए जो सीधे ट्रेडफेड (गैर-मॉड्यूल) में एकीकृत हैं, नाम इनपुट करें जैसा कि यह tradefed.sh list configs
कमांड के आउटपुट में दिखाई देता है। उदाहरण के लिए:
reboot.xml
परीक्षण चलाने के लिए:
atest example/reboot
native-benchmark.xml
परीक्षण चलाने के लिए:
atest native-benchmark
दस्तावेज पथ
एटेस्ट मॉड्यूल-आधारित परीक्षण और एकीकरण-आधारित परीक्षण दोनों को उनकी परीक्षण फ़ाइल या निर्देशिका में उपयुक्त पथ इनपुट करके चलाने का समर्थन करता है। यह क्लास की जावा फ़ाइल के लिए पथ निर्दिष्ट करके एकल क्लास चलाने का भी समर्थन करता है। सापेक्ष और निरपेक्ष दोनों पथ समर्थित हैं।
एक मॉड्यूल चलाएँ
निम्नलिखित उदाहरण फ़ाइल पथ का उपयोग करके CtsVideoTestCases
मॉड्यूल को चलाने के दो तरीके दिखाते हैं।
एंड्रॉइड repo-root
से चलाएं:
atest cts/tests/video
एंड्रॉइड repo-root/cts/tests/video
से चलाएं:
atest .
एक परीक्षण कक्षा चलाएँ
निम्नलिखित उदाहरण दिखाता है कि फ़ाइल पथ का उपयोग करके CtsVideoTestCases
मॉड्यूल के भीतर एक विशिष्ट कक्षा को कैसे चलाया जाए।
एंड्रॉइड repo-root
से:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
एक एकीकरण परीक्षण चलाएँ
निम्नलिखित उदाहरण दिखाता है कि एंड्रॉइड repo-root
से फ़ाइल पथ का उपयोग करके एकीकरण परीक्षण कैसे चलाया जाए:
atest tools/tradefederation/contrib/res/config/example/reboot.xml
पैकेज का नाम
एटेस्ट पैकेज नाम से परीक्षणों की खोज का समर्थन करता है।
उदाहरण:
atest com.android.server.wm
atest com.android.uibench.janktests
चरण निर्दिष्ट करें: बनाएँ, स्थापित करें, या चलाएँ
कौन से चरण चलाने हैं यह निर्दिष्ट करने के लिए -b
, -i
, और -t
विकल्पों का उपयोग करें। यदि आप कोई विकल्प निर्दिष्ट नहीं करते हैं, तो सभी चरण चलते हैं।
- केवल लक्ष्य बनाएँ:
atest -b test-to-run
- केवल परीक्षण चलाएँ:
atest -t test-to-run
- एपीके इंस्टॉल करें और परीक्षण चलाएं:
atest -it test-to-run
- बनाएं और चलाएं, लेकिन इंस्टॉल न करें:
atest -bt test-to-run
एटेस्ट किसी परीक्षण को सफ़ाई या फाड़ने के चरण को छोड़ने के लिए बाध्य कर सकता है। कई परीक्षण, जैसे सीटीएस, परीक्षण चलाने के बाद डिवाइस को साफ़ करते हैं, इसलिए -t
के साथ आपके परीक्षण को फिर से चलाने का प्रयास --disable-teardown
पैरामीटर के बिना विफल हो जाएगा। परीक्षण सफ़ाई चरण को छोड़ने और पुनरावृत्तीय रूप से परीक्षण करने के लिए -t
से पहले -d
उपयोग करें।
atest -d test-to-run
atest -t test-to-run
विशिष्ट विधियाँ चलाएँ
एटेस्ट एक परीक्षण कक्षा के भीतर विशिष्ट तरीकों को चलाने का समर्थन करता है। हालाँकि पूरे मॉड्यूल को बनाने की आवश्यकता है, इससे परीक्षण चलाने के लिए आवश्यक समय कम हो जाता है। विशिष्ट तरीकों को चलाने के लिए, किसी वर्ग की पहचान करने के लिए समर्थित किसी भी तरीके (मॉड्यूल: क्लास, फ़ाइल पथ, आदि) का उपयोग करके वर्ग की पहचान करें और विधि का नाम जोड़ें:
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
को चलाने के पसंदीदा तरीके दिखाते हैं। इन उदाहरणों को केवल क्लास नाम का उपयोग करने से अधिक प्राथमिकता दी जाती है क्योंकि मॉड्यूल या जावा फ़ाइल स्थान निर्दिष्ट करने से एटेस्ट को परीक्षण को और अधिक तेज़ी से ढूंढने की अनुमति मिलती है।
मॉड्यूल का उपयोग करना: कक्षा:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
एंड्रॉइड 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 बायनेरिज़ चलाएँ
एटेस्ट जीटीटेस्ट बायनेरिज़ चला सकता है। सभी उपलब्ध डिवाइस आर्किटेक्चर के लिए इन परीक्षणों को चलाने के लिए -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 में परीक्षण चलाएँ
एटेस्ट 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
उपनिर्देशिकाओं में परीक्षण चलाएँ
डिफ़ॉल्ट रूप से, एटेस्ट केवल TEST_MAPPING फ़ाइलों में ऊपर की ओर (वर्तमान या दी गई निर्देशिका से उसकी मूल निर्देशिकाओं तक) परीक्षणों की खोज करता है। यदि आप उपनिर्देशिकाओं में TEST_MAPPING फ़ाइलों में परीक्षण भी चलाना चाहते हैं, तो Atest को उन परीक्षणों को भी शामिल करने के लिए बाध्य करने के लिए --include-subdirs
उपयोग करें:
atest --include-subdirs /path/to/project
पुनरावृत्ति में परीक्षण चलाएँ
--iterations
तर्क पारित करके पुनरावृत्ति में परीक्षण चलाएँ। चाहे वह उत्तीर्ण हो या असफल, एटेस्ट अधिकतम पुनरावृत्ति तक पहुंचने तक परीक्षण दोहराएगा।
उदाहरण:
डिफ़ॉल्ट रूप से, एटेस्ट 10 बार पुनरावृत्त होता है। पुनरावृत्तियों की संख्या एक धनात्मक पूर्णांक होनी चाहिए.
atest test-to-run --iterations
atest test-to-run --iterations 5
निम्नलिखित तरीकों से परतदार परीक्षणों का पता लगाना आसान हो जाता है:
दृष्टिकोण 1: विफलता होने तक या अधिकतम पुनरावृत्ति तक पहुंचने तक सभी परीक्षण चलाएं।
- जब कोई विफलता हो या पुनरावृत्ति 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
AVDs पर परीक्षण चलाएँ
एटेस्ट नव निर्मित एवीडी पर परीक्षण चलाने में सक्षम है। 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 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
केवल-परीक्षण विकल्पों पर अधिक जानकारी के लिए, मॉड्यूल में पास विकल्प देखें।