किन सेलेनियम र काकडी एक साथ प्रयोग हुँदैन

यस पोष्टमा, म किन यो विश्वास गर्दछु किन मं विश्वास गर्दछु सेलेनियम र काकडी संग UI स्वचालित परीक्षणहरु लेख्नु खराब विचार हो।

पोष्टको शीर्षकले सेलेनियम र काकम्बर उल्लेख गर्दछ किनकि तिनीहरू क्रमशः सबै भन्दा लोकप्रिय ब्राउजर ऑटोमेशन र BDD उपकरणहरू हो, यद्यपि, यस लेखको प्रस context्ग कुनै पनि BDD उपकरणको संयोजनमा कुनै UI स्वचालन उपकरणमा लागू हुन्छ।

म गहिरो खन्न अघि, हामी केहि पृष्ठभूमि जानकारी समीक्षा गरौं।




सेलेनियम भनेको के हो?

सेलेनियम एक ब्राउजर स्वचालन परीक्षण उपकरण हो जुन प्रयोगकर्ता गतिविधि अनुकरण गर्न वेब अनुप्रयोगको HTML तत्वहरूसँग अन्तर्क्रिया गर्न सक्षम छ।

सेलेनियम वेब ड्राईभरमा, हामी धेरै प्रोग्रामिंग भाषाहरूमा लिपिहरू लेख्न सक्दछौं र बहु ​​OS र क्रस-ब्राउजर परीक्षणको लागि एक ठूलो सम्पत्ति हुन सक्छ।




काकडी भनेको के हो?

काकडी व्यवहार ड्राइभ डेभलपमेन्ट (BDD) प्रक्रिया ड्राइभ गर्नका लागि सिर्जना गरिएको हो, जसमा ग्राहकले आवश्यकताको वर्णन गर्न सकिन्छ परिदृश्य भनिने उदाहरणको श्रृंखलाको रूपमा, सादा टेक्स्ट फाईलमा Gherकिन भाषा प्रयोग गरेर दिंदा जब स्वरूपमा।

काकडी संसारमा, यी फाईलहरूलाई फिचर फाइलहरू भनिन्छ जुन स्क्र्याम टोली द्वारा समीक्षा गरियो वास्तविक विकास सुरु गर्नु अघि आवश्यकताहरूको स्पष्ट समझ लिन।

एकपटक विकास चलिरहेको छ, विकासकर्ताहरू र / वा क्यूए ले चरण परिभाषाहरू लेख्नेछन् जुन अनिवार्य रूपमा कोडको स्निपेटहरू हुन्छन् जसले परिदृश्यहरूलाई फीचर फाइलहरूबाट परीक्षण कोडमा बाँध्छ जुन परीक्षण अन्तर्गत अनुप्रयोगको बिरूद्ध कार्यहरू गर्दछ।



सेलेनियम र काकडी

दुबै सेलेनियम र काकडी आफ्नै उद्देश्यका लागि उत्कृष्ट उपकरणहरू हुन् तर जब सँगै प्रयोग गरिन्छ, चीजहरू राम्रोसँग विवाह गर्दैनन्! आउनुहोस् हामी हेरौं।


कथाहरू सामान्यतया प्रयोगकर्ताको दृष्टिकोणबाट लेखिएका हुन्छन्, उदाहरणका लागि:

सुविधा: कार्यक्षमता लग ईन गर्नुहोस्

वेबसाइट abc.com को प्रयोगकर्ताको रूपमा

म ग्राहकहरू साइटमा लगइन गर्न सक्षम भएको चाहन्छु


ताकि तिनीहरूले तिनीहरूको खाता जानकारी हेर्न सक्दछन्।

बदलेमा, सुविधा फाइलहरूमा परिदृश्यहरू एक तरीकाले लेखिएको हुन्छ जुन प्रयोगकर्ताको अन्तर्क्रियामा फीचरको व्यवहारको वर्णन गर्दछ। अनुप्रयोग । उदाहरण को लागी:

परिदृश्य १: मान्य लगइन

दिइएको म abc.com लगइन पृष्ठमा छु


जब म मान्य प्रमाणहरू प्रविष्ट गर्छु

त्यसो भए म मेरो खाता पृष्ठमा पुन: निर्देशित हुनेछु

र यसैले तपाईं थप परिदृश्यहरू थप्न सक्नुहुनेछ बिभिन्न डाटा संयोजनहरूको परीक्षण गर्न।

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


तर, जहाँ यो समस्या हुन्छ; जब हामी स्वचालित UI परीक्षणहरू लेख्न काकडीको साथ सेलेनियमको संयोजन गर्न थाल्छौं।

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

त्यस्ता ब्लगहरूका पाठकहरूले यो अनुमान लगाउँदछ कि उनीहरूले साधारण लग इन परिदृश्य लिन सक्छन् र समान सिद्धान्त अनुप्रयोगको विस्तृत संदर्भमा लागू गर्न सक्दछन्।

यद्यपि मूर्ख नहुनुहोस्, किनकि सेलेनियम र काकडीको साथ चीजहरू धेरै वास्तविकतामा प्राप्त गर्न सकिन्छ जब एक वास्तविक-विश्व ठूलो वेब-आधारित अनुप्रयोगमा लागू गरिन्छ।

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

म खोज परिणाम पृष्ठमा प्रत्येक सुविधा, चपल विकास प्रयोग गरेर एक वृद्धि वृद्धिमा साइटमा थपिएको थियो भनेर मान्न गइरहेको छु।

हाम्रो सरल लगइन उदाहरणको समान सिद्धान्त लागू गर्दै, प्रत्येक सुविधाहरू विकसित भएपछि हामीसँग सम्बन्धित फिचर फाईल धेरै फरक परिदृश्यहरूले भरिएको हुन्छ। उदाहरण को लागी:

विकासको पुनरावृत्ति १ मा, 'मूल्य अनुसार फिल्टर' विकसित भएको छ, त्यसैले हामी यसको लागि एक फिल्टर फाइल मूल्य फिल्टर सम्बन्धित आफ्नो परिदृश्य संग हुनेछ।

विकासको पुनरावृत्ति २ मा, 'स्टार रेटिंग द्वारा फिल्टर' विकसित गरिएको छ, त्यसैले हामीसँग यसको नयाँ फिचरको लागि स्टार रेटिंग फिल्टरसँग सम्बन्धित आफ्नै परिदृश्यहरू सहित फिचर फाइल छ।

यो ध्यान दिनु महत्त्वपूर्ण छ कि प्रत्येक सुविधा फाईलमा परिदृश्यहरू तिनीहरूको सम्बन्धित सुविधाहरूमा मात्र विशिष्ट हुन्छन्। वास्तवमा, यसैले उनीहरूलाई बोलाइन्छ सुविधा फाईलहरू किनभने ध्यान केन्द्रित छ व्यक्तिगत सुविधाहरू

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

उदाहरण को लागी, म पहिले मेरो खोज परिणामहरु मूल्य बाट फिल्टर गर्न सक्दछु र सितारा रेटिंग को लागी अर्को फिल्टर लागू गर्न सक्छु। अह ... अब हामीसँग समस्या छ!

यस परिदृश्यमा अब कुन फिचर फाइल जानु पर्छ? 'स्टार रेटिंग द्वारा फिल्टर' फाईलमा वा 'मूल्य द्वारा फिल्टर' फाइल? कसरी अब म मेरो फिल्टर परिणाम मा एक क्रम लागू गर्न एक परिदृश्य जोड्ने बारे मा उच्च मत द्वारा क्रमबद्ध?

यदि एक हितधारकले हाम्रो परीक्षण कभरेज के हो हेर्न चाहन्छ भने, उनले कुन फिचर फाईलमा हेर्नु पर्छ? के उसले एक दृश्य फाइलहरू पढेर दृश्य परिदृश्य कभरेजको पूर्ण तस्वीर प्राप्त गर्दछ वा उसलाई सबै फिचर फाइलहरू पढ्नु आवश्यक छ?

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

र वास्तवमा यो एप्लिकेसनका वास्तविक प्रयोगकर्ताहरूले के गर्छन्। उनीहरूले पहिले आफ्ना खोज मापदण्डमा प्रविष्ट गर्छन्, एक पटक खोजी परिणाम पृष्ठमा, तिनीहरू सम्भवतः पेजिनेट, फिल्टर, त्यसपछि क्रमबद्ध, पछाडि फर्कन्छन्, र यस्तै प्रकार, र ती कार्यहरू कुनै पनि क्रममा गर्न सक्छन्। घटनाहरूको निर्धारित क्रम हुने छैन। यो एक हो वास्तविक प्रयोगकर्ता यात्रा र प्रणालीको वास्तविक परीक्षण!

एप्लिकेसनमा धेरैजसो बगहरू पर्दाफास हुन्छ जब कि त आफै सुविधाहरू बग्गी हो वा दुई सुविधाहरू जुन पूर्ण रूपमा एक्लोसेसनमा काम गर्दछन्, सँगै काम नगर्नुहोस्। यो पेयरवाइज टेस्टि Model मोडेलमा आधारित छ।

त्यसोभए, सेलेनियम र काकडी सँगै प्रयोग गर्ने ठूलो सम्झौता के हो?

जहाँ सम्भव छ, हामीले वेब GUI प्रयोगात्मक प्रमाणिकरणको लागि प्रयोग गर्नुहुन्न। एक सुविधाको कार्यक्षमता एकीकरण परीक्षणहरू द्वारा API लेयरमा परीक्षण गरिनु पर्छ।

UI मात्र अनुप्रयोगको माध्यमबाट प्रयोगकर्ता प्रवाहहरू जाँच गर्न, वा अन्त्य-अन्त अन्त्यमा परीक्षणहरूको लागि आरक्षित हुनुपर्दछ र सुनिश्चित गर्नुहोस् कि सान्दर्भिक अपेक्षित मोड्युलहरू वा विजेटहरू पृष्ठमा उपस्थित छन् किनकि प्रयोगकर्ताले एक पृष्ठबाट अर्कोमा अन्वेषण गर्दछ।

एक सामान्य उपयोगकर्ता यात्रा लाग्छ:

१ - abc.com वेबसाइटको गृहपृष्ठमा जानुहोस्

२ - गृहपृष्ठबाट उत्पादनको लागि खोजी गर्नुहोस्

- - खोज परिणामहरूको सूची मार्फत ब्राउज गर्नुहोस्

- - फिल्टर र / वा क्रमबद्ध लागू गर्नुहोस्

- - उत्पाद विवरण पढ्नुहोस्

6 - टोकरीमा उत्पाद थप्नुहोस्

- - जाँच गर्न जारी राख्नुहोस् ...

सेलेनियम यी परिदृश्यहरूलाई स्वचालित बनाउन र प्रत्येक पृष्ठमा बिभिन्न तत्वहरूको लागि जाँच गर्न उत्कृष्ट छ र मैले माथि उल्लेख गरें कि त्यो के हो जुन हामीले UI लेयरमा परीक्षण गर्दा केन्द्रित गर्नुपर्दछ, र बिभिन्न राज्य संक्रमणहरूको परीक्षण गर्दा।

देख्न सकिन्छ, अनुप्रयोग मार्फत प्रत्येक प्रयोगकर्ताको यात्रा धेरै पृष्ठहरूमा छुन्छ र सम्भावित प्रत्येक र प्रत्येक पृष्ठमा बहु सुविधाहरूसँग अन्तर्क्रिया गर्दछ, र हामी यात्राको प्रत्येक चरणमा विभिन्न चीजहरू प्रमाणित गर्दैछौं, त्यसैले एक प्रयोग गरेर सुविधा फाईल यी परिदृश्यहरु लाई कागजात गर्न को लागी कुनै पनि मतलब हुँदैन, किनभने हामी एक सुविधाको परीक्षण गरिरहेका छैनौं, हामी एकीकृत प्रणालीको परीक्षण गर्दैछौं।

जब हामी दिईएको-पछि-ढाँचामा अन्तिम-देखि-अन्त परिदृश्यहरू लेख्ने कोसिस गर्दा चीजहरू वास्तवमै नाश हुने आकारमा जान्छन्। हामी कति कति दिन्छौं? हामी कती कति छन्?

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

सारांश

काकडी एकीकरण परीक्षणहरूको साथ एपीआई लेयरमा सुविधाको व्यवहार जाँच गर्न एक उत्तम उपकरण हो जहाँ प्रत्येक सुविधाहरू पूर्ण रूपमा परीक्षण गर्न सकिन्छ। यो उपकरण कहानी परीक्षणको लागि प्रयोग गर्नुपर्दछ।

सेलेनियम यूआई लेयरमा प्रयोगकर्ता परिदृश्यहरू स्वचालित गर्न र प्रणालीको व्यवहार पूर्ण रूपमा जाँच्न धेरै प्रयोगकर्ता कथाहरू समावेश गर्ने उत्तम उपकरण हो।

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

मेरो लेख तथ्यहरु घटाउने मा आधारित छ!

  • यदि त्यहाँ काकडी प्रयोग गर्न कुनै मूल्य छ भने, यो सुविधा स्तरमा छ।
  • एक सुविधाको कार्यक्षमता जाँच UI को बाहिर राम्रो गरीन्छ, जस्तै। एपीआई परीक्षणहरू।
  • एपीआई लेयर टेस्टहरूमा पनि पनि काकडी असफल हुन्छ।
  • यूआई टेस्टले प्रयोगकर्ता / व्यवसाय परिदृश्य कभर गर्नुपर्दछ र एकल सुविधाहरू होइन।

खीरा सुन्दरतापूर्वक परीक्षण र परिदृश्यहरूको सरल र भोली दृश्यको साथ काम गर्दछ, जस्तै सबैको मनपर्ने लगईन कार्यक्षमता।

दिइयो म लगइन पृष्ठमा छु
जब म मान्य प्रमाणहरू प्रविष्ट गर्छु
त्यसो भए मैले मेरो खाता हेर्नु पर्छ

तर कुनै पनि स्यावी परीक्षकले जान्दछ कि एक साधारण लगइन कार्यक्षमतासँग पनि धेरै चेकहरू छन्। ती जाँचहरूलाई काकडीमा रूपान्तरण गर्ने प्रयास गर्नुहोस्।

यो केवल लगइनको लागि हो; काकडीमा अन्त-देखि-अन्त परीक्षण लेख्ने प्रयास गर्नुहोस्!

UI परीक्षण प्रयोगकर्ता यात्रा कभर गर्नु पर्छ जुन सामान्यतया अन्त्य-अन्तमा हुन्छ र अनुप्रयोगको धेरै सुविधाहरू अभ्यास गर्दछ।

त्यहाँ धेरै धेरै अनुप्रयोगहरूमा एकल प्रयोगकर्ता यात्रामा जान्छ।

काकडी निश्चित रूपमा प्रयोगकर्ता / व्यवसाय परिदृश्य परीक्षणको लागि सही उपकरण होइन।

रोचक लेख