यह पृष्ठ बताता है कि ACTS परीक्षणों को कैसे कॉन्फ़िगर किया जाए।
विन्यास के स्रोत
एंड्रॉइड कॉम्स टेस्ट सूट (एसीटीएस) में कॉन्फ़िगरेशन के तीन प्रमुख स्रोत हैं:
- कमांड लाइन इंटरफ़ेस (सीएलआई)
- ACTS कॉन्फ़िग फ़ाइल
- पर्यावरण चर
इन स्रोतों के मानों को एक एकल कॉन्फ़िगरेशन में संयोजित किया जाता है जिसका उपयोग ACTS परीक्षण चलाने के लिए किया जाता है। यदि मान कई स्थानों पर निर्दिष्ट किए गए हैं, तो मान उपरोक्त क्रम के आधार पर अधिलेखित कर दिए जाते हैं (जहां सीएलआई को प्राथमिकता दी जाती है)।
पर्यावरण चर पर एक नोट
ACTS परीक्षणों के लिए पर्यावरण चर का उपयोग करते समय सावधान रहें। ये मान उपयोगकर्ता को सबसे कम दिखाई देते हैं, और डेवलपर के वर्कस्टेशन के बाहर उपयोग के लिए अनुशंसित नहीं हैं। पर्यावरण विषाक्तता को रोकने के लिए ACTS स्वचालित परीक्षणों के दौरान पर्यावरण चर अक्षम कर दिए जाते हैं।
आवश्यक कॉन्फ़िगरेशन चर
प्रत्येक ACTS परीक्षण के लिए निम्नलिखित चर सेट करने की आवश्यकता होती है।
ACTS परीक्षण पथ
ACTS एकल मुख्य प्रवेश स्थान से चलता है। परिणामस्वरूप, परीक्षण पथ का स्थान धावक के लिए अज्ञात है।
ACTS_TESTPATH
पर्यावरण चर का उपयोग करके या कमांड लाइन में -tp
/ --testpaths
ध्वज के साथ परीक्षण पथ स्थान सेट करें। मान निर्देशिकाओं की एक सूची हो सकता है।
ACTS परीक्षण कक्षाएं
ACTS को पता होना चाहिए कि कौन सी परीक्षण कक्षाएँ चलानी हैं। यह रेगेक्स या परीक्षण वर्ग नामों की सूची हो सकती है।
इस मान को सेट करने के लिए, कमांड लाइन में -tc
/ --test_class
ध्वज का उपयोग करें। ध्यान दें कि यह ध्वज वर्ग नामों की सूची भी स्वीकार करता है। क्लास के नाम उनके संबंधित फ़ाइल नामों से मेल खाने चाहिए, उदाहरण के लिए, SampleTest
SampleTest.py
में पाया जाना चाहिए।
ACTS लॉग पथ
ACTS के पास STDOUT के अलावा लॉग लिखने के लिए कोई स्थान होना चाहिए। ACTS डेटा युक्त पूर्ण डिबग लॉग लिखता है जो यह निर्धारित करने में मदद कर सकता है कि कुछ परीक्षण क्यों विफल हो रहे हैं। अव्यवस्था को रोकने के लिए, ACTS इन लॉग को STDOUT पर नहीं लिखता है।
लॉग पथ सेट करने के लिए, कमांड लाइन में ACTS_LOGPATH
पर्यावरण चर या -lp
/ --logpath
ध्वज का उपयोग करें।
ACTS कॉन्फ़िग पथ
परीक्षण चलाने के लिए, ACTS को पता होना चाहिए कि कौन सा परीक्षण बिस्तर मौजूद है। ACTS कॉन्फ़िगरेशन में परीक्षण किए गए सभी डिवाइस और कोई विशेष परीक्षण या पर्यावरण पैरामीटर शामिल हैं जिनकी आवश्यकता हो सकती है। -c
/ --config
का उपयोग करके इस मान को कमांड लाइन पर सेट करें।
यदि कॉन्फ़िगरेशन के भीतर कई टेस्टबेड हैं, तो ACTS प्रत्येक टेस्टबेड के लिए परीक्षण चलाता है। सूची में केवल एक टेस्टबेड के लिए परीक्षण चलाने के लिए, -tb/--testbed <NAME>
कमांड लाइन तर्क का उपयोग करें।
एक स्थानीय कार्य केंद्र उदाहरण
अधिकांश ACTS उपयोगकर्ता एक ही Android रेपो शाखा पर विकसित होते हैं, और उनके पास इस के समान एक सेटअप होता है:
# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='~/android/<REPO_BRANCH>/tools/test/connectivity/acts_tests/'
# On cmdline
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin
यदि ACTS उपयोगकर्ता एकाधिक शाखाओं पर चलते हैं, तो वे अक्सर acts/framework
निर्देशिका से ACTS चलाते हैं, और ACTS_TESTPATH
के लिए एक सापेक्ष पथ का उपयोग करते हैं:
# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='../acts_tests/'
# On cmdline
$ cd ~/android/main/tools/test/connectivity/acts_tests/acts_contrib/
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin
अपने परीक्षण बिस्तरों को कॉन्फ़िगर करना
ACTS कॉन्फ़िग फ़ाइल हार्डवेयर उपकरणों पर परीक्षण चलाने के लिए सभी आवश्यक जानकारी प्रदान करती है:
{
"testbed": {
"my_testbed": {
"my_testbed_value": "value"
},
"another_testbed": {
"AndroidDevice": [
"53R147"
]
}
},
"user_parameter_1": "special environment value",
"user_parameter_2": "other special value"
}
इस कॉन्फ़िगरेशन की आधार इकाई परीक्षण बिस्तर है। उपरोक्त उदाहरण कॉन्फ़िगरेशन में, टेस्टबेड my_testbed
एकल टेस्टबेड मान के साथ बनाया गया है। दूसरे टेस्टबेड, another_testbed
में एक विशेष नियंत्रक कॉन्फिगरेशन है जो एंड्रॉइड डिवाइसों की सूची के लिए जानकारी रखता है। ये डिवाइस self.android_devices
के अंतर्गत डिवाइस की सूची में संग्रहीत हैं। ध्यान दें कि यदि कोई टेस्टबेड AndroidDevice
ऑब्जेक्ट निर्दिष्ट नहीं करता है, तो एक टेस्ट क्लास जो AndroidDevice
ऑब्जेक्ट की अपेक्षा करता है वह एक अपवाद उठाता है। ACTS के साथ आने वाले समर्थित नियंत्रक कॉन्फ़िगरेशन की पूरी सूची के लिए, /acts/framework/acts/controllers/
पर सूची देखें।
अन्य सभी मान (जो उपरोक्त अनुभाग में उल्लिखित विशेष मान नहीं हैं) एक शब्दकोश के रूप में self.user_params
में संग्रहीत हैं। यह पर्यावरण या परीक्षण जानकारी रखने के लिए एक अच्छी जगह है जैसे कि क्या फोन मीटर्ड डेटा वातावरण में हैं, या परीक्षण के लिए डेटा कितनी देर तक एकत्र करना है।
AndroidDevice के लिए विशेष मामले
विकास की सुविधा के लिए जब आप अलग-अलग गुणों के साथ कई डिवाइस उपलब्ध कराना चाहते हैं, AndroidDevice
के पास कुछ विशेष मामले हैं।
JSON कॉन्फ़िगरेशन प्रारूप
नीचे दिए गए JSON में सभी कुंजी/मूल्य जोड़े संबंधित AndroidDevice
ऑब्जेक्ट पर सेट हैं। यदि कॉन्फ़िगरेशन AndroidDevice
विशेषता में परिभाषित पैरामीटर को ओवरराइट करने का प्रयास करता है, ControllerError
फेंक दिया जाता है।
"AndroidDevice": [{"serial": "XXXXXX", "label": "publisher"},
{"serial": "YYYYYY", "label": "subscriber", "user_parameter_1": "anything"}]
फिर परीक्षण स्क्रिप्ट में, आप सही डिवाइस को पुनः प्राप्त करने और डिवाइस ऑब्जेक्ट से अतिरिक्त पैरामीटर तक पहुंचने के लिए फ़िल्टर फ़ंक्शन का उपयोग कर सकते हैं:
def setup_class(self):
self.pub = next(filter(lambda ad: ad.label == 'publisher',
self.android_devices))
self.sub = next(filter(lambda ad: ad.label == 'user_parameter_1',
self.android_devices))
वैकल्पिक पैरामीटर
निम्नलिखित एक वैकल्पिक पैरामीटर है:
-
adb_logcat_param
: एडीबी लॉग इकट्ठा करने के लिएadb logcat
कमांड से जुड़ी एक स्ट्रिंग। डिफ़ॉल्ट रूप से,adb logcat -v threadtime -b all
उपयोग किया जाता है। यदिadb_logcat_param
सेट है, तो-b all
अनुभाग अधिलेखित हो जाता है। उदाहरण के लिए,adb_logcat_param
-b radio
पर सेट करने से कमांडadb logcat -v threadtime -b radio
में बदल जाता है।