उदाहरण के साथ सभी प्रकार के सॉफ्टवेयर एकीकरण परीक्षण

एकीकरण परीक्षण क्यों करते हैं?

हालांकि प्रत्येक सॉफ्टवेयर मॉड्यूल इकाई परीक्षण है, फिर भी विभिन्न कारणों से दोष मौजूद हैं जैसे:

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

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

निम्नलिखित परिदृश्य के लिए नमूना एकीकरण परीक्षण मामले: एप्लिकेशन में 3 मॉड्यूल हैं जैसे ‘लॉगिन पेज’, ‘मेलबॉक्स’ और ‘ईमेल हटाएं’ और उनमें से प्रत्येक तार्किक रूप से एकीकृत है।

यहां लॉगिन पेज टेस्टिंग पर ज्यादा ध्यान न दें क्योंकि यह यूनिट टेस्टिंग में पहले ही किया जा चुका है। लेकिन जांचें कि यह मेल बॉक्स पेज से कैसे जुड़ा है।

इसी तरह मेल बॉक्स: डिलीट मेल मॉड्यूल में इसके इंटीग्रेशन की जांच करें।

दृष्टिकोण, रणनीतियाँ, एकीकरण परीक्षण के तरीके

सॉफ्टवेयर इंजीनियरिंग एकीकरण परीक्षण को निष्पादित करने के लिए विभिन्न रणनीतियों को परिभाषित करता है, अर्थात।

बिग बैंग दृष्टिकोण:
वृद्धिशील दृष्टिकोण: जिसे आगे निम्नलिखित में विभाजित किया गया है:
शीर्ष पाद उपागम
नीचे से ऊपर का दृष्टिकोण
सैंडविच दृष्टिकोण – ऊपर से नीचे और नीचे से ऊपर का संयोजन

नीचे विभिन्न रणनीतियां हैं, जिस तरह से उन्हें क्रियान्वित किया जाता है और उनकी सीमाएं भी फायदे हैं।

बिग बैंग परीक्षण

बिग बैंग टेस्टिंग एक एकीकरण परीक्षण दृष्टिकोण है जिसमें सभी घटकों या मॉड्यूल को एक साथ एकीकृत किया जाता है और फिर एक इकाई के रूप में परीक्षण किया जाता है। घटकों के इस संयुक्त सेट को परीक्षण करते समय एक इकाई के रूप में माना जाता है। यदि इकाई के सभी घटक पूर्ण नहीं होते हैं, तो एकीकरण प्रक्रिया निष्पादित नहीं होगी।

लाभ:

छोटे सिस्टम के लिए सुविधाजनक।

नुकसान:

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

• वृद्धिशील परीक्षण दृष्टिकोण में, परीक्षण दो या दो से अधिक मॉड्यूल को एकीकृत करके किया जाता है जो तार्किक रूप से एक दूसरे से संबंधित होते हैं और फिर एप्लिकेशन के उचित कामकाज के लिए परीक्षण किया जाता है। फिर अन्य संबंधित मॉड्यूल को क्रमिक रूप से एकीकृत किया जाता है और प्रक्रिया तब तक जारी रहती है जब तक कि सभी तार्किक रूप से संबंधित मॉड्यूल एकीकृत और सफलतापूर्वक परीक्षण नहीं किए जाते हैं।

  वृद्धिशील दृष्टिकोण, बदले में, दो अलग-अलग तरीकों से किया जाता है:

  नीचे से ऊपर
  ऊपर से नीचें
  स्टब्स और ड्राइवर्स

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

  स्टब: टेस्ट के तहत मॉड्यूल द्वारा बुलाया जाता है।

  ड्राइवर: परीक्षण के लिए मॉड्यूल को कॉल करता है।

  बॉटम-अप इंटीग्रेशन टेस्टिंग

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

  आरेखीय प्रतिनिधित्व:

  लाभ:

1. दोष स्थानीयकरण आसान है।
   बिग-बैंग दृष्टिकोण के विपरीत सभी मॉड्यूल विकसित होने की प्रतीक्षा में कोई समय बर्बाद नहीं होता है

   नुकसान:

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

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

   आरेखीय प्रतिनिधित्व:

   लाभ:

   दोष स्थानीयकरण आसान है।
   प्रारंभिक प्रोटोटाइप प्राप्त करने की संभावना।
   महत्वपूर्ण मॉड्यूल का प्राथमिकता पर परीक्षण किया जाता है; प्रमुख डिजाइन खामियों को पहले पाया और ठीक किया जा सकता था।

   नुकसान:

   कई स्टब्स की जरूरत है।
   निचले स्तर पर मॉड्यूल का अपर्याप्त परीक्षण किया जाता है।
   सैंडविच परीक्षण

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

   एकीकरण परीक्षण कैसे करें?

   सॉफ्टवेयर परीक्षण रणनीतियों के बावजूद एकीकरण परीक्षण प्रक्रिया (ऊपर चर्चा की गई है):

   एकीकरण परीक्षण योजना तैयार करें
   परीक्षण परिदृश्य, मामले और लिपियों को डिज़ाइन करें।
   दोषों की रिपोर्ट करने के बाद परीक्षण मामलों को निष्पादित करना।
   दोषों को ट्रैक करना और पुन: परीक्षण करना।
   चरण 3 और 4 को तब तक दोहराया जाता है जब तक कि एकीकरण पूरा नहीं हो जाता।
   एकीकरण परीक्षण योजनाओं का संक्षिप्त विवरण:

   इसमें निम्नलिखित विशेषताएं शामिल हैं:

   परीक्षण के तरीके/दृष्टिकोण (जैसा कि ऊपर चर्चा की गई है)।
   एकीकरण परीक्षण के दायरे और दायरे से बाहर के आइटम।
   नियम और जिम्मेदारियाँ।
   एकीकरण परीक्षण के लिए पूर्वापेक्षाएँ।
   परीक्षण का माहौल।
   जोखिम और शमन योजनाएँ।
   एकीकरण परीक्षण का प्रवेश और निकास मानदंड

   किसी भी सॉफ्टवेयर विकास मॉडल में एकीकरण परीक्षण चरण में प्रवेश और निकास मानदंड

   प्रवेश मानदंड:

   यूनिट परीक्षण घटक/मॉड्यूल
   सभी उच्च प्राथमिकता वाले बग को ठीक किया गया और बंद किया गया
   सभी मॉड्यूल को कोड पूर्ण और सफलतापूर्वक एकीकृत किया जाना है।
   एकीकरण परीक्षण योजना, परीक्षण मामले, परिदृश्यों को हस्ताक्षरित और प्रलेखित किया जाना है।
   एकीकरण परीक्षण के लिए आवश्यक परीक्षण वातावरण स्थापित किया जाना है

   बाहर निकलें मानदंड:

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

• निष्पादित करने से पहले, हमेशा नकली डेटा तैयार रखें। परीक्षण मामलों को निष्पादित करते समय परीक्षण डेटा का चयन न करें.