रोबोट फ्रेमवर्क के साथ डेटिंग और काम करने का मेरा अनुभव

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

हालाँकि, यह दृष्टिकोण की विशेषताओं के बारे में बात करने लायक है।

रोबोट कौन है और इसके साथ क्या खाता है

संभवतः इस शक्तिशाली उपकरण की शुरुआत के साथ लायक है।

रोबोट फ्रेमवर्क कीवर्ड द्वारा संचालित परीक्षण के लिए एक रूपरेखा है। इसका उपयोग स्वीकृति परीक्षण और ATDD (स्वीकृति परीक्षण के माध्यम से विकास दृष्टिकोण) को स्वचालित करने के लिए किया जाता है। इस प्रणाली में आसानी से उपयोग किया जाने वाला परीक्षण डेटा सिंटैक्स है और आपको कीवर्ड का उपयोग करके परीक्षणों को स्वचालित करने की अनुमति देता है। इसके अलावा, रोबोट फ्रेमवर्क में उत्कृष्ट अंतर्निहित और तीसरे पक्ष के पुस्तकालय हैं जो आपको अपने स्वयं के साइकिल का आविष्कार किए बिना कार्य प्रक्रियाओं में स्वचालन को जल्दी से शुरू करने और एकीकृत करने की अनुमति देते हैं - बहुत कम प्रवेश सीमा जो मैंने ऊपर उल्लेख किया है।

रोबोट फ्रेमवर्क की बुनियादी संरचना को पायथन का उपयोग करके कार्यान्वित किया गया है और यह Jython (JVM) और IronPython (.NET) पर भी काम करता है।

उपयोग के उदाहरण, साथ ही फ्रेमवर्क और आंतरिक पुस्तकालयों पर पूर्ण प्रलेखन परियोजना की आधिकारिक वेबसाइट पर पाया जा सकता है: http://robotframework.org/ ।

मेरे पहले कदम। पहला तरीका

नौकरी बदलने के बाद पहली बार मैं एक साल पहले रोबोट फ्रेमवर्क में आया था। इससे पहले, मैंने केवल जावा और सी # में स्वचालित किया था।

अपने लिए उन उपकरणों को चुनना जिनके साथ मुझे मौजूदा परीक्षणों से निपटना है, मैंने उनकी पसंद के बारे में नए सहयोगियों का साक्षात्कार लिया। वे रोबोट फ्रेमवर्क के साथ काम करने के लिए सर्वश्रेष्ठ आईडीई पर सहमत नहीं थे। विभिन्न पाठ संपादकों और IDEs, जैसे PyCharm, के लिए प्लग-इन मुख्य रूप से रोबोट फ्रेमवर्क के साथ काम करने की अनुमति देता है। और मैंने जो सिफारिशें एकत्र कीं, वे एटम और पाइकार्म के बीच 50/50 विभाजित की गईं। बेशक, RIDE है, लेकिन यह रामबाण नहीं है। उस समय (एक साल पहले), मुझे इस पर सामान्य दस्तावेज़ीकरण नहीं मिला, और जो मुझे मिला, उसमें मैंने अपने काम के लिए कोई बड़ा प्लस नहीं देखा। इसलिए, शुरुआत के लिए, मैंने एटम को प्लगइन्स के साथ आज़माने का फैसला किया। रिपॉजिटरी की क्लोनिंग, मैंने धीरे-धीरे अध्ययन करना शुरू कर दिया कि हमारे परीक्षणों में और रोबोट फ्रेमवर्क में क्या हो रहा था।

मुझे व्यावहारिक रूप से सब कुछ के लिए परियोजना के लिए झुका दिया गया है। जाइथन + रोबोट फ्रेमवर्क का एक गुच्छा पहले से ही वहां काम करता था, एक विशाल कोड बेस (स्वयं डीएसएल रोबोट फ्रेमवर्क पर लिखा गया था) को 1000 से अधिक परीक्षणों और जावा में सहायक पुस्तकालयों के कोड के कई हजार लाइनों से इकट्ठा किया गया था।

जैसा कि मैं इसे समझता हूं, जब परियोजना शुरू हुई, अर्थात्। इससे पहले कि मैं विभाग में आया, यह मुख्य रूप से जावा विशेषज्ञ थे जिन्होंने इस पर काम किया था, और परीक्षण के तहत उत्पाद स्वयं जावा में था, इसलिए जब एक दृष्टिकोण चुनते हैं, तो हमने उपलब्ध संसाधनों पर ध्यान केंद्रित किया। सामान्य तौर पर, गणना कुछ इस तरह थी: रोबोट फ्रेमवर्क और जावा के एकीकरण से संबंधित कुछ समस्याओं को हल करने के बाद (मुख्य रूप से इस तथ्य के कारण कि जावा एक संकलित भाषा है, लेकिन अजगर और आरएफ बंडल में एक ही पायथन और परीक्षणों की व्याख्या की गई है), फिर तीसरे पक्ष के विशेषज्ञों को आकर्षित करना आसान है जो केवल डीएसएल रोबोट फ्रेमवर्क जानते हैं, और चुपचाप कीवर्ड पर परीक्षण लिखते हैं। सच है, सहकर्मियों को जावा में पुस्तकालय बनाने में काफी प्रयास करना पड़ता था, इसलिए, ग्राहक से शर्तों के बिना, वे इस तरह के पथ की सिफारिश नहीं करेंगे।

अपने पहले कार्य के हिस्से के रूप में, मैंने कुछ परीक्षण किए। चूंकि Jython + RF बंडल का उपयोग किया गया था, सब कुछ मावेन द्वारा एकत्र किया गया था, और रोबोट फ़ाइलों को बाद में निष्पादन के लिए लक्ष्य निर्देशिका में कॉपी किया गया था।

परीक्षण स्क्रिप्ट (.bat या .sh फ़ाइलों) द्वारा चलाए गए थे, जो या तो एक अलग परीक्षण मामले (एक अलग .robot फ़ाइल) या एक परीक्षण योजना (मामलों की जाँच करने के लिए संबंधित पथों की सूची वाली फ़ाइल) के लिए रास्ता ले गए।

रिफैक्टिंग ने बड़ी संख्या में परीक्षणों को प्रभावित किया, इसलिए पहले रन में लगभग 15 मिनट लगे। इसके पूरा होने के बाद, यह रोबोट फ्रेमवर्क द्वारा प्रदान की गई रिपोर्टों पर एक नज़र डालने का समय है।
मानक रिपोर्ट (ऊपर स्क्रीनशॉट में) में रिपोर्ट.html और log.html फाइलें शामिल हैं:

• रिपोर्ट में पिछले रन का एक सामान्य सारांश होता है, जहां आप सभी परीक्षणों (पास या असफल) के सतह परिणाम देख सकते हैं;
• लॉग-फाइल में आप अधिक विस्तृत जानकारी देख सकते हैं - प्रत्येक परीक्षण चरण का निष्पादन। वहां आप उन सभी चीज़ों को प्रदर्शित कर सकते हैं जिनकी आपको परीक्षणों की आवश्यकता है।

ईमानदारी से, रोबोट फ्रेमवर्क रिपोर्ट में पहली नज़र से, आंख थोड़ी सी मुड़ने लगती है: भारी मात्रा में जानकारी प्रदर्शित होती है और परीक्षणों के अंत-टू-एंड संरचना को समझने और इस तरह के लॉग को पढ़ने के लिए कौशल विकसित करने में कुछ समय लगता है। लेकिन यह व्यवसाय इतना मुश्किल नहीं है। कुछ महीनों के भीतर मैं द मैट्रिक्स को उद्धृत कर सका: “आपका मस्तिष्क अनुवाद स्वयं करता है। मैं कोड भी नहीं देखता। मुझे एक गोरा, एक श्यामला और एक रेडहेड दिखाई देता है। ” इसलिए मैंने - अतिरिक्त उपकरणों के बिना एक फ़ाइल में सभी आवश्यक जानकारी देखी।

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

हमारे मुख्य उपकरण के रूप में DSL रोबोट फ्रेमवर्क का उपयोग करते हुए, हमने लगभग छह महीने तक काम किया। इस समय के दौरान, मैंने एटम से लेकर VSCode तक व्यक्तिगत प्राथमिकताओं पर स्विच किया, लेकिन इससे दृष्टिकोण का सार नहीं बदला।

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

दूसरा तरीका

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

चूंकि पायथन एक शुद्ध उच्च-स्तरीय भाषा है, न कि डीएसएल, इसमें अधिक संरचित विकल्प हैं, इसे सभी को समझाना आसान है। कम से कम, आप समान तरीकों को खोजने में मदद करने के लिए पायथन आईडीई का उपयोग कर सकते हैं (वे एक ही काम करते हैं, लेकिन अलग-अलग तरीके से कहते हैं) या यहां तक ​​कि आपके लिए कोड का एक टुकड़ा भी लिखें। कुछ डेटा जनरेटर में लिपटे जा सकते हैं, फ़ंक्शंस पर डेकोरेटर लटका सकते हैं, आदि इस पृष्ठभूमि के खिलाफ, पहले दृष्टिकोण के उपकरण (शुद्ध रोबोट फ्रेमवर्क) कठोर दिखते हैं - वास्तव में, यह सिंटैक्स हाइलाइटिंग के साथ नोटपैड था। कोई भी बसने वाला या पाने वाला नहीं जो इंटेलीजे आपके लिए लिखता है। इसलिए मैं उच्च स्तर की भाषा में लौटकर खुश था। इस दृष्टिकोण के साथ काम करना सामान्य विकास की तरह है। सच है, मरहम में एक मक्खी है। अतिरिक्त नृत्य के बिना, यह समझना असंभव है कि RF से बुलाए गए पायथन के अंदर क्या गिर गया।

धीरे-धीरे, हमारे उपतंत्र के लिए पहले परीक्षण और सहायक पुस्तकालय लिखे जाने लगे। उस समय के दौरान जब मैं एक नए दृष्टिकोण के साथ काम करने में सक्षम था, मुझे लगा कि एक और उपकरण के साथ वास्तव में अधिक अवसर हैं। लेकिन वास्तव में, परीक्षणों का लेखन ज्यादा नहीं बदला है। इस विशेष परियोजना में, पायथन कोड के अंदर, रोबोट फ्रेमवर्क अंतर्निहित पुस्तकालय विधियों को अभी भी कहा जाता था। यह परीक्षणों के विकास के लिए ग्राहक की विशेष आवश्यकताओं के कारण था। हमने परीक्षण मामले के एल्गोरिथ्म से बस निष्पादन योग्य भाग को अलग कर दिया।

कौन सा बेहतर है?

मैं व्यक्तिगत रूप से दूसरे दृष्टिकोण को पसंद करता हूं। हालांकि, अपनी परियोजना का रास्ता चुनना, यह कार्य से शुरू होने के लायक है - कौन परीक्षण लिखता है और कैसे।

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

नतीजतन, रोबोट फ्रेमवर्क और हमने इसे पहले कैसे इस्तेमाल किया, यह कल के मैनुअल परीक्षकों के लिए उच्च स्तरीय भाषाओं में बिना किसी स्पष्ट प्रोग्रामिंग अनुभव के अधिक उपयुक्त है। यहां तक ​​कि एक व्यक्ति जो प्रोग्रामिंग में बहुत शामिल नहीं है, केवल आवश्यक कीवर्ड को कॉल करके, एक परीक्षण लिख सकता है।

हालांकि, यदि आप हमारे प्रोजेक्ट के उदाहरण के बाद, निष्पादन योग्य भाग को अलग रखना चाहते हैं, और उसी समय कोड को फ्रेंडली IDEs में रिफ्लेक्टर करते हैं, तो दूसरा तरीका आपके लिए है।

लेख लेखक: दिमित्री मास्टर्स

पुनश्च: हम कई रनट साइटों पर अपने लेख प्रकाशित करते हैं। वीके , एफबी या टेलीग्राम-चैनल पर हमारे सभी प्रकाशनों और अन्य मैक्सिलैक्ट समाचारों के बारे में जानने के लिए हमारे पेज की सदस्यता लें।