रनिंग टेस्ट (एटेस्ट), रनिंग टेस्ट (एटेस्ट)

एटेस्ट एक कमांड लाइन टूल है जो उपयोगकर्ताओं को ट्रेड फेडरेशन टेस्ट हार्नेस कमांड लाइन विकल्पों के ज्ञान की आवश्यकता के बिना टेस्ट री-रन को बहुत तेज करते हुए स्थानीय रूप से एंड्रॉइड टेस्ट बनाने, इंस्टॉल करने और चलाने की अनुमति देता है। यह पृष्ठ 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	डिवाइस पर टेस्ट आर्टिफैक्ट (एपीके) इंस्टॉल करता है। (चूक)
-t	--test	परीक्षण चलाता है। (चूक)
-s	--serial	निर्दिष्ट डिवाइस पर परीक्षण चलाता है। एक समय में एक डिवाइस का परीक्षण किया जा सकता है।
-d	--disable-teardown	टेस्ट टियरडाउन और क्लीनअप को अक्षम करता है।
	--info	निर्दिष्ट लक्ष्यों के बारे में प्रासंगिक जानकारी दिखाता है, फिर बाहर निकल जाता है।
	--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 कमांड का उपयोग करके 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

दस्तावेज पथ

Atest मॉड्यूल-आधारित परीक्षण और एकीकरण-आधारित परीक्षण दोनों को उनकी परीक्षण फ़ाइल या निर्देशिका में उचित रूप से इनपुट करके चलाने का समर्थन करता है। यह वर्ग की जावा फ़ाइल के पथ को निर्दिष्ट करके एकल वर्ग चलाने का भी समर्थन करता है। सापेक्ष और निरपेक्ष दोनों पथ समर्थित हैं।

एक मॉड्यूल चलाएँ

निम्नलिखित उदाहरण फ़ाइल पथ का उपयोग करके CtsVideoTestCases मॉड्यूल को चलाने के दो तरीके दिखाते हैं।

Android repo-root से चलाएँ:

atest cts/tests/video

Android 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 पैकेज नाम से परीक्षण की खोज का समर्थन करता है।

उदाहरण:

    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

Atest एक परीक्षण को क्लीनअप या टियरडाउन चरण छोड़ने के लिए बाध्य कर सकता है। कई परीक्षण, जैसे सीटीएस, परीक्षण चलने के बाद डिवाइस को साफ करते हैं, इसलिए -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 को चलाने के पसंदीदा तरीके दिखाते हैं। इन उदाहरणों को केवल कक्षा के नाम का उपयोग करने से अधिक पसंद किया जाता है क्योंकि मॉड्यूल या जावा फ़ाइल स्थान निर्दिष्ट करने से एटेस्ट को परीक्षण को और अधिक तेज़ी से ढूंढने की अनुमति मिलती है।

मॉड्यूल का उपयोग करना: कक्षा:

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 बायनेरिज़ चलाएँ

Atest GTest बायनेरिज़ चला सकता है। सभी उपलब्ध डिवाइस आर्किटेक्चर के लिए इन परीक्षणों को चलाने के लिए -a का उपयोग करें, जो इस उदाहरण में armeabi-v7a (ARM 32-बिट) और arm64-v8a (ARM 64-बिट) हैं।

उदाहरण इनपुट परीक्षण:

atest -a libinput_tests inputflinger_tests

चलाने के लिए एक विशिष्ट जीटीएस्ट बाइनरी का चयन करने के लिए, परीक्षण नाम निर्दिष्ट करने के लिए एक कोलन (:) का उपयोग करें, और एक व्यक्तिगत विधि को आगे निर्दिष्ट करने के लिए हैशटैग (#) का उपयोग करें।

उदाहरण के लिए, निम्न परीक्षण परिभाषा के लिए:

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 फ़ाइलों में परीक्षण चलाना चाहते हैं, तो उन परीक्षणों को भी शामिल करने के लिए Atest को बाध्य करने के लिए --include --include-subdirs का उपयोग करें:

atest --include-subdirs /path/to/project

पुनरावृत्ति में परीक्षण चलाएँ

- --iterations तर्क पास करके पुनरावृत्ति में परीक्षण चलाएँ। चाहे वह उत्तीर्ण हो या विफल, Atest परीक्षण को तब तक दोहराएगा जब तक कि अधिकतम पुनरावृति नहीं हो जाती।

उदाहरण:

डिफ़ॉल्ट रूप से, Atest 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
  

एवीडी पर परीक्षण चलाएं

Atest नव निर्मित 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 मॉड्यूल का परीक्षण करने के लिए विकल्प पास करने में सक्षम है। अपने टेस्ट रन में ट्रेडफेड कमांड लाइन विकल्पों को जोड़ने के लिए, निम्नलिखित संरचना का उपयोग करें और सुनिश्चित करें कि आपके कस्टम तर्क ट्रेडफेड कमांड लाइन विकल्प प्रारूप का पालन करते हैं।

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

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