सॉफ़्टवेयर परीक्षण में, ऐप्स की विश्वसनीयता और मजबूती सुनिश्चित करने के लिए परीक्षण मामलों का डिज़ाइन मौलिक है। संयुक्त परीक्षण डिजाइन तकनीक, जैसे कि के-वे परीक्षण और जोड़ीदार परीक्षण, का उद्देश्य विभिन्न इनपुट चर के बीच बातचीत का परीक्षण करना है। हालाँकि, यह स्पष्ट हो जाता है कि चुनौतियाँ और नुकसान महत्वपूर्ण त्रुटियों को उजागर करने में उनकी प्रभावशीलता में बाधा बन सकते हैं।
यह संक्षिप्त लेख उन विशिष्ट मुद्दों पर केंद्रित है जिनका कॉम्बिनेटरियल परीक्षण डिजाइन के दौरान सामना किया जा सकता है, और उन बारीकियों की खोज की जा रही है जिन पर सावधानीपूर्वक विचार करने की आवश्यकता है। आइए गलत इनपुट मानों के उदाहरणों, मजबूत भविष्यवाणियों के महत्व, अक्सर नजरअंदाज किए गए चर संयोजनों के महत्व और चर कैसे बातचीत करते हैं इसकी महत्वपूर्ण समझ पर ध्यान दें।
के-वे परीक्षण सेट में के वेरिएबल्स के लिए मानों के सभी संभावित संयोजन शामिल होते हैं। उदाहरण के लिए, ऑलपेयर एल्गोरिदम को लागू करने से 2-तरफा परीक्षण सेट प्राप्त होता है, जिसमें परिवर्तनीय मानों के जोड़े के सभी संभावित संयोजन शामिल होते हैं। नतीजतन, के-वे फॉल्ट, के वेरिएबल्स के मानों की परस्पर क्रिया के परिणामस्वरूप होने वाली त्रुटि को संदर्भित करता है। दो प्रणालियों, SYS1 और SYS2 की जांच करने पर, उनके उत्पादन रिलीज़ के बाद त्रुटियों का पता चला। दोनों प्रणालियों को 2, 3, 4 और 5+ के k मानों के साथ k-वे परीक्षण से गुजरना पड़ा।
तालिका दो प्रणालियों के लिए के-वे परीक्षण के परिणामों को प्रदर्शित करती है।
दोष प्रकार | SYS1 | SYS2 |
---|---|---|
2 रास्ते | 30 | 29 |
3-तरफा | 4 | 12 |
4 तरफा | 7 | 1 |
> 4-तरफा | 7 | 3 |
नहीं मिला | 34 | 43 |
प्रत्येक के-वे सेट के लिए अनुक्रमिक जाँचें आयोजित की गईं। चित्र 2.1 इंगित करता है कि दो या कम इनपुट चर की परस्पर क्रिया से उत्पन्न होने वाली त्रुटियाँ 29 in SYS1
और 30 in SYS2
थीं। तीन वेरिएबल्स की परस्पर क्रिया से त्रुटियाँ 4*(30+4) in SYS2
और 12*(29+12) in SYS1
थीं। चार चर वाले इंटरैक्शन के लिए, त्रुटियां 7*(30+4+7) in SYS2
और 1*(29+12+1) in SYS1
थीं। चार से अधिक वेरिएबल के साथ इंटरैक्शन से त्रुटियां 3*(29+12+1+3) in SYS1
और 7*(30+4+7+7) in SYS2
थीं। उल्लेखनीय रूप से, SYS1 में 43 त्रुटियाँ नहीं पाई गईं, और SYS2 में 34 त्रुटियाँ नहीं पाई गईं।
इस उदाहरण में, सबसे महत्वपूर्ण त्रुटियाँ नॉट फाउंड श्रेणी से संबंधित थीं। आगे की जांच से पता चला कि अधिकांश अज्ञात त्रुटियां एक-तरफ़ा दोष थीं, जिसका अर्थ है कि एक चर के विशिष्ट मान के कारण अन्य चर मानों से स्वतंत्र रूप से त्रुटि हुई। जोड़ीवार परीक्षण से इन त्रुटियों का पता लगाया जाना चाहिए था, लेकिन किसी कारण से, वे अनदेखा रह गए। ये नॉट फाउंड त्रुटियां मुख्य रूप से 1-वे दोष हैं जिन पर ध्यान नहीं दिया गया क्योंकि कुछ इनपुट मान या तो चयनित नहीं थे या गलत तरीके से चुने गए थे।
समस्या का सार इस तथ्य में निहित है कि ऑलपेयर एल्गोरिदम के अनुप्रयोग से पहले की गई कोई भी त्रुटि बनी रहेगी। इसका तात्पर्य यह है कि यदि पिछली परीक्षण डिजाइन तकनीकों को गलत तरीके से लागू किया गया था या इनपुट मान गलत थे, तो ऑलपेयर एल्गोरिदम या ऑर्थोगोनल एरे परीक्षण का उपयोग करने के बावजूद आवेदन में त्रुटियां बनी रहेंगी।
उदाहरण के तौर पर, आइए एक एप्लिकेशन मॉड्यूल पर विचार करें जिसमें कई विकल्प हैं (कुछ ऐसा जो इस फॉर्म जैसा दिखता है) और, परिणामस्वरूप, बड़ी संख्या में इनपुट डेटा संयोजन।
मॉड्यूल में, मान लें कि 2^12 * 3
संभावित संयोजन हैं। यहां, चुनौती गलत इनपुट मानों को चुनने में नहीं है, क्योंकि ऑलपेयर एल्गोरिदम का उपयोग करके सभी संभावित परिवर्तनीय मानों का विस्तृत परीक्षण किया जा सकता है। हालाँकि, क्या इससे सभी महत्वपूर्ण त्रुटियाँ उजागर हो जाएँगी? अपेक्षित परिणाम संबंधी समस्याओं के कारण संभवतः नहीं। इस प्रकार के सॉफ़्टवेयर मॉड्यूल में विकल्पों के प्रत्येक संयोजन में हेरफेर करने के बाद, किसी को यह सत्यापित करने के लिए कुछ समय के लिए सिस्टम का उपयोग करने की आवश्यकता होगी कि विकल्प सही ढंग से काम करते हैं और चुने गए विकल्पों को लागू करने के बाद कुछ भी नहीं टूटा है। इस मामले में, इस बात की कोई गारंटी नहीं है कि कोई भी सूक्ष्म, गैर-स्पष्ट समस्या आसानी से छूट न जाए।
प्रत्येक परीक्षण के बाद, किसी को सिस्टम के मुख्य कार्यों का गहन मूल्यांकन करने की आवश्यकता हो सकती है। यहां मुद्दा यह है कि गंभीर खामियां अक्सर उतनी स्पष्ट नहीं होती हैं जितनी कोई चाहता है, और अपेक्षित परिणामों में हर चीज का हिसाब-किताब रखना व्यावहारिक रूप से असंभव हो जाता है।
2^12 * 3
संयोजनों में से (जैसा कि हमने उपरोक्त उदाहरण में सुझाव दिया है), मॉड्यूल विकल्पों में से एक संयोजन होने की संभावना है जो अन्य सभी की तुलना में बहुत अधिक बार घटित होगा - डिफ़ॉल्ट सेटिंग। यदि 95% लोग इस मॉड्यूल के लिए डिफ़ॉल्ट सेटिंग्स से विकल्प कभी नहीं बदलेंगे, तो लगभग/लगभग-डिफ़ॉल्ट विकल्पों का अच्छा कवरेज होना चाहिए। एक विकल्प में डिफ़ॉल्ट कॉन्फ़िगरेशन से विचलन के साथ सभी विविधताओं का परीक्षण करने पर परीक्षणों की 2-अंकीय संख्या प्राप्त होगी। यदि डिफ़ॉल्ट से दो सेटिंग्स में संभावित विचलन के साथ विकल्पों के सभी संयोजनों का परीक्षण किया जाए, तो यह लगभग सौ परीक्षण मामले होंगे। इन परीक्षण मामलों और सभी-युग्मित परीक्षण मामलों के साथ परीक्षण करने से डिफ़ॉल्ट विकल्प के अस्तित्व को अनदेखा करने की तुलना में बेहतर परिणाम मिल सकते हैं। हालाँकि, ऑलपेयर एल्गोरिदम परीक्षक को सबसे संभावित और आमतौर पर उपयोग किए जाने वाले चर संयोजनों को नजरअंदाज करने के लिए मजबूर करता है।
जोड़ीवार परीक्षण की सफलता या विफलता का मुख्य कारक यह समझना है कि इनपुट चर का संयोजन आउटपुट डेटा को कैसे प्रभावित करता है। दो अलग-अलग परीक्षण किए गए अनुप्रयोगों पर जोड़ीवार परीक्षण लागू करने से काफी भिन्न परिणाम मिल सकते हैं। कुछ एप्लिकेशन आउटपुट डेटा उत्पन्न करने के लिए कम इनपुट डेटा का उपयोग करते हैं, जबकि अन्य अधिक उपयोग करते हैं।
उदाहरण के तौर पर, प्रोग्राम पर विचार करें, जिसमें तीन इनपुट वैरिएबल (एक्स, वाई, जेड) और तीन संभावित आउटपुट डेटा (1, 2, 3) हैं। तीर इंगित करते हैं कि विशिष्ट परिणाम उत्पन्न करने के लिए किन चरों को परस्पर क्रिया करनी चाहिए। 1 का परिणाम प्राप्त करने के लिए, चर Y और X को परस्पर क्रिया करनी होगी; 2 का परिणाम प्राप्त करने के लिए, वेरिएबल Z और X को इंटरैक्ट करना होगा। इस एप्लिकेशन के लिए, जोड़ीवार परीक्षण लागू करना एक उपयुक्त विकल्प होगा, और सकारात्मक परिणाम आने की संभावना है। हालाँकि, ऐसे मामलों में जहां आउटपुट डेटा दो से अधिक इनपुट वेरिएबल्स की परस्पर क्रिया से उत्पन्न होता है, इस बात की अधिक संभावना है कि जोड़ीवार परीक्षण त्रुटियों की पहचान करने में विफल रहेगा। बस जोड़ीवार परीक्षण लागू करने से परीक्षण किए गए एप्लिकेशन में महत्वपूर्ण त्रुटियों को नजरअंदाज करने का जोखिम बढ़ जाता है।
एक क्यूए पेशेवर के रूप में, इन बारीकियों को समझना महत्वपूर्ण है। कुछ मामलों में सैद्धांतिक होते हुए भी, ये अंतर्दृष्टि एक समग्र परीक्षण दृष्टिकोण की आवश्यकता को रेखांकित करती है जो सतह से परे जाकर आपके ऐप्स की विश्वसनीयता और मजबूती सुनिश्चित करती है। कॉम्बिनेटरियल टेस्ट डिज़ाइन की जटिलता को समझने से क्यूए पेशेवरों को ऐप्स के जटिल व्यावसायिक तर्क का प्रभावी ढंग से परीक्षण करने और अपने उपयोगकर्ताओं को उच्च गुणवत्ता वाले सॉफ़्टवेयर वितरित करने की अनुमति मिलती है।