ACTS टेस्ट कॉन्फ़िगर करें

इस पेज पर ACTS टेस्ट को कॉन्फ़िगर करने का तरीका बताया गया है.

कॉन्फ़िगरेशन के सोर्स

Android Comms Test Suite (ACTS) में कॉन्फ़िगरेशन के तीन मुख्य स्रोत हैं:

• कमांड-लाइन इंटरफ़ेस (सीएलआई)
• ACTS कॉन्फ़िगरेशन फ़ाइल
• एनवायरमेंट वैरिएबल

इन सोर्स की वैल्यू को एक कॉन्फ़िगरेशन में जोड़ा जाता है. इसका इस्तेमाल ACTS टेस्ट चलाने के लिए किया जाता है. अगर वैल्यू एक से ज़्यादा जगहों पर दी गई हैं, तो ऊपर दिए गए क्रम (जहां सीएलआई को प्राथमिकता मिलती है) के आधार पर वैल्यू ओवरराइट हो जाती हैं.

एनवायरमेंट वैरिएबल के बारे में जानकारी

ACTS टेस्ट के लिए एनवायरमेंट वैरिएबल का इस्तेमाल करते समय सावधानी बरतें. ये वैल्यू लोगों को सबसे कम दिखती हैं. साथ ही, डेवलपर के वर्कस्टेशन के बाहर इस्तेमाल करने के लिए, इन वैल्यू का सुझाव नहीं दिया जाता. एसीटीएस ऑटोमेटेड टेस्ट के दौरान एनवायरमेंट वैरिएबल बंद कर दिए जाते हैं, ताकि एनवायरमेंट को नुकसान पहुंचने से बचाया जा सके.

ज़रूरी कॉन्फ़िगरेशन वैरिएबल

हर ACTS टेस्ट में नीचे दिए गए वैरिएबल सेट होने चाहिए.

ACTS टेस्ट पाथ

ACTS एक मुख्य एंट्री लोकेशन से चलता है. इस वजह से, रनर को टेस्ट पाथ की जगह की जानकारी नहीं है.

टेस्ट पाथ की जगह सेट करने के लिए, ACTS_TESTPATH एनवायरमेंट वैरिएबल का इस्तेमाल करें या कमांड लाइन में -tp/--testpaths फ़्लैग का इस्तेमाल करें. वैल्यू, डायरेक्ट्री की सूची हो सकती है.

एसीटीएस टेस्ट क्लास

ACTS को यह पता होना चाहिए कि कौनसी टेस्ट क्लास चलाई जा सकती हैं. यह रेगुलर एक्सप्रेशन या टेस्ट क्लास के नामों की सूची हो सकती है.

यह वैल्यू सेट करने के लिए, कमांड लाइन में -tc/--test_class फ़्लैग का इस्तेमाल करें. ध्यान दें कि यह फ़्लैग क्लास के नामों की सूची भी स्वीकार करता है. क्लास के नाम, उनसे जुड़ी फ़ाइल के नामों से मेल खाने चाहिए. उदाहरण के लिए, SampleTest, SampleTest.py में होना चाहिए.

ACTS लॉग पाथ

STDOUT के अलावा किसी दूसरे में लॉग लिखने के लिए ACTS में कोई जगह होनी चाहिए. 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 में एक खास कंट्रोलर कॉन्फ़िगरेशन है, जिसमें Android डिवाइसों की सूची की जानकारी होती है. इन डिवाइसों को self.android_devices से जुड़े डिवाइसों की सूची में सेव किया गया है. ध्यान दें कि अगर किसी testbed में 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 लॉग इकट्ठा करने के लिए, adb logcat कमांड में जोड़ी गई एक स्ट्रिंग. डिफ़ॉल्ट रूप से, adb logcat -v threadtime -b all का इस्तेमाल किया जाता है. अगर adb_logcat_param सेट है, तो -b all सेक्शन ओवरराइट हो जाता है. जैसे, adb_logcat_param को -b radio पर सेट करने से निर्देश adb logcat -v threadtime -b radio में बदल जाता है.