Trade Federation (जिसे Tradefed या TF भी कहा जाता है), एक ऐसा टेस्ट फ़्रेमवर्क है जिसे Android डिवाइसों पर टेस्ट चलाने के लिए डिज़ाइन किया गया है. उदाहरण के लिए, Tradefed का इस्तेमाल, Compatibility Test Suite (CTS) और Vendor Test Suite (VTS) को चलाने के लिए किया जाता है.
Trade Federation एक Java ऐप्लिकेशन है, जो होस्ट कंप्यूटर पर चलता है. साथ ही, यह adb के ज़रिए ddmlib (DDMS के पीछे मौजूद लाइब्रेरी) का इस्तेमाल करके, एक या एक से ज़्यादा Android डिवाइसों से संपर्क करता है.
हमने यहां TF की कुछ मुख्य सुविधाओं के साथ-साथ, इस्तेमाल के कुछ उदाहरणों की सूची दी है. हालांकि, अगर आपको सीधे इस सुविधा का इस्तेमाल शुरू करना है, तो यहां से शुरू करें पेज पर जाएं.
सुविधाएं
- मॉड्यूलर, फ़्लेक्सिबल, और स्केलेबल डिज़ाइन
- इसमें Android की कई तरह की जांच करने की सुविधा पहले से मौजूद है: इंस्ट्रूमेंटेशन, uiautomator, नेटिव/gtest, होस्ट-आधारित JUnit वगैरह
- adb के साथ-साथ, भरोसेमंद और रिकवरी मैकेनिज्म उपलब्ध कराता है
- एक साथ कई डिवाइसों पर टेस्ट शेड्यूल करने और चलाने की सुविधा देता है
TF की मदद से टेस्ट करना लेख पढ़ें. इसमें, इंस्ट्रूमेंटेशन जैसे मौजूदा टेस्ट चलाने के तरीके के बारे में अप-टू-डेट जानकारी दी गई है.
इस्तेमाल के उदाहरण
Trade Federation के मॉड्यूलर होने की वजह से, इसे मौजूदा बिल्ड, टेस्ट, और रिपोर्टिंग इन्फ़्रास्ट्रक्चर वाले एनवायरमेंट में आसानी से शामिल किया जा सकता है. हम यहां कुछ ऐसे उदाहरणों के बारे में बता रहे हैं जिनमें tradefed, जांच के बेहतर और बड़े पैमाने पर लागू किए जा सकने वाले तरीकों को चालू कर सकता है.
सबसे पहले, "किस हिस्से में बदलाव किया जा सकता है और कौनसे हिस्से स्टैटिक हैं?" सवाल के हिसाब से, संभावित इस्तेमाल के उदाहरणों को ध्यान में रखना मददगार होता है. उदाहरण के लिए, डिवाइस का OEM, फ़्रेमवर्क, सिस्टम, और हार्डवेयर में बदलाव कर सकता है. हालांकि, मौजूदा ऐप्लिकेशन पर इसका बहुत कम या कोई असर नहीं पड़ता. दूसरी ओर, ऐप्लिकेशन डेवलपर ऐप्लिकेशन में बदलाव कर सकता है. हालांकि, उसके पास सिस्टम या फ़्रेमवर्क के ज़्यादातर पहलुओं पर ज़्यादा कंट्रोल नहीं होता.
इस वजह से, हर इस्तेमाल के उदाहरण में इकाई के लिए टेस्टिंग के अलग-अलग लक्ष्य होंगे. साथ ही, टेस्ट के दौरान किसी इकाई के काम न करने पर, उसके लिए अलग-अलग विकल्प होंगे. इन अंतरों के बावजूद, Trade Federation की मदद से हर टेस्ट प्रोसेस को बेहतर, आसान, और स्केल किया जा सकता है.
डिवाइस का OEM
डिवाइस OEM, हार्डवेयर बनाता है. साथ ही, वह अक्सर Android सिस्टम और फ़्रेमवर्क में बदलाव करता है, ताकि वे हार्डवेयर पर अच्छी तरह से काम कर सकें. OEM, हार्डवेयर और सिस्टम लेवल पर स्थिरता और परफ़ॉर्मेंस बनाए रखते हुए, इन लक्ष्यों को पूरा करने की कोशिश कर सकता है. साथ ही, यह पक्का कर सकता है कि फ़्रेमवर्क में किए गए बदलावों से, मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा पर असर न पड़े.
OEM, डिवाइस फ़्लैशिंग मॉड्यूल लागू कर सकता है. यह लाइफ़साइकल के टारगेट सेटअप चरण के दौरान काम करेगा. उस मॉड्यूल के चालू रहने के दौरान, डिवाइस पर उसका पूरा कंट्रोल होता है. इसकी मदद से, डिवाइस को बूटलोडर में भेजा जा सकता है, फ़्लैश किया जा सकता है, और फिर डिवाइस को यूज़रस्पेस मोड में रीबूट किया जा सकता है. लगातार बिल्ड सिस्टम से जुड़े मॉड्यूल के साथ, इससे OEM को अपने डिवाइस पर टेस्ट चलाने की अनुमति मिलेगी, क्योंकि वे सिस्टम-लेवल फ़र्मवेयर और Java-लेवल फ़्रेमवर्क में बदलाव करते हैं.
डिवाइस पूरी तरह से बूट होने के बाद, OEM, अपनी पसंद की सुविधा की पुष्टि करने के लिए, JUnit पर आधारित मौजूदा टेस्ट का फ़ायदा ले सकता है या नए टेस्ट लिख सकता है. आखिर में, वे एक या एक से ज़्यादा नतीजों की रिपोर्टिंग मॉड्यूल लिख सकते हैं, ताकि उन्हें मौजूदा टेस्ट के नतीजों के डेटाबेस से जोड़ा जा सके या नतीजों को सीधे तौर पर रिपोर्ट किया जा सके. उदाहरण के लिए, ईमेल से.
ऐप्लिकेशन डेवलपर
ऐप्लिकेशन डेवलपर, ऐसा ऐप्लिकेशन बनाता है जो अलग-अलग प्लैटफ़ॉर्म के वर्शन और अलग-अलग डिवाइसों पर अच्छी तरह से काम करे. अगर किसी खास प्लैटफ़ॉर्म वर्शन और/या डिवाइस पर कोई समस्या आती है, तो इसका एक ही समाधान है. इसके लिए, आपको समस्या को हल करने का तरीका जोड़ना होगा और आगे बढ़ना होगा. बड़े डेवलपर के लिए, टेस्ट प्रोसेस को लगातार बिल्ड करने के क्रम में शामिल किया जा सकता है. छोटे डेवलपर के लिए, इसे समय-समय पर या मैन्युअल तरीके से शुरू किया जा सकता है.
ज़्यादातर ऐप्लिकेशन डेवलपर, TF में पहले से मौजूद APK टेस्ट इंस्टॉलेशन मॉड्यूल का इस्तेमाल करेंगे. इसका एक वर्शन लोकल फ़ाइल सिस्टम से इंस्टॉल होता है. साथ ही, इसका एक वर्शन बिल्ड सेवा से डाउनलोड किए गए APK इंस्टॉल कर सकता है. ध्यान दें कि बाद वाला वर्शन, एक ही होस्ट मशीन पर चल रहे कई TF इंस्टेंस के साथ सही तरीके से काम करता रहेगा.
TF, कई डिवाइसों के साथ काम करने में माहिर है. इसलिए, हर टेस्ट के नतीजे को उस डिवाइस के टाइप के हिसाब से आसानी से बांटा जा सकता है जिसका इस्तेमाल उस टेस्ट के लिए किया गया था. इसलिए, TF, ऐप्लिकेशन के हर बिल्ड के लिए, संभावित रूप से दो-आयामी (या कई-आयामी) कम्पैटिबिलिटी मैट्रिक जनरेट कर सकता है.
टेस्टिंग सेवा
उदाहरण के लिए, टेस्ट सेवा की मदद से ऐप्लिकेशन डेवलपर, ऐप्लिकेशन सबमिट कर सकते हैं. साथ ही, ऐप्लिकेशन के लिए बिजली के इस्तेमाल का पता लगाने के लिए, बिजली के इस्तेमाल को मेज़र करने वाले टूल से इंस्ट्रूमेंट किए गए डिवाइसों पर टेस्ट चला सकते हैं. यह पिछले दो इस्तेमाल के उदाहरणों से अलग है, क्योंकि सेवा बिल्डर, चल रहे डिवाइसों या ऐप्लिकेशन को कंट्रोल नहीं करता.
Trade Federation, आसान IRemoteTest इंटरफ़ेस को लागू करने वाली किसी भी Java क्लास को चला सकता है. इसलिए, ऐसे ड्राइवर लिखना आसान है जो डिवाइस पर चल रहे टेस्ट केस के साथ, किसी बाहरी हार्डवेयर को कोऑर्डिनेट कर सकते हैं. ड्राइवर खुद थ्रेड बना सकता है, दूसरे सर्वर को अनुरोध भेज सकता है या अपनी ज़रूरत के हिसाब से कोई भी काम कर सकता है. इसके अलावा, नतीजों की रिपोर्टिंग इंटरफ़ेस, ITestInvocationListener की आसानी और सुविधाओं का मतलब है कि स्टैंडर्ड नतीजों की रिपोर्टिंग पाइपलाइन में, मनमुताबिक टेस्ट के नतीजों (जैसे, संख्या वाली मेट्रिक) को दिखाना भी आसान है.