सॉफ्टवेयर परीक्षण
सॉफ्टवेयर परीक्षण दोषों का पता लगाने और यह विश्वास प्राप्त करने के लिए चयनित इनपुट के साथ एक प्रोग्राम का गतिशील निष्पादन है कि सॉफ्टवेयर इच्छित रूप से व्यवहार करता है।
Definition
सॉफ्टवेयर परीक्षण परीक्षण मामलों — अपेक्षित परिणामों के साथ युग्मित इनपुट — को डिजाइन और निष्पादित करने की गतिविधि है ताकि वास्तविक और आवश्यक व्यवहार के बीच विसंगतियों का पता लगाया जा सके और सॉफ्टवेयर विश्वसनीयता का अनुमान लगाया जा सके।
Scope
यह विषय परीक्षण स्तरों (यूनिट, एकीकरण, सिस्टम, स्वीकृति); ब्लैक-बॉक्स तकनीकों जैसे समतुल्यता विभाजन, सीमा-मान विश्लेषण और संयोजनात्मक परीक्षण; कोड कवरेज मानदंडों द्वारा संचालित व्हाइट-बॉक्स तकनीकों; प्रतिगमन, प्रदर्शन और अन्वेषी परीक्षण; परीक्षण स्वचालन; और परीक्षण पर्याप्तता और कवरेज के सिद्धांत को शामिल करता है।
Core questions
- असाध्य रूप से बड़े इनपुट स्थान से प्रभावी परीक्षण मामलों का चयन कैसे किया जाता है?
- कौन से कवरेज मानदंड एक परीक्षण सूट की पर्याप्तता को मापते हैं?
- यूनिट से स्वीकृति तक के परीक्षण के स्तर एक-दूसरे के पूरक कैसे होते हैं?
- परीक्षण को कैसे स्वचालित किया जा सकता है और वितरण पाइपलाइन में एकीकृत किया जा सकता है?
Key theories
- ब्लैक-बॉक्स और व्हाइट-बॉक्स परीक्षण डिजाइन
- ब्लैक-बॉक्स तकनीकें विभाजन और सीमा विश्लेषण के माध्यम से विनिर्देश से परीक्षण प्राप्त करती हैं, जबकि व्हाइट-बॉक्स तकनीकें कवरेज मानदंडों द्वारा निर्देशित कोड संरचना से परीक्षण प्राप्त करती हैं; दोनों पूरक हैं।
- कवरेज और परीक्षण पर्याप्तता मानदंड
- पर्याप्तता मानदंड जैसे स्टेटमेंट, ब्रांच और कंडीशन कवरेज, और कंट्रोल- और डेटा-फ्लो ग्राफ़ पर मॉडल-आधारित मानदंड, इस बात के लिए मापने योग्य लक्ष्य देते हैं कि एक परीक्षण सूट एक प्रोग्राम का कितनी अच्छी तरह अभ्यास करता है।
Clinical relevance
परीक्षण सॉफ्टवेयर को जारी करने से पहले सही ढंग से व्यवहार करने का सबसे व्यापक रूप से प्रचलित साधन है; अच्छी तरह से डिज़ाइन किए गए स्वचालित परीक्षण प्रारंभिक प्रतिगमन को पकड़ते हैं, रिफैक्टरिंग और निरंतर वितरण का समर्थन करते हैं, और विश्वसनीय सॉफ्टवेयर के लिए केंद्रीय हैं।
Evidence & guidelines
ISO/IEC/IEEE 29119 सॉफ्टवेयर परीक्षण प्रक्रियाओं, दस्तावेज़ीकरण और तकनीकों के लिए अंतर्राष्ट्रीय मानक प्रदान करता है, और SWEBOK सॉफ्टवेयर परीक्षण ज्ञान क्षेत्र एक सर्वसम्मत अवलोकन देता है।
History
परीक्षण 1979 में मायर्स के व्यवस्थित उपचार के साथ एक अनुशासन में तदर्थ डिबगिंग से परिपक्व हुआ; कवरेज सिद्धांत, मॉडल-आधारित परीक्षण और परीक्षण स्वचालन अगले दशकों में विकसित हुए, और परीक्षण-संचालित विकास और निरंतर एकीकरण ने स्वचालित परीक्षण को एक मुख्य फुर्तीली प्रथा बना दिया।
Debates
- कितना स्वचालित परीक्षण सार्थक है
- यूनिट, एकीकरण और एंड-टू-एंड स्वचालित परीक्षणों के बीच सही संतुलन पर बहस होती है; परीक्षण पिरामिड धीमी एंड-टू-एंड परीक्षणों की तुलना में कई तेज़ यूनिट परीक्षणों का पक्षधर है, लेकिन आलोचकों का कहना है कि यह संतुलन सिस्टम के प्रकार और जोखिम पर निर्भर करता है।
Key figures
- Glenford Myers
- Paul Ammann
- Jeff Offutt
- Boris Beizer
Related topics
Seminal works
- myers2011
- ammann2016
- swebok2014
Frequently asked questions
- हम हर संभव इनपुट का परीक्षण क्यों नहीं कर सकते?
- अधिकांश प्रोग्रामों के लिए संभावित इनपुट और निष्पादन पथों का स्थान खगोलीय रूप से बड़ा या अनंत होता है, इसलिए संपूर्ण परीक्षण अव्यावहारिक है; इसके बजाय परीक्षण प्रति परीक्षण दोष का पता लगाने को अधिकतम करने के लिए व्यवस्थित तकनीकों का उपयोग करके प्रतिनिधि और सीमा मामलों का चयन करता है।
- परीक्षण स्तरों में क्या अंतर है?
- यूनिट परीक्षण अलग-अलग घटकों का अलगाव में अभ्यास करता है, एकीकरण परीक्षण उनकी बातचीत की जाँच करता है, सिस्टम परीक्षण अपनी आवश्यकताओं के विरुद्ध पूरे सिस्टम का मूल्यांकन करता है, और स्वीकृति परीक्षण पुष्टि करता है कि यह उपयोगकर्ता की जरूरतों को पूरा करता है; प्रत्येक स्तर विभिन्न प्रकार के दोषों को लक्षित करता है।