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

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

Android के लिए परीक्षण लिखने के बारे में सामान्य जानकारी के लिए, Android प्लेटफ़ॉर्म परीक्षण देखें।

Atest की समग्र संरचना के बारे में जानकारी के लिए, Atest डेवलपर मार्गदर्शिका देखें।

Atest के माध्यम से TEST_MAPPING फ़ाइलों में परीक्षण चलाने के बारे में जानकारी के लिए, TEST_MAPPING फ़ाइलों में परीक्षण चलाना देखें।

Atest में एक सुविधा जोड़ने के लिए, Atest Developer Workflow का पालन करें।

अपना वातावरण स्थापित करना

अपना अटेस्ट परिवेश स्थापित करने के लिए निम्नलिखित अनुभागों में दिए गए चरणों का पालन करें।

पर्यावरण चर सेट करें

निम्नलिखित पैकेजिंग बिल्ड स्क्रिप्ट नियम बनाने के लिए जल्द या LOCAL_COMPATIBILITY_SUITE के लिए test_suite सेट करें।

envsetup.sh . चलाएँ

Android स्रोत चेकआउट की जड़ से, चलाएँ:

source build/envsetup.sh

lunch चलाएं

समर्थित उपकरणों का एक मेनू लाने के लिए lunch कमांड चलाएँ। डिवाइस ढूंढें और उस कमांड को चलाएं।

उदाहरण के लिए, यदि आपके पास ARM डिवाइस कनेक्टेड है, तो निम्न कमांड चलाएँ:

lunch aosp_arm64-eng

यह Atest को चलाने के लिए आवश्यक विभिन्न पर्यावरण चर सेट करता है और Atest कमांड को आपके $PATH में जोड़ता है।

मूल उपयोग

एटेस्ट कमांड निम्नलिखित रूप लेते हैं:

atest test-to-run [optional-arguments]

वैकल्पिक तर्क

निम्न तालिका सबसे अधिक उपयोग किए जाने वाले तर्कों को सूचीबद्ध करती है। atest --help के माध्यम से एक पूरी सूची उपलब्ध है।

विकल्प लंबा विकल्प विवरण
-b --build परीक्षण लक्ष्य बनाता है। (चूक)
-i --install डिवाइस पर परीक्षण कलाकृतियां (APK) स्थापित करता है। (चूक)
-t --test परीक्षण चलाता है। (चूक)
-s --serial निर्दिष्ट डिवाइस पर परीक्षण चलाता है। एक समय में एक डिवाइस का परीक्षण किया जा सकता है।
-d --disable-teardown टेस्ट टियरडाउन और क्लीनअप को अक्षम करता है।
<c> --info निर्दिष्ट लक्ष्यों के बारे में प्रासंगिक जानकारी दिखाता है, फिर बाहर निकलता है।
<c> --dry-run ड्राय-रन एटेस्ट वास्तव में बिना किसी निर्माण, संस्थापन, या परीक्षण चलाए।
-m --rebuild-module-info module-info.json फ़ाइल के पुनर्निर्माण के लिए बाध्य करता है।
-w --wait-for-debugger निष्पादन से पहले डीबगर के समाप्त होने की प्रतीक्षा करता है।
-v --verbose DEBUG स्तर लॉगिंग प्रदर्शित करता है।
<c> --iterations लूप-रन परीक्षण जब तक अधिकतम पुनरावृत्ति तक नहीं पहुंच जाता है। (10 डिफ़ॉल्ट रूप से)
<c> --rerun-until-failure [COUNT=10] विफलता होने या अधिकतम पुनरावृत्ति तक पहुंचने तक सभी परीक्षणों को फिर से चलाता है। (10 डिफ़ॉल्ट रूप से)
<c> --retry-any-failure [COUNT=10] उत्तीर्ण होने तक या अधिकतम पुनरावृत्ति तक पुन: विफल परीक्षण। (10 डिफ़ॉल्ट रूप से)
<c> --start-avd स्वचालित रूप से एक AVD बनाता है और वर्चुअल डिवाइस पर परीक्षण चलाता है।
<c> --acloud-create acloud कमांड का उपयोग करके एक एवीडी बनाता है।
<c> --[CUSTOM_ARGS] परीक्षण धावकों के लिए कस्टम तर्क निर्दिष्ट करता है।
-a --all-abi सभी उपलब्ध डिवाइस आर्किटेक्चर के लिए परीक्षण चलाता है।
<c> --host बिना डिवाइस के होस्ट पर पूरी तरह से टेस्ट चलाता है.
नोट: एक होस्ट परीक्षण चलाना जिसके लिए --host वाले उपकरण की आवश्यकता होती है, विफल हो जाएगा।
<c> --flakes-info फ्लेक्स जानकारी के साथ परीक्षा परिणाम दिखाता है।
<c> --history कालानुक्रमिक क्रम में परीक्षा परिणाम दिखाता है।
<c> --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 (गैर-मॉड्यूल) में एकीकृत परीक्षण चलाने के लिए, नाम दर्ज करें जैसा कि tradefed.sh list configs कमांड के आउटपुट में दिखाई देता है। उदाहरण के लिए:

reboot.xml परीक्षण चलाने के लिए:

atest example/reboot

native-benchmark.xml परीक्षण चलाने के लिए:

atest native-benchmark

दस्तावेज पथ

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

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

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

Android 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 पैरामीटर के बिना विफल हो जाएगा। परीक्षण को साफ करने के चरण को छोड़ने और पुनरावृत्त रूप से परीक्षण करने के लिए -d से पहले -t का उपयोग करें।

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

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 फ़ाइलों में पोस्ट सबमिट परीक्षण चलाएँ:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

TEST_MAPPING फ़ाइलों में सभी समूहों से परीक्षण चलाएँ:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

/path/to/project और इसकी मूल निर्देशिकाओं में TEST_MAPPING फ़ाइलों में पोस्टसबमिट परीक्षण चलाएँ:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

/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 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 पर परीक्षण चलाने में सक्षम है। 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

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

,

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

Android के लिए परीक्षण लिखने के बारे में सामान्य जानकारी के लिए, Android प्लेटफ़ॉर्म परीक्षण देखें।

Atest की समग्र संरचना के बारे में जानकारी के लिए, Atest डेवलपर मार्गदर्शिका देखें।

Atest के माध्यम से TEST_MAPPING फ़ाइलों में परीक्षण चलाने के बारे में जानकारी के लिए, TEST_MAPPING फ़ाइलों में परीक्षण चलाना देखें।

Atest में एक सुविधा जोड़ने के लिए, Atest Developer Workflow का पालन करें।

अपना वातावरण स्थापित करना

अपना अटेस्ट परिवेश स्थापित करने के लिए निम्नलिखित अनुभागों में दिए गए चरणों का पालन करें।

पर्यावरण चर सेट करें

निम्नलिखित पैकेजिंग बिल्ड स्क्रिप्ट नियम बनाने के लिए जल्द या LOCAL_COMPATIBILITY_SUITE के लिए test_suite सेट करें।

envsetup.sh . चलाएँ

Android स्रोत चेकआउट की जड़ से, चलाएँ:

source build/envsetup.sh

lunch चलाएं

समर्थित उपकरणों का एक मेनू लाने के लिए lunch कमांड चलाएँ। डिवाइस ढूंढें और उस कमांड को चलाएं।

उदाहरण के लिए, यदि आपके पास ARM डिवाइस कनेक्टेड है, तो निम्न कमांड चलाएँ:

lunch aosp_arm64-eng

यह Atest को चलाने के लिए आवश्यक विभिन्न पर्यावरण चर सेट करता है और Atest कमांड को आपके $PATH में जोड़ता है।

मूल उपयोग

एटेस्ट कमांड निम्नलिखित रूप लेते हैं:

atest test-to-run [optional-arguments]

वैकल्पिक तर्क

निम्न तालिका सबसे अधिक उपयोग किए जाने वाले तर्कों को सूचीबद्ध करती है। atest --help के माध्यम से एक पूरी सूची उपलब्ध है।

विकल्प लंबा विकल्प विवरण
-b --build परीक्षण लक्ष्य बनाता है। (चूक)
-i --install डिवाइस पर परीक्षण कलाकृतियां (APK) स्थापित करता है। (चूक)
-t --test परीक्षण चलाता है। (चूक)
-s --serial निर्दिष्ट डिवाइस पर परीक्षण चलाता है। एक समय में एक डिवाइस का परीक्षण किया जा सकता है।
-d --disable-teardown टेस्ट टियरडाउन और क्लीनअप को अक्षम करता है।
<c> --info निर्दिष्ट लक्ष्यों के बारे में प्रासंगिक जानकारी दिखाता है, फिर बाहर निकलता है।
<c> --dry-run ड्राय-रन एटेस्ट वास्तव में बिना किसी निर्माण, संस्थापन, या परीक्षण चलाए।
-m --rebuild-module-info module-info.json फ़ाइल के पुनर्निर्माण के लिए बाध्य करता है।
-w --wait-for-debugger निष्पादन से पहले डीबगर के समाप्त होने की प्रतीक्षा करता है।
-v --verbose DEBUG स्तर लॉगिंग प्रदर्शित करता है।
<c> --iterations लूप-रन परीक्षण जब तक अधिकतम पुनरावृत्ति तक नहीं पहुंच जाता है। (10 डिफ़ॉल्ट रूप से)
<c> --rerun-until-failure [COUNT=10] विफलता होने या अधिकतम पुनरावृत्ति तक पहुंचने तक सभी परीक्षणों को फिर से चलाता है। (10 डिफ़ॉल्ट रूप से)
<c> --retry-any-failure [COUNT=10] उत्तीर्ण होने तक या अधिकतम पुनरावृत्ति तक पुन: विफल परीक्षण। (10 डिफ़ॉल्ट रूप से)
<c> --start-avd स्वचालित रूप से एक AVD बनाता है और वर्चुअल डिवाइस पर परीक्षण चलाता है।
<c> --acloud-create acloud कमांड का उपयोग करके एक एवीडी बनाता है।
<c> --[CUSTOM_ARGS] परीक्षण धावकों के लिए कस्टम तर्क निर्दिष्ट करता है।
-a --all-abi सभी उपलब्ध डिवाइस आर्किटेक्चर के लिए परीक्षण चलाता है।
<c> --host बिना डिवाइस के होस्ट पर पूरी तरह से टेस्ट चलाता है.
नोट: एक होस्ट परीक्षण चलाना जिसके लिए --host वाले उपकरण की आवश्यकता होती है, विफल हो जाएगा।
<c> --flakes-info फ्लेक्स जानकारी के साथ परीक्षा परिणाम दिखाता है।
<c> --history कालानुक्रमिक क्रम में परीक्षा परिणाम दिखाता है।
<c> --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 (गैर-मॉड्यूल) में एकीकृत परीक्षण चलाने के लिए, नाम दर्ज करें जैसा कि tradefed.sh list configs कमांड के आउटपुट में दिखाई देता है। उदाहरण के लिए:

reboot.xml परीक्षण चलाने के लिए:

atest example/reboot

native-benchmark.xml परीक्षण चलाने के लिए:

atest native-benchmark

दस्तावेज पथ

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

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

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

Android 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 पैरामीटर के बिना विफल हो जाएगा। परीक्षण को साफ करने के चरण को छोड़ने और पुनरावृत्त रूप से परीक्षण करने के लिए -d से पहले -t का उपयोग करें।

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

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 फ़ाइलों में पोस्ट सबमिट परीक्षण चलाएँ:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

TEST_MAPPING फ़ाइलों में सभी समूहों से परीक्षण चलाएँ:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

/path/to/project और इसकी मूल निर्देशिकाओं में TEST_MAPPING फ़ाइलों में पोस्टसबमिट परीक्षण चलाएँ:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

/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 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 पर परीक्षण चलाने में सक्षम है। 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

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