ग्रे क्या है? Box परीक्षण तकनीक, उदाहरण

ग्रे क्या है? Box परिक्षण?

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

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

ग्रे Box टेस्टिंग एक सॉफ्टवेयर टेस्टिंग विधि है जो निम्नलिखित को जोड़ती है: सफेद Box परीक्षण और काली Box परीक्षणइन तीनों के बीच का अंतर इस बात पर निर्भर करता है कि परीक्षक आंतरिक संरचना का कितना हिस्सा देख सकता है:

• सफ़ेद रंग में Box आंतरिक संरचना (कोड) का परीक्षण करना ज्ञात है।
• काले रंग में Box आंतरिक संरचना (कोड) का परीक्षण करना अज्ञात है।
• ग्रे रंग में Box आंतरिक संरचना (कोड) का परीक्षण करना आंशिक रूप से ज्ञात है।

नीचे दिया गया आरेख तीनों विधियों को दृश्यता के उसी पैमाने पर दर्शाता है।

In सॉफ्टवेयर इंजीनियरिंग, स्लेटी Box टेस्टिंग से एप्लिकेशन के दोनों पक्षों, यानी प्रेजेंटेशन लेयर और उसके पीछे के कोड, का परीक्षण करने की क्षमता मिलती है। यह मुख्य रूप से उपयोगी है एकीकरण जांच और भेदन परीक्षण.

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

क्यों ग्रे Box परीक्षण

ग्रे Box निम्नलिखित कारणों से परीक्षण किया जाता है:

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

ग्रे Box टेस्टिंग बनाम ब्लैक Box बनाम श्वेत Box परीक्षण

ये तीनों विधियाँ परस्पर विरोधी विकल्प नहीं हैं, बल्कि पहुँच के तीन स्तर हैं, और प्रत्येक विधि एक अलग प्रकार के प्रश्न का उत्तर देती है। इन्हें साथ-साथ रखने से चुनाव स्पष्ट हो जाता है।

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

ग्रे Box परीक्षण रणनीति

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

ग्रे का प्रदर्शन करने के लिए Box परीक्षण:

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

ग्रे रंग के लिए प्रयुक्त तकनीकें Box परीक्षण इस प्रकार हैं:

• मैट्रिक्स परीक्षण: इस तकनीक में प्रोग्राम में मौजूद सभी वेरिएबल्स को परिभाषित करना शामिल है, साथ ही प्रत्येक वेरिएबल से जुड़े जोखिम को भी परिभाषित करना शामिल है, ताकि अप्रयुक्त और उच्च जोखिम वाले वेरिएबल्स स्पष्ट रूप से दिखाई दें।
• प्रतिगमन परीक्षण: यह जांच करता है कि पिछले संस्करण में किए गए बदलाव से नए संस्करण में प्रोग्राम के अन्य पहलुओं पर कोई नकारात्मक प्रभाव तो नहीं पड़ा है। यह सभी का पुनः परीक्षण, जोखिम भरे उपयोग मामलों का पुनः परीक्षण और फ़ायरवॉल के भीतर पुनः परीक्षण जैसी रणनीतियों के माध्यम से किया जाता है।
• ऑर्थोगोनल ऐरे परीक्षण या ओएटी: यह न्यूनतम टेस्ट केसों के साथ अधिकतम कोड कवरेज प्रदान करता है।
• पैटर्न परीक्षण: यह परीक्षण पिछली प्रणाली की खामियों के ऐतिहासिक डेटा पर किया जाता है। ब्लैक बॉक्स परीक्षण के विपरीत, ग्रे परीक्षण Box टेस्टिंग के जरिए कोड की गहराई से जांच की जाती है और यह पता लगाया जाता है कि विफलता क्यों हुई।

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

ग्रे रंग करने के चरण Box परीक्षण इस प्रकार हैं:

• चरण 1: इनपुट की पहचान करें।
• चरण 2: आउटपुट की पहचान करें।
• चरण 3: प्रमुख मार्गों की पहचान करें।
• चरण 4: उपकार्यों की पहचान करें।
• चरण 5: उपकार्यों के लिए इनपुट विकसित करें।
• चरण 6: उपकार्यों के लिए आउटपुट विकसित करें।
• चरण 7: उपकार्यों के लिए परीक्षण मामले को निष्पादित करें।
• चरण 8: उपकार्यों के लिए सही परिणाम सत्यापित करें।
• चरण 9: अन्य उपकार्यों के लिए चरण 4 से 8 को दोहराएं।
• चरण 10: अन्य उपकार्यों के लिए चरण 7 और 8 को दोहराएँ।

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

जहां ग्रे Box परीक्षण का उपयोग किया जाता है

यह तकनीक उन सभी स्थितियों में उपयोगी साबित होती है जहां किसी दोष का निदान केवल दो परतों को एक साथ देखकर ही किया जा सकता है। निम्नलिखित परिस्थितियाँ वे हैं जिनमें इसे सबसे अधिक लागू किया जाता है:

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

इन सभी प्रक्रियाओं में, सिस्टम की खामियों की कुल लागत कम हो जाती है क्योंकि समस्याओं को आगे बढ़ने से पहले ही पकड़ लिया जाता है और उनकी व्याख्या कर दी जाती है। प्रणाली परीक्षण या उत्पादन.

ग्रे Box परीक्षण उपकरण

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

• एपीआई और वेब-सेवा क्लाइंट जैसे Postman और SoapUIइसका उपयोग अनुरोध जारी करने और स्थिति कोड और प्रतिक्रिया निकायों पर दावा करने के लिए किया जाता है।
• डेटाबेस क्लाइंट और SQL क्वेरी टूलइसका उपयोग इंटरफेस क्रिया के बाद स्थायी स्थिति को सत्यापित करने के लिए किया जाता है।
• ब्राउज़र डेवलपर टूल और HTTP प्रॉक्सी जैसे Burp Suiteइसका उपयोग सुरक्षा संबंधी सत्रों के दौरान अनुरोधों का निरीक्षण और संशोधन करने के लिए किया जाता है।
• यूआई स्वचालन फ्रेमवर्क जैसे Selenium, जिसका उपयोग किसी प्रेजेंटेशन लेयर को चलाने के लिए किया जाता है स्वचालन परीक्षण पर।
• लॉग और निगरानी उपकरणइसका उपयोग किसी देखी गई विफलता को उस समय एप्लिकेशन द्वारा आंतरिक रूप से रिकॉर्ड किए गए डेटा से सहसंबंधित करने के लिए किया जाता है।

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

ग्रे Box परीक्षण चुनौतियाँ

आंशिक दृश्यता से ऐसी समस्याएं उत्पन्न होती हैं जो दोनों ही शुद्ध विधियों में नहीं होतीं, और निम्नलिखित वे समस्याएं हैं जिनका सामना टीमें अक्सर करती हैं:

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

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

अक्सर पूछे जाने वाले प्रश्न