मेन्यू

ऑटोमेशन परीक्षण क्या है (टेस्ट ऑटोमेशन शुरू करने के लिए अंतिम गाइड)

what is automation testing

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

अपनी परियोजना पर स्वचालन परीक्षण शुरू करने के लिए एक पूर्ण गाइड:

स्वचालन परीक्षण क्या है?

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

स्वचालन परीक्षण गाइड

क्या आप अपनी परियोजना पर स्वचालन परीक्षण शुरू करना चाहते हैं लेकिन क्या आप नीचे बताए अनुसार सबसे बुनियादी चरणों से जूझ रहे हैं:

  • अपनी परियोजना के लिए स्वचालन कैसे शुरू करें?
  • सबसे अच्छा और सही स्वचालन उपकरण का चयन कैसे करें?
  • लिपियों को प्रभावी ढंग से कैसे विकसित किया जाए?
  • परीक्षण स्क्रिप्ट का निष्पादन और रखरखाव कैसे करें?
  • और आखिरकार सफल स्वचालन परीक्षण के लिए आपको किन सर्वोत्तम प्रथाओं का पालन करना होगा?

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

आइए अपने प्रोजेक्ट पर स्वचालन शुरू करने के ट्यूटोरियल की श्रृंखला पर एक नज़र डालें !!

ऑटोमेशन एंड-टू-एंड प्रोसेस:

iPhone और Android के लिए खाली समय कार्ड अनुप्रयोग

ट्यूटोरियल # 1 : अपने प्रोजेक्ट पर स्वचालन शुरू करने के लिए सर्वश्रेष्ठ गाइड
ट्यूटोरियल # 2: स्वचालित टेस्ट और कुछ गलत धारणाओं के प्रकार
ट्यूटोरियल # 3: अपने प्रोजेक्ट पर ऑटोमेशन का परिचय देने के लिए 10 कदम
ट्यूटोरियल # 4: सर्वश्रेष्ठ स्वचालन उपकरण का चयन करने पर A से Z गाइड
ट्यूटोरियल # 5: स्क्रिप्ट डेवलपमेंट और ऑटोमेशन फ्रेमवर्क
ट्यूटोरियल # 6: स्वचालन के निष्पादन और रिपोर्टिंग
ट्यूटोरियल # 7: सर्वश्रेष्ठ अभ्यास और टेस्ट ऑटोमेशन की रणनीतियाँ

स्वचालन युक्तियाँ:

ट्यूटोरियल # 8: 10 युक्तियाँ आपको अपने परीक्षण कार्य को स्वचालित करने से पहले पढ़नी चाहिए
ट्यूटोरियल # 9: मैनुअल और स्वचालन परियोजनाओं के लिए टेस्ट प्लानिंग अंतर कैसे होता है
ट्यूटोरियल # 10: जब स्वचालन के लिए ऑप्ट करने के लिए?
ट्यूटोरियल # 11: ऑटोमेशन टेस्ट चुनौतियां
ट्यूटोरियल # 12: ऑटोमेशन में कॉन्सेप्ट प्रूफ ऑफ कॉन्सेप्ट (POC) को गाइड करें
ट्यूटोरियल # 13: स्वचालन के लिए सही टेस्ट मामलों का चयन कैसे करें
ट्यूटोरियल # 14: ऑटोमेशन लिपियों में मैनुअल टेस्ट के मामलों का अनुवाद कैसे करें

स्वचालन कैरियर:

ट्यूटोरियल # 15: युक्तियाँ एक बेहतर स्वचालन परीक्षक बनने के लिए
ट्यूटोरियल # 16: टेस्ट स्वचालन - यह एक विशेष कैरियर है? क्या सामान्य परीक्षक भी स्वचालन कर सकते हैं?

लोकप्रिय स्वचालन उपकरण:

ट्यूटोरियल # 17: सेलेनियम ट्यूटोरियल 31+ सर्वश्रेष्ठ मुफ्त सेलेनियम प्रशिक्षण ट्यूटोरियल
ट्यूटोरियल # 18: QTP ट्यूटोरियल
ट्यूटोरियल # 19: SoapUI वेब सेवा परीक्षण उपकरण
ट्यूटोरियल # 20: प्रदर्शन परीक्षण के लिए एचपी लोडरनर

स्वचालन फ्रेमवर्क:

ट्यूटोरियल # 21: हमें स्वचालन के लिए फ्रेमवर्क की आवश्यकता क्यों है
ट्यूटोरियल # 22: सबसे लोकप्रिय स्वचालन फ्रेमवर्क

फुर्तीली में स्वचालन:

ट्यूटोरियल # 23: चुस्त दुनिया में कुशल स्वचालन कैसे लागू करें

अन्य स्वचालन उपकरण:

ट्यूटोरियल # 24: सर्वश्रेष्ठ स्वचालन परीक्षण उपकरण
ट्यूटोरियल # 25: सिकुली GUI ऑटोमेशन टूल
ट्यूटोरियल # 26: PowerShell: डेस्कटॉप एप्लिकेशन UI स्वचालन के साथ PowerShell
ट्यूटोरियल # 27: कैटलन ऑटोमेशन रिकॉर्डर (सेलेनियम आईडीई वैकल्पिक)
ट्यूटोरियल # 28: Geb टूल: Geb टूल का उपयोग करके ब्राउज़र ऑटोमेशन
ट्यूटोरियल # 29: AutoIt: AutoIt का उपयोग करके विंडोज पॉप-अप को कैसे हैंडल करें
ट्यूटोरियल # 30: ककड़ी: ककड़ी उपकरण और सेलेनियम का उपयोग करके स्वचालन
ट्यूटोरियल # 31: एंगुलरजेएस एप्लिकेशन के एंड-टू-एंड परीक्षण के लिए प्रोटेक्टर परीक्षण उपकरण

मोबाइल स्वचालन परीक्षण:

ट्यूटोरियल # 32: एपियम स्टूडियो हैंड्स-ऑन ट्यूटोरियल
ट्यूटोरियल # 33: शुरुआती के लिए Appium ट्यूटोरियल
ट्यूटोरियल # 34: सेलेंड्रोइड ट्यूटोरियल: एंड्रॉइड मोबाइल ऑटोमेशन फ्रेमवर्क
ट्यूटोरियल # 35: Ranorex ट्यूटोरियल: एक शक्तिशाली डेस्कटॉप, वेब और मोबाइल परीक्षण उपकरण

डोमेन विशिष्ट स्वचालन उदाहरण:

ट्यूटोरियल # 36: JAVA / J2EE अनुप्रयोगों का स्वचालन

स्वचालन नौकरियों के लिए साक्षात्कार की तैयारी:

ट्यूटोरियल # 37: स्वचालन परीक्षण साक्षात्कार प्रश्न
ट्यूटोरियल # 38: सेलेनियम साक्षात्कार प्रश्न

आइए, 'अंतिम गाइड टू ऑटोमेशन टेस्टिंग' श्रृंखला के पहले ट्यूटोरियल को देखें !!

आप क्या सीखेंगे:

स्वचालन परीक्षण क्या है?

यदि एक सॉफ्टवेयर कुछ भी कर सकता है, तो एक सॉफ्टवेयर एक सॉफ्टवेयर का परीक्षण क्यों नहीं कर सकता है?

क्या यह कथन आपके लिए तार्किक है?

यदि हाँ, तो बधाई हो, अब आप टेस्ट ऑटोमेशन के बारे में सोच रहे हैं, जो केंद्र बिंदु है कि हम जानकारीपूर्ण ट्यूटोरियल की इस श्रृंखला में चर्चा करने जा रहे हैं।

एक एसक्यूए के रूप में अपनी नौकरी पर पहले दिन खुद की कल्पना करें। आपको परीक्षण के लिए एक आवेदन प्रस्तुत किया जाता है। यह एक ईआरपी एप्लिकेशन है जिसमें 100s फॉर्म और हजारों रिपोर्ट हैं। आप एक फार्म खोलकर अपनी खोजपूर्ण परीक्षा शुरू करते हैं जिसमें लगभग 50 अलग-अलग क्षेत्र होते हैं।

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

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

अब तीसरा दिन आता है, एक डेवलपर ने फिर से एक नया संस्करण जारी किया है। अब आपको फिर से उस फॉर्म का परीक्षण करना होगा ताकि यह सुनिश्चित हो सके कि कोई प्रतिगमन मुद्दा नहीं मिला है। वही 20 मिनट अब आप थोड़ा ऊब महसूस करते हैं।

अब कल्पना करें कि अब से 1 महीने बाद, नए संस्करण लगातार रिलीज़ हो रहे हैं और हर रिलीज़ पर, आपको इस तरह के अन्य रूपों के 100 से अधिक रूपों का परीक्षण करना होगा, बस यह सुनिश्चित करने के लिए कि कोई प्रतिगमन नहीं है।

अब आपको गुस्सा आता है। तुम थका हुआ महसूस कर रहे हो । आप कदमों को छोड़ना शुरू करते हैं। आप कुल क्षेत्रों का लगभग 50% भरते हैं। आपकी सटीकता समान नहीं है, आपकी ऊर्जा समान नहीं है और निश्चित रूप से, आपके कदम समान नहीं हैं।

और एक दिन, ग्राहक उसी बग को उसी रूप में रिपोर्ट करता है। आप दयनीय महसूस करते हैं। अब आप अपुष्ट महसूस करते हैं। आपको लगता है कि आप पर्याप्त सक्षम नहीं हैं। प्रबंधक आपकी क्षमता पर सवाल उठा रहे हैं।

मेरे पास आपके लिए एक खबर है; यह 90% मैनुअल परीक्षकों की कहानी है। आप अलग नहीं हैं।

प्रतिगमन मुद्दे सबसे दर्दनाक मुद्दे हैं। हम इंसान हैं। और हम हर दिन एक ही ऊर्जा, गति और सटीकता के साथ एक ही काम नहीं कर सकते हैं। यह वही है जो मशीनों करते हैं। यह वही है जो स्वचालन के लिए आवश्यक है, उसी गति, सटीकता और ऊर्जा के साथ समान चरणों को दोहराने के लिए, क्योंकि वे पहली बार दोहराए गए थे।

मुझे आशा है कि आप मेरी बात प्राप्त करेंगे !!

स्वचालन एक दोस्त का परीक्षण

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

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

स्वचालन - प्रतिगमन परीक्षण के लिए एक लागत प्रभावी तरीका

स्वचालन लागत वास्तव में शुरू में अधिक है। इसमें उपकरण की लागत, फिर स्वचालन परीक्षण संसाधन की लागत और उसका प्रशिक्षण शामिल है।

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

परिदृश्य जिसमें स्वचालन की आवश्यकता होती है

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

उदाहरण के लिए ,

  1. पिक्सेल द्वारा दो छवियों की तुलना पिक्सेल।
  2. हजारों पंक्तियों और स्तंभों वाले दो स्प्रेडशीट की तुलना करना।
  3. 100,000 उपयोगकर्ताओं के लोड के तहत एक एप्लिकेशन का परीक्षण करना।
  4. प्रदर्शन बेंचमार्क।
  5. विभिन्न ब्राउज़रों पर एप्लिकेशन का परीक्षण करना और समानांतर में विभिन्न ऑपरेटिंग सिस्टम पर।

इन स्थितियों की आवश्यकता होती है और उपकरणों द्वारा परीक्षण किया जाना चाहिए।

तो, स्वचालित करने के लिए कब?

यह एक युग है फुर्तीली कार्यप्रणाली एसडीएलसी में, जहां विकास और परीक्षण लगभग समानांतर में चले जाएंगे और यह तय करना बहुत मुश्किल है कि कब स्वचालित करना है।

स्वचालन में कदम रखने से पहले निम्नलिखित स्थितियों पर विचार करें

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

सर्वश्रेष्ठ स्वचालन मामलों का निर्णय कैसे करें:

स्वचालन एक परीक्षण चक्र का एक अभिन्न अंग है और यह तय करना बहुत महत्वपूर्ण है कि हम ऑटोमेशन के बारे में निर्णय लेने से पहले स्वचालन के साथ क्या हासिल करना चाहते हैं।

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

कुशल टेस्ट ऑटोमेशन

यह श्रृंखला आपको बताती है कि कैसे एक ऑटोमेशन सूट को पर्याप्त कुशल बनाया जा सकता है ताकि सही परीक्षण मामलों को उठाया जा सके और हमारे पास मौजूद ऑटोमेशन लिपियों के साथ सही परिणाम मिल सके।

इसके अलावा, मैंने सवालों के जवाबों को कवर किया है जैसे कि स्वचालित करने के लिए, स्वचालित करने के लिए क्या, स्वचालित करने के लिए क्या नहीं और स्वचालन को कैसे प्रेरित किया जाए।

स्वचालन के लिए सही परीक्षण

इस समस्या से निपटने का सबसे अच्छा तरीका यह है कि हम जल्द ही एक 'ऑटोमेशन स्ट्रेटेजी' तैयार करें जो हमारे उत्पाद के अनुकूल हो।

विचार परीक्षण मामलों को समूहित करने के लिए है ताकि प्रत्येक समूह हमें एक अलग तरह का परिणाम दे। नीचे दिए गए चित्रण से पता चलता है कि हम अपने समान परीक्षण मामलों को कैसे उत्पाद / समाधान पर निर्भर करते हैं जिन्हें हम परीक्षण कर रहे हैं।

समूहन परीक्षण मामले

आइए अब हम गहरा गोता लगाएँ और समझें कि प्रत्येक समूह हमें क्या हासिल करने में मदद कर सकता है:

# 1) सभी बुनियादी कार्यक्षमता का एक परीक्षण सूट बनाएं सकारात्मक परीक्षण । यह सूट स्वचालित होना चाहिए, और जब यह सूट किसी भी निर्माण के खिलाफ चलाया जाता है, तो परिणाम तुरंत दिखाए जाते हैं। इस सुइट में कोई भी स्क्रिप्ट विफल होने पर S1 या S2 दोष हो जाता है, और जो विशिष्ट बनाता है वह अयोग्य हो सकता है। इसलिए हमने यहां काफी समय बचाया है।

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

यह स्पष्ट रूप से स्वचालन के लक्ष्यों को प्राप्त करता है जो हैं:

  • परीक्षण के प्रयास को कम करें।
  • पहले चरणों में कीड़े का पता लगाएं।

#दो) अगला, हमारे पास एक समूह है एंड टू एंड टेस्ट ।

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

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

बेहतर समझने के लिए मान लें कि हम परीक्षण कर रहे हैं ऑनलाइन शॉपिंग पोर्टल , अंत से लेकर अंत तक के परीक्षणों के भाग के रूप में हमें केवल प्रमुख चरणों को शामिल करना चाहिए।

नीचे दिए गए अनुसार:

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

इसलिए जब एक ऐसी स्क्रिप्ट चलती है तो यह विश्वास दिलाता है कि संपूर्ण रूप से समाधान ठीक काम कर रहा है!

# 3) तीसरा सेट है फ़ीचर / फ़ंक्शनलिटी आधारित परीक्षण ।

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

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

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

स्वचालित करने के लिए क्या नहीं है?

नीचे दिए गए कुछ परीक्षण हैं जिन्हें स्वचालित नहीं किया जाना चाहिए।

# 1) नकारात्मक परीक्षण / विफलता परीक्षण

हमें स्वचालित करने का प्रयास नहीं करना चाहिए नकारात्मक या विफलता परीक्षण , क्योंकि इन परीक्षणों के लिए परीक्षकों को विश्लेषणात्मक रूप से सोचने की आवश्यकता होती है और नकारात्मक परीक्षण वास्तव में पास या असफल परिणाम देने के लिए सीधे नहीं होते हैं जो हमारी मदद कर सकते हैं।

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

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

# 2) तदर्थ परीक्षण

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

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

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

# 3) बड़े पैमाने पर प्री-सेटअप के साथ टेस्ट

ऐसे परीक्षण हैं जिनके लिए कुछ भारी पूर्व-आवश्यकताएं होती हैं।

उदाहरण के लिए, हमारे पास एक उत्पाद हो सकता है जो कुछ कार्यों के लिए एक 3 पार्टी सॉफ्टवेयर के साथ एकीकृत करता है, क्योंकि उत्पाद किसी भी मैसेजिंग कतार प्रणाली के साथ एकीकृत होता है जिसे सिस्टम पर स्थापना, कतारों की स्थापना, कतारें बनाना आदि की आवश्यकता होती है।

३तृतीयपार्टी सॉफ्टवेयर कुछ भी हो सकता है और सेटअप प्रकृति में जटिल हो सकता है और यदि ऐसी स्क्रिप्ट स्वचालित हैं तो ये हमेशा के लिए उस 3 पार्टी सॉफ्टवेयर के फ़ंक्शन / सेटअप पर निर्भर होंगे।

पूर्व-आवश्यकता में शामिल हैं:

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

ऊपर सिर्फ एक उदाहरण है, सामान्य तौर पर, उन परीक्षणों पर नज़र रखें जिनके पास एक सरल परीक्षण के लिए श्रमसाध्य पूर्व सेटअप हैं।

टेस्ट ऑटोमेशन का सरल उदाहरण

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

उदाहरण के लिए , यदि आप एक कैलकुलेटर का परीक्षण कर रहे हैं और परीक्षण का मामला यह है कि आपको दो संख्याओं को जोड़ना होगा और परिणाम देखना होगा। स्क्रिप्ट आपके माउस और कीबोर्ड का उपयोग करके समान चरणों का प्रदर्शन करेगी।

उदाहरण नीचे दिखाया गया है।

मैनुअल टेस्ट केस स्टेप्स:

  1. कैलकुलेटर लॉन्च करें
  2. 2 दबाएं
  3. + दबाएं
  4. 3 दबाएं
  5. प्रेस =
  6. स्क्रीन को 5 प्रदर्शित करना चाहिए।
  7. कैलकुलेटर बंद करें।

स्वचालन स्क्रिप्ट:

//the example is written in MS Coded UI using c# language. (TestMethod) public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }

उपरोक्त स्क्रिप्ट आपके मैनुअल चरणों का केवल एक दोहराव है। स्क्रिप्ट बनाना आसान है और साथ ही समझने में आसान है।

दावे क्या हैं?

स्क्रिप्ट की दूसरी आखिरी पंक्ति को कुछ और स्पष्टीकरण की आवश्यकता है।

Assert.AreEqual ('5', txtResult.DisplayText, 'कैलकुलेटर 5 नहीं दिखा रहा है);

हर परीक्षण के मामले में, हमारे पास अंत में कुछ अपेक्षित या अनुमानित परिणाम होते हैं। उपरोक्त स्क्रिप्ट में, हमें एक उम्मीद है कि '5' को स्क्रीन पर दिखाया जाना चाहिए। वास्तविक परिणाम वह परिणाम है जो स्क्रीन पर प्रदर्शित होता है। प्रत्येक परीक्षण के मामले में, हम वास्तविक परिणाम के साथ अपेक्षित परिणाम की तुलना करते हैं।

वही स्वचालन परीक्षण के लिए भी जाता है। यहां एकमात्र अंतर यह है, जब हम परीक्षण स्वचालन में उस तुलना को करते हैं, तो इसे प्रत्येक उपकरण में कुछ और कहा जाता है।

कुछ उपकरण इसे 'कहते हैं' अभिकथन ', कुछ इसे' कहते हैं जांच की चौकी 'और कुछ इसे' सत्यापन 'कहते हैं। लेकिन मूल रूप से, यह सिर्फ एक तुलना है। यदि यह तुलना विफल हो जाती है, तो जैसे एक स्क्रीन 5 के बजाय 15 दिखा रहा है तो यह दावा / जांच / सत्यापन विफल हो जाता है और आपका परीक्षण मामला विफल के रूप में चिह्नित किया जाता है।

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

उपरोक्त लिपि में, हमने दूसरी अंतिम पंक्ति में एक प्रदर्शन किया है। 5 अपेक्षित परिणाम है, txtResult । डिस्प्लेटेक्स्ट वास्तविक परिणाम है और यदि वे समान नहीं हैं, तो हमें एक संदेश दिखाया जाएगा कि 'कैलकुलेटर 5 नहीं दिखा रहा है'।

निष्कर्ष

परीक्षण के अनुमानों को बेहतर बनाने के लिए प्रायः सभी परीक्षकों ने परियोजना की समय सीमा और सभी मामलों को स्वचालित करने का आदेश दिया है।

स्वचालन के बारे में कुछ सामान्य 'गलत' धारणाएं हैं।

वे:

  • हम प्रत्येक परीक्षण मामले को स्वचालित कर सकते हैं।
  • स्वचालित परीक्षण से परीक्षण का समय बहुत कम हो जाएगा।
  • स्वचालन स्क्रिप्ट को सुचारू रूप से चलाने पर कोई बग नहीं आते हैं।

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

सही उम्मीदवारों को समूहीकृत और स्वचालित करने से समय की पूरी बचत होगी और स्वचालन के सभी लाभ मिलेंगे।

इस उत्कृष्ट ट्यूटोरियल को केवल 7 बिंदुओं में संक्षेपित किया जा सकता है।

स्वचालन परीक्षण:

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

यहां, स्वचालन को सरल शब्दों में समझाया गया है, लेकिन इसका मतलब यह नहीं है कि यह हमेशा करना आसान है। इसमें चुनौतियां, जोखिम और कई अन्य बाधाएं शामिल हैं। ऐसे कई तरीके हैं जिनके द्वारा परीक्षण स्वचालन गलत हो सकता है, लेकिन अगर सब ठीक हो जाता है, तो परीक्षण स्वचालन के लाभ वास्तव में बहुत बड़े हैं।

इस श्रृंखला में आगामी:

हमारे आगामी ट्यूटोरियल में, हम स्वचालन से संबंधित कई पहलुओं पर चर्चा करेंगे।

इसमे शामिल है:

  1. स्वचालित परीक्षणों के प्रकार और कुछ गलत धारणाएँ।
  2. अपने संगठन में स्वचालन कैसे शुरू करें और परीक्षण स्वचालन करते समय आम नुकसान से बचें।
  3. उपकरण चयन प्रक्रिया और विभिन्न स्वचालन उपकरणों की तुलना।
  4. उदाहरण के साथ स्क्रिप्ट डेवलपमेंट और ऑटोमेशन फ्रेमवर्क।
  5. निष्पादन और परीक्षण स्वचालन की रिपोर्टिंग।
  6. सर्वश्रेष्ठ अभ्यास और टेस्ट ऑटोमेशन की रणनीतियाँ।

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

अगले ट्यूटोरियल # 2

अनुशंसित पाठ

^