structural testing tutorial what is structural testing
यह व्यापक संरचनात्मक परीक्षण ट्यूटोरियल बताता है कि संरचनात्मक परीक्षण क्या है, इसके प्रकार, नियंत्रण प्रवाह परीक्षण और नियंत्रण प्रवाह ग्राफ़, कवरेज स्तर आदि क्या है।
कुछ सबसे महंगे सॉफ़्टवेयर बग की त्वरित Google खोज ने मेरे दिमाग को छोड़ दिया - $ 500 बिलियन। हां, बग कितना महंगा हो सकता है। एक सॉफ्टवेयर बग के कारण परिवहन और स्वास्थ्य सेवा उद्योगों में खोई हुई ज़िंदगी से संबंधित कुछ भी पढ़ना भयानक हो सकता है।
हालांकि कोड में त्रुटियां हमेशा चरम पर नहीं होती हैं, जहां वे प्रचुर मात्रा में धन और जीवन को नुकसान पहुंचाते हैं, केवल मुख्य टेकअवे यहां हम यह बताने की कोशिश कर रहे हैं कि कोई भी परीक्षण की अनदेखी नहीं कर सकता है।
जब परीक्षण पूरे एसडीएलसी में अक्सर किया जाता है, तो यह हमें उन बग्स को पकड़ने की अनुमति देता है जो उत्पाद की शिपिंग के बाद ठीक करने के लिए बहुत अधिक समय की आवश्यकता होगी।
सॉफ्टवेयर परीक्षण के प्रकारों का महत्व है जो हम चुनते हैं। इनमें से कई हैं, जिनमें कार्यात्मक, संरचनात्मक और परिवर्तन आधारित परीक्षण शामिल हैं।
यह ट्यूटोरियल स्ट्रक्चरल टेस्टिंग टाइप्स की भी व्याख्या करता है। म्यूटेशन टेस्टिंग, स्लाइस बेस्ड टेस्टिंग, डेटा फ्लो टेस्टिंग उदाहरण और स्पष्टीकरण के साथ विस्तार से जानें।
आप क्या सीखेंगे:
- क्यों सॉफ्टवेयर परीक्षण महत्वपूर्ण है
- संरचनात्मक परीक्षण क्या है
- संरचनात्मक परीक्षण के प्रकार
- लाभ और संरचनात्मक परीक्षण के नुकसान
- स्ट्रक्चरल टेस्टिंग बेस्ट प्रैक्टिस
- निष्कर्ष
क्यों सॉफ्टवेयर परीक्षण महत्वपूर्ण है
पैसे बचाने के अलावा, और ऊपर बताए गए मामलों की तरह आपदाओं से बचने के लिए, परीक्षण के महत्व को सही ठहराने के लिए कई अन्य कारण हैं।
नीचे सूचीबद्ध कुछ कारण हैं:
# 1) यह सुनिश्चित करने के लिए कि निर्धारित आवश्यकताओं को पूरा किया जाता है प्रोजेक्ट बनाने से पहले। हितधारकों (उदाहरण के लिए, डेवलपर्स और क्लाइंट) को समाधान / उत्पाद / सॉफ्टवेयर के सभी पहलुओं पर सहमत होना चाहिए जो एक परियोजना बनाने के लिए आवश्यक हैं।
परीक्षण में यह सत्यापित करना शामिल है कि क्या सॉफ़्टवेयर आवश्यकताएं पूरी हुई हैं। समाधान के निर्माण में शामिल डेवलपर या कंपनी भी इस तरह के उच्च-गुणवत्ता वाले समाधान को डिजाइन करने के लिए एक अच्छी प्रतिष्ठा प्राप्त करते हैं जो कि एक्लैट कोड द्वारा चलाया जाता है।
# 2) यह पुष्टि करता है कि कोड फ़ंक्शन उद्देश्य के अनुसार काम कर रहा है। परीक्षण में सॉफ़्टवेयर की कार्यक्षमता की पुष्टि करना भी शामिल है और किसी भी खराबी के मामले में, इसे SDLC (सॉफ़्टवेयर डेवलपमेंट लाइफ साइकल) के शुरुआती चरणों में तय किया जाना चाहिए।
# 3) यह प्रदर्शन के लिए जाँच करता है: उदाहरण के लिए, कोड चलाते समय हुए कुल समय की पहचान करना। अगर हम कई का उपयोग करें लूप्स के लिए हमारे कोड में, इच्छित आउटपुट प्राप्त करने में लंबा समय लगेगा और कभी-कभी टाइमआउट भी हो सकता है।
# 4) यह एक बेहतर उपयोगकर्ता अनुभव प्राप्त करने में मदद करता है। उपयोगकर्ता ऐसे सॉफ़्टवेयर का उपयोग करने का आनंद नहीं लेंगे जो खराबी, छोटी गाड़ी या 'बहुत धीमी गति से हो'। उपयोगकर्ताओं को संभवतः अधीर हो जाएगा और सॉफ्टवेयर का उपयोग कर छोड़ देगा। परीक्षण हमें यह सुनिश्चित करने के लिए एक बेहतर शॉट देता है कि उपयोगकर्ता आसानी से हमारे उत्पादों का उपयोग कर सकते हैं।
# 5) यह स्केलेबिलिटी के लिए जाँच करता है। एक डेवलपर को ऐसे सॉफ्टवेयर के निर्माण का लक्ष्य रखना चाहिए, जिसे बढ़ाया जा सके।
# 6) यह कोड में कमजोरियों के लिए जाँच करता है। परीक्षण हमें सुरक्षा कमजोरियों को देखने का अवसर देता है, उदाहरण के लिए, कोड जो समझौता कर सकता है PII (व्यक्तिगत रूप से पहचान योग्य सूचना) जो GDPR के लिए एक उच्च प्राथमिकता है।
इस लेख में, हम एक प्रकार के परीक्षण पर ध्यान केंद्रित करने जा रहे हैं अर्थात्। संरचनात्मक परीक्षण । जैसा कि नाम से पता चलता है कि इसे कोड की संरचना के साथ करना है। यह उस चीज से अलग है जो हमने पहले उल्लेख किया था कि परीक्षण कोड प्रदर्शन, कार्यक्षमता और सुरक्षा जैसे पहलुओं को निर्धारित करने में मदद करता है।
संरचनात्मक परीक्षण बनाम अन्य परीक्षण प्रकार
सॉफ्टवेयर परीक्षण कई प्रकार के होते हैं। हालांकि रुकें (अंतर्राष्ट्रीय सॉफ्टवेयर परीक्षण योग्यता बोर्ड), 4 प्रमुख सॉफ्टवेयर परीक्षण प्रकारों को परिभाषित करता है, अर्थात्
- कार्यात्मक
- नॉन-फंक्शनल
- संरचनात्मक
- परिवर्तन आधारित
मतभेदों को नीचे बताया जा सकता है:
क्रियात्मक परीक्षण: इसमें निर्धारित आवश्यकताओं के विरुद्ध सॉफ्टवेयर की कार्यक्षमता का सत्यापन करना शामिल है। टेस्ट डेटा का उपयोग इनपुट के रूप में किया जाता है। हम यह भी जाँचते हैं कि दिया गया आउटपुट अपेक्षित है।
गैर-कार्यात्मक परीक्षण : इसमें यह विश्लेषण करने के लिए एक परीक्षण प्रक्रिया शामिल है कि सॉफ्टवेयर कितनी अच्छी तरह काम करता है, उदाहरण के लिए, उपयोगकर्ताओं की संख्या इसे एक साथ संभाल सकती है।
संरचनात्मक परीक्षण: इस प्रकार का परीक्षण कोड की संरचना पर आधारित है। उदाहरण के लिए, यदि कोई कोड किसी सरणी में सम संख्याओं के औसत की गणना करने के लिए है, तो संरचना-आधारित परीक्षण to उन चरणों में रुचि रखेगा जो औसत की गणना करते हैं ’, बजाय इसके कि अंतिम आउटपुट एक सही संख्यात्मक मान है।
मान लीजिए कि हमें यह जाँचना है कि क्या हमने उस कोड को परिभाषित किया है जो विषम संख्याओं से संख्याओं को भिन्न करता है। हमारे यहाँ एक सशर्त विवरण हो सकता है, जैसे, यदि कोई सरणी तत्व शेष के बिना दो से विभाज्य है, अगर (गिरफ्तार (i)% 2 === 0) तब संख्या को सम संख्या के रूप में कहा जा सकता है।
संरचनात्मक परीक्षण उन्हीं लोगों द्वारा किया जाता है जो कोड लिखते हैं क्योंकि वे इसे सबसे अच्छा समझते हैं।
परिवर्तन आधारित परीक्षण : इसमें कोड में परिवर्तन करने के प्रभावों का परीक्षण करना और फिर यह सुनिश्चित करना कि किए गए बदलावों को लागू किया गया है। यह यह भी सुनिश्चित करता है कि कोड में परिवर्तन इसे तोड़ न दें।
क्या संरचनात्मक परीक्षण नहीं है
हमने पहले उल्लेख किया है कि संरचना-आधारित परीक्षण कोड की संरचना को संदर्भित करता है। ध्यान दें, हम यहां वास्तविक कोड के साथ सौदा करते हैं। हम आवश्यकताओं के खिलाफ या यहां तक कि अपेक्षित आउटपुट के खिलाफ इनपुट का परीक्षण नहीं करते हैं। हम इस बिंदु पर कार्यक्षमता, उपयोगकर्ता अनुभव या प्रदर्शन से चिंतित नहीं हैं।
संरचनात्मक परीक्षण क्या है
इसलिए, संरचना-आधारित परीक्षण को एक प्रकार के सॉफ़्टवेयर परीक्षण के रूप में परिभाषित किया जा सकता है जो कोड की संरचना और इच्छित प्रवाह का परीक्षण करता है। उदाहरण के लिए, सशर्त बयानों के सही कार्यान्वयन जैसे पहलुओं के लिए वास्तविक कोड की पुष्टि करना, और क्या कोड में प्रत्येक कथन को सही ढंग से निष्पादित किया गया है। इसे संरचना-आधारित परीक्षण के रूप में भी जाना जाता है।
इस प्रकार के परीक्षण को करने के लिए, हमें कोड को अच्छी तरह से समझने की आवश्यकता है। यही कारण है कि यह परीक्षण आमतौर पर डेवलपर्स द्वारा किया जाता है जिन्होंने कोड लिखा था क्योंकि वे इसे सबसे अच्छा समझते हैं।
कैसे करें संरचनात्मक परीक्षण
कोड के विभिन्न पहलुओं का परीक्षण करने के लिए, हमें पहले नियंत्रण प्रवाह को समझने की आवश्यकता है।
नियंत्रण प्रवाह परीक्षण
यह कोड के नियंत्रण प्रवाह (जिस क्रम में कथन, कार्य और कोड के विभिन्न पहलुओं को लागू किया जाता है) से परीक्षण प्राप्त कर रहा है।
एक सरणी में एक तत्व जोड़ें
नियंत्रण प्रवाह परीक्षण प्रक्रिया:
नियंत्रण प्रवाह ग्राफ
नियंत्रण प्रवाह प्रक्रिया कोड के विभिन्न वर्गों का एक दृश्य प्रतिनिधित्व बनाने से शुरू होती है जो हमें निष्पादन के दौरान उन मार्गों को परिभाषित करने में मदद करती है जिनका पालन किया जा सकता है।
इन दृश्य अभ्यावेदन को कंट्रोल फ़्लो ग्राफ़ (सीएफजी) के रूप में जाना जाता है और इसमें कई घटक होते हैं जैसे कि नोड्स, किनारे, पथ, जंक्शन और निर्णय बिंदु। ग्राफ मैन्युअल रूप से या स्वचालित रूप से बनाया जा सकता है, जहां सॉफ्टवेयर का उपयोग स्रोत कोड से ग्राफ निकालने के लिए किया जाता है।
नीचे इन घटकों को देखें:
(1) प्रोसेस ब्लॉक
इस भाग का उपयोग कोड के एक अनुभाग का प्रतिनिधित्व करने के लिए किया जाता है जिसे क्रमिक रूप से निष्पादित किया जाता है। इसका मतलब यह है कि इसे हर बार उसी तरह से अंजाम दिया जाता है, और इसमें कोई निर्णय या it ब्रांचिंग ’नहीं किया जाता है। यह एक प्रवेश और निकास मार्ग के साथ नोड्स से बना है।
एक प्रक्रिया ब्लॉक का उदाहरण:
(छवि स्रोत )
प्रक्रिया ब्लॉक नियंत्रण प्रवाह का एक अनिवार्य हिस्सा नहीं है और परिणामस्वरूप, केवल एक बार परीक्षण करने की आवश्यकता है।
# 2) निर्णय बिंदु
ये कोड के नियंत्रण प्रवाह में कुछ प्रमुख घटक हैं। इन नोड्स के भीतर, निर्णय किए जाते हैं। यह आमतौर पर निर्णय के आधार पर तुलना और नियंत्रण प्रवाह परिवर्तनों के माध्यम से किया जाता है। सीएफजी का यह हिस्सा कम से कम 2 आउटपुट के साथ एक नोड से बना है।
यहाँ किया गया निर्णय सशर्त कथन हो सकता है, जैसे कि, यदि-और कथन (जिसमें दो संभावित आउटपुट हैं) और केस स्टेटमेंट (जो दो से अधिक आउटपुट हो सकते हैं)।
(छवि स्रोत )
उपरोक्त आरेख में, एक निर्णय बिंदु है (सशर्त 18 उम्र = 18 'से) जिसके बाद ‘हां’ या ’नहीं’ विकल्प हैं।
# 3) जंक्शन अंक
उपरोक्त आरेख से, हम आसानी से जंक्शन बिंदुओं की पहचान कर सकते हैं जहां निर्णय बिंदु जुड़ते हैं। जंक्शन बिंदुओं में कई प्रवेश मार्ग हो सकते हैं लेकिन केवल एक निकास पथ हो सकता है।
नियंत्रण प्रवाह रेखांकन सर्वोत्तम प्रथाओं:
कंट्रोल फ्लो ग्राफ बनाते समय ध्यान देने योग्य बातें हैं:
- सीएफजी को सरल रखने के लिए यथासंभव प्रयास करें। हम इसे उन भागों को मिलाकर कर सकते हैं जिन्हें ’कम महत्वपूर्ण’ के रूप में समझा जा सकता है। उदाहरण के लिए, प्रक्रिया ब्लॉक।
- सुनिश्चित करें कि निर्णय बिंदुओं पर केवल एक निर्णय किया जाता है। निर्णय लेने के बाद आने वाले अधिक जटिल सीएफजी में s परिणाम ’होते हैं। हमारे उपरोक्त उदाहरण में, हम यह भी जोड़ सकते हैं कि यदि कोई व्यक्ति 18 वर्ष या उससे अधिक उम्र का है, तो वे पात्र हैं और टिकट के लिए भुगतान करने की आवश्यकता है। यदि वे नहीं हैं, तो प्रवेश मुफ्त है। A अन्य 'निर्णय के लिए कुछ नोड्स को' स्किप 'करना होगा, और उन सभी चरणों को हमारे CFG में दिखाना होगा।
एक बार जब हमने अपने सीएफजी को परिभाषित कर लिया है, तो अब नियंत्रण प्रवाह परीक्षण प्रक्रिया में अगले चरण पर जाने का समय है यानी हम कोड का परीक्षण करने के लिए किस हद तक जा रहे हैं, इसे परिभाषित करने के लिए।
परीक्षण करने के लिए कितना परिभाषित करना:
स्रोत कोड का कितना परीक्षण किया जाना चाहिए? क्या हमें प्रत्येक संभावित मार्ग का परीक्षण करना चाहिए? हमारे परीक्षणों में सभी मार्गों को शामिल करने की कोशिश करना व्यावहारिक रूप से असंभव है। हमें यह निर्धारित करने के लिए एक मध्यम जमीन खोजने की आवश्यकता है कि हम कितना परीक्षण कर सकते हैं।
यदि हम कहते हैं कि हम अपने कोड के 50% का परीक्षण करना चाहते हैं, तो इसका मतलब यह हो सकता है कि हम सभी निष्पादन योग्य कोड स्टेटमेंट को परिभाषित करेंगे और उनमें से कम से कम आधे का परीक्षण करेंगे। हालांकि, यहां जो सवाल उठता है वह यह है कि क्या हमें सभी संभावित निष्पादन योग्य रास्तों को परिभाषित करने की आवश्यकता है?
यह फिर से व्यावहारिक रूप से असंभव हो सकता है। एक बेहतर दृष्टिकोण 50% पथों का परीक्षण करना हो सकता है जिन्हें हम कोड के प्रत्येक भाग में पहचान सकते हैं।
कवरेज, कथन, शाखा और पथ कवरेज के विभिन्न स्तर हैं। हम संक्षेप में बाद में उन्हें देखेंगे।
परीक्षण के मामले बनाना:
अगला चरण परीक्षण मामलों का निर्माण कर रहा है जो हम उपयोग करेंगे। संरचना-आधारित परीक्षण में परीक्षण के मामले निम्नलिखित कारकों पर आधारित हैं:
- निष्पादन योग्य कथन।
- 'निर्णय' जिन्हें करने की आवश्यकता है
- जिन संभावित रास्तों का पालन किया जा सकता है।
- जिन शर्तों को पूरा करने की जरूरत है (ये कई या बूलियन हो सकती हैं)।
उपरोक्त कारक हमें उन प्रकार के परीक्षण मामलों की जानकारी देते हैं, जिन्हें हमें बनाने की आवश्यकता है। हम एक संरचनात्मक परीक्षण पीढ़ी उपकरण का भी उपयोग कर सकते हैं। यदि हमारा कोड C प्रोग्रामिंग लैंग्वेज में है, तो हम टेस्ट कोड जनरेट करने के लिए PathCrawler का उपयोग कर सकते हैं। एक और उपकरण जिसका हम उपयोग कर सकते हैं वह है एफएमबीटी।
परीक्षण मामलों को निष्पादित करना:
यहां, हमें परीक्षण चलाने के लिए मिलता है। हम यह जाँचने के लिए इनपुट या डेटा दर्ज कर सकते हैं कि कोड इसे कैसे निष्पादित करता है, और फिर सत्यापित करें कि हमें अपेक्षित परिणाम मिले। उदाहरण के लिए, फ़ंक्शन कॉल में एक सरणी दर्ज करें यह देखने के लिए कि परिणाम हमें इसके माध्यम से लूप करने के बाद मिलते हैं, या यह जांचने के लिए कि क्या निर्णय बिंदु सही निर्णय ले रहे हैं।
परिणामों का विश्लेषण:
इस भाग में, हम सभी को यह जाँचना है कि निष्पादन के बाद हमें सही परिणाम मिले या नहीं। उदाहरण के लिए, यदि हम एक सरणी दर्ज करते हैं जहां सभी मान 18 से ऊपर हैं, तो हमारे पास सभी निर्णय बिंदु होने चाहिए, जिसके परिणामस्वरूप 'पात्र' हैं।
नियंत्रण प्रवाह मान्यताओं
यह ध्यान रखना महत्वपूर्ण है कि नियंत्रण प्रवाह परीक्षण करने के लिए, कुछ धारणाएं हैं जो बनाई जाती हैं। इसमे शामिल है:
- केवल मौजूद बग वे हैं जो नियंत्रण प्रवाह को प्रभावित कर सकते हैं।
- सभी चर, कार्य और तत्व सटीक रूप से परिभाषित हैं।
नियंत्रण के स्तर में कवरेज स्तर
जैसा कि हमने पहले उल्लेख किया है, नियंत्रण प्रवाह परीक्षण में कवरेज के विभिन्न स्तर हैं।
आइए उन्हें संक्षेप में देखें।
(1) स्टेटमेंट कवरेज
संरचनात्मक परीक्षण में, निष्पादन योग्य कोड स्टेटमेंट एक महत्वपूर्ण भूमिका निभाते हैं जब परीक्षणों को डिजाइन करने के तरीके तय करने की बात आती है।
हम 100% कवरेज प्राप्त करने का लक्ष्य रखते हैं, जिसका अर्थ है कि प्रत्येक निष्पादन योग्य कथन का कम से कम एक बार परीक्षण किया गया है। कवरेज जितना अधिक होगा, कीड़े और त्रुटियों को याद करने की संभावना उतनी ही कम होगी।
यहां परीक्षण मामलों का उपयोग करना आवश्यक है। हम जिस डेटा की ज़रूरतों के लिए जाते हैं, वह यह सुनिश्चित करना है कि कोड के एक ब्लॉक में प्रत्येक निष्पादन योग्य विवरण को कम से कम एक बार निष्पादित किया जाए।
# 2) शाखा कवरेज
इस कवरेज स्तर में सीएफजी शाखाओं (जहां निर्णय किए जाते हैं) के बिंदुओं का परीक्षण करना शामिल है। परिणाम बूलियन हैं। भले ही एक स्विच स्टेटमेंट का उपयोग किया जाता है और कई परिणाम हैं, संक्षेप में, प्रत्येक केस ब्लॉक मूल्यों की एक जोड़ी की तुलना है।
बयान कवरेज के साथ की तरह, हमें 100% शाखा कवरेज का लक्ष्य रखना चाहिए। इसे प्राप्त करने के लिए, हमें प्रत्येक निर्णय स्तर पर कम से कम एक बार प्रत्येक परिणाम का परीक्षण करना होगा। चूंकि हम बूलियन परिणामों से निपट रहे हैं, तो हमें कोड के प्रति अनुभाग कम से कम 2 परीक्षण चलाने का लक्ष्य रखना चाहिए।
# 3) पथ कवरेज
निर्णय और कथन कवरेज की तुलना में कवरेज का यह स्तर अधिक गहन है। यहाँ का उद्देश्य सभी संभावित रास्तों की खोज करना है और कम से कम एक बार उनका परीक्षण करना है। यह बेहद समय लेने वाला हो सकता है। हालाँकि, यह हमारे कोड में बग्स या त्रुटियों को खोजने में मदद कर सकता है, या यहां तक कि उन पहलुओं को भी जिन्हें हमें परिभाषित करने की आवश्यकता है, उदाहरण के लिए, उपयोगकर्ता का निवेश।
संरचनात्मक परीक्षण के प्रकार
(छवि स्रोत )
उत्परिवर्तन परीक्षण
उत्परिवर्तन परीक्षण एक दोष-आधारित परीक्षण तकनीक है जिसमें परीक्षण डेटासेट के खिलाफ एक सॉफ्टवेयर अनुप्रयोग के विभिन्न रूपों का परीक्षण किया जाता है।
>> इस ट्यूटोरियल को इन-डीप लुक के लिए देखें उत्परिवर्तन परीक्षण।
स्लाइस आधारित परीक्षण
स्लाइस बेस्ड टेस्टिंग (एसबीटी) को एक सॉफ्टवेयर टेस्टिंग तकनीक के रूप में परिभाषित किया जा सकता है जो पर आधारित है स्लाइस - कार्यक्रम के निष्पादन योग्य भागों या बयानों के समूह जो कार्यक्रम में रुचि के कुछ बिंदुओं पर कुछ मूल्यों को प्रभावित करते हैं, उदाहरण के लिए, वे हिस्से जहाँ चर परिभाषित किए जाते हैं या बयानों के समूह का उत्पादन होता है।
कैसे करें स्लाइसिंग
SBT में कटा हुआ उदाहरण: समान और विषम संख्याओं का पता लगाने के लिए कोड (पायथन)
num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}') 
एक स्लाइस को देखने के दो तरीके हैं: ब्याज के एक चर या कोड के भाग का अनुसरण करके जो आउटपुट को प्रभावित करता है।
हमारे उदाहरण में, यदि हम विषम संख्या आउटपुट को देखते हैं, तो हम उस कोड के भाग का पता लगा सकते हैं जो हमें इस आउटपुट की ओर ले जाता है।
मार्क वेसर (जिन्होंने एसबीटी की शुरुआत की) के दिए गए स्लाइसिंग मानदंड में, इस फॉर्मूले का उपयोग करके एक स्लाइस को परिभाषित किया गया है: एस (वी, एन) , कहां है, v प्रश्न में चर को संदर्भित करता है ( उदाहरण के लिए, जहां एक चर परिभाषित किया गया है), और एन ब्याज का बयान है ( उदाहरण के लिए, जहां आउटपुट दिया गया है), और रों टुकड़ा के लिए खड़ा है।
उपरोक्त उदाहरण में, स्लाइस प्राप्त करने के लिए, हम लाइन 10 पर अपने आउटपुट से शुरू करते हैं, जो कि हमारा हो जाता है एन । हमारा चर है कहां है ।
तो हमारा स्लाइसिंग मानदंड है:
S(v,n) = S(var,10)हमारी चिंता उन बयानों की है जो हमें आउटपुट की ओर ले जाते हैं।
ये:
10,9,8,4,3,1
तो, इस कोड में हमारा टुकड़ा है:
num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
स्लाइस आधारित परीक्षण प्रकार
एसबीटी दो प्रकार के होते हैं: स्टेटिक और डायनामिक
# 1) डायनामिक स्लाइस बेस्ड टेस्टिंग
एसबीटी उदाहरण ऊपर समझाया गया है जहां हमने उन बयानों को देखा, जो विषम संख्याओं की छपाई को प्रभावित करते हैं, गतिशील एसबीटी है। हमारी चिंता बहुत विशिष्ट है। हम केवल इस बात पर ध्यान केंद्रित करते हैं कि किसी विशेष आउटपुट को सीधे क्या प्रभावित करता है।
हम कोड को निष्पादित करते हैं और यह सुनिश्चित करने के लिए परीक्षण डेटा का उपयोग करते हैं कि यह काम करता है जैसा कि यह माना जाता है। हम सीमा को बढ़ा सकते हैं (1,50), उदाहरण के लिए, यह देखने के लिए कि क्या यह अभी भी केवल विषम संख्या उत्पन्न करता है। डायनेमिक एसबीटी को सत्यापन परीक्षण के रूप में भी जाना जाता है।
# 2) स्थिरस्लाइस आधारित परीक्षण
डायनेमिक एसबीटी के विपरीत, स्थैतिक परीक्षण का ध्यान एक विशेष चर पर है। अगर हम उपरोक्त उदाहरण में अपने आउटपुट के बारे में सोचते हैं कहां है , हम उस स्लाइस का पता लगा सकते हैं जो इसे प्रभावित करता है 10,9,8,7,6,5,4,3,2,1
यह मूल रूप से पूरे कोड ब्लॉक है! यहां हम यह सत्यापित करते हैं कि कोड सिंटैक्स और आवश्यकताओं के संदर्भ में सही है, और हम इसे निष्पादित नहीं करते हैं। स्टेटिक एसबीटी को सत्यापन परीक्षण के रूप में भी जाना जाता है।
यह ध्यान रखना महत्वपूर्ण है कि गतिशील एसबीटी अपने स्थिर समकक्ष की तुलना में 'छोटा' होता है। यह भी अधिक विशिष्ट है।
स्लाइस आधारित परीक्षण सर्वोत्तम अभ्यास / दिशानिर्देश
स्लाइसिंग मानदंड द्वारा निर्धारित किया जाना चाहिए:
- वे पद जहाँ मान परिभाषित या असाइन किए गए मूल्य के साथ-साथ पुन: असाइन किए गए मान हैं।
- कथन जहां कार्यक्रम के बाहर से मान प्राप्त किए जा रहे हैं, उदाहरण के लिए, उपयोगकर्ता इनपुट के माध्यम से।
- आउटपुट / रिटर्न आउटपुट प्रिंट करने वाले कथन।
- कार्यक्रम का अंतिम विवरण, उदाहरण के लिए, एक फ़ंक्शन कॉल जो मानों को परिभाषित कर सकता है, या तर्क को मूल्य प्रदान कर सकता है
स्लाइस-आधारित परीक्षण के लाभों में शामिल हैं:
- चूंकि एसबीटी में हम केवल ब्याज के विशिष्ट क्षेत्रों के साथ काम करते हैं, इसलिए यह प्रभावी रूप से परीक्षण सूट उत्पन्न करना आसान बनाता है।
- पथ को कोड के भीतर निर्भरता द्वारा परिभाषित किया गया है, जो उपयोग करने से बेहतर है पथ कवरेज।
- SBT के साथ, स्रोत कोड में त्रुटियों को खोजना आसान है।
स्लाइस-आधारित परीक्षण के नुकसान में शामिल हैं:
- यदि हम बड़े कोडबेस का परीक्षण करते समय गतिशील परीक्षण का उपयोग करते हैं, तो हमें बहुत सारे कम्प्यूटेशनल संसाधनों की आवश्यकता होगी।
- यदि हम स्थैतिक परीक्षण का उपयोग करते हैं, तो हम त्रुटियों को याद कर सकते हैं।
डेटा प्रवाह परीक्षण
डेटा प्रवाह परीक्षण को एक सॉफ्टवेयर परीक्षण तकनीक के रूप में परिभाषित किया जा सकता है जो एक कार्यक्रम में डेटा मान और उनके उपयोग पर आधारित है। यह पुष्टि करता है कि डेटा मानों का सही उपयोग किया गया है और वे सही परिणाम उत्पन्न करते हैं। डेटा प्रवाह परीक्षण एक विशेष निष्पादन पथ पर डेटा मूल्यों के बीच निर्भरता का पता लगाने में मदद करता है।
डेटा प्रवाह विसंगतियाँ
डेटा प्रवाह विसंगतियाँ एक सॉफ्टवेयर प्रोग्राम में केवल त्रुटियाँ हैं। उन्हें क्रमशः 1, 2, और 3 में वर्गीकृत किया गया है।
उन्हें नीचे दें:
श्रेणी 1: एक चर परिभाषित किया गया है और एक मूल्य इसे दो बार सौंपा गया है।
उदाहरण कोड: पायथन
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var) 
Lst_1 परिभाषित किया गया है, और इसे दो अलग-अलग मान सौंपे गए हैं। पहला मान बस अनदेखा किया जाता है। टाइप 1 विसंगतियाँ कार्यक्रम को विफल करने का कारण नहीं बनती हैं।
टाइप 2: किसी वैरिएबल के मान को परिभाषित करने से पहले उपयोग या संदर्भित किया जाता है।
उदाहरण कोड: पायथन
for var in lst_1: print(var) 
ऊपर दिए गए लूप को पुनरावृति करने के लिए कोई मूल्य नहीं है। टाइप 2 विसंगतियां कार्यक्रम को विफल करने का कारण बनती हैं।
टाइप 3: ए डेटा मान उत्पन्न होता है, लेकिन इसका उपयोग कभी नहीं किया जाता है।
उदाहरण कोड: पायथन
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var) 
चर lst_2 संदर्भित नहीं किया गया है। टाइप 3 विसंगतियाँ कार्यक्रम की विफलता का कारण नहीं हो सकती हैं।
डेटा प्रवाह परीक्षण प्रक्रिया
डेटा मानों के बीच निर्भरता को परिभाषित करने के लिए, हमें उन विभिन्न रास्तों को परिभाषित करने की आवश्यकता है, जिनका किसी प्रोग्राम में पालन किया जा सकता है। इसे प्रभावी ढंग से करने के लिए, हमें एक और संरचनात्मक परीक्षण प्रकार से उधार लेने की आवश्यकता है जिसे कहा जाता है नियंत्रण-प्रवाह परीक्षण ।
चरण 1) एक नियंत्रण प्रवाह ग्राफ बनाएं
हमें एक नियंत्रण प्रवाह ग्राफ बनाने की आवश्यकता है, जो उन पथों का चित्रमय प्रतिनिधित्व है जिन्हें हम अपने कार्यक्रम में अनुसरण कर सकते हैं।
उदाहरण कोड: पायथन
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill) 
उपरोक्त कोड उदाहरण में, एक सदस्य को एक छूट मिलनी चाहिए अगर वे एक आगंतुक को आमंत्रित करते हैं।
नियंत्रण प्रवाह ग्राफ (CFG):
चरण 2) चर और डेटा मान की परिभाषा और उपयोग का अन्वेषण करें।
एक कार्यक्रम में एक चर या तो परिभाषित या उपयोग किया जाता है। CFG में, हमारे पास प्रत्येक नोड पर चर हैं। प्रत्येक नोड का नाम चर प्रकार के अनुसार रखा गया है। यदि किसी विशेष नोड पर एक चर को परिभाषित किया जाता है, तो यह एक परिभाषित नोड बनाता है। यदि एक नोड पर एक चर का उपयोग किया जाता है, तो यह एक उपयोग नोड बनाता है।
यदि हम CFG में परिवर्तनीय लागत पर विचार करते हैं, तो ये परिभाषित और उपयोग नोड हैं:
| नोड | प्रकार | कोड |
|---|---|---|
| 1 | नोड को परिभाषित करना | लागत = २० |
| ५ | उपयोग नोड | बिल = लागत -1 |
| । | उपयोग नोड | बिल = लागत |
चरण 3) परिभाषा-उपयोग पथ परिभाषित करें।
परिभाषा-उपयोग पथ दो प्रकार के होते हैं: डु पथ और डीसी पथ। ड्यू पाथ डेफिनेशन पाथ्स हैं जो डेफिनिशन नोड के साथ शुरू होते हैं और उपयोग नोड के साथ समाप्त होते हैं। उपरोक्त चर लागत के संदर्भ में पथ के लिए यह मामला है।
डीसी मार्ग का एक उदाहरण, एक निर्णय स्पष्ट पथ, नीचे दिए गए बिल चर के संबंध में पथ है:
| नोड | प्रकार | कोड |
|---|---|---|
| ५ | नोड को परिभाषित करना | बिल = लागत -1 |
| । | नोड को परिभाषित करना | बिल = लागत |
| । | उपयोग नोड | प्रिंट (बिल) |
dc पाथ में एक से अधिक डेफिनिशन नोड हैं, हालांकि यह अभी भी एक उपयोग नोड पर समाप्त होता है।
चरण 4) परीक्षण सूट बनाएँ।
यह इनपुट जोड़ रहा है। ध्यान दें कि हमें प्रत्येक चर के लिए एक अलग परीक्षण सूट की आवश्यकता है। परीक्षण सूट हमें डेटा प्रवाह विसंगतियों की पहचान करने में मदद करेगा।
डेटा फ्लो परीक्षण प्रकार
इसके दो प्रकार हैं - स्थिर और गतिशील ।
स्टेटिक का मतलब है कि हम कोड और सीएफजी के माध्यम से डेटा विसंगतियों की पहचान करते हैं, इसे क्रियान्वित किए बिना। डायनामिक का अर्थ है कि हम वास्तव में विशिष्ट रास्तों की पहचान करते हैं और फिर स्थैतिक परीक्षण के दौरान during कैच ’विसंगतियों की बोली में परीक्षण करने के लिए टेस्ट सूट बनाते हैं, जिन्हें हम याद कर सकते हैं।
डेटा प्रवाह परीक्षण के फायदे और नुकसान:
- डेटा प्रवाह परीक्षण डेटा प्रवाह विसंगतियों की पहचान करने के लिए आदर्श है, जो इसे एक बहुत प्रभावी संरचनात्मक परीक्षण विधि बनाता है।
- इसका नकारात्मक पक्ष यह है कि डेटा प्रवाह परीक्षण का उपयोग करने के लिए कोड लिखने के लिए उपयोग की जाने वाली भाषा में अच्छी तरह से वाकिफ होने की आवश्यकता है। यह समय लेने वाली भी है।
लाभ और संरचनात्मक परीक्षण के नुकसान
आइए अब हम उन कारणों का पता लगाएं कि संरचनात्मक परीक्षण एक महान दृष्टिकोण क्यों है, और इसके कुछ डाउनसाइड्स को भी देखें।
लाभ:
- पूरी तरह से कोड परीक्षण की अनुमति देता है, जिसके परिणामस्वरूप न्यूनतम त्रुटियां हैं। संरचना-आधारित परीक्षण सॉफ्टवेयर को अच्छी तरह से जांचने के लिए जगह देता है। कवरेज के विभिन्न स्तरों - कथन द्वारा कथन, प्रत्येक निर्णय बिंदु, और पथ का उद्देश्य 100% कवरेज प्राप्त करना है जो त्रुटियों को कम करने की संभावना को बहुत कम कर देता है।
- स्वचालित करने की क्षमता । कई उपकरण हैं जिनका उपयोग हम परीक्षण को स्वचालित करने के लिए कर सकते हैं। यह हमें मैन्युअल रूप से परीक्षण करने की तुलना में अधिकतम कोड कवरेज और कम समय के भीतर प्राप्त करने में मदद करेगा।
- इसका परिणाम उच्च गुणवत्ता कोड होता है । डेवलपर्स के पास कोड की संरचना और कार्यान्वयन का अध्ययन करने और किसी भी त्रुटि को ठीक करने का एक मौका है, साथ ही इन पहलुओं पर सुधार भी है। यह हमें महान संरचना को ध्यान में रखने की अनुमति देता है क्योंकि हम कोड के बाद के हिस्सों को लिखते हैं या शेष सुविधाओं को लागू करते हैं।
- यह एसडीएलसी के प्रत्येक चरण के माध्यम से किया जा सकता है - 100% पूरा होने के लिए विकास की प्रतीक्षा किए बिना एसडीएलसी के प्रत्येक चरण में संरचनात्मक परीक्षण किया जा सकता है। इससे शुरुआती चरण में त्रुटियों की पहचान करना आसान हो जाता है और इस प्रकार विकास पूरा होने के बाद परीक्षण की तुलना में बहुत समय की बचत होती है।
- यह मृत कोड से छुटकारा पाने में मदद करता है । इसे 'अतिरिक्त' या अनावश्यक कोड के रूप में देखा जा सकता है, उदाहरण के लिए, कोड जो किसी परिणाम की गणना करेगा लेकिन निम्न गणनाओं में से किसी में भी इसका उपयोग कभी नहीं करता है।
- दक्षता - चूंकि कोड लिखने वाले डेवलपर्स वही हैं जो इसे परीक्षण करते हैं, इसलिए QAs जैसे अन्य लोगों को शामिल करने की कोई आवश्यकता नहीं है।
नुकसान:
- जो डेवलपर्स संरचना-आधारित परीक्षण करते हैं, उन्हें भाषा की पूरी समझ होनी चाहिए । अन्य डेवलपर्स और QAs, जो भाषा के अच्छे जानकार नहीं हैं, परीक्षण में मदद नहीं कर सकते।
- यह समय और धन के मामले में काफी महंगा हो सकता है । कुशलतापूर्वक परीक्षण करने के लिए बहुत समय और संसाधनों की आवश्यकता होती है।
- यह सुविधाओं के वितरण में देरी का कारण बनता है । ऐसा इसलिए है क्योंकि डेवलपर्स को टेस्टिंग करने के लिए सॉफ्टवेयर बनाने से खींचा जाता है।
- स्केलिंग एक मुद्दा है, खासकर जहां बड़े अनुप्रयोग शामिल हैं । एक बड़ा अनुप्रयोग कवर करने के लिए मार्गों की एक अत्यधिक उच्च संख्या के बराबर होता है। 100% कवरेज हासिल करना असंभव हो जाता है।
- छूटे हुए मामले और रूट हो सकते हैं , उदाहरण के लिए, ऐसे मामले में जहां सुविधाएँ पूरी तरह से विकसित नहीं हुई हैं या अभी विकसित नहीं हुई हैं। इसका मतलब है कि इसे अन्य परीक्षण प्रकारों के साथ जोड़ा जाना चाहिए, जैसे आवश्यकताओं का परीक्षण (जहां हम उन विशिष्ट विशेषताओं के खिलाफ जांच करते हैं जिन्हें बनाने की आवश्यकता है)।
स्ट्रक्चरल टेस्टिंग बेस्ट प्रैक्टिस
संरचना-आधारित परीक्षण करते समय ध्यान देने की आवश्यकता वाले कुछ कारक निम्नानुसार हैं:
- स्पष्ट रूप से लेबल करें और परीक्षणों को नाम दें । यदि किसी और को परीक्षण चलाने की आवश्यकता है, तो उन्हें आसानी से पता लगाने में सक्षम होने की आवश्यकता है।
- कोड बढ़ाने से पहले, यानी इसे रिफलेक्ट करके, और इसे अलग-अलग वातावरण में उपयोग के लिए अनुकूलित करके, सुनिश्चित करें कि इसकी संरचना और प्रवाह आदर्श है।
- अलग से परीक्षण चलाएं । इस तरह, बग्स की पहचान करना और उन्हें ठीक करना आसान है। दूसरी ओर, हमें कोड सेक्शन, ब्लॉक, या रास्तों में ओवरलैप के परिणामस्वरूप बग या रास्तों की कमी महसूस होती है।
- परिवर्तन करने से पहले परीक्षण उत्पन्न करें । परीक्षण अपेक्षित रूप से चलाने के लिए आवश्यक हैं। इस तरह, अगर कुछ टूटता है, तो समस्या का पता लगाना और ठीक करना आसान है।
- प्रत्येक अनुभाग या कोड के ब्लॉक के लिए परीक्षण अलग रखें । इस तरह, यदि रेखा के नीचे परिवर्तन होते हैं, तो हमें बहुत सारे परीक्षणों को बदलने की आवश्यकता नहीं है।
- परीक्षण के साथ आगे बढ़ने से पहले कीड़े को ठीक करें । यदि हम किसी भी कीड़े की पहचान करते हैं, तो हम अगले खंड या कोड के ब्लॉक का परीक्षण करने से पहले उन्हें ठीक करना बेहतर समझते हैं।
- कभी भी संरचनात्मक परीक्षण को इस धारणा के साथ न छोड़ें कि क्यूए अभी भी वैसे भी परीक्षण करेगा '। यहां तक कि अगर कीड़े पहले से कम लग सकते हैं, तो संचयी रूप से, वे बगिया कोड में परिणाम कर सकते हैं जो कभी भी अपने इच्छित उद्देश्य को प्राप्त नहीं कर सकते हैं।
संरचना-आधारित परीक्षण के लिए अक्सर पूछे जाने वाले प्रश्न
यहां हम संरचना-आधारित परीक्षण की बात करते समय अक्सर पूछे जाने वाले प्रश्नों का पता लगाएंगे।
Q # 1) कार्यात्मक परीक्षण और संरचनात्मक परीक्षण के बीच अंतर क्या है?
उत्तर: कार्यात्मक परीक्षण एसआरएस (सॉफ्टवेयर आवश्यकताएँ विनिर्देश) में निर्धारित आवश्यकताओं के आधार पर सॉफ्टवेयर परीक्षण का एक प्रकार है। यह आमतौर पर एसआरएस में स्पेक्स और कोड कैसे काम करता है, के बीच असमानता का पता लगाने के लिए किया जाता है। संरचनात्मक परीक्षण कोड की आंतरिक संरचना और इसके कार्यान्वयन पर आधारित है। कोड की गहन समझ आवश्यक है।
Q # 2) संरचनात्मक परीक्षण के प्रकार क्या हैं?
के जवाब प्रकार में शामिल हैं:
- डेटा प्रवाह परीक्षण
- उत्परिवर्तन परीक्षण
- नियंत्रण प्रवाह परीक्षण
- स्लाइस-आधारित परीक्षण
Q # 3) एक संरचनात्मक परीक्षण उदाहरण क्या है?
उत्तर: यहाँ एक उदाहरण बयान कवरेज दिखा रहा है:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums(); हमें मिलने वाली कवरेज की मात्रा उस परीक्षण डेटा पर निर्भर करती है जिसे हम इनपुट के रूप में प्रदान करते हैं (चाहे वह योग> 0 शर्तों को पूरा करता हो)।
Q # 4) डेटा प्रवाह परीक्षण और नियंत्रण प्रवाह परीक्षण के बीच अंतर क्या है?
उत्तर: दोनों डेटा प्रवाह परीक्षण और नियंत्रण प्रवाह परीक्षण नियंत्रण प्रवाह ग्राफ़ का उपयोग करते हैं। अंतर केवल इतना है कि नियंत्रण प्रवाह परीक्षण में, हम कोड से उत्पन्न रास्तों पर ध्यान केंद्रित करते हैं, जबकि डेटा प्रवाह परीक्षण में, हम एक प्रोग्राम के भीतर पहचाने गए रास्तों के भीतर डेटा मान, उनकी परिभाषा और उपयोग पर ध्यान केंद्रित करते हैं।
Q # 5) डेटा प्रवाह परीक्षण किसके लिए उपयोग किया जाता है?
उत्तर: डेटा प्रवाह परीक्षण एक नियंत्रण प्रवाह ग्राफ में पथ के भीतर डेटा मूल्यों के उपयोग में विसंगतियों की पहचान करने के लिए आदर्श है, उदाहरण के लिए, एक चर जिसे दो बार मान दिया गया है, एक चर जिसे परिभाषित किया गया है और जिसका उपयोग नहीं किया गया है, या एक चर जिसका उपयोग किया गया है या संदर्भित और परिभाषित नहीं किया गया है।
Q # 6) सॉफ्टवेयर टेस्टिंग में स्लाइसिंग और डिसिंग के बीच क्या अंतर है?
उत्तर: स्लाइसिंग का अर्थ है किसी कार्यक्रम में रुचि के विशेष कथनों पर ध्यान केंद्रित करना और बाकी को अनदेखा करना। Dicing तब होती है जब हम एक ऐसे स्लाइस की पहचान करते हैं जिसमें गलत इनपुट होता है और फिर सही व्यवहार को ट्रेस करने के लिए इसे और अधिक स्लाइस किया जाता है।
Q # 7) म्यूटेशन टेस्टिंग और कोड कवरेज में क्या अंतर है?
उत्तर: उत्परिवर्तन परीक्षण में, हम मारे गए म्यूटेंट की संख्या को कुल म्यूटेंट का प्रतिशत मानते हैं। कोड कवरेज केवल कोड की मात्रा है जिसे एक कार्यक्रम में परीक्षण किया गया है।
निष्कर्ष
इस ट्यूटोरियल में हमने संरचनात्मक परीक्षण को गहराई से देखा - यह क्या है, यह क्या नहीं है, इसके बारे में कैसे जाना जाए, कवरेज प्रकार, फायदे, और नुकसान, सर्वोत्तम अभ्यास और यहां तक कि इस सॉफ़्टवेयर परीक्षण प्रकार के बारे में कुछ अक्सर पूछे जाने वाले प्रश्न।
अभी भी बहुत कुछ है जो हम संरचना-आधारित परीक्षण के बारे में जान सकते हैं। भविष्य के ट्यूटोरियल में, हम कोड कवरेज (स्टेटमेंट, निर्णय, शाखा और पथ), संरचनात्मक परीक्षण प्रकार (उत्परिवर्तन, डेटा-प्रवाह और स्लाइस-आधारित), और यहां तक कि उन उपकरणों का भी पता लगाएंगे जिनका उपयोग हम इन परीक्षण प्रक्रियाओं को स्वचालित करने के लिए कर सकते हैं।
यह ध्यान रखना महत्वपूर्ण है कि कोई सॉफ्टवेयर परीक्षण प्रकार या दृष्टिकोण नहीं है जो 100% कुशल हो। विभिन्न परीक्षण प्रकारों और दृष्टिकोणों को जोड़ना हमेशा उचित होता है।
उदाहरण के लिए, संरचनात्मक परीक्षण बहुत आवश्यकताओं के परीक्षण के पूरक हैं, क्योंकि ऐसी विशेषताएं हो सकती हैं जो उस समय विकसित नहीं हुई होंगी जब संरचना-आधारित परीक्षण किया गया था।
संरचनात्मक परीक्षण तकनीक उन त्रुटियों पर आधारित होती है जो कोड लिखते समय मानव प्रोग्रामर बनाते हैं। धारणा यह है कि प्रोग्रामर एक विशेषज्ञ है और जानता है कि वह क्या या वह कोडिंग कर रहा है, लेकिन समय-समय पर गलतियां करता है।
विभिन्न संरचनात्मक परीक्षण प्रकार जिन्हें हमने देखा है - म्यूटेशन परीक्षण, स्लाइस-आधारित परीक्षण, और डेटा प्रवाह परीक्षण, गलत ऑपरेटर (म्यूटेशन परीक्षण) का उपयोग करने या इसे उपयोग करने से पहले एक चर का संदर्भ देने जैसी त्रुटियों (डेटा प्रवाह परीक्षण) से पता लगाया जा सकता है। ।
अनुशंसित पाठ
- विनाशकारी परीक्षण और गैर विनाशकारी परीक्षण ट्यूटोरियल
- कार्यात्मक परीक्षण बनाम गैर-कार्यात्मक परीक्षण
- दोष आधारित परीक्षण तकनीक क्या है?
- सोख परीक्षण ट्यूटोरियल - सोख परीक्षण क्या है
- SOA परीक्षण ट्यूटोरियल: SOA आर्किटेक्चर मॉडल के लिए परीक्षण पद्धति
- एचपी लोडरनर ट्यूटोरियल के साथ लोड परीक्षण
- गामा परीक्षण क्या है? अंतिम परीक्षण चरण
- DevOps टेस्टिंग ट्युटोरियल: QO टेस्टिंग को कैसे प्रभावित करेगा DevOps?
- अनुपालन परीक्षण (अनुरूपता परीक्षण) क्या है?