फुर्ति प्रोजेक्टहरूको लागि परीक्षण स्वचालन रणनीति

यो परीक्षण स्वचालन रणनीति उदाहरण बहु चपल टोलीहरूको साथ एक निरन्तर वितरण मोडेल मान्दछ।

अघिल्लो लेखहरूमा, एक अतिव्यापी फुर्ती परीक्षण रणनीति कागजात साथै कसरी फुर्ती प्रोजेक्टको लागि स्क्र्याचबाट QA प्रकार्य सेट अप गर्ने र कसरी स्वचालित परीक्षण प्रारंभिक सेटअपमा प्रमुख आईटमहरू मध्ये एक हो।

यो परीक्षण स्वचालन रणनीति उदाहरणमा, म परीक्षण स्वचालित प्रयासबाट अधिक प्राप्त गर्नका लागि विचार गर्न मुख्य बुँदाहरू सूचीबद्ध गर्दछु।




कार्यकारी सारांश

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

यो द्रुत प्रतिक्रिया प्राप्त गर्न, स्वचालित परीक्षणहरू निरन्तर कार्यान्वयन गर्न आवश्यक छ, छिटो हुनुपर्दछ र परीक्षण परिणामहरू स्थिर र विश्वसनीय हुनुपर्छ।


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

यसको लागि 'परीक्षण स्वचालित पिरामिड इन्भर्टिंग' आवश्यक हुन्छ GUI परीक्षणहरू तल धकेल्दै जुन कार्यान्वयन गर्न लामो समय लिन्छ, तल्लो तहमा उदाहरणका लागि। एपीआई तह जुन विश्वासको प्रारम्भिक स्तर प्रदान गर्न निर्माणको भागको रूपमा एकाई परीक्षणको पछाडि सिध्याउन सक्छ।

सम्बन्धित:



परीक्षण स्वचालन रणनीति सिंहावलोकन

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


गुण मात्रा भन्दा बढी इष्ट हुनुपर्दछ। प्राय जसो केसहरूमा, एउटा सुविधाको साथ छोड्नु राम्रो हो जुन फ्ल्याकमा रहेको बहुविध सुविधाहरूको सट्टा ठोस ढु rock्गा हो। न्यूनतम रिलीज मापदण्डको रूपमा, कुनै नयाँ विकसित सुविधाले कुनै रिग्रेसन दोषहरू प्रस्तुत गर्नु हुँदैन।

पहिले नै उल्लेख गरिएझैं निरन्तर वितरणलाई सहयोग पुर्‍याउन एप्लिकेसनको स्वास्थ्यमा द्रुत प्रतिक्रिया ठूलो महत्त्वको हुन्छ, त्यसकारण हामी प्रक्रिया तुरुन्तै प्रतिक्रिया लिन सक्दछौं।

द्रुत फीडबैक प्राप्त गर्ने एक तरीका युनिट टेस्ट, एकीकरण परीक्षण, र एपीआई परीक्षणको संख्या बढाउनु हो। यी निम्न-स्तर परीक्षणहरूले कोडले उद्देश्यको रूपमा काम गरिरहेको छ र सुरक्षाको अन्य तहहरूमा त्रुटिहरू उम्कन रोक्न मद्दत पुर्‍याउन सुरक्षा सुरक्षा प्रदान गर्दछ।

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


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



रिग्रेसन प्याकको परिभाषा

स्वचालित प्रतिगमन परीक्षणहरू परीक्षण स्वचालन रणनीतिको मुख्य हुन्।

धुवाँ रिग्रेसन प्याक

रिग्रेसन प्याकले सेनिटी जाँचको रूपमा सेवा प्रदान गर्दछ कि अनुप्रयोग लोड गर्न सकिन्छ र पहुँच गर्न सकिन्छ। साथै, केहि मुख्य परिदृश्यहरू पनि चलाउनुपर्दछ निश्चित अनुप्रयोग अझ कार्यात्मक छ।

धुवाँ परीक्षण प्याकको उद्देश्य सबैभन्दा स्पष्ट मुद्दाहरू समात्नु हो, जस्तै अनुप्रयोग लोड भइरहेको छैन, वा साधारण प्रयोगकर्ता प्रवाह कार्यान्वयन हुन सक्दैन; यस कारणको लागि, धुम्रपान परीक्षण अब भन्दा लामो समयसम्म रहनु पर्छ 5 मिनेट द्रुत प्रतिक्रिया दिन को लागी केहि प्रमुख काम गरीरहेको छैन।


धुम्रपान परीक्षण प्याक प्रत्येक प्रयोगमा लाग्छ र एपीआई र / वा GUI परीक्षणको मिश्रण हुन सक्छ।

कार्यात्मक रिग्रेसन प्याक , जुन धूम्रपान परीक्षण भन्दा बढी विस्तृतमा अनुप्रयोगको कार्यक्षमता जाँच्नको लागि हो।

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

यी प्याकहरू कुनै पनि वातावरणमा चलाउन सक्षम हुनुपर्दछ र आवश्यक पर्दा सुविधाहरूको व्यवहार वातावरणभरि निरन्तर रहिरहन्छ। तिनीहरू दिनमा धेरै चोटि कार्यान्वयन गरिन्छ र १ 15 देखि minutes० मिनेट भन्दा लामो समयसम्म रहनुहुन्न।


किनकि यी कार्यात्मक परीक्षणहरू विस्तृत रूपमा लिइन्छ, त्यसो गर्न तिनीहरू लामो समय लाग्दछ यसैले, एपीआई लेयरमा बहुमत फंक्शनल टेस्टहरू हुनु महत्त्वपूर्ण छ जहाँ परीक्षणहरू चाँडै कार्यान्वयन गर्न सकिन्छ त्यसैले हामी भित्र हुन सक्छौं। १ to देखि minutes० मिनेट समयसीमा।

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

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

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



बहु चपल टोलीहरूको लागि परीक्षण स्वचालन रणनीति

परीक्षण_आटोमेसन_स्ट्रेट_गईल

स्वचालित एकाई टेस्ट

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

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

युनिट टेस्टले टोलीलाई सबैभन्दा धेरै ROI प्रदान गर्दछ किनकि तिनीहरू दौड्न धेरै नै छिटो छन्, मद्दत गर्न र परिमार्जन गर्न सजिलो छ (किनकि त्यहाँ कुनै निर्भरताहरू छैनन्) र जब कोडमा त्रुटिहरू छन् भने यसलाई छिटो नै विकासकर्तालाई खुवाइन्छ।

एकाई परीक्षणहरू विकासकर्ताको मेसिनको साथ साथै CI वातावरणमा चलाइन्छन्।

स्वचालित एकीकरण / एपीआई वा सेवा परीक्षणहरू

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

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

जहाँ आवश्यक छ, नक्कलहरू जस्तै वायरमॉक अन्य of को निर्भरता निर्धारण गर्न प्रयोग हुनेछrdपार्टी प्रणाली र जब डाउनस्ट्रीम प्रणाली परीक्षणको लागि आवश्यक डाटा प्रदान गर्न उपलब्ध छैनन्।

एकीकरण टेस्टहरू र / वा सेवा परीक्षणहरू विकासकर्ताको मेशिनमा चलाउन सकिन्छ र निर्माणको भाग हुन सक्छ, तर यदि तिनीहरूले लामो समय लिन सुरु गरे भने, त्यसो भए उत्तम हो CI वातावरणमा।

उपकरणहरू जस्तै SoapUI सेवा परीक्षणको लागि प्रयोग गर्न सकिन्छ।

अनुप्रयोग परीक्षण

सामान्य ई-वाणिज्य अनुप्रयोग बिभिन्न प्रकार्यहरू प्रदान गर्ने बिभिन्न अनुप्रयोग वा 'अनुप्रयोग' मा विभाजन गर्न सकिन्छ। 'अनुप्रयोग परीक्षण' को अवधारणा जहाँ अनुप्रयोगहरूको कार्यक्षमता परीक्षण गर्ने परीक्षणहरूको समूह सँगै संगठित हुन्छ र इच्छित अनुप्रयोगको बिरूद्ध चलाइन्छ। यो प्याक केसहरूमा उपयोगी हुन्छ जब टोलीले व्यक्तिगत अनुप्रयोग रिलिज गर्न चाहन्छ र यो सहि ढ functioning्गले कार्य गरिरहेको छ कि भनेर जान्न चाहान्छ।

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

अनुप्रयोग परीक्षणको उद्देश्य भनेको यो सुनिश्चित गर्नु हो कि अनुप्रयोगका सुविधाहरू सही रूपमा सही छन्। किनभने परीक्षणहरू विशेष अनुप्रयोगको स्वास्थ्यमा विश्वास प्रदान गर्न एक किसिमले व्यवस्थित गरिएको छ, यी परीक्षणहरू सामान्यत: वर्टिकल टेस्टको रूपमा लिइन्छ, किनकि उनीहरूले कुनै खास अनुप्रयोग 'तल' चलाउँछन्। परीक्षण धेरै गहन हो र कभरेज ठूलो छ।

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

अन्त देखि अन्त्य परिदृश्य परीक्षणहरू

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



परीक्षण स्वचालन पिरामिड Inverting

परिक्षण स्वचालन रणनीतिको अंशको रूपमा, हामीले GUI तहमा चलाईएको स्वचालित परीक्षणहरूको संख्या कम गर्न सुनिश्चित गर्नु पर्छ।

GUI मार्फत स्वचालित परीक्षणहरू चलाउँदा अनुप्रयोगको साथ प्रयोगकर्ताको अन्तर्क्रियाको अनुकरणको हिसाबले राम्रो र अर्थपूर्ण परीक्षणहरू प्रदान गर्दछ, यो धेरै मुद्दाहरूको खतरामा छ जुन तल सूचीबद्ध छ:

भंगुर

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

सीमित परीक्षण

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

ढिलो

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

कम से कम ROI

माथि उल्लेखित मुद्दाहरूको कारण, GUI स्वचालित परीक्षणहरूले कम से कम ROI प्रदान गर्दछ।

ब्राउजर स्वचालन परीक्षणहरू न्यूनतम राखिनेछ र प्रयोगकर्ताको व्यवहार अनुकरण गर्न प्रयोग गरिन्छ सामान्य प्रयोगकर्ता प्रवाह र अन्त-टु-अन्त परिदृश्यहरू समाहित गर्दछ जहाँ सम्पूर्ण प्रणाली प्रयोग गरिन्छ।