एटेस्ट एक कमांड लाइन टूल है जो उपयोगकर्ताओं को ट्रेड फेडरेशन टेस्ट हार्नेस कमांड लाइन विकल्पों के ज्ञान की आवश्यकता के बिना स्थानीय स्तर पर एंड्रॉइड टेस्ट बनाने, स्थापित करने और चलाने की अनुमति देता है। यह पृष्ठ बताता है कि 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 FrameworksServicesTestsatest CtsVideoTestCases
मॉड्यूल: कक्षा
मॉड्यूल के भीतर एकल वर्ग चलाने के लिए, मॉड्यूल: कक्षा का उपयोग करें। मॉड्यूल वही है जो मॉड्यूल नाम में वर्णित है। कक्षा .java फ़ाइल में परीक्षण वर्ग का नाम है, और पूरी तरह से योग्य वर्ग का नाम या मूल नाम हो सकता है।
उदाहरण:
atest CtsVideoTestCases:VideoEncoderDecoderTestatest FrameworksServicesTests:ScreenDecorWindowTestsatest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
कक्षा का नाम
मॉड्यूल नाम को स्पष्ट रूप से बताए बिना एकल वर्ग चलाने के लिए, वर्ग नाम का उपयोग करें।
उदाहरण:
atest ScreenDecorWindowTestsatest 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-runatest -t test-to-run
विशिष्ट तरीके चलाना
एटेस्ट एक परीक्षण वर्ग के भीतर विशिष्ट विधियों को चलाने का समर्थन करता है। हालांकि पूरे मॉड्यूल को बनाने की जरूरत है, इससे परीक्षण चलाने के लिए आवश्यक समय कम हो जाता है। विशिष्ट विधियों को चलाने के लिए, किसी वर्ग (मॉड्यूल: कक्षा, फ़ाइल पथ, आदि) की पहचान करने के लिए समर्थित किसी भी तरीके का उपयोग करके कक्षा की पहचान करें और विधि का नाम संलग्न करें:
atest reference-to-class#method1
अनेक विधियों को निर्दिष्ट करते समय, उन्हें अल्पविराम से अलग करें:
atest reference-to-class#method1,method2,method3
उदाहरण:
atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecorsatest 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 --iterationsatest 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-valueatest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
एक धावक प्रकार या वर्ग के लिए विकल्प पास करें:
atest test-to-run -- --test-arg test-class:option-name:option-valueatest 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 FrameworksServicesTestsatest CtsVideoTestCases
मॉड्यूल: कक्षा
मॉड्यूल के भीतर एकल वर्ग चलाने के लिए, मॉड्यूल: कक्षा का उपयोग करें। मॉड्यूल वही है जो मॉड्यूल नाम में वर्णित है। कक्षा .java फ़ाइल में परीक्षण वर्ग का नाम है, और पूरी तरह से योग्य वर्ग का नाम या मूल नाम हो सकता है।
उदाहरण:
atest CtsVideoTestCases:VideoEncoderDecoderTestatest FrameworksServicesTests:ScreenDecorWindowTestsatest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
कक्षा का नाम
मॉड्यूल नाम को स्पष्ट रूप से बताए बिना एकल वर्ग चलाने के लिए, वर्ग नाम का उपयोग करें।
उदाहरण:
atest ScreenDecorWindowTestsatest 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-runatest -t test-to-run
विशिष्ट तरीके चलाना
एटेस्ट एक परीक्षण वर्ग के भीतर विशिष्ट विधियों को चलाने का समर्थन करता है। हालांकि पूरे मॉड्यूल को बनाने की जरूरत है, इससे परीक्षण चलाने के लिए आवश्यक समय कम हो जाता है। विशिष्ट विधियों को चलाने के लिए, किसी वर्ग (मॉड्यूल: कक्षा, फ़ाइल पथ, आदि) की पहचान करने के लिए समर्थित किसी भी तरीके का उपयोग करके कक्षा की पहचान करें और विधि का नाम संलग्न करें:
atest reference-to-class#method1
अनेक विधियों को निर्दिष्ट करते समय, उन्हें अल्पविराम से अलग करें:
atest reference-to-class#method1,method2,method3
उदाहरण:
atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecorsatest 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 --iterationsatest 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-valueatest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
धावक प्रकार या वर्ग के लिए विकल्प पास करें:
atest test-to-run -- --test-arg test-class:option-name:option-valueatest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
केवल-परीक्षण विकल्पों के बारे में अधिक जानकारी के लिए, मॉड्यूल में विकल्प पास करें देखें।