TestCafe: कार्यात्मक परीक्षण में सद्भाव खोजने का एक संक्षिप्त इतिहास (चित्रों के साथ)

TestCafe हाल ही में DevExpress द्वारा जारी एक क्रॉस-प्लेटफ़ॉर्म वेब एप्लिकेशन फ़ंक्शनल टेस्टिंग फ्रेमवर्क है।

हम DevExpress पर वेब डेवलपर्स ( ASP.NET WebForms , ASP.NET MVC , साथ ही जावास्क्रिप्ट घटकों और चौखटे ) के लिए कई प्रकार के घटकों का विकास कर रहे हैं और निश्चित रूप से, उनका परीक्षण कर रहे हैं। यदि यूनिट परीक्षणों के साथ सब कुछ आम तौर पर स्पष्ट है और कुछ अविश्वसनीय खुलासे के लिए कोई जगह नहीं बची है, तो कार्यात्मक परीक्षणों के साथ स्थिति उनके कार्यान्वयन की जटिलता के कारण अस्पष्ट से बहुत दूर है। प्रारंभ में, TestCafe फ्रेमवर्क एक आंतरिक विकास था जिसका उद्देश्य हमारे घटकों और साइटों के कार्यात्मक परीक्षण के साथ दबाने वाली समस्याओं को हल करना था। और ऐसा हुआ कि यह आंतरिक विकास अंततः एक स्वतंत्र उत्पाद के रूप में विकसित हुआ।

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

अत्यावश्यक के बारे में

समस्या:

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

यह अक्सर पता चलता है कि एक बड़ी विकास टीम में, सभी डेवलपर्स के पास बस एक परीक्षण वातावरण स्थापित नहीं होता है या परीक्षण ढांचे का एक पुराना संस्करण स्थापित होता है। और ऐसी स्थिति पैदा होती है कि एक निरंतर एकीकरण प्रणाली में एक परीक्षण क्रैश हो जाता है, एक त्रुटि को तत्काल ठीक करने की आवश्यकता होती है, और साथ ही समय का एक महत्वपूर्ण हिस्सा केवल स्थानीय रूप से "टेक ऑफ" करने के लिए परीक्षण के लिए खर्च किया जाता है। प्लगइन्स को अपडेट करना, एक निरंतर एकीकरण प्रणाली में एक फ्रेमवर्क एक अलग मजेदार विषय है।

इसके अलावा यहां मोबाइल डिवाइस अलग से खड़े हैं। अधिकांश कॉन्फ़िगरेशन के लिए, बस कोई प्लगइन्स नहीं हैं, कुछ के लिए, प्लगइन स्थापित करना तुच्छ से दूर है।

TestCafe की मुख्य "विशेषता" यह है कि फ्रेमवर्क को ब्राउज़र प्लग-इन या किसी ब्राउज़र पूर्व-सेटिंग की आवश्यकता नहीं है। TestCafe ब्राउज़रों के लिए plug'n'play दृष्टिकोण का उपयोग करता है। आप उस ब्राउज़र में डेमो टेस्ट चलाकर इसे सत्यापित कर सकते हैं जिसमें आप वर्तमान में इस लेख को देख रहे हैं। यदि आप एक स्थानीय मशीन पर काम करते हैं, तो TestCafe स्वचालित रूप से इंस्टॉल किए गए ब्राउज़रों का पता लगाएगा और आपके लिए एक कार्यकर्ता बनाएगा:



मोबाइल डिवाइस के ब्राउज़र से सिंगल बटन दबाकर या क्यूआर कोड स्कैन करके मोबाइल डिवाइस को कनेक्ट करना उतना ही सरल है:



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

इसके अलावा, TestCafe ब्राउज़र और कीबोर्ड / माउस इनपुट को ब्लॉक नहीं करता है। यानी आप अपने पसंदीदा ब्राउज़र के दूसरे टैब में काम करना जारी रखते हुए सभी ब्राउज़रों में समानांतर में परीक्षण चला सकते हैं।

समस्या:

परीक्षण कोड और उत्पादन कोड के बीच एक महत्वपूर्ण अंतर है: एक नियम के रूप में, परीक्षण एक बार लिखे गए कोड होते हैं, लेकिन हम अक्सर विकसित अनुप्रयोग के काम में उल्लंघन का विश्लेषण करने के लिए इस कोड पर लौटते हैं। यानी परीक्षण कोड का मुख्य उद्देश्य समस्याओं की पहचान करना है, इसलिए इसके लिए दो आवश्यकताएं हैं:

• परीक्षण परिदृश्य का निर्धारण - परीक्षण को वास्तव में एक कार्रवाई परिदृश्य करना चाहिए और इस परिदृश्य को आसानी से परीक्षण कोड से समझा जाना चाहिए;
• परिदृश्य की अवस्था को जल्दी से स्थानीय करने की क्षमता जहां समस्या उत्पन्न हुई।

जब मेरे एक सहयोगी और मैंने एक बहुत ही जटिल कार्यात्मक परीक्षण को डिबग किया तो ये विचार मेरे सिर में दृढ़ता से अंकित थे। यह कोड की एक दीवार थी, जिसमें से यह समझना मुश्किल था कि परीक्षण परिदृश्य में क्या चल रहा है। इसलिए, हमने कदम से परीक्षण कदम को डिबग किया और कोड के साथ दृश्यमान क्रियाओं की तुलना की। बस हमें यह पता लगाने में आधा घंटा लग गया कि हम किस परिदृश्य के साथ काम कर रहे थे!

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

लेकिन कब से सभी लोगों को सही करने के लिए एक कार्य है, इसे हल्के ढंग से, थोड़ा व्यवहार्य बनाने के लिए, फिर टेस्टकैफ़ में हमने कठिन परिस्थितियों में व्यवहार के एक सार्वभौमिक एल्गोरिथ्म को लागू नहीं किया ^[1] । हमने थोड़े अलग तरीके से कदम उठाए, थोड़ा परीक्षण डेवलपर समय का त्याग करते हुए (याद रखें कि एक परीक्षण आमतौर पर एक बार लिखा जाता है) उन लोगों के लिए जो बाद में इस परीक्षण के परिणामों का विश्लेषण करेंगे।

टेस्ट कैफ़े में टेस्ट चरणों में टूट गए हैं:

'@fixture Example'; '@page http://testcafe.devexpress.com/Example'; '@test'['Drag slider'] = { '1.Click label "I have tried TestCafe"': function () { act.click(':containsExcludeChildren(I have tried TestCafe)'); }, '2.Check initial slider value': function() { eq($('#Developer_Rating').val(), 0); }, '3.Drag slider handle': function () { act.drag('.ui-slider-handle', 360, 0); }, '4.Check resulting slider value': function() { eq($('#Developer_Rating').val(), 7); } }; 

चरणों की दो आवश्यकताएं हैं:

• चरणों का नाम होना चाहिए, अर्थात् डेवलपर को एक प्राकृतिक भाषा में वर्णन करना होगा कि क्या हो रहा है;
• प्रत्येक चरण में एक से अधिक उपयोगकर्ता कार्रवाई नहीं होनी चाहिए।

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

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

समस्या:

ऐसा लगता है कि एक कार्यात्मक परीक्षण सरल है: हम एक निश्चित परिदृश्य में अंतिम उपयोगकर्ता के कार्यों का अनुकरण करते हैं और परिणामों का मूल्यांकन करते हैं। लेकिन कई छिपे हुए तंत्र हैं जो उपयोगकर्ता के नियंत्रण के बाहर होते हैं, लेकिन स्क्रिप्ट के निष्पादन को प्रभावित करते हैं। और परीक्षण डेवलपर्स को उन पर विचार करना होगा।

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

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

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

समस्या:

अक्सर एक परीक्षित पृष्ठ को मूल या विंडोज प्रमाणीकरण की आवश्यकता होती है। और अक्सर इस समस्या का समाधान नहीं होता है "बॉक्स से बाहर।"

TestCafe में इन प्रमाणीकरण प्रोटोकॉल के लिए अंतर्निहित समर्थन है - बस अपनी लॉगिन जानकारी दर्ज करें और TestCafe स्वचालित रूप से प्रमाणित करेगा, ठीक उसी तरह जैसे आपका ब्राउज़र करता है:



आप परीक्षण कोड में लॉगिन जानकारी भी निर्दिष्ट कर सकते हैं:

 '@auth guest:MostlyHarmless'; '@test'['Click Input'] = { '1. Type name': function() { act.type(getInput(), 'Peter Parker'); }, '2. Move caret position': function() { act.click(getInput(), { caretPos: 5 }); }, '3. Erase a character': function() { act.press('backspace'); }, '4. Check result': function() { eq(getInput().val(), 'Pete Parker'); } }; 

समस्या:

कार्यात्मक परीक्षण फ्रेमवर्क एपीआई - विशेष ध्यान देने योग्य बात। DOM पर ये राक्षसी ऐड-ऑन, जो कभी-कभी ब्राउज़रों के DOM API में नवाचारों के साथ नहीं रहते हैं, सीखने के लिए सबसे आसान काम से दूर हैं।

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

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

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

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

TestCafe API में 4 प्रकार के दावे भी शामिल हैं जो ऑब्जेक्ट प्रकारों को पहचान सकते हैं और "गहरी" तुलना कर सकते हैं। परीक्षणों को संपादित करने के लिए, आप फ्रेमवर्क में निर्मित संपादक का उपयोग कर सकते हैं:



आप अपने पसंदीदा जावास्क्रिप्ट संपादक का भी उपयोग कर सकते हैं। TestCafe मक्खी पर परीक्षण संकलित करता है, इसलिए यदि आप सिंटैक्स त्रुटि करते हैं या गलत तरीके से परीक्षण संरचना बनाते हैं, तो आपको सूचित किया जाएगा:



समस्या:

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

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

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

परीक्षण रिकॉर्डर के बारे में

बेशक, पहले से वर्णित सब कुछ के अलावा, टेस्ट कैफ़े में एक अंतर्निहित परीक्षण रिकॉर्डर है जिसमें चयनकर्ताओं के सुविधाजनक लाइव-संपादक और प्रदर्शन किए गए कार्यों को वापस रोल करने की क्षमता है:

निष्कर्ष में

टेस्ट कैफ़े का विकास करते समय, हमने बड़ी संख्या में ओपन-सोर्स विकास का उपयोग किया, इसलिए हमारे लिए ओपन सोर्स समुदाय को क्रेडिट न देना थोड़ा अनुचित होगा। इसलिए, टेस्ट कैफे विकास के संदर्भ में, पार्स 5 बनाया गया था - एक HTML पार्सर ^[2] , जो नोड के लिए HTML5 विनिर्देश के साथ पूरी तरह से संगत पार्सर्स का सबसे तेज है । और whacko एक मंच के रूप में parse5 का उपयोग कर चीयरियो पुस्तकालय का एक कांटा है।

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

नोट