परीक्षण चलाएँ (अटेस्ट)

एटेस्ट एक कमांड लाइन टूल है जो उपयोगकर्ताओं को स्थानीय स्तर पर एंड्रॉइड टेस्ट बनाने, इंस्टॉल करने और चलाने की अनुमति देता है, ट्रेड फेडरेशन टेस्ट हार्नेस कमांड लाइन विकल्पों के ज्ञान की आवश्यकता के बिना टेस्ट री-रन को बहुत तेज करता है। यह पृष्ठ बताता है कि एंड्रॉइड परीक्षण चलाने के लिए एटेस्ट का उपयोग कैसे करें।

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

केवल-परीक्षण विकल्पों पर अधिक जानकारी के लिए, मॉड्यूल में पास विकल्प देखें।