सॉफ्टवेयर परिक्षण: Difference between revisions

From Vigyanwiki
No edit summary
 
(8 intermediate revisions by 5 users not shown)
Line 2: Line 2:


{{Software development process|Core activities}}
{{Software development process|Core activities}}
सॉफ्टवेयर परीक्षण सत्यापन और सत्यापन द्वारा परीक्षण के तहत सॉफ्टवेयर के व्यवहार और कलाकृतियों की जांच करने का कार्य है। [[सॉफ़्टवेयर]] परीक्षण सॉफ़्टवेयर का एक उद्देश्यपूर्ण, स्वतंत्र दृश्य भी प्रदान कर सकता है जिससे व्यवसाय सॉफ़्टवेयर कार्यान्वयन के जोखिमों की सराहना और समझ सके। टेस्ट तकनीकों में शामिल हैं, लेकिन जरूरी नहीं कि ये सीमित हों:
'''सॉफ्टवेयर परीक्षण''' सत्यापन और सत्यापन द्वारा परीक्षण के तहत सॉफ्टवेयर के व्यवहार और कलाकृतियों की जांच करने का कार्य है। [[सॉफ़्टवेयर]] परीक्षण सॉफ़्टवेयर का एक उद्देश्यपूर्ण, स्वतंत्र दृश्य भी प्रदान कर सकता है जिससे व्यवसाय सॉफ़्टवेयर कार्यान्वयन के जोखिमों की सराहना और समझ सके। टेस्ट तकनीकों में सम्मिलित हैं, लेकिन जरूरी नहीं कि ये सीमित हों:


* विभिन्न संदर्भों में उद्योग के दृष्टिकोण, व्यापार के दृष्टिकोण, व्यवहार्यता और कार्यान्वयन की व्यवहार्यता, उपयोगिता, प्रदर्शन, सुरक्षा, बुनियादी ढांचे के विचार आदि में पूर्णता और शुद्धता के लिए उत्पाद आवश्यकताओं का विश्लेषण करना।
* विभिन्न संदर्भों में उद्योग के दृष्टिकोण, व्यापार के दृष्टिकोण, व्यवहार्यता और कार्यान्वयन की व्यवहार्यता, उपयोगिता, प्रदर्शन, सुरक्षा, बुनियादी ढांचे के विचार आदि में पूर्णता और शुद्धता के लिए उत्पाद आवश्यकताओं का विश्लेषण करना।
Line 13: Line 13:
सॉफ्टवेयर परीक्षण, सॉफ्टवेयर की गुणवत्ता और उपयोगकर्ताओं या प्रायोजकों को इसकी विफलता के जोखिम के बारे में उद्देश्यपूर्ण, स्वतंत्र जानकारी प्रदान कर सकता है।<ref name="Kaner 1">{{Cite conference |last=Kaner |first=Cem |author-link=Cem Kaner |date=November 17, 2006 |title=खोजपूर्ण परीक्षण|url=https://kaner.com/pdfs/ETatQAI.pdf |conference=Quality Assurance Institute Worldwide Annual Software Testing Conference |location=Orlando, FL |access-date=November 22, 2014}}</ref>
सॉफ्टवेयर परीक्षण, सॉफ्टवेयर की गुणवत्ता और उपयोगकर्ताओं या प्रायोजकों को इसकी विफलता के जोखिम के बारे में उद्देश्यपूर्ण, स्वतंत्र जानकारी प्रदान कर सकता है।<ref name="Kaner 1">{{Cite conference |last=Kaner |first=Cem |author-link=Cem Kaner |date=November 17, 2006 |title=खोजपूर्ण परीक्षण|url=https://kaner.com/pdfs/ETatQAI.pdf |conference=Quality Assurance Institute Worldwide Annual Software Testing Conference |location=Orlando, FL |access-date=November 22, 2014}}</ref>


सॉफ्टवेयर परीक्षण कुछ विशिष्ट परिकल्पनाओं की धारणा के तहत सॉफ्टवेयर की शुद्धता का निर्धारण कर सकता है (नीचे परीक्षण कठिनाई का पदानुक्रम देखें), परीक्षण सॉफ्टवेयर के भीतर सभी विफलताओं की पहचान नहीं कर सकता है।<ref name="pan">{{Cite web |last=Pan |first=Jiantao |date=Spring 1999 |title=सॉफ्टवेयर परिक्षण|url=http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/ |access-date=November 21, 2017 |publisher=Carnegie Mellon University |type=coursework}}</ref> इसके बजाय, यह एक आलोचना या तुलना प्रस्तुत करता है जो उत्पाद की स्थिति और व्यवहार की तुलना परीक्षण ऑरेकल - सिद्धांतों या तंत्रों से करता है जिसके द्वारा कोई समस्या को पहचान सकता है। इन भविष्यवाणियों में विनिर्देश, अनुबंध,<ref>{{Cite conference |last1=Leitner |first1=Andreas |last2=Ciupa |first2=Ilinca |last3=Oriol |first3=Manuel |last4=Meyer |first4=Bertrand |author-link4=Bertrand Meyer |last5=Fiva |first5=Arno |date=September 2007 |title=अनुबंध संचालित विकास = टेस्ट संचालित विकास - टेस्ट केस लिखना|url=http://se.inf.ethz.ch/people/leitner/publications/cdd_leitner_esec_fse_2007.pdf |conference=ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007 |location=Dubrovnik, Croatia |access-date=December 8, 2017}}</ref> तुलनीय उत्पाद, एक ही उत्पाद के पिछले संस्करण, इच्छित या अपेक्षित उद्देश्य के बारे में अनुमान, उपयोगकर्ता या ग्राहक अपेक्षाएं, प्रासंगिक मानक, लागू कानून, या अन्य मानदंड शामिल हो सकते हैं (लेकिन इन तक सीमित नहीं हैं) .
सॉफ्टवेयर परीक्षण कुछ विशिष्ट परिकल्पनाओं की धारणा के तहत सॉफ्टवेयर की शुद्धता का निर्धारण कर सकता है (नीचे परीक्षण कठिनाई का पदानुक्रम देखें), परीक्षण सॉफ्टवेयर के भीतर सभी विफलताओं की पहचान नहीं कर सकता है।<ref name="pan">{{Cite web |last=Pan |first=Jiantao |date=Spring 1999 |title=सॉफ्टवेयर परिक्षण|url=http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/ |access-date=November 21, 2017 |publisher=Carnegie Mellon University |type=coursework}}</ref> इसके बजाय, यह एक आलोचना या तुलना प्रस्तुत करता है जो उत्पाद की स्थिति और व्यवहार की तुलना परीक्षण ऑरेकल - सिद्धांतों या तंत्रों से करता है जिसके द्वारा कोई समस्या को पहचान सकता है। इन भविष्यवाणियों में विनिर्देश, अनुबंध,<ref>{{Cite conference |last1=Leitner |first1=Andreas |last2=Ciupa |first2=Ilinca |last3=Oriol |first3=Manuel |last4=Meyer |first4=Bertrand |author-link4=Bertrand Meyer |last5=Fiva |first5=Arno |date=September 2007 |title=अनुबंध संचालित विकास = टेस्ट संचालित विकास - टेस्ट केस लिखना|url=http://se.inf.ethz.ch/people/leitner/publications/cdd_leitner_esec_fse_2007.pdf |conference=ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007 |location=Dubrovnik, Croatia |access-date=December 8, 2017}}</ref> तुलनीय उत्पाद, एक ही उत्पाद के पिछले संस्करण, इच्छित या अपेक्षित उद्देश्य के बारे में अनुमान, उपयोगकर्ता या ग्राहक अपेक्षाएं, प्रासंगिक मानक, लागू कानून, या अन्य मानदंड सम्मिलित हो सकते हैं (लेकिन इन तक सीमित नहीं हैं) .


परीक्षण का प्राथमिक उद्देश्य सॉफ़्टवेयर विफलताओं का पता लगाना है ताकि दोषों को खोजा और ठीक किया जा सके। परीक्षण यह स्थापित नहीं कर सकता है कि कोई उत्पाद सभी परिस्थितियों में ठीक से काम करता है, लेकिन केवल यह कि यह विशिष्ट परिस्थितियों में ठीक से काम नहीं करता है।<ref name="Kaner2">{{Cite book |last1=Kaner |first1=Cem |title=कंप्यूटर सॉफ्टवेयर का परीक्षण|last2=Falk |first2=Jack |last3=Nguyen |first3=Hung Quoc |publisher=John Wiley and Sons |year=1999 |isbn=978-0-471-35846-6 |edition=2nd |location=New York |author-link=Cem Kaner}}</ref> सॉफ्टवेयर परीक्षण के दायरे में कोड की परीक्षा के साथ-साथ विभिन्न वातावरणों और स्थितियों में उस कोड के निष्पादन के साथ-साथ कोड के पहलुओं की जांच भी शामिल हो सकती है: क्या यह वह करता है जो इसे करना चाहिए और इसे करने की आवश्यकता होती है। सॉफ़्टवेयर विकास की वर्तमान संस्कृति में, एक परीक्षण संगठन विकास टीम से अलग हो सकता है। परीक्षण टीम के सदस्यों के लिए विभिन्न भूमिकाएँ हैं। सॉफ़्टवेयर परीक्षण से प्राप्त जानकारी का उपयोग उस प्रक्रिया को ठीक करने के लिए किया जा सकता है जिसके द्वारा सॉफ़्टवेयर विकसित किया जाता है।<ref name="kolawa">{{Cite book |last1=Kolawa |first1=Adam |url=http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html |title=स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास|last2=Huizinga |first2=Dorota |publisher=Wiley-IEEE Computer Society Press |year=2007 |isbn=978-0-470-04212-0}}</ref>{{rp|41–43}}
परीक्षण का प्राथमिक उद्देश्य सॉफ़्टवेयर विफलताओं का पता लगाना है ताकि दोषों को खोजा और ठीक किया जा सके। परीक्षण यह स्थापित नहीं कर सकता है कि कोई उत्पाद सभी परिस्थितियों में ठीक से काम करता है, लेकिन केवल यह कि यह विशिष्ट परिस्थितियों में ठीक से काम नहीं करता है।<ref name="Kaner2">{{Cite book |last1=Kaner |first1=Cem |title=कंप्यूटर सॉफ्टवेयर का परीक्षण|last2=Falk |first2=Jack |last3=Nguyen |first3=Hung Quoc |publisher=John Wiley and Sons |year=1999 |isbn=978-0-471-35846-6 |edition=2nd |location=New York |author-link=Cem Kaner}}</ref> सॉफ्टवेयर परीक्षण के दायरे में कोड की परीक्षा के साथ-साथ विभिन्न वातावरणों और स्थितियों में उस कोड के निष्पादन के साथ-साथ कोड के पहलुओं की जांच भी सम्मिलित हो सकती है: क्या यह वह करता है जो इसे करना चाहिए और इसे करने की आवश्यकता होती है। सॉफ़्टवेयर विकास की वर्तमान संस्कृति में, परीक्षण संगठन विकास टीम से अलग हो सकता है। परीक्षण टीम के सदस्यों के लिए विभिन्न भूमिकाएँ हैं। सॉफ़्टवेयर परीक्षण से प्राप्त जानकारी का उपयोग उस प्रक्रिया को ठीक करने के लिए किया जा सकता है जिसके द्वारा सॉफ़्टवेयर विकसित किया जाता है।<ref name="kolawa">{{Cite book |last1=Kolawa |first1=Adam |url=http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html |title=स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास|last2=Huizinga |first2=Dorota |publisher=Wiley-IEEE Computer Society Press |year=2007 |isbn=978-0-470-04212-0}}</ref>{{rp|41–43}}


प्रत्येक सॉफ़्टवेयर उत्पाद का एक लक्षित दर्शक होता है। उदाहरण के लिए, वीडियो गेम सॉफ़्टवेयर के लिए दर्शक बैंकिंग सॉफ़्टवेयर से बिल्कुल अलग हैं। इसलिए, जब कोई संगठन सॉफ़्टवेयर उत्पाद विकसित करता है या उसमें निवेश करता है, तो वह यह आकलन कर सकता है कि क्या सॉफ़्टवेयर उत्पाद उसके अंतिम उपयोगकर्ताओं, उसके लक्षित दर्शकों, उसके खरीदारों और अन्य हितधारकों के लिए स्वीकार्य होगा। सॉफ्टवेयर परीक्षण इस आकलन में सहायता करता है।
प्रत्येक सॉफ़्टवेयर उत्पाद का एक लक्षित दर्शक होता है। उदाहरण के लिए, वीडियो गेम सॉफ़्टवेयर के लिए दर्शक बैंकिंग सॉफ़्टवेयर से बिल्कुल अलग हैं। इसलिए, जब कोई संगठन सॉफ़्टवेयर उत्पाद विकसित करता है या उसमें निवेश करता है, तो वह यह आकलन कर सकता है कि क्या सॉफ़्टवेयर उत्पाद उसके अंतिम उपयोगकर्ताओं, उसके लक्षित दर्शकों, उसके खरीदारों और अन्य हितधारकों के लिए स्वीकार्य होगा। सॉफ्टवेयर परीक्षण इस आकलन में सहायता करता है।
Line 21: Line 21:
=== दोष और [[असफलता]] ===
=== दोष और [[असफलता]] ===


सॉफ़्टवेयर दोष निम्न प्रक्रिया के माध्यम से होते हैं: एक प्रोग्रामर एक त्रुटि (गलती) करता है, जिसके परिणामस्वरूप सॉफ़्टवेयर स्रोत कोड में एक दोष (दोष, बग) होता है। यदि यह दोष निष्पादित किया जाता है, तो कुछ स्थितियों में सिस्टम गलत परिणाम देगा, जिससे विफलता होगी।<ref name="IEEEglossary">{{Citation |title=610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology |date=1990 |publisher=IEEE |doi=10.1109/IEEESTD.1990.101064 |isbn=978-1-55937-067-7}}</ref>{{rp|31}}
सॉफ़्टवेयर दोष निम्न प्रक्रिया के माध्यम से होते हैं: प्रोग्रामर एक त्रुटि (गलती) करता है, जिसके परिणामस्वरूप सॉफ़्टवेयर स्रोत कोड में एक दोष (दोष, बग) होता है। यदि यह दोष निष्पादित किया जाता है, तो कुछ स्थितियों में सिस्टम गलत परिणाम देगा, जिससे विफलता होगी।<ref name="IEEEglossary">{{Citation |title=610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology |date=1990 |publisher=IEEE |doi=10.1109/IEEESTD.1990.101064 |isbn=978-1-55937-067-7}}</ref>{{rp|31}}


जरूरी नहीं है कि सभी गलतियां असफलता का कारण बने। उदाहरण के लिए, डेड कोड में दोष कभी भी विफल नहीं होंगे। एक गलती जो विफलताओं को प्रकट नहीं करती है, जब पर्यावरण में परिवर्तन होता है तो विफलता हो सकती है। वातावरण में इन परिवर्तनों के उदाहरणों में एक नए कंप्यूटर हार्डवेयर प्लेटफॉर्म पर चलने वाले सॉफ़्टवेयर, [[स्रोत डेटा]] में परिवर्तन, या विभिन्न सॉफ़्टवेयर के साथ इंटरैक्ट करना शामिल हैं।<ref>{{Cite web |date=March 31, 2011 |title=सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस|url=https://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-syllabus-2011.html |access-date=December 15, 2017 |publisher=[[International Software Testing Qualifications Board]] |at=Section 1.1.2 |format=pdf}}</ref> एक गलती के परिणामस्वरूप विफलता के कई लक्षण हो सकते हैं।
जरूरी नहीं है कि सभी गलतियां असफलता का कारण बने। उदाहरण के लिए, डेड कोड में दोष कभी भी विफल नहीं होंगे। गलती जो विफलताओं को प्रकट नहीं करती है, जब पर्यावरण में परिवर्तन होता है तो विफलता हो सकती है। वातावरण में इन परिवर्तनों के उदाहरणों में नए कंप्यूटर हार्डवेयर प्लेटफॉर्म पर चलने वाले सॉफ़्टवेयर, [[स्रोत डेटा]] में परिवर्तन, या विभिन्न सॉफ़्टवेयर के साथ इंटरैक्ट करना सम्मिलित हैं।<ref>{{Cite web |date=March 31, 2011 |title=सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस|url=https://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-syllabus-2011.html |access-date=December 15, 2017 |publisher=[[International Software Testing Qualifications Board]] |at=Section 1.1.2 |format=pdf}}</ref> एक गलती के परिणामस्वरूप विफलता के कई लक्षण हो सकते हैं।


कोडिंग त्रुटियों के कारण सभी सॉफ़्टवेयर दोष नहीं होते हैं। महंगे दोषों का एक सामान्य स्रोत आवश्यकता अंतराल है, अर्थात, अपरिचित आवश्यकताएं जिसके परिणामस्वरूप प्रोग्राम डिजाइनर द्वारा चूक की त्रुटियां होती हैं।<ref name="kolawa" />{{rp|426}}  
कोडिंग त्रुटियों के कारण सभी सॉफ़्टवेयर दोष नहीं होते हैं। महंगे दोषों का सामान्य स्रोत आवश्यकता अंतराल है, अर्थात, अपरिचित आवश्यकताएं जिसके परिणामस्वरूप प्रोग्राम डिजाइनर द्वारा चूक की त्रुटियां होती हैं।<ref name="kolawa" />{{rp|426}}  


=== इनपुट संयोजन और पूर्व शर्त ===
=== इनपुट संयोजन और पूर्व शर्त ===


सॉफ्टवेयर परीक्षण के साथ एक मौलिक समस्या यह है कि इनपुट और पूर्व शर्त (प्रारंभिक स्थिति) के सभी संयोजनों के तहत परीक्षण संभव नहीं है, यहां तक कि एक साधारण उत्पाद के साथ भी।<ref name="Kaner2" />{{rp|17–18}}<ref>{{Cite web |date=July 1, 2005 |title=सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस|url=http://www.bcs.org/upload/pdf/istqbsyll.pdf |access-date=December 15, 2017 |publisher=[[International Software Testing Qualifications Board]] |at=Principle 2, Section 1.3 |archive-date=December 17, 2008 |archive-url=https://web.archive.org/web/20081217060536/http://www.bcs.org/upload/pdf/istqbsyll.pdf |url-status=dead }}</ref> इसका मतलब है कि एक [[सॉफ्टवेयर बग|सॉफ्टवेयर]] में दोषों की संख्या उत्पाद बहुत बड़ा हो सकता है और दोष जो कभी-कभी होते हैं, परीक्षण और डिबगिंग में खोजना मुश्किल होता है। अधिक महत्वपूर्ण रूप से, गुणवत्ता के गैर-कार्यात्मक आयाम (इसे कैसे माना जाता है बनाम इसे क्या करना चाहिए) - उपयोगिता, मापनीयता, प्रदर्शन, संगतता और विश्वसनीयता - अत्यधिक व्यक्तिपरक हो सकते हैं; कुछ ऐसा जो एक व्यक्ति के लिए पर्याप्त मूल्य का गठन करता है, दूसरे के लिए असहनीय हो सकता है।
सॉफ्टवेयर परीक्षण के साथ मौलिक समस्या यह है कि इनपुट और पूर्व शर्त (प्रारंभिक स्थिति) के सभी संयोजनों के तहत परीक्षण संभव नहीं है, यहां तक कि एक साधारण उत्पाद के साथ भी।<ref name="Kaner2" />{{rp|17–18}}<ref>{{Cite web |date=July 1, 2005 |title=सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस|url=http://www.bcs.org/upload/pdf/istqbsyll.pdf |access-date=December 15, 2017 |publisher=[[International Software Testing Qualifications Board]] |at=Principle 2, Section 1.3 |archive-date=December 17, 2008 |archive-url=https://web.archive.org/web/20081217060536/http://www.bcs.org/upload/pdf/istqbsyll.pdf |url-status=dead }}</ref> इसका मतलब है कि एक [[सॉफ्टवेयर बग|सॉफ्टवेयर]] में दोषों की संख्या उत्पाद बहुत बड़ा हो सकता है और दोष जो कभी-कभी होते हैं, परीक्षण और डिबगिंग में खोजना मुश्किल होता है। अधिक महत्वपूर्ण रूप से, गुणवत्ता के गैर-कार्यात्मक आयाम (इसे कैसे माना जाता है बनाम इसे क्या करना चाहिए) - उपयोगिता, मापनीयता, प्रदर्शन, संगतता और विश्वसनीयता - अत्यधिक व्यक्तिपरक हो सकते हैं; कुछ ऐसा जो एक व्यक्ति के लिए पर्याप्त मूल्य का गठन करता है, दूसरे के लिए असहनीय हो सकता है।


सॉफ़्टवेयर डेवलपर सब कुछ का परीक्षण नहीं कर सकते हैं, लेकिन वे अपने इच्छित कवरेज को प्राप्त करने के लिए आवश्यक परीक्षणों की न्यूनतम संख्या की पहचान करने के लिए मिश्रित परीक्षण डिज़ाइन का उपयोग कर सकते हैं। कॉम्बिनेटरियल टेस्ट डिज़ाइन उपयोगकर्ताओं को कम परीक्षणों के साथ अधिक परीक्षण कवरेज प्राप्त करने में सक्षम बनाता है। चाहे वे गति या परीक्षण की गहराई की तलाश कर रहे हों, वे अपने परीक्षण मामलों में संरचित भिन्नता के निर्माण के लिए संयुक्त परीक्षण डिजाइन विधियों का उपयोग कर सकते हैं।<ref>{{Cite conference |last1=Ramler |first1=Rudolf |last2=Kopetzky |first2=Theodorich |last3=Platz |first3=Wolfgang |date=April 17, 2012 |title=TOSCA टेस्टसुइट में कॉम्बिनेटरियल टेस्ट डिज़ाइन: सीखे गए सबक और व्यावहारिक निहितार्थ|conference=IEEE Fifth International Conference on Software Testing and Validation (ICST) |location=Montreal, QC, Canada |doi=10.1109/ICST.2012.142}}</ref>
सॉफ़्टवेयर डेवलपर सब कुछ का परीक्षण नहीं कर सकते हैं, लेकिन वे अपने इच्छित कवरेज को प्राप्त करने के लिए आवश्यक परीक्षणों की न्यूनतम संख्या की पहचान करने के लिए मिश्रित परीक्षण डिज़ाइन का उपयोग कर सकते हैं। कॉम्बिनेटरियल टेस्ट डिज़ाइन उपयोगकर्ताओं को कम परीक्षणों के साथ अधिक परीक्षण कवरेज प्राप्त करने में सक्षम बनाता है। चाहे वे गति या परीक्षण की गहराई की खोज कर रहे हों, वे अपने परीक्षण मामलों में संरचित भिन्नता के निर्माण के लिए संयुक्त परीक्षण डिजाइन विधियों का उपयोग कर सकते हैं।<ref>{{Cite conference |last1=Ramler |first1=Rudolf |last2=Kopetzky |first2=Theodorich |last3=Platz |first3=Wolfgang |date=April 17, 2012 |title=TOSCA टेस्टसुइट में कॉम्बिनेटरियल टेस्ट डिज़ाइन: सीखे गए सबक और व्यावहारिक निहितार्थ|conference=IEEE Fifth International Conference on Software Testing and Validation (ICST) |location=Montreal, QC, Canada |doi=10.1109/ICST.2012.142}}</ref>


=== अर्थशास्त्र ===
=== अर्थशास्त्र ===


[[एनआईएसटी]] द्वारा 2002 में किए गए एक अध्ययन में बताया गया है कि सॉफ्टवेयर बग से अमेरिकी अर्थव्यवस्था को सालाना 59.5 बिलियन डॉलर का नुकसान होता है। यदि बेहतर सॉफ्टवेयर परीक्षण किया जाता है तो इस लागत के एक तिहाई से अधिक से बचा जा सकता है।<ref>{{Cite web |date=May 2002 |title=सॉफ्टवेयर परीक्षण के लिए अपर्याप्त बुनियादी ढांचे का आर्थिक प्रभाव|url=https://www.nist.gov/director/planning/upload/report02-3.pdf |access-date=December 19, 2017 |publisher=[[National Institute of Standards and Technology]]}}</ref>
[[एनआईएसटी]] द्वारा 2002 में किए गए अध्ययन में बताया गया है कि सॉफ्टवेयर बग से अमेरिकी अर्थव्यवस्था को सालाना 59.5 बिलियन डॉलर का नुकसान होता है। यदि बेहतर सॉफ्टवेयर परीक्षण किया जाता है तो इस लागत के एक तिहाई से अधिक से बचा जा सकता है।<ref>{{Cite web |date=May 2002 |title=सॉफ्टवेयर परीक्षण के लिए अपर्याप्त बुनियादी ढांचे का आर्थिक प्रभाव|url=https://www.nist.gov/director/planning/upload/report02-3.pdf |access-date=December 19, 2017 |publisher=[[National Institute of Standards and Technology]]}}</ref>


लागत के कारण [[आउटसोर्सिंग]] सॉफ्टवेयर परीक्षण बहुत आम है, चीन, फिलीपींस और भारत पसंदीदा स्थान हैं।<ref>{{Cite magazine |last=Sharma |first=Bharadwaj |date=April 2016 |title=अर्देंटिया टेक्नोलॉजीज: अत्याधुनिक सॉफ्टवेयर समाधान और व्यापक परीक्षण सेवाएं प्रदान करना|url=http://www.cioreviewindia.com/magazine/Ardentia-Technologies-Providing-Cutting-Edge-Software-Solutions-and-Comprehensive-Testing-Services---JSAH430576969.html |magazine=CIO Review |edition=India |access-date=December 20, 2017}}</ref>
लागत के कारण [[आउटसोर्सिंग]] सॉफ्टवेयर परीक्षण बहुत साधारण है, चीन, फिलीपींस और भारत पसंदीदा स्थान हैं।<ref>{{Cite magazine |last=Sharma |first=Bharadwaj |date=April 2016 |title=अर्देंटिया टेक्नोलॉजीज: अत्याधुनिक सॉफ्टवेयर समाधान और व्यापक परीक्षण सेवाएं प्रदान करना|url=http://www.cioreviewindia.com/magazine/Ardentia-Technologies-Providing-Cutting-Edge-Software-Solutions-and-Comprehensive-Testing-Services---JSAH430576969.html |magazine=CIO Review |edition=India |access-date=December 20, 2017}}</ref>


=== भूमिकाएं ===
=== भूमिकाएं ===


सॉफ्टवेयर परीक्षण समर्पित सॉफ्टवेयर परीक्षकों द्वारा किया जा सकता है; 1980 के दशक तक, "सॉफ़्टवेयर टेस्टर" शब्द का उपयोग आम तौर पर किया जाता था, लेकिन बाद में इसे एक अलग पेशे के रूप में भी देखा जाने लगा। सॉफ़्टवेयर परीक्षण में अवधियों और विभिन्न लक्ष्यों के संबंध में,<ref>{{Cite journal |last1=Gelperin |first1=David |author-link=Dave Gelperin |last2=Hetzel |first2=Bill |author-link2=William C. Hetzel |date=June 1, 1988 |title=सॉफ्टवेयर परीक्षण की वृद्धि|journal=Communications of the ACM |volume=31 |issue=6 |pages=687–695 |doi=10.1145/62959.62965 |s2cid=14731341}}</ref> विभिन्न भूमिकाएँ स्थापित की गई हैं, जैसे कि टेस्ट मैनेजर, टेस्ट लीड, टेस्ट एनालिस्ट, टेस्ट डिज़ाइनर, टेस्टर, ऑटोमेशन डेवलपर और टेस्ट एडमिनिस्ट्रेटर। सॉफ़्टवेयर परीक्षण गैर-समर्पित सॉफ़्टवेयर परीक्षकों द्वारा भी किया जा सकता है।<ref>{{Cite book |last1=Gregory |first1=Janet |title=अधिक चुस्त परीक्षण|last2=Crispin |first2=Lisa |publisher=Addison-Wesley Professional |year=2014 |isbn=978-0-13-374956-4 |pages=23–39}}</ref>
सॉफ्टवेयर परीक्षण समर्पित सॉफ्टवेयर परीक्षकों द्वारा किया जा सकता है; 1980 के दशक तक, "सॉफ़्टवेयर टेस्टर" शब्द का उपयोग सामान्यतः किया जाता था, लेकिन बाद में इसे एक अलग पेशे के रूप में भी देखा जाने लगा। सॉफ़्टवेयर परीक्षण में अवधियों और विभिन्न लक्ष्यों के संबंध में,<ref>{{Cite journal |last1=Gelperin |first1=David |author-link=Dave Gelperin |last2=Hetzel |first2=Bill |author-link2=William C. Hetzel |date=June 1, 1988 |title=सॉफ्टवेयर परीक्षण की वृद्धि|journal=Communications of the ACM |volume=31 |issue=6 |pages=687–695 |doi=10.1145/62959.62965 |s2cid=14731341}}</ref> विभिन्न भूमिकाएँ स्थापित की गई हैं, जैसे कि टेस्ट मैनेजर, टेस्ट लीड, टेस्ट एनालिस्ट, टेस्ट डिज़ाइनर, टेस्टर, ऑटोमेशन डेवलपर और टेस्ट एडमिनिस्ट्रेटर। सॉफ़्टवेयर परीक्षण गैर-समर्पित सॉफ़्टवेयर परीक्षकों द्वारा भी किया जा सकता है।<ref>{{Cite book |last1=Gregory |first1=Janet |title=अधिक चुस्त परीक्षण|last2=Crispin |first2=Lisa |publisher=Addison-Wesley Professional |year=2014 |isbn=978-0-13-374956-4 |pages=23–39}}</ref>
== इतिहास ==
== इतिहास ==


ग्लेनफोर्ड जे. मायर्स ने शुरू में 1979 में [[डिबगिंग]] को परीक्षण से अलग करने की शुरुआत की।<ref name="Myers 1979">{{Cite book |last=Myers |first=Glenford J. |url=https://archive.org/details/artofsoftwaretes00myer |title=सॉफ्टवेयर परीक्षण की कला|publisher=John Wiley and Sons |year=1979 |isbn=978-0-471-04328-7 |author-link=Glenford Myers}}</ref> हालांकि उनका ध्यान ब्रेकडाउन टेस्टिंग पर था ("एक सफल परीक्षण मामला वह है जो अभी तक अनदेखे त्रुटि का पता लगाता है।<ref name="Myers 1979" />
ग्लेनफोर्ड जे. मायर्स ने शुरू में 1979 में [[डिबगिंग]] को परीक्षण से अलग करने की आरंभ की।<ref name="Myers 1979">{{Cite book |last=Myers |first=Glenford J. |url=https://archive.org/details/artofsoftwaretes00myer |title=सॉफ्टवेयर परीक्षण की कला|publisher=John Wiley and Sons |year=1979 |isbn=978-0-471-04328-7 |author-link=Glenford Myers}}</ref> हालांकि उनका ध्यान ब्रेकडाउन टेस्टिंग पर था ("एक सफल परीक्षण मामला वह है जो अभी तक अनदेखे त्रुटि का पता लगाता है।<ref name="Myers 1979" />


इसने सॉफ्टवेयर इंजीनियरिंग समुदाय की बुनियादी विकास गतिविधियों, जैसे डीबगिंग, को सत्यापन से अलग करने की इच्छा को स्पष्ट किया।
इसने सॉफ्टवेयर इंजीनियरिंग समुदाय की बुनियादी विकास गतिविधियों, जैसे डीबगिंग, को सत्यापन से अलग करने की इच्छा को स्पष्ट किया था ।


== परीक्षण दृष्टिकोण ==
== परीक्षण दृष्टिकोण ==
Line 54: Line 54:
सॉफ़्टवेयर परीक्षण में कई दृष्टिकोण उपलब्ध हैं। समीक्षा, पूर्वाभ्यास, या निरीक्षण को स्थैतिक परीक्षण के रूप में संदर्भित किया जाता है, जबकि परीक्षण मामलों के दिए गए सेट के साथ क्रमादेशित कोड को क्रियान्वित करना [[गतिशील परीक्षण]] के रूप में संदर्भित किया जाता है।<ref name="GrahamFoundations08">{{Cite book |last1=Graham, D. |url=https://books.google.com/books?id=Ss62LSqCa1MC&pg=PA57 |title=सॉफ्टवेयर परीक्षण की नींव|last2=Van Veenendaal, E. |last3=Evans, I. |publisher=Cengage Learning |year=2008 |isbn=978-1-84480-989-9 |pages=57–58}}</ref><ref name="OberkampfVerif10">{{Cite book |last1=Oberkampf, W.L. |url=https://books.google.com/books?id=7d26zLEJ1FUC&pg=PA155 |title=वैज्ञानिक कंप्यूटिंग में सत्यापन और मान्यता|last2=Roy, C.J. |publisher=Cambridge University Press |year=2010 |isbn=978-1-139-49176-1 |pages=154–5}}</ref>
सॉफ़्टवेयर परीक्षण में कई दृष्टिकोण उपलब्ध हैं। समीक्षा, पूर्वाभ्यास, या निरीक्षण को स्थैतिक परीक्षण के रूप में संदर्भित किया जाता है, जबकि परीक्षण मामलों के दिए गए सेट के साथ क्रमादेशित कोड को क्रियान्वित करना [[गतिशील परीक्षण]] के रूप में संदर्भित किया जाता है।<ref name="GrahamFoundations08">{{Cite book |last1=Graham, D. |url=https://books.google.com/books?id=Ss62LSqCa1MC&pg=PA57 |title=सॉफ्टवेयर परीक्षण की नींव|last2=Van Veenendaal, E. |last3=Evans, I. |publisher=Cengage Learning |year=2008 |isbn=978-1-84480-989-9 |pages=57–58}}</ref><ref name="OberkampfVerif10">{{Cite book |last1=Oberkampf, W.L. |url=https://books.google.com/books?id=7d26zLEJ1FUC&pg=PA155 |title=वैज्ञानिक कंप्यूटिंग में सत्यापन और मान्यता|last2=Roy, C.J. |publisher=Cambridge University Press |year=2010 |isbn=978-1-139-49176-1 |pages=154–5}}</ref>


स्टेटिक परीक्षण अक्सर अंतर्निहित होता है, जैसे प्रूफरीडिंग, प्लस जब प्रोग्रामिंग टूल/टेक्स्ट एडिटर स्रोत कोड संरचना या कंपाइलर्स (प्री-कंपाइलर) की जांच करते हैं तो सिंटैक्स और डेटा प्रवाह को स्थिर प्रोग्राम विश्लेषण के रूप में चेक करते हैं। गतिशील परीक्षण तब होता है जब प्रोग्राम स्वयं चलाया जाता है। असतत कार्यों या मॉड्यूल पर लागू कोड के विशेष वर्गों का परीक्षण करने के लिए कार्यक्रम के 100% पूर्ण होने से पहले गतिशील परीक्षण शुरू हो सकता है।<ref name="GrahamFoundations08" /><ref name="OberkampfVerif10" /> इनके लिए विशिष्ट तकनीकें या तो स्टब्स/ड्राइवर्स का उपयोग कर रही हैं या [[डिबगर]] वातावरण से निष्पादन कर रही हैं।<ref name="OberkampfVerif10" />
स्टेटिक परीक्षण प्रायः अंतर्निहित होता है, जैसे प्रूफरीडिंग, प्लस जब प्रोग्रामिंग टूल/टेक्स्ट एडिटर स्रोत कोड संरचना या कंपाइलर्स (प्री-कंपाइलर) की जांच करते हैं तो सिंटैक्स और डेटा प्रवाह को स्थिर प्रोग्राम विश्लेषण के रूप में चेक करते हैं। गतिशील परीक्षण तब होता है जब प्रोग्राम स्वयं चलाया जाता है। असतत कार्यों या मॉड्यूल पर लागू कोड के विशेष वर्गों का परीक्षण करने के लिए कार्यक्रम के 100% पूर्ण होने से पहले गतिशील परीक्षण शुरू हो सकता है।<ref name="GrahamFoundations08" /><ref name="OberkampfVerif10" /> इनके लिए विशिष्ट तकनीकें या तो स्टब्स/ड्राइवर्स का उपयोग कर रही हैं या [[डिबगर]] वातावरण से निष्पादन कर रही हैं।<ref name="OberkampfVerif10" />


स्थिर परीक्षण में सत्यापन शामिल है, जबकि गतिशील परीक्षण में सत्यापन भी शामिल है।<ref name="OberkampfVerif10" />
स्थिर परीक्षण में सत्यापन सम्मिलित है, जबकि गतिशील परीक्षण में सत्यापन भी सम्मिलित है।<ref name="OberkampfVerif10" />


निष्क्रिय परीक्षण का अर्थ है सॉफ्टवेयर उत्पाद के साथ किसी भी तरह की बातचीत के बिना सिस्टम के व्यवहार को सत्यापित करना। सक्रिय परीक्षण के विपरीत, परीक्षक कोई परीक्षण डेटा प्रदान नहीं करते हैं, लेकिन सिस्टम लॉग और ट्रेस को देखते हैं। वे किसी तरह का निर्णय लेने के लिए पैटर्न और विशिष्ट व्यवहार की खोज करते हैं।<ref>{{Cite journal |last1=Lee |first1=D. |last2=Netravali |first2=A.N. |last3=Sabnani |first3=K.K. |last4=Sugla |first4=B. |last5=John |first5=A. |year=1997 |title=नेटवर्क प्रबंधन के लिए निष्क्रिय परीक्षण और अनुप्रयोग|journal=Proceedings 1997 International Conference on Network Protocols |publisher=IEEE Comput. Soc |pages=113–122 |doi=10.1109/icnp.1997.643699 |isbn=978-0-8186-8061-8 |s2cid=42596126}}</ref> यह ऑफ़लाइन क्रम सत्यापन और [[लॉग विश्लेषण]] से संबंधित है।
निष्क्रिय परीक्षण का अर्थ है सॉफ्टवेयर उत्पाद के साथ किसी भी तरह की बातचीत के बिना सिस्टम के व्यवहार को सत्यापित करना। सक्रिय परीक्षण के विपरीत, परीक्षक कोई परीक्षण डेटा प्रदान नहीं करते हैं, लेकिन सिस्टम लॉग और ट्रेस को देखते हैं। वे किसी तरह का निर्णय लेने के लिए पैटर्न और विशिष्ट व्यवहार की खोज करते हैं।<ref>{{Cite journal |last1=Lee |first1=D. |last2=Netravali |first2=A.N. |last3=Sabnani |first3=K.K. |last4=Sugla |first4=B. |last5=John |first5=A. |year=1997 |title=नेटवर्क प्रबंधन के लिए निष्क्रिय परीक्षण और अनुप्रयोग|journal=Proceedings 1997 International Conference on Network Protocols |publisher=IEEE Comput. Soc |pages=113–122 |doi=10.1109/icnp.1997.643699 |isbn=978-0-8186-8061-8 |s2cid=42596126}}</ref> यह ऑफ़लाइन क्रम सत्यापन और [[लॉग विश्लेषण]] से संबंधित है।


=== अन्वेषणात्मक दृष्टिकोण ===
=== अन्वेषणात्मक दृष्टिकोण ===
अन्वेषणात्मक परीक्षण सॉफ्टवेयर परीक्षण के लिए एक दृष्टिकोण है जिसे संक्षिप्त रूप से एक साथ सीखने, [[परीक्षण डिजाइन]] और परीक्षण निष्पादन के रूप में वर्णित किया जाता है। केम कनेर, जिन्होंने 1984 में इस शब्द को गढ़ा था,<ref name="KanerTutorial">{{Citation |last=Cem Kaner |title=A Tutorial in Exploratory Testing |date=2008 |url=http://www.kaner.com/pdfs/QAIExploring.pdf}}</ref>  अन्वेषणात्मक परीक्षण को "सॉफ़्टवेयर परीक्षण की एक शैली के रूप में परिभाषित करता है जो व्यक्तिगत परीक्षक की व्यक्तिगत स्वतंत्रता और उत्तरदायित्व पर जोर देता है ताकि वह परीक्षण का इलाज करके अपने काम की गुणवत्ता को लगातार अनुकूलित कर सके- परस्पर सहायक गतिविधियों के रूप में संबंधित शिक्षा, परीक्षण डिजाइन, परीक्षण निष्पादन, और परीक्षा परिणाम की व्याख्या, जो पूरे प्रोजेक्ट में समानांतर रूप से चलती है।"<ref name="KanerTutorial" />
अन्वेषणात्मक परीक्षण सॉफ्टवेयर परीक्षण के लिए दृष्टिकोण है जिसे संक्षिप्त रूप से एक साथ सीखने, [[परीक्षण डिजाइन]] और परीक्षण निष्पादन के रूप में वर्णित किया जाता है। केम कनेर, जिन्होंने 1984 में इस शब्द को गढ़ा था,<ref name="KanerTutorial">{{Citation |last=Cem Kaner |title=A Tutorial in Exploratory Testing |date=2008 |url=http://www.kaner.com/pdfs/QAIExploring.pdf}}</ref>  अन्वेषणात्मक परीक्षण को "सॉफ़्टवेयर परीक्षण की एक शैली के रूप में परिभाषित करता है जो व्यक्तिगत परीक्षक की व्यक्तिगत स्वतंत्रता और उत्तरदायित्व पर जोर देता है ताकि वह परीक्षण का इलाज करके अपने काम की गुणवत्ता को लगातार अनुकूलित कर सके- परस्पर सहायक गतिविधियों के रूप में संबंधित शिक्षा, परीक्षण डिजाइन, परीक्षण निष्पादन, और परीक्षा परिणाम की व्याख्या, जो पूरे प्रोजेक्ट में समानांतर रूप से चलती है।"<ref name="KanerTutorial" />


=== बॉक्स दृष्टिकोण ===
=== बॉक्स दृष्टिकोण ===
Line 69: Line 69:
{{Main|व्हाइट-बॉक्स परीक्षण}}
{{Main|व्हाइट-बॉक्स परीक्षण}}


[[File:White Box Testing Approach.png|alt=White Box Testing Diagram|thumb|व्हाइट बॉक्स परीक्षण आरेख]]व्हाइट-बॉक्स टेस्टिंग (क्लियर बॉक्स टेस्टिंग, ग्लास बॉक्स टेस्टिंग, ट्रांसपेरेंट बॉक्स टेस्टिंग और स्ट्रक्चरल टेस्टिंग के रूप में भी जाना जाता है) एंड-यूज़र के सामने आने वाली कार्यक्षमता के विपरीत, किसी प्रोग्राम की आंतरिक संरचनाओं या कार्यप्रणाली की पुष्टि करता है। व्हाइट-बॉक्स परीक्षण में, सिस्टम के एक आंतरिक परिप्रेक्ष्य (स्रोत कोड) के साथ-साथ प्रोग्रामिंग कौशल का परीक्षण मामलों को डिजाइन करने के लिए उपयोग किया जाता है। परीक्षक कोड के माध्यम से पथ का प्रयोग करने के लिए इनपुट चुनता है और उचित आउटपुट निर्धारित करता है।<ref name="LimayeSoftware09" /><ref name="SalehSoftware09" /> यह एक सर्किट में परीक्षण नोड्स के अनुरूप है, उदाहरण के लिए, [[इन-सर्किट परीक्षण]] (आईसीटी)।
[[File:White Box Testing Approach.png|alt=White Box Testing Diagram|thumb|व्हाइट बॉक्स परीक्षण आरेख]]व्हाइट-बॉक्स टेस्टिंग (क्लियर बॉक्स टेस्टिंग, ग्लास बॉक्स टेस्टिंग, ट्रांसपेरेंट बॉक्स टेस्टिंग और स्ट्रक्चरल टेस्टिंग के रूप में भी जाना जाता है) एंड-यूज़र के सामने आने वाली कार्यक्षमता के विपरीत, किसी प्रोग्राम की आंतरिक संरचनाओं या कार्यप्रणाली की पुष्टि करता है। व्हाइट-बॉक्स परीक्षण में, सिस्टम के एक आंतरिक परिप्रेक्ष्य (स्रोत कोड) के साथ-साथ प्रोग्रामिंग कौशल का परीक्षण मामलों को डिजाइन करने के लिए उपयोग किया जाता है। परीक्षक कोड के माध्यम से पथ का प्रयोग करने के लिए इनपुट चुनता है और उचित आउटपुट निर्धारित करता है।<ref name="LimayeSoftware09" /><ref name="SalehSoftware09" /> यह सर्किट में परीक्षण नोड्स के अनुरूप है, उदाहरण के लिए, [[इन-सर्किट परीक्षण]] (आईसीटी)।


जबकि व्हाइट-बॉक्स टेस्टिंग को [[इकाई का परीक्षण|इकाई]], [[एकीकरण जांच]] और सॉफ्टवेयर टेस्टिंग प्रोसेस के [[सिस्टम परीक्षण]] लेवल पर लागू किया जा सकता है, यह आमतौर पर यूनिट लेवल पर किया जाता है।<ref name="AmmannIntro16" />यह एक इकाई के भीतर पथों का परीक्षण कर सकता है, एकीकरण के दौरान इकाइयों के बीच और सिस्टम-स्तरीय परीक्षण के दौरान उप-प्रणालियों के बीच पथों का परीक्षण कर सकता है। हालांकि परीक्षण डिजाइन की यह विधि कई त्रुटियों या समस्याओं को उजागर कर सकती है, यह विनिर्देश या लापता आवश्यकताओं के लागू नहीं किए गए भागों का पता नहीं लगा सकती है।
जबकि व्हाइट-बॉक्स टेस्टिंग को [[इकाई का परीक्षण|इकाई]], [[एकीकरण जांच]] और सॉफ्टवेयर टेस्टिंग प्रोसेस के [[सिस्टम परीक्षण]] लेवल पर लागू किया जा सकता है, यह सामान्यतः यूनिट लेवल पर किया जाता है।<ref name="AmmannIntro16" /> यह एक इकाई के भीतर पथों का परीक्षण कर सकता है, एकीकरण के दौरान इकाइयों के बीच और सिस्टम-स्तरीय परीक्षण के दौरान उप-प्रणालियों के बीच पथों का परीक्षण कर सकता है। हालांकि परीक्षण डिजाइन की यह विधि कई त्रुटियों या समस्याओं को उजागर कर सकती है, यह विनिर्देश या लापता आवश्यकताओं के लागू नहीं किए गए भागों का पता नहीं लगा सकती है।


व्हाइट-बॉक्स परीक्षण में उपयोग की जाने वाली तकनीकों में शामिल हैं:<ref name="SalehSoftware09" /><ref name="EverettSoftware07">{{Cite book |last1=Everatt, G.D. |title=सॉफ्टवेयर परीक्षण: संपूर्ण सॉफ्टवेयर विकास जीवन चक्र का परीक्षण|last2=McLeod Jr., R. |publisher=John Wiley & Sons |year=2007 |isbn=978-0-470-14634-7 |pages=99–121 |chapter=Chapter 7: Functional Testing}}</ref>
व्हाइट-बॉक्स परीक्षण में उपयोग की जाने वाली तकनीकों में सम्मिलित हैं:<ref name="SalehSoftware09" /><ref name="EverettSoftware07">{{Cite book |last1=Everatt, G.D. |title=सॉफ्टवेयर परीक्षण: संपूर्ण सॉफ्टवेयर विकास जीवन चक्र का परीक्षण|last2=McLeod Jr., R. |publisher=John Wiley & Sons |year=2007 |isbn=978-0-470-14634-7 |pages=99–121 |chapter=Chapter 7: Functional Testing}}</ref>
* [[एपीआई परीक्षण]] - सार्वजनिक और निजी [[अनुप्रयोग प्रोग्रामिंग इंटरफेस]] (एप्लिकेशन प्रोग्रामिंग इंटरफेस) का उपयोग करके एप्लिकेशन का परीक्षण
* [[एपीआई परीक्षण]] - सार्वजनिक और निजी [[अनुप्रयोग प्रोग्रामिंग इंटरफेस]] (एप्लिकेशन प्रोग्रामिंग इंटरफेस) का उपयोग करके एप्लिकेशन का परीक्षण
* [[कोड कवरेज़]] - कोड कवरेज के कुछ मानदंडों को पूरा करने के लिए परीक्षण बनाना (उदाहरण के लिए, परीक्षण डिजाइनर कार्यक्रम में सभी बयानों को कम से कम एक बार निष्पादित करने के लिए परीक्षण बना सकता है)
* [[कोड कवरेज़]] - कोड कवरेज के कुछ मानदंडों को पूरा करने के लिए परीक्षण बनाना (उदाहरण के लिए, परीक्षण डिजाइनर कार्यक्रम में सभी बयानों को कम से कम एक बार निष्पादित करने के लिए परीक्षण बना सकता है)
Line 85: Line 85:
:* निर्णय (डिसीज़न) कवरेज, जो इस बात की रिपोर्ट करता है कि किसी दिए गए परीक्षण की सही और गलत दोनों शाखाएँ निष्पादित की गई हैं या नहीं
:* निर्णय (डिसीज़न) कवरेज, जो इस बात की रिपोर्ट करता है कि किसी दिए गए परीक्षण की सही और गलत दोनों शाखाएँ निष्पादित की गई हैं या नहीं


100% स्टेटमेंट कवरेज यह सुनिश्चित करता है कि सभी कोड पथ या शाखाएं (नियंत्रण प्रवाह के संदर्भ में) कम से कम एक बार निष्पादित हों। यह सही कार्यक्षमता सुनिश्चित करने में मददगार है, लेकिन पर्याप्त नहीं है क्योंकि एक ही कोड अलग-अलग इनपुट को सही या गलत तरीके से संसाधित कर सकता है।<ref>As a simple example, the [[C (programming language)|C]] function <syntaxhighlight lang="C" inline>int f(int x){return x*x-6*x+8;}</syntaxhighlight> consists of only one statement. All tests against a specification <syntaxhighlight lang="C" inline>f(x)>=0</syntaxhighlight> will succeed, except if <syntaxhighlight lang="C" inline>x=3</syntaxhighlight> happens to be chosen.</ref> छद्म-परीक्षण कार्य और विधियाँ वे हैं जो कवर किए गए हैं लेकिन निर्दिष्ट नहीं हैं (बिना किसी परीक्षण मामले को तोड़े उनके शरीर को निकालना संभव है)।<ref name="Vera-PérezDanglot2018">{{Cite journal |last1=Vera-Pérez |first1=Oscar Luis |last2=Danglot |first2=Benjamin |last3=Monperrus |first3=Martin |last4=Baudry |first4=Benoit |year=2018 |title=छद्म परीक्षण विधियों का व्यापक अध्ययन|url=https://hal.archives-ouvertes.fr/hal-01867423/document |journal=Empirical Software Engineering |volume=24 |issue=3 |pages=1195–1225 |arxiv=1807.05030 |bibcode=2018arXiv180705030V |doi=10.1007/s10664-018-9653-2 |s2cid=49744829}}</रेफरी>
100% स्टेटमेंट कवरेज यह सुनिश्चित करता है कि सभी कोड पथ या शाखाएं (नियंत्रण प्रवाह के संदर्भ में) कम से कम एक बार निष्पादित हों। यह सही कार्यक्षमता सुनिश्चित करने में मददगार है, लेकिन पर्याप्त नहीं है क्योंकि एक ही कोड अलग-अलग इनपुट को सही या गलत तरीके से संसाधित कर सकता है।<ref>As a simple example, the [[C (programming language)|C]] function <syntaxhighlight lang="C" inline>int f(int x){return x*x-6*x+8;}</syntaxhighlight> consists of only one statement. All tests against a specification <syntaxhighlight lang="C" inline>f(x)>=0</syntaxhighlight> will succeed, except if <syntaxhighlight lang="C" inline>x=3</syntaxhighlight> happens to be chosen.</ref> छद्म-परीक्षण कार्य और विधियाँ वे हैं जो कवर किए गए हैं लेकिन निर्दिष्ट नहीं हैं (बिना किसी परीक्षण मामले को तोड़े उनके शरीर को निकालना संभव है)।<ref name="Vera-PérezDanglot2018">{{Cite journal |last1=Vera-Pérez |first1=Oscar Luis |last2=Danglot |first2=Benjamin |last3=Monperrus |first3=Martin |last4=Baudry |first4=Benoit |year=2018 |title=छद्म परीक्षण विधियों का व्यापक अध्ययन|url=https://hal.archives-ouvertes.fr/hal-01867423/document |journal=Empirical Software Engineering |volume=24 |issue=3 |pages=1195–1225 |arxiv=1807.05030 |bibcode=2018arXiv180705030V |doi=10.1007/s10664-018-9653-2 |s2cid=49744829}}</ref>


==== ब्लैक-बॉक्स परीक्षण ====
==== ब्लैक-बॉक्स परीक्षण ====
Line 91: Line 91:


[[File:Black box diagram.svg|thumb|ब्लैक बॉक्स आरेख]]ब्लैक-बॉक्स परीक्षण (कार्यात्मक परीक्षण के रूप में भी जाना जाता है) सॉफ्टवेयर को ब्लैक बॉक्स के रूप में मानता है, आंतरिक कार्यान्वयन के किसी भी ज्ञान के बिना, स्रोत कोड को देखे बिना कार्यक्षमता की जांच करता है। परीक्षक केवल इस बात से अवगत होते हैं कि सॉफ्टवेयर को क्या करना चाहिए, न कि यह कैसे करता है।<ref name="Patton">{{Cite book |last=Patton |first=Ron |url=https://archive.org/details/softwaretesting0000patt |title=सॉफ्टवेयर परिक्षण|publisher=Sams Publishing |year=2005 |isbn=978-0-672-32798-8 |edition=2nd |location=Indianapolis}}</ref>
[[File:Black box diagram.svg|thumb|ब्लैक बॉक्स आरेख]]ब्लैक-बॉक्स परीक्षण (कार्यात्मक परीक्षण के रूप में भी जाना जाता है) सॉफ्टवेयर को ब्लैक बॉक्स के रूप में मानता है, आंतरिक कार्यान्वयन के किसी भी ज्ञान के बिना, स्रोत कोड को देखे बिना कार्यक्षमता की जांच करता है। परीक्षक केवल इस बात से अवगत होते हैं कि सॉफ्टवेयर को क्या करना चाहिए, न कि यह कैसे करता है।<ref name="Patton">{{Cite book |last=Patton |first=Ron |url=https://archive.org/details/softwaretesting0000patt |title=सॉफ्टवेयर परिक्षण|publisher=Sams Publishing |year=2005 |isbn=978-0-672-32798-8 |edition=2nd |location=Indianapolis}}</ref>


== '''ब्लैक-बॉक्स परीक्षण''' ==
== '''ब्लैक-बॉक्स परीक्षण''' ==
ब्लैक-बॉक्स परीक्षण (कार्यात्मक परीक्षण के रूप में भी जाना जाता है) सॉफ्टवेयर को "ब्लैक बॉक्स" के रूप में मानता है, आंतरिक कार्यान्वयन के किसी भी ज्ञान के बिना और स्रोत कोड को देखे बिना कार्यक्षमता की जांच करता है। परीक्षक केवल इस बात से अवगत होते हैं कि सॉफ्टवेयर को क्या करना चाहिए, न कि यह कैसे करता है। [27] ब्लैक-बॉक्स परीक्षण विधियों में तुल्यता विभाजन, सीमा मूल्य विश्लेषण, सभी जोड़े परीक्षण, राज्य संक्रमण तालिका, निर्णय तालिका परीक्षण, फ़ज़ परीक्षण, मॉडल-आधारित परीक्षण, केस परीक्षण, खोजपूर्ण परीक्षण और विनिर्देश-आधारित परीक्षण शामिल हैं।<ref name="LimayeSoftware09" /><ref name="SalehSoftware09" /><ref name="BlackPragmatic11" />
ब्लैक-बॉक्स परीक्षण (कार्यात्मक परीक्षण के रूप में भी जाना जाता है) सॉफ्टवेयर को "ब्लैक बॉक्स" के रूप में मानता है, आंतरिक कार्यान्वयन के किसी भी ज्ञान के बिना और स्रोत कोड को देखे बिना कार्यक्षमता की जांच करता है। परीक्षक केवल इस बात से अवगत होते हैं कि सॉफ्टवेयर को क्या करना चाहिए, न कि यह कैसे करता है। [27] ब्लैक-बॉक्स परीक्षण विधियों में तुल्यता विभाजन, सीमा मूल्य विश्लेषण, सभी जोड़े परीक्षण, राज्य संक्रमण तालिका, निर्णय तालिका परीक्षण, फ़ज़ परीक्षण, मॉडल-आधारित परीक्षण, केस परीक्षण, खोजपूर्ण परीक्षण और विनिर्देश-आधारित परीक्षण सम्मिलित हैं।<ref name="LimayeSoftware09" /><ref name="SalehSoftware09" /><ref name="BlackPragmatic11" />


विनिर्देश-आधारित परीक्षण का उद्देश्य लागू आवश्यकताओं के अनुसार सॉफ़्टवेयर की कार्यक्षमता का परीक्षण करना है।<ref>{{Cite thesis |last=Laycock |first=Gilbert T. |title=विशिष्टता आधारित सॉफ्टवेयर परीक्षण का सिद्धांत और अभ्यास|degree=dissertation |publisher=Department of Computer Science, [[University of Sheffield]] |url=http://www.cs.le.ac.uk/people/glaycock/thesis.pdf |year=1993 |access-date=January 2, 2018}}</ref> परीक्षण के इस स्तर के लिए आमतौर पर परीक्षक को पूरी तरह से परीक्षण के मामलों की आवश्यकता होती है, जो तब केवल यह सत्यापित कर सकता है कि किसी दिए गए इनपुट के लिए, आउटपुट मान (या व्यवहार), या तो "है" या "नहीं है" अपेक्षित मान के समान परीक्षण के मामले में निर्दिष्ट है।
विनिर्देश-आधारित परीक्षण का उद्देश्य लागू आवश्यकताओं के अनुसार सॉफ़्टवेयर की कार्यक्षमता का परीक्षण करना है।<ref>{{Cite thesis |last=Laycock |first=Gilbert T. |title=विशिष्टता आधारित सॉफ्टवेयर परीक्षण का सिद्धांत और अभ्यास|degree=dissertation |publisher=Department of Computer Science, [[University of Sheffield]] |url=http://www.cs.le.ac.uk/people/glaycock/thesis.pdf |year=1993 |access-date=January 2, 2018}}</ref> परीक्षण के इस स्तर के लिए सामान्यतः परीक्षक को पूरी तरह से परीक्षण के मामलों की आवश्यकता होती है, जो तब केवल यह सत्यापित कर सकता है कि किसी दिए गए इनपुट के लिए, आउटपुट मान (या व्यवहार), या तो "है" या "नहीं है" अपेक्षित मान के समान परीक्षण के मामले में निर्दिष्ट है।


टेस्ट केस विनिर्देशों और आवश्यकताओं के आसपास बनाए जाते हैं, यानी, एप्लिकेशन को क्या करना चाहिए। यह परीक्षण मामलों को प्राप्त करने के लिए विशिष्टताओं, आवश्यकताओं और डिजाइनों सहित सॉफ्टवेयर के बाहरी विवरणों का उपयोग करता है। ये परीक्षण कार्यात्मक परीक्षण या [[गैर-कार्यात्मक परीक्षण]] | गैर-कार्यात्मक हो सकते हैं, हालांकि आमतौर पर कार्यात्मक होते हैं।
टेस्ट केस विनिर्देशों और आवश्यकताओं के आसपास बनाए जाते हैं, यानी, एप्लिकेशन को क्या करना चाहिए। यह परीक्षण मामलों को प्राप्त करने के लिए विशिष्टताओं, आवश्यकताओं और डिजाइनों सहित सॉफ्टवेयर के बाहरी विवरणों का उपयोग करता है। ये परीक्षण कार्यात्मक परीक्षण या [[गैर-कार्यात्मक परीक्षण]] | गैर-कार्यात्मक हो सकते हैं, हालांकि सामान्यतः कार्यात्मक होते हैं।


विशिष्टता-आधारित परीक्षण सही कार्यक्षमता सुनिश्चित करने के लिए आवश्यक हो सकता है, लेकिन यह जटिल या उच्च जोखिम वाली स्थितियों से बचाव के लिए अपर्याप्त है।<ref>{{Cite journal |last=Bach |first=James |author-link=James Bach |date=June 1999 |title=जोखिम और आवश्यकता-आधारित परीक्षण|url=http://www.satisfice.com/articles/requirements_based_testing.pdf |journal=Computer |volume=32 |issue=6 |pages=113–114 |access-date=August 19, 2008}}</ref>ब्लैक बॉक्स तकनीक का एक फायदा यह है कि किसी प्रोग्रामिंग ज्ञान की आवश्यकता नहीं है। प्रोग्रामर के पास जो भी पक्षपात हो सकता है, परीक्षक के पास एक अलग सेट हो सकता है और कार्यक्षमता के विभिन्न क्षेत्रों पर जोर दे सकता है। दूसरी ओर, ब्लैक-बॉक्स परीक्षण को बिना टॉर्च के अंधेरे भूलभुलैया में चलने जैसा कहा गया है।<ref>{{Cite book |last=Savenkov |first=Roman |title=सॉफ्टवेयर टेस्टर कैसे बनें|publisher=Roman Savenkov Consulting |year=2008 |isbn=978-0-615-23372-7 |page=159}}</ref> क्योंकि वे स्रोत कोड की जांच नहीं करते हैं, ऐसे हालात होते हैं जब एक परीक्षक किसी चीज की जांच करने के लिए कई परीक्षण मामलों को लिखता है जो कि केवल एक परीक्षण मामले द्वारा परीक्षण किया जा सकता था या कार्यक्रम के कुछ हिस्सों को छोड़ देता है।
विशिष्टता-आधारित परीक्षण सही कार्यक्षमता सुनिश्चित करने के लिए आवश्यक हो सकता है, लेकिन यह जटिल या उच्च जोखिम वाली स्थितियों से बचाव के लिए अपर्याप्त है।<ref>{{Cite journal |last=Bach |first=James |author-link=James Bach |date=June 1999 |title=जोखिम और आवश्यकता-आधारित परीक्षण|url=http://www.satisfice.com/articles/requirements_based_testing.pdf |journal=Computer |volume=32 |issue=6 |pages=113–114 |access-date=August 19, 2008}}</ref>ब्लैक बॉक्स तकनीक का एक फायदा यह है कि किसी प्रोग्रामिंग ज्ञान की आवश्यकता नहीं है। प्रोग्रामर के पास जो भी पक्षपात हो सकता है, परीक्षक के पास अलग सेट हो सकता है और कार्यक्षमता के विभिन्न क्षेत्रों पर जोर दे सकता है। दूसरी ओर, ब्लैक-बॉक्स परीक्षण को बिना टॉर्च के अंधेरे भूलभुलैया में चलने जैसा कहा गया है।<ref>{{Cite book |last=Savenkov |first=Roman |title=सॉफ्टवेयर टेस्टर कैसे बनें|publisher=Roman Savenkov Consulting |year=2008 |isbn=978-0-615-23372-7 |page=159}}</ref> क्योंकि वे स्रोत कोड की जांच नहीं करते हैं, ऐसे हालात होते हैं जब एक परीक्षक किसी चीज की जांच करने के लिए कई परीक्षण मामलों को लिखता है जो कि केवल एक परीक्षण मामले द्वारा परीक्षण किया जा सकता था या कार्यक्रम के कुछ हिस्सों को छोड़ देता है।


परीक्षण का यह तरीका सॉफ्टवेयर परीक्षण के सभी स्तरों पर लागू किया जा सकता है: इकाई परीक्षण, एकीकरण परीक्षण, सिस्टम परीक्षण और स्वीकृति परीक्षण।<ref name="AmmannIntro16" />यह आम तौर पर उच्च स्तर पर सभी परीक्षण नहीं होने पर सबसे अधिक शामिल होता है, लेकिन यूनिट परीक्षण पर भी हावी हो सकता है।
परीक्षण का यह तरीका सॉफ्टवेयर परीक्षण के सभी स्तरों पर लागू किया जा सकता है: इकाई परीक्षण, एकीकरण परीक्षण, सिस्टम परीक्षण और स्वीकृति परीक्षण।<ref name="AmmannIntro16" />यह सामान्यतः उच्च स्तर पर सभी परीक्षण नहीं होने पर सबसे अधिक सम्मिलित होता है, लेकिन यूनिट परीक्षण पर भी हावी हो सकता है।


== घटक (कम्पोनेंट) इंटरफ़ेस परीक्षण ==
== घटक (कम्पोनेंट) इंटरफ़ेस परीक्षण ==
घटक इंटरफ़ेस परीक्षण ब्लैक-बॉक्स परीक्षण का एक प्रकार है, जिसमें सबसिस्टम घटक की संबंधित क्रियाओं से परे डेटा मूल्यों पर ध्यान केंद्रित किया जाता है।<ref name="MathurFound11-63" /> घटक इंटरफ़ेस परीक्षण के अभ्यास का उपयोग उन इकाइयों के बीच पूर्ण एकीकरण परीक्षण से परे, विभिन्न इकाइयों, या सबसिस्टम घटकों के बीच पारित डेटा के प्रबंधन की जांच के लिए किया जा सकता है।<ref name="Clapp" /><ref name="Mathur" /> पारित होने वाले डेटा को "संदेश पैकेट" के रूप में माना जा सकता है और एक इकाई से उत्पन्न डेटा के लिए श्रेणी या डेटा प्रकार की जांच की जा सकती है, और किसी अन्य इकाई में पारित होने से पहले वैधता के लिए परीक्षण किया जा सकता है। इंटरफ़ेस परीक्षण के लिए एक विकल्प पास किए जा रहे डेटा आइटम की एक अलग लॉग फ़ाइल रखना है, अक्सर टाइमस्टैम्प लॉग के साथ दिनों या हफ्तों के लिए इकाइयों के बीच डेटा के हजारों मामलों के विश्लेषण की अनुमति देता है। टेस्ट में कुछ एक्सट्रीम डेटा मानों के प्रबंधन की जांच शामिल हो सकती है जबकि अन्य इंटरफ़ेस चर सामान्य मान के रूप में पारित किए जाते हैं। [32] इंटरफ़ेस में असामान्य डेटा मान अगली इकाई में अनपेक्षित प्रदर्शन की व्याख्या करने में सहायता कर सकते हैं।
घटक इंटरफ़ेस परीक्षण ब्लैक-बॉक्स परीक्षण का एक प्रकार है, जिसमें सबसिस्टम घटक की संबंधित क्रियाओं से परे डेटा मूल्यों पर ध्यान केंद्रित किया जाता है।<ref name="MathurFound11-63" /> घटक इंटरफ़ेस परीक्षण के अभ्यास का उपयोग उन इकाइयों के बीच पूर्ण एकीकरण परीक्षण से परे, विभिन्न इकाइयों, या सबसिस्टम घटकों के बीच पारित डेटा के प्रबंधन की जांच के लिए किया जा सकता है।<ref name="Clapp" /><ref name="Mathur" /> पारित होने वाले डेटा को "संदेश पैकेट" के रूप में माना जा सकता है और एक इकाई से उत्पन्न डेटा के लिए श्रेणी या डेटा प्रकार की जांच की जा सकती है, और किसी अन्य इकाई में पारित होने से पहले वैधता के लिए परीक्षण किया जा सकता है। इंटरफ़ेस परीक्षण के लिए एक विकल्प पास किए जा रहे डेटा आइटम की एक अलग लॉग फ़ाइल रखना है, प्रायः टाइमस्टैम्प लॉग के साथ दिनों या हफ्तों के लिए इकाइयों के बीच डेटा के हजारों मामलों के विश्लेषण की अनुमति देता है। टेस्ट में कुछ एक्सट्रीम डेटा मानों के प्रबंधन की जांच सम्मिलित हो सकती है जबकि अन्य इंटरफ़ेस चर सामान्य मान के रूप में पारित किए जाते हैं। [32] इंटरफ़ेस में असामान्य डेटा मान अगली इकाई में अनपेक्षित प्रदर्शन की व्याख्या करने में सहायता कर सकते हैं।


घटक इंटरफ़ेस परीक्षण [[ब्लैक-बॉक्स परीक्षण]] का एक रूप है, जिसमें सबसिस्टम घटक की संबंधित क्रियाओं से परे डेटा मानों पर ध्यान केंद्रित किया जाता है।<ref name="MathurFound11-63">{{Cite book |last=Mathur, A.P. |url=https://books.google.com/books?id=hyaQobu44xUC&pg=PA18 |title=सॉफ्टवेयर परीक्षण की नींव|publisher=Pearson Education India |year=2011 |isbn=978-81-317-5908-0 |page=63}}</ref> घटक इंटरफ़ेस परीक्षण के अभ्यास का उपयोग उन इकाइयों के बीच पूर्ण एकीकरण परीक्षण से परे, विभिन्न इकाइयों, या सबसिस्टम घटकों के बीच पारित डेटा के प्रबंधन की जांच के लिए किया जा सकता है।<ref name="Clapp">{{Cite book |last=Clapp |first=Judith A. |url=https://books.google.com/books?id=wAq0rnyiGMEC&pg=PA313 |title=सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण|year=1995 |isbn=978-0-8155-1363-6 |page=313 |access-date=January 5, 2018}}</ref><ref name="Mathur">{{Cite book |last=Mathur |first=Aditya P. |url=https://books.google.com/books?id=yU-rTcurys8C&pg=PR38 |title=सॉफ्टवेयर परीक्षण की नींव|publisher=Pearson Education India |year=2007 |isbn=978-81-317-1660-1 |page=18}}</ref> पारित होने वाले डेटा को संदेश पैकेट के रूप में माना जा सकता है और एक इकाई से उत्पन्न डेटा के लिए श्रेणी या डेटा प्रकार की जांच की जा सकती है, और किसी अन्य इकाई में पारित होने से पहले वैधता के लिए परीक्षण किया जा सकता है। इंटरफ़ेस परीक्षण के लिए एक विकल्प डेटा आइटम की एक अलग लॉग फ़ाइल को पास करना है, अक्सर टाइमस्टैम्प लॉग के साथ दिनों या हफ्तों के लिए इकाइयों के बीच डेटा के हजारों मामलों के विश्लेषण की अनुमति देता है। टेस्ट में कुछ चरम डेटा मानों की हैंडलिंग की जांच शामिल हो सकती है जबकि अन्य इंटरफ़ेस चर सामान्य मान के रूप में पारित किए जाते हैं।<ref name=Clapp/> इंटरफ़ेस में असामान्य डेटा मान अगली इकाई में अनपेक्षित प्रदर्शन की व्याख्या करने में सहायता कर सकते हैं।
घटक इंटरफ़ेस परीक्षण [[ब्लैक-बॉक्स परीक्षण]] का एक रूप है, जिसमें सबसिस्टम घटक की संबंधित क्रियाओं से परे डेटा मानों पर ध्यान केंद्रित किया जाता है।<ref name="MathurFound11-63">{{Cite book |last=Mathur, A.P. |url=https://books.google.com/books?id=hyaQobu44xUC&pg=PA18 |title=सॉफ्टवेयर परीक्षण की नींव|publisher=Pearson Education India |year=2011 |isbn=978-81-317-5908-0 |page=63}}</ref> घटक इंटरफ़ेस परीक्षण के अभ्यास का उपयोग उन इकाइयों के बीच पूर्ण एकीकरण परीक्षण से परे, विभिन्न इकाइयों, या सबसिस्टम घटकों के बीच पारित डेटा के प्रबंधन की जांच के लिए किया जा सकता है।<ref name="Clapp">{{Cite book |last=Clapp |first=Judith A. |url=https://books.google.com/books?id=wAq0rnyiGMEC&pg=PA313 |title=सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण|year=1995 |isbn=978-0-8155-1363-6 |page=313 |access-date=January 5, 2018}}</ref><ref name="Mathur">{{Cite book |last=Mathur |first=Aditya P. |url=https://books.google.com/books?id=yU-rTcurys8C&pg=PR38 |title=सॉफ्टवेयर परीक्षण की नींव|publisher=Pearson Education India |year=2007 |isbn=978-81-317-1660-1 |page=18}}</ref> पारित होने वाले डेटा को संदेश पैकेट के रूप में माना जा सकता है और एक इकाई से उत्पन्न डेटा के लिए श्रेणी या डेटा प्रकार की जांच की जा सकती है, और किसी अन्य इकाई में पारित होने से पहले वैधता के लिए परीक्षण किया जा सकता है। इंटरफ़ेस परीक्षण के लिए विकल्प डेटा आइटम की एक अलग लॉग फ़ाइल को पास करना है, प्रायः टाइमस्टैम्प लॉग के साथ दिनों या हफ्तों के लिए इकाइयों के बीच डेटा के हजारों मामलों के विश्लेषण की अनुमति देता है। टेस्ट में कुछ चरम डेटा मानों की हैंडलिंग की जांच सम्मिलित हो सकती है जबकि अन्य इंटरफ़ेस चर सामान्य मान के रूप में पारित किए जाते हैं।<ref name=Clapp/> इंटरफ़ेस में असामान्य डेटा मान अगली इकाई में अनपेक्षित प्रदर्शन की व्याख्या करने में सहायता कर सकते हैं।


===== विजुअल परीक्षण =====
===== विजुअल परीक्षण =====
Line 121: Line 132:
==== ग्रे-बॉक्स परीक्षण ====
==== ग्रे-बॉक्स परीक्षण ====
{{main|ग्रे-बॉक्स परीक्षण}}
{{main|ग्रे-बॉक्स परीक्षण}}
ग्रे-बॉक्स परीक्षण (अमेरिकी वर्तनी: ग्रे-बॉक्स परीक्षण) में उपयोगकर्ता या ब्लैक-बॉक्स स्तर पर उन परीक्षणों को निष्पादित करते समय परीक्षणों को डिजाइन करने के उद्देश्यों के लिए आंतरिक डेटा संरचनाओं और एल्गोरिदम का ज्ञान होना शामिल है। परीक्षक के पास अक्सर स्रोत कोड और निष्पादन योग्य बाइनरी दोनों तक पहुंच होगी।<ref name="RansomeCore13">{{Cite book |last1=Ransome, J. |url=https://books.google.com/books?id=MX5cAgAAQBAJ&pg=PA140 |title=कोर सॉफ्टवेयर सुरक्षा: स्रोत पर सुरक्षा|last2=Misra, A. |publisher=CRC Press |year=2013 |isbn=978-1-4665-6095-6 |pages=140–3}}</ref> उदाहरण के लिए, सीमा मान या त्रुटि संदेशों को निर्धारित करने के लिए ग्रे-बॉक्स परीक्षण में [[रिवर्स कोडिंग]] (गतिशील कोड विश्लेषण का उपयोग करके) भी शामिल हो सकता है।<ref name="RansomeCore13" />इनपुट डेटा में हेरफेर करना और आउटपुट को स्वरूपित करना ग्रे-बॉक्स के रूप में योग्य नहीं है, क्योंकि इनपुट और आउटपुट स्पष्ट रूप से ब्लैक बॉक्स के बाहर हैं जिसे हम परीक्षण के तहत सिस्टम कह रहे हैं। दो अलग-अलग डेवलपर्स द्वारा लिखे गए कोड के दो मॉड्यूल के बीच एकीकरण परीक्षण करते समय यह अंतर विशेष रूप से महत्वपूर्ण है, जहां परीक्षण के लिए केवल इंटरफेस का खुलासा किया जाता है।
ग्रे-बॉक्स परीक्षण (अमेरिकी वर्तनी: ग्रे-बॉक्स परीक्षण) में उपयोगकर्ता या ब्लैक-बॉक्स स्तर पर उन परीक्षणों को निष्पादित करते समय परीक्षणों को डिजाइन करने के उद्देश्यों के लिए आंतरिक डेटा संरचनाओं और एल्गोरिदम का ज्ञान होना सम्मिलित है। परीक्षक के पास प्रायः स्रोत कोड और निष्पादन योग्य बाइनरी दोनों तक पहुंच होगी।<ref name="RansomeCore13">{{Cite book |last1=Ransome, J. |url=https://books.google.com/books?id=MX5cAgAAQBAJ&pg=PA140 |title=कोर सॉफ्टवेयर सुरक्षा: स्रोत पर सुरक्षा|last2=Misra, A. |publisher=CRC Press |year=2013 |isbn=978-1-4665-6095-6 |pages=140–3}}</ref> उदाहरण के लिए, सीमा मान या त्रुटि संदेशों को निर्धारित करने के लिए ग्रे-बॉक्स परीक्षण में [[रिवर्स कोडिंग]] (गतिशील कोड विश्लेषण का उपयोग करके) भी सम्मिलित हो सकता है।<ref name="RansomeCore13" />इनपुट डेटा में हेरफेर करना और आउटपुट को स्वरूपित करना ग्रे-बॉक्स के रूप में योग्य नहीं है, क्योंकि इनपुट और आउटपुट स्पष्ट रूप से ब्लैक बॉक्स के बाहर हैं जिसे हम परीक्षण के तहत सिस्टम कह रहे हैं। दो अलग-अलग डेवलपर्स द्वारा लिखे गए कोड के दो मॉड्यूल के बीच एकीकरण परीक्षण करते समय यह अंतर विशेष रूप से महत्वपूर्ण है, जहां परीक्षण के लिए केवल इंटरफेस का खुलासा किया जाता है।


सॉफ़्टवेयर कैसे काम करता है, इसकी अंतर्निहित अवधारणाओं को जानकर, परीक्षक बाहर से सॉफ़्टवेयर का परीक्षण करते समय बेहतर-सूचित परीक्षण विकल्प बनाता है। आमतौर पर, एक ग्रे-बॉक्स टेस्टर को [[डेटाबेस]] सीडिंग जैसी गतिविधियों के साथ एक पृथक परीक्षण वातावरण स्थापित करने की अनुमति दी जाएगी। परीक्षक कुछ क्रियाओं को करने के बाद परीक्षण किए जा रहे उत्पाद की स्थिति का निरीक्षण कर सकता है जैसे कि डेटाबेस के विरुद्ध [[SQL]] कथनों को निष्पादित करना और फिर यह सुनिश्चित करने के लिए प्रश्नों को निष्पादित करना कि अपेक्षित परिवर्तन परिलक्षित हुए हैं। ग्रे-बॉक्स परीक्षण सीमित जानकारी के आधार पर बुद्धिमान परीक्षण परिदृश्यों को लागू करता है। यह विशेष रूप से डेटा टाइप हैंडलिंग, अपवाद हैंडलिंग आदि पर लागू होगा।<ref name="ref4">{{Cite web |title=ब्लैक, व्हाइट और ग्रे बॉक्स के लिए SOA टेस्टिंग टूल्स|url=http://www.crosschecknet.com/soa_testing_black_white_gray_box.php |archive-url=https://web.archive.org/web/20181001010542/http://www.crosschecknet.com:80/soa_testing_black_white_gray_box.php |archive-date=October 1, 2018 |access-date=December 10, 2012 |publisher=Crosscheck Networks |type=white paper}}</ref>
सॉफ़्टवेयर कैसे काम करता है, इसकी अंतर्निहित अवधारणाओं को जानकर, परीक्षक बाहर से सॉफ़्टवेयर का परीक्षण करते समय बेहतर-सूचित परीक्षण विकल्प बनाता है। सामान्यतः, एक ग्रे-बॉक्स टेस्टर को [[डेटाबेस]] सीडिंग जैसी गतिविधियों के साथ एक पृथक परीक्षण वातावरण स्थापित करने की अनुमति दी जाएगी। परीक्षक कुछ क्रियाओं को करने के बाद परीक्षण किए जा रहे उत्पाद की स्थिति का निरीक्षण कर सकता है जैसे कि डेटाबेस के विरुद्ध [[SQL]] कथनों को निष्पादित करना और फिर यह सुनिश्चित करने के लिए प्रश्नों को निष्पादित करना कि अपेक्षित परिवर्तन परिलक्षित हुए हैं। ग्रे-बॉक्स परीक्षण सीमित जानकारी के आधार पर बुद्धिमान परीक्षण परिदृश्यों को लागू करता है। यह विशेष रूप से डेटा टाइप हैंडलिंग, अपवाद हैंडलिंग आदि पर लागू होगा।<ref name="ref4">{{Cite web |title=ब्लैक, व्हाइट और ग्रे बॉक्स के लिए SOA टेस्टिंग टूल्स|url=http://www.crosschecknet.com/soa_testing_black_white_gray_box.php |archive-url=https://web.archive.org/web/20181001010542/http://www.crosschecknet.com:80/soa_testing_black_white_gray_box.php |archive-date=October 1, 2018 |access-date=December 10, 2012 |publisher=Crosscheck Networks |type=white paper}}</ref>
== परीक्षण स्तर ==
== परीक्षण स्तर ==


मोटे तौर पर, परीक्षण के कम से कम तीन स्तर हैं: इकाई परीक्षण, एकीकरण परीक्षण और सिस्टम परीक्षण।<ref name="Computer.org">{{Cite book |title=ज्ञान के सॉफ्टवेयर इंजीनियरिंग निकाय के लिए गाइड|publisher=IEEE Computer Society |year=2014 |isbn=978-0-7695-5166-1 |editor-last=Bourque |editor-first=Pierre |series=3.0 |chapter=Chapter 5 |access-date=January 2, 2018 |editor-last2=Fairley |editor-first2=Richard E. |chapter-url=https://www.computer.org/web/swebok/v3}}</ref><ref name="BourqueSWEBOK14-4">{{Cite book |title=SWEBOK v3.0: सॉफ़्टवेयर इंजीनियरिंग बॉडी ऑफ़ नॉलेज के लिए गाइड|publisher=IEEE |year=2014 |isbn=978-0-7695-5166-1 |editor-last=Bourque, P. |pages=4–1–4–17 |chapter=Chapter 4: Software Testing |access-date=July 13, 2018 |editor-last2=Fairley, R.D. |chapter-url=http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf |archive-date=June 19, 2018 |archive-url=https://web.archive.org/web/20180619003324/http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf |url-status=dead }}</ref><ref name="DooleySoftware11">{{Cite book |last=Dooley, J. |url=https://books.google.com/books?id=iOqP9_6w-18C&pg=PA193 |title=सॉफ्टवेयर विकास और व्यावसायिक अभ्यास|publisher=APress |year=2011 |isbn=978-1-4302-3801-0 |pages=193–4}}</ref><ref name="WiegersCreating13">{{Cite book |last=Wiegers, K. |url=https://books.google.com/books?id=uVsUAAAAQBAJ&pg=PA212 |title=एक सॉफ्टवेयर इंजीनियरिंग संस्कृति बनाना|publisher=Addison-Wesley |year=2013 |isbn=978-0-13-348929-3 |pages=211–2}}</ref> हालाँकि, एक चौथा स्तर, स्वीकृति परीक्षण, डेवलपर्स द्वारा शामिल किया जा सकता है। यह परिचालन स्वीकृति परीक्षण के रूप में हो सकता है या सरल एंड-यूज़र (बीटा) परीक्षण हो सकता है, यह सुनिश्चित करने के लिए परीक्षण कि सॉफ्टवेयर कार्यात्मक अपेक्षाओं को पूरा करता है।<ref name="LewisSoftware16-2" /><ref name="BorbaTesting10">{{Cite book |last1=Machado, P. |title=सॉफ्टवेयर इंजीनियरिंग में परीक्षण तकनीक|last2=Vincenzi, A. |last3=Maldonado, J.C. |publisher=Springer Science & Business Media |year=2010 |isbn=978-3-642-14334-2 |editor-last=Borba, P. |pages=13–14 |chapter=Chapter 1: Software Testing: An Overview |editor-last2=Cavalcanti, A. |editor-last3=Sampaio, A. |editor-last4=Woodcook, J. |chapter-url=https://books.google.com/books?id=ZOHrm02GFCEC&pg=PA13}}</ref><ref name="ClappSoftware95">{{Cite book |last1=Clapp, J.A. |url=https://books.google.com/books?id=wAq0rnyiGMEC&pg=PA254 |title=सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण|last2=Stanten, S.F. |last3=Peng, W.W. |publisher=Nova Data Corporation |year=1995 |isbn=978-0-8155-1363-6 |page=254 |display-authors=et al}}</ref> आईएसटीक्यूबी सर्टिफाइड टेस्ट फाउंडेशन लेवल सिलेबस के आधार पर, टेस्ट लेवल में वे चार लेवल शामिल होते हैं, और चौथे लेवल को एक्सेप्टेंस टेस्टिंग कहा जाता है।<ref name=":0">{{Cite web |title=आईएसटीक्यूबी सीटीएफएल पाठ्यक्रम 2018|url=https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB-CTFL_Syllabus_2018_v3.1.1.pdf |website=ISTQB - International Software Testing Qualifications Board |url-status=live |archive-url=https://web.archive.org/web/20220324091506/https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB-CTFL_Syllabus_2018_v3.1.1.pdf |archive-date=2022-03-24 |access-date=2022-04-11}}</ref> परीक्षणों को अक्सर इन स्तरों में से एक में समूहीकृत किया जाता है, जहां उन्हें सॉफ्टवेयर डेवलपमेंट प्रोसेस में जोड़ा जाता है, या टेस्ट की विशिष्टता के स्तर के अनुसार।
मोटे तौर पर, परीक्षण के कम से कम तीन स्तर हैं: इकाई परीक्षण, एकीकरण परीक्षण और सिस्टम परीक्षण।<ref name="Computer.org">{{Cite book |title=ज्ञान के सॉफ्टवेयर इंजीनियरिंग निकाय के लिए गाइड|publisher=IEEE Computer Society |year=2014 |isbn=978-0-7695-5166-1 |editor-last=Bourque |editor-first=Pierre |series=3.0 |chapter=Chapter 5 |access-date=January 2, 2018 |editor-last2=Fairley |editor-first2=Richard E. |chapter-url=https://www.computer.org/web/swebok/v3}}</ref><ref name="BourqueSWEBOK14-4">{{Cite book |title=SWEBOK v3.0: सॉफ़्टवेयर इंजीनियरिंग बॉडी ऑफ़ नॉलेज के लिए गाइड|publisher=IEEE |year=2014 |isbn=978-0-7695-5166-1 |editor-last=Bourque, P. |pages=4–1–4–17 |chapter=Chapter 4: Software Testing |access-date=July 13, 2018 |editor-last2=Fairley, R.D. |chapter-url=http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf |archive-date=June 19, 2018 |archive-url=https://web.archive.org/web/20180619003324/http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf |url-status=dead }}</ref><ref name="DooleySoftware11">{{Cite book |last=Dooley, J. |url=https://books.google.com/books?id=iOqP9_6w-18C&pg=PA193 |title=सॉफ्टवेयर विकास और व्यावसायिक अभ्यास|publisher=APress |year=2011 |isbn=978-1-4302-3801-0 |pages=193–4}}</ref><ref name="WiegersCreating13">{{Cite book |last=Wiegers, K. |url=https://books.google.com/books?id=uVsUAAAAQBAJ&pg=PA212 |title=एक सॉफ्टवेयर इंजीनियरिंग संस्कृति बनाना|publisher=Addison-Wesley |year=2013 |isbn=978-0-13-348929-3 |pages=211–2}}</ref> हालाँकि, एक चौथा स्तर, स्वीकृति परीक्षण, डेवलपर्स द्वारा सम्मिलित किया जा सकता है। यह परिचालन स्वीकृति परीक्षण के रूप में हो सकता है या सरल एंड-यूज़र (बीटा) परीक्षण हो सकता है, यह सुनिश्चित करने के लिए परीक्षण कि सॉफ्टवेयर कार्यात्मक अपेक्षाओं को पूरा करता है।<ref name="LewisSoftware16-2" /><ref name="BorbaTesting10">{{Cite book |last1=Machado, P. |title=सॉफ्टवेयर इंजीनियरिंग में परीक्षण तकनीक|last2=Vincenzi, A. |last3=Maldonado, J.C. |publisher=Springer Science & Business Media |year=2010 |isbn=978-3-642-14334-2 |editor-last=Borba, P. |pages=13–14 |chapter=Chapter 1: Software Testing: An Overview |editor-last2=Cavalcanti, A. |editor-last3=Sampaio, A. |editor-last4=Woodcook, J. |chapter-url=https://books.google.com/books?id=ZOHrm02GFCEC&pg=PA13}}</ref><ref name="ClappSoftware95">{{Cite book |last1=Clapp, J.A. |url=https://books.google.com/books?id=wAq0rnyiGMEC&pg=PA254 |title=सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण|last2=Stanten, S.F. |last3=Peng, W.W. |publisher=Nova Data Corporation |year=1995 |isbn=978-0-8155-1363-6 |page=254 |display-authors=et al}}</ref> आईएसटीक्यूबी सर्टिफाइड टेस्ट फाउंडेशन लेवल सिलेबस के आधार पर, टेस्ट लेवल में वे चार लेवल सम्मिलित होते हैं, और चौथे लेवल को एक्सेप्टेंस टेस्टिंग कहा जाता है।<ref name=":0">{{Cite web |title=आईएसटीक्यूबी सीटीएफएल पाठ्यक्रम 2018|url=https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB-CTFL_Syllabus_2018_v3.1.1.pdf |website=ISTQB - International Software Testing Qualifications Board |url-status=live |archive-url=https://web.archive.org/web/20220324091506/https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB-CTFL_Syllabus_2018_v3.1.1.pdf |archive-date=2022-03-24 |access-date=2022-04-11}}</ref> परीक्षणों को प्रायः इन स्तरों में से एक में समूहीकृत किया जाता है, जहां उन्हें सॉफ्टवेयर डेवलपमेंट प्रोसेस में जोड़ा जाता है, या टेस्ट की विशिष्टता के स्तर के अनुसार।


=== यूनिट परीक्षण ===
=== यूनिट परीक्षण ===
{{Main|यूनिट परीक्षण}}
{{Main|यूनिट परीक्षण}}


यूनिट परीक्षण उन परीक्षणों को संदर्भित करता है जो कोड के एक विशिष्ट खंड की कार्यक्षमता को सत्यापित करते हैं, आमतौर पर फ़ंक्शन स्तर पर। एक वस्तु-उन्मुख वातावरण में, यह आमतौर पर वर्ग स्तर पर होता है, और न्यूनतम इकाई परीक्षणों में निर्माणकर्ता और विध्वंसक शामिल होते हैं।<ref>{{Cite book |last=Binder |first=Robert V. |url=https://archive.org/details/testingobjectori00bind/page/45 |title=टेस्टिंग ऑब्जेक्ट-ओरिएंटेड सिस्टम्स: ऑब्जेक्ट्स, पैटर्न्स एंड टूल्स|publisher=Addison-Wesley Professional |year=1999 |isbn=978-0-201-80938-1 |page=[https://archive.org/details/testingobjectori00bind/page/45 45]}}</ref>
यूनिट परीक्षण उन परीक्षणों को संदर्भित करता है जो कोड के विशिष्ट खंड की कार्यक्षमता को सत्यापित करते हैं, सामान्यतः फ़ंक्शन स्तर पर। वस्तु-उन्मुख वातावरण में, यह सामान्यतः वर्ग स्तर पर होता है, और न्यूनतम इकाई परीक्षणों में निर्माणकर्ता और विध्वंसक सम्मिलित होते हैं।<ref>{{Cite book |last=Binder |first=Robert V. |url=https://archive.org/details/testingobjectori00bind/page/45 |title=टेस्टिंग ऑब्जेक्ट-ओरिएंटेड सिस्टम्स: ऑब्जेक्ट्स, पैटर्न्स एंड टूल्स|publisher=Addison-Wesley Professional |year=1999 |isbn=978-0-201-80938-1 |page=[https://archive.org/details/testingobjectori00bind/page/45 45]}}</ref>


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


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


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


=== एकीकरण परीक्षण ===
=== एकीकरण परीक्षण ===
{{Main|एकीकरण परीक्षण}}
{{Main|एकीकरण परीक्षण}}
एकीकरण परीक्षण किसी भी प्रकार का सॉफ़्टवेयर परीक्षण है जो सॉफ़्टवेयर डिज़ाइन के विरुद्ध घटकों के बीच इंटरफेस को सत्यापित करने का प्रयास करता है। सॉफ़्टवेयर घटकों को पुनरावृत्त तरीके से या सभी को एक साथ (बिग बैंग) एकीकृत किया जा सकता है। आम तौर पर पूर्व को एक बेहतर अभ्यास माना जाता है क्योंकि यह इंटरफ़ेस के मुद्दों को अधिक तेज़ी से और ठीक करने की अनुमति देता है।
एकीकरण परीक्षण किसी भी प्रकार का सॉफ़्टवेयर परीक्षण है जो सॉफ़्टवेयर डिज़ाइन के विरुद्ध घटकों के बीच इंटरफेस को सत्यापित करने का प्रयास करता है। सॉफ़्टवेयर घटकों को पुनरावृत्त तरीके से या सभी को एक साथ (बिग बैंग) एकीकृत किया जा सकता है। सामान्यतः पूर्व को एक बेहतर अभ्यास माना जाता है क्योंकि यह इंटरफ़ेस के मुद्दों को अधिक तेज़ी से और ठीक करने की अनुमति देता है।


एकीकरण परीक्षण इंटरफेस और एकीकृत घटकों (मॉड्यूल) के बीच बातचीत में दोषों को उजागर करने के लिए काम करता है। आर्किटेक्चरल डिज़ाइन के तत्वों के अनुरूप परीक्षण किए गए सॉफ़्टवेयर घटकों के उत्तरोत्तर बड़े समूहों को तब तक एकीकृत और परीक्षण किया जाता है जब तक कि सॉफ़्टवेयर सिस्टम के रूप में काम नहीं करता।<ref>{{Cite book |last=Beizer |first=Boris |title=सॉफ्टवेयर परीक्षण तकनीक|publisher=Van Nostrand Reinhold |year=1990 |isbn=978-0-442-20672-7 |edition=Second |location=New York |pages=21,430 |author-link=Boris Beizer}}</ref>
एकीकरण परीक्षण इंटरफेस और एकीकृत घटकों (मॉड्यूल) के बीच बातचीत में दोषों को उजागर करने के लिए काम करता है। आर्किटेक्चरल डिज़ाइन के तत्वों के अनुरूप परीक्षण किए गए सॉफ़्टवेयर घटकों के उत्तरोत्तर बड़े समूहों को तब तक एकीकृत और परीक्षण किया जाता है जब तक कि सॉफ़्टवेयर सिस्टम के रूप में काम नहीं करता है।<ref>{{Cite book |last=Beizer |first=Boris |title=सॉफ्टवेयर परीक्षण तकनीक|publisher=Van Nostrand Reinhold |year=1990 |isbn=978-0-442-20672-7 |edition=Second |location=New York |pages=21,430 |author-link=Boris Beizer}}</ref>


एकीकरण परीक्षणों में आमतौर पर बहुत सारे कोड शामिल होते हैं, और ऐसे अंश उत्पन्न करते हैं जो इकाई परीक्षणों द्वारा उत्पादित किए गए से बड़े होते हैं। एकीकरण परीक्षण विफल होने पर गलती को स्थानीयकृत करने में आसानी पर इसका प्रभाव पड़ता है। इस मुद्दे को दूर करने के लिए, दोष स्थानीयकरण में सुधार के लिए बड़े परीक्षणों को स्वचालित रूप से छोटे टुकड़ों में काटने का प्रस्ताव दिया गया है।<ref>{{Cite journal |last1=Xuan |first1=Jifeng |last2=Monperrus |first2=Martin |date=2014 |title=गलती स्थानीयकरण में सुधार के लिए टेस्ट केस शुद्धि|journal=Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2014 |pages=52–63 |arxiv=1409.3176 |bibcode=2014arXiv1409.3176X |doi=10.1145/2635868.2635906 |isbn=978-1-4503-3056-5 |s2cid=14540841}}</ref>
एकीकरण परीक्षणों में सामान्यतः बहुत सारे कोड सम्मिलित होते हैं, और ऐसे अंश उत्पन्न करते हैं जो इकाई परीक्षणों द्वारा उत्पादित किए गए से बड़े होते हैं। एकीकरण परीक्षण विफल होने पर गलती को स्थानीयकृत करने में आसानी पर इसका प्रभाव पड़ता है। इस मुद्दे को दूर करने के लिए, दोष स्थानीयकरण में सुधार के लिए बड़े परीक्षणों को स्वचालित रूप से छोटे टुकड़ों में काटने का प्रस्ताव दिया गया है।<ref>{{Cite journal |last1=Xuan |first1=Jifeng |last2=Monperrus |first2=Martin |date=2014 |title=गलती स्थानीयकरण में सुधार के लिए टेस्ट केस शुद्धि|journal=Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2014 |pages=52–63 |arxiv=1409.3176 |bibcode=2014arXiv1409.3176X |doi=10.1145/2635868.2635906 |isbn=978-1-4503-3056-5 |s2cid=14540841}}</ref>
=== सिस्टम परीक्षण ===
=== सिस्टम परीक्षण ===
{{Main|सिस्टम परीक्षण}}
{{Main|सिस्टम परीक्षण}}
सिस्टम परीक्षण यह सत्यापित करने के लिए पूरी तरह से एकीकृत प्रणाली का परीक्षण करता है कि सिस्टम अपनी आवश्यकताओं को पूरा करता है।<ref name=IEEEglossary/> उदाहरण के लिए, एक सिस्टम परीक्षण में एक लॉगिन इंटरफ़ेस का परीक्षण करना, फिर एक प्रविष्टि बनाना और संपादित करना, साथ ही भेजने या प्रिंट करने के परिणाम शामिल हो सकते हैं, इसके बाद प्रविष्टियों का सारांश प्रसंस्करण या विलोपन (या संग्रह), फिर लॉगऑफ़।
सिस्टम परीक्षण यह सत्यापित करने के लिए पूरी तरह से एकीकृत प्रणाली का परीक्षण करता है कि सिस्टम अपनी आवश्यकताओं को पूरा करता है।<ref name=IEEEglossary/> उदाहरण के लिए, एक सिस्टम परीक्षण में एक लॉगिन इंटरफ़ेस का परीक्षण करना, फिर एक प्रविष्टि बनाना और संपादित करना, साथ ही भेजने या प्रिंट करने के परिणाम सम्मिलित हो सकते हैं, इसके बाद प्रविष्टियों का सारांश प्रसंस्करण या विलोपन (या संग्रह), फिर लॉगऑफ़।


=== स्वीकार्यता परीक्षण ===
=== स्वीकार्यता परीक्षण ===
{{Main|स्वीकार्यता परीक्षण}}
{{Main|स्वीकार्यता परीक्षण}}
स्वीकृति परीक्षण में आमतौर पर निम्नलिखित चार प्रकार शामिल होते हैं:<ref name=":0" />
स्वीकृति परीक्षण में सामान्यतः निम्नलिखित चार प्रकार सम्मिलित होते हैं:<ref name=":0" />


* उपयोगकर्ता स्वीकृति परीक्षण (यूएटी)
* उपयोगकर्ता स्वीकृति परीक्षण (यूएटी)
Line 170: Line 181:
अलग-अलग लेबल और समूहीकरण परीक्षण के तरीके परीक्षण प्रकार, सॉफ़्टवेयर परीक्षण रणनीति या तकनीक हो सकते हैं।<ref>{{Cite book |last1=Kaner |first1=Cem |url=https://archive.org/details/lessonslearnedso00kane |title=सॉफ़्टवेयर परीक्षण में सीखे गए पाठ: एक प्रसंग-संचालित दृष्टिकोण|last2=Bach |first2=James |last3=Pettichord |first3=Bret |publisher=Wiley |year=2001 |isbn=978-0-471-08112-8 |pages=[https://archive.org/details/lessonslearnedso00kane/page/n55 31]–43 |url-access=limited}}</ref>
अलग-अलग लेबल और समूहीकरण परीक्षण के तरीके परीक्षण प्रकार, सॉफ़्टवेयर परीक्षण रणनीति या तकनीक हो सकते हैं।<ref>{{Cite book |last1=Kaner |first1=Cem |url=https://archive.org/details/lessonslearnedso00kane |title=सॉफ़्टवेयर परीक्षण में सीखे गए पाठ: एक प्रसंग-संचालित दृष्टिकोण|last2=Bach |first2=James |last3=Pettichord |first3=Bret |publisher=Wiley |year=2001 |isbn=978-0-471-08112-8 |pages=[https://archive.org/details/lessonslearnedso00kane/page/n55 31]–43 |url-access=limited}}</ref>


[[File:TestingCup-Polish-Championship-in-Software-Testing-Katowice-2016.jpg|thumb|TestingCup - सॉफ्टवेयर टेस्टिंग में पोलिश चैम्पियनशिप, [[Katowice]], मई 2016]]
[[File:TestingCup-Polish-Championship-in-Software-Testing-Katowice-2016.jpg|thumb|टेस्टिंग कप - सॉफ्टवेयर परीक्षण में पोलिश चैम्पियनशिप, कैटोविस, मई 2016]]


=== स्थापना (इंस्टालेशन) परीक्षण ===
=== स्थापना (इंस्टालेशन) परीक्षण ===
Line 178: Line 189:
=== संगतता परीक्षण ===
=== संगतता परीक्षण ===
{{main|संगतता परीक्षण}}
{{main|संगतता परीक्षण}}
सॉफ़्टवेयर विफलता (वास्तविक या कथित) का एक सामान्य कारण अन्य [[अनुप्रयोग प्रक्रिया सामग्री]], [[ऑपरेटिंग सिस्टम]] (या ऑपरेटिंग सिस्टम सॉफ़्टवेयर संस्करण, पुराने या नए), या लक्ष्य वातावरण के साथ इसकी कंप्यूटर संगतता की कमी है जो मूल से बहुत भिन्न है (जैसे कि एक [[कंप्यूटर टर्मिनल|कंप्यूटर]] या [[जीयूआई]] एप्लिकेशन को [[डेस्कटॉप रूपक|डेस्कटॉप]] पर चलाने का इरादा है, जिसे अब [[वेब एप्लीकेशन]] बनने की आवश्यकता है, जिसे [[वेब ब्राउज़र]] में प्रस्तुत करना होगा)। उदाहरण के लिए, पश्चगामी अनुकूलता की कमी के मामले में, ऐसा इसलिए हो सकता है क्योंकि प्रोग्रामर केवल लक्षित वातावरण के नवीनतम संस्करण पर सॉफ़्टवेयर विकसित और परीक्षण करते हैं, जो सभी उपयोगकर्ता नहीं चला सकते हैं। इसका परिणाम अनपेक्षित परिणाम में होता है कि नवीनतम कार्य लक्ष्य परिवेश के पुराने संस्करणों पर या पुराने हार्डवेयर पर काम नहीं कर सकता है जो लक्ष्य वातावरण के पुराने संस्करणों का उपयोग करने में सक्षम थे। कभी-कभी ऐसे मुद्दों को एक अलग प्रोग्राम [[मॉड्यूलर प्रोग्रामिंग]] या [[पुस्तकालय (कम्प्यूटिंग)]] में सक्रिय रूप से अमूर्त (कंप्यूटर विज्ञान) ऑपरेटिंग सिस्टम की कार्यक्षमता द्वारा तय किया जा सकता है।
सॉफ़्टवेयर विफलता (वास्तविक या कथित) का एक सामान्य कारण अन्य [[अनुप्रयोग प्रक्रिया सामग्री]], [[ऑपरेटिंग सिस्टम]] (या ऑपरेटिंग सिस्टम सॉफ़्टवेयर संस्करण, पुराने या नए), या लक्ष्य वातावरण के साथ इसकी कंप्यूटर संगतता की कमी है जो मूल से बहुत भिन्न है (जैसे कि [[कंप्यूटर टर्मिनल|कंप्यूटर]] या [[जीयूआई]] एप्लिकेशन को [[डेस्कटॉप रूपक|डेस्कटॉप]] पर चलाने का इरादा है, जिसे अब [[वेब एप्लीकेशन]] बनने की आवश्यकता है, जिसे [[वेब ब्राउज़र]] में प्रस्तुत करना होगा)। उदाहरण के लिए, पश्चगामी अनुकूलता की कमी के मामले में, ऐसा इसलिए हो सकता है क्योंकि प्रोग्रामर केवल लक्षित वातावरण के नवीनतम संस्करण पर सॉफ़्टवेयर विकसित और परीक्षण करते हैं, जो सभी उपयोगकर्ता नहीं चला सकते हैं। इसका परिणाम अनपेक्षित परिणाम में होता है कि नवीनतम कार्य लक्ष्य परिवेश के पुराने संस्करणों पर या पुराने हार्डवेयर पर काम नहीं कर सकता है जो लक्ष्य वातावरण के पुराने संस्करणों का उपयोग करने में सक्षम थे। कभी-कभी ऐसे मुद्दों को अलग प्रोग्राम [[मॉड्यूलर प्रोग्रामिंग]] या [[पुस्तकालय (कम्प्यूटिंग)]] में सक्रिय रूप से अमूर्त (कंप्यूटर विज्ञान) ऑपरेटिंग सिस्टम की कार्यक्षमता द्वारा तय किया जा सकता है।


=== धूम्रपान और स्वच्छता परीक्षण ===
=== धूम्रपान और स्वच्छता परीक्षण ===
Line 189: Line 200:
=== प्रतिगमन परीक्षण ===
=== प्रतिगमन परीक्षण ===
{{Main|प्रतिगमन परीक्षण}}
{{Main|प्रतिगमन परीक्षण}}
प्रतिगमन परीक्षण एक प्रमुख कोड परिवर्तन होने के बाद दोषों को खोजने पर केंद्रित है। विशेष रूप से, यह सॉफ़्टवेयर प्रतिगमन को उजागर करने का प्रयास करता है, पुराने बग सहित, खराब या खोई हुई सुविधाओं के रूप में, जो वापस आ गए हैं। इस तरह के प्रतिगमन तब होते हैं जब सॉफ़्टवेयर कार्यक्षमता जो पहले ठीक से काम कर रही थी, इच्छित के रूप में काम करना बंद कर देती है। आमतौर पर, प्रतिगमन प्रोग्राम परिवर्तनों के [[अनपेक्षित परिणाम]] के रूप में होता है, जब सॉफ़्टवेयर का नया विकसित हिस्सा पहले से मौजूद कोड से टकराता है। प्रतिगमन परीक्षण आम तौर पर वाणिज्यिक सॉफ्टवेयर विकास में सबसे बड़ा परीक्षण प्रयास है,<ref>{{Cite book |last1=Ammann |first1=Paul |url=https://books.google.com/books?id=leokXF8pLY0C&pg=PA215 |title=सॉफ्टवेयर परीक्षण का परिचय|last2=Offutt |first2=Jeff |date=January 28, 2008 |publisher=[[Cambridge University Press]] |isbn=978-0-521-88038-1 |page=215 |access-date=November 29, 2017}}</ref> पूर्व सॉफ़्टवेयर सुविधाओं में कई विवरणों की जाँच के कारण, और यहां तक ​​​​कि नए सॉफ़्टवेयर को कुछ पुराने परीक्षण मामलों का उपयोग करते हुए विकसित किया जा सकता है ताकि नए डिज़ाइन के कुछ हिस्सों का परीक्षण किया जा सके ताकि यह सुनिश्चित हो सके कि पूर्व कार्यक्षमता अभी भी समर्थित है।
प्रतिगमन परीक्षण एक प्रमुख कोड परिवर्तन होने के बाद दोषों को खोजने पर केंद्रित है। विशेष रूप से, यह सॉफ़्टवेयर प्रतिगमन को उजागर करने का प्रयास करता है, पुराने बग सहित, खराब या खोई हुई सुविधाओं के रूप में, जो वापस आ गए हैं। इस तरह के प्रतिगमन तब होते हैं जब सॉफ़्टवेयर कार्यक्षमता जो पहले ठीक से काम कर रही थी, इच्छित के रूप में काम करना बंद कर देती है। सामान्यतः, प्रतिगमन प्रोग्राम परिवर्तनों के [[अनपेक्षित परिणाम]] के रूप में होता है, जब सॉफ़्टवेयर का नया विकसित हिस्सा पहले से मौजूद कोड से टकराता है। प्रतिगमन परीक्षण सामान्यतः वाणिज्यिक सॉफ्टवेयर विकास में सबसे बड़ा परीक्षण प्रयास है,<ref>{{Cite book |last1=Ammann |first1=Paul |url=https://books.google.com/books?id=leokXF8pLY0C&pg=PA215 |title=सॉफ्टवेयर परीक्षण का परिचय|last2=Offutt |first2=Jeff |date=January 28, 2008 |publisher=[[Cambridge University Press]] |isbn=978-0-521-88038-1 |page=215 |access-date=November 29, 2017}}</ref> पूर्व सॉफ़्टवेयर सुविधाओं में कई विवरणों की जाँच के कारण, और यहां तक ​​​​कि नए सॉफ़्टवेयर को कुछ पुराने परीक्षण मामलों का उपयोग करते हुए विकसित किया जा सकता है ताकि नए डिज़ाइन के कुछ हिस्सों का परीक्षण किया जा सके ताकि यह सुनिश्चित हो सके कि पूर्व कार्यक्षमता अभी भी समर्थित है।


प्रतिगमन परीक्षण के सामान्य तरीकों में परीक्षण मामलों के पिछले सेटों को फिर से चलाना और यह जाँचना शामिल है कि क्या पहले से तय किए गए दोष फिर से उभर आए हैं। परीक्षण की गहराई रिलीज़ प्रक्रिया के चरण और जोड़ी गई सुविधाओं के [[जोखिम प्रबंधन]] पर निर्भर करती है। वे या तो पूर्ण हो सकते हैं, रिलीज में देर से जोड़े गए परिवर्तनों के लिए या जोखिम भरा माना जाता है, या बहुत उथला हो सकता है, जिसमें प्रत्येक सुविधा पर सकारात्मक परीक्षण शामिल हैं, यदि परिवर्तन रिलीज में जल्दी हैं या कम जोखिम वाले माने जाते हैं। प्रतिगमन परीक्षण में, मौजूदा व्यवहार पर मजबूत अभिकथन होना महत्वपूर्ण है। इसके लिए, मौजूदा परीक्षण मामलों में नए अभिकथन उत्पन्न करना और जोड़ना संभव है,<ref>{{Cite journal |last1=Danglot |first1=Benjamin |last2=Vera-Pérez |first2=Oscar Luis |last3=Baudry |first3=Benoit |last4=Monperrus |first4=Martin |date=2019 |title=डीस्पॉट के साथ स्वत: परीक्षण सुधार: दस परिपक्व ओपन-सोर्स परियोजनाओं के साथ एक अध्ययन|url=https://hal.archives-ouvertes.fr/hal-01923575/document |journal=Empirical Software Engineering |language=en |volume=24 |issue=4 |pages=2603–2635 |arxiv=1811.08330 |doi=10.1007/s10664-019-09692-y |s2cid=53748524}}</ref> इसे स्वचालित परीक्षण प्रवर्धन के रूप में जाना जाता है।<ref>{{Cite journal |last1=Danglot |first1=Benjamin |last2=Vera-Perez |first2=Oscar |last3=Yu |first3=Zhongxing |last4=Zaidman |first4=Andy |last5=Monperrus |first5=Martin |last6=Baudry |first6=Benoit |date=November 2019 |title=परीक्षण प्रवर्धन पर एक स्नोबॉलिंग साहित्य अध्ययन|url=https://hal.inria.fr/hal-02290742/file/1705.10692.pdf |journal=Journal of Systems and Software |language=en |volume=157 |pages=110398 |arxiv=1705.10692 |doi=10.1016/j.jss.2019.110398 |s2cid=20959692}}</ref>
प्रतिगमन परीक्षण के सामान्य तरीकों में परीक्षण मामलों के पिछले सेटों को फिर से चलाना और यह जाँचना सम्मिलित है कि क्या पहले से तय किए गए दोष फिर से उभर आए हैं। परीक्षण की गहराई रिलीज़ प्रक्रिया के चरण और जोड़ी गई सुविधाओं के [[जोखिम प्रबंधन]] पर निर्भर करती है। वे या तो पूर्ण हो सकते हैं, रिलीज में देर से जोड़े गए परिवर्तनों के लिए या जोखिम भरा माना जाता है, या बहुत उथला हो सकता है, जिसमें प्रत्येक सुविधा पर सकारात्मक परीक्षण सम्मिलित हैं, यदि परिवर्तन रिलीज में जल्दी हैं या कम जोखिम वाले माने जाते हैं। प्रतिगमन परीक्षण में, मौजूदा व्यवहार पर मजबूत अभिकथन होना महत्वपूर्ण है। इसके लिए, मौजूदा परीक्षण मामलों में नए अभिकथन उत्पन्न करना और जोड़ना संभव है,<ref>{{Cite journal |last1=Danglot |first1=Benjamin |last2=Vera-Pérez |first2=Oscar Luis |last3=Baudry |first3=Benoit |last4=Monperrus |first4=Martin |date=2019 |title=डीस्पॉट के साथ स्वत: परीक्षण सुधार: दस परिपक्व ओपन-सोर्स परियोजनाओं के साथ एक अध्ययन|url=https://hal.archives-ouvertes.fr/hal-01923575/document |journal=Empirical Software Engineering |language=en |volume=24 |issue=4 |pages=2603–2635 |arxiv=1811.08330 |doi=10.1007/s10664-019-09692-y |s2cid=53748524}}</ref> इसे स्वचालित परीक्षण प्रवर्धन के रूप में जाना जाता है।<ref>{{Cite journal |last1=Danglot |first1=Benjamin |last2=Vera-Perez |first2=Oscar |last3=Yu |first3=Zhongxing |last4=Zaidman |first4=Andy |last5=Monperrus |first5=Martin |last6=Baudry |first6=Benoit |date=November 2019 |title=परीक्षण प्रवर्धन पर एक स्नोबॉलिंग साहित्य अध्ययन|url=https://hal.inria.fr/hal-02290742/file/1705.10692.pdf |journal=Journal of Systems and Software |language=en |volume=157 |pages=110398 |arxiv=1705.10692 |doi=10.1016/j.jss.2019.110398 |s2cid=20959692}}</ref>
=== स्वीकार्यता परीक्षण ===
=== स्वीकार्यता परीक्षण ===
{{Main|स्वीकार्यता परीक्षण}}
{{Main|स्वीकार्यता परीक्षण}}
Line 197: Line 208:
स्वीकार्यता परीक्षण का अर्थ दो चीजों में से एक हो सकता है:
स्वीकार्यता परीक्षण का अर्थ दो चीजों में से एक हो सकता है:


# एक धूम्रपान परीक्षण (सॉफ्टवेयर) का उपयोग आगे के परीक्षण से पहले निर्माण स्वीकृति परीक्षण के रूप में किया जाता है, उदाहरण के लिए, एकीकरण परीक्षण या [[प्रतिगमन परीक्षण]] से पहले।
# धूम्रपान परीक्षण (सॉफ्टवेयर) का उपयोग आगे के परीक्षण से पहले निर्माण स्वीकृति परीक्षण के रूप में किया जाता है, उदाहरण के लिए, एकीकरण परीक्षण या [[प्रतिगमन परीक्षण]] से पहले।
# ग्राहक द्वारा किया गया स्वीकृति परीक्षण, अक्सर उनके स्वयं के हार्डवेयर पर प्रयोगशाला वातावरण में, [[उपयोगकर्ता स्वीकृति परीक्षण]] (यूएटी) के रूप में जाना जाता है। विकास के किन्हीं दो चरणों के बीच हैंड-ऑफ़ प्रक्रिया के भाग के रूप में स्वीकृति परीक्षण किया जा सकता है।{{Citation needed|date= January 2008}}
# ग्राहक द्वारा किया गया स्वीकृति परीक्षण, प्रायः उनके स्वयं के हार्डवेयर पर प्रयोगशाला वातावरण में, [[उपयोगकर्ता स्वीकृति परीक्षण]] (यूएटी) के रूप में जाना जाता है। विकास के किन्हीं दो चरणों के बीच हैंड-ऑफ़ प्रक्रिया के भाग के रूप में स्वीकृति परीक्षण किया जा सकता है।{{Citation needed|date= January 2008}}
=== अल्फा परीक्षण ===
=== अल्फा परीक्षण ===
{{Main|अल्फा परीक्षण}}
{{Main|अल्फा परीक्षण}}
अल्फा परीक्षण संभावित उपयोगकर्ताओं/ग्राहकों या डेवलपर्स की साइट पर एक स्वतंत्र परीक्षण टीम द्वारा सिम्युलेटेड या वास्तविक परिचालन परीक्षण है। सॉफ़्टवेयर के बीटा परीक्षण में जाने से पहले अल्फा परीक्षण को अक्सर ऑफ़-द-शेल्फ सॉफ़्टवेयर के लिए आंतरिक स्वीकृति परीक्षण के रूप में नियोजित किया जाता है।<ref>{{Cite web |title=सॉफ्टवेयर परीक्षण में उपयोग की जाने वाली शर्तों की मानक शब्दावली|url=https://www.astqb.org/documents/Glossary-of-Software-Testing-Terms-v3.pdf |access-date=January 9, 2018 |publisher=International Software Testing Qualifications Board |version=Version 3.1}}</ref>
अल्फा परीक्षण संभावित उपयोगकर्ताओं/ग्राहकों या डेवलपर्स की साइट पर एक स्वतंत्र परीक्षण टीम द्वारा सिम्युलेटेड या वास्तविक परिचालन परीक्षण है। सॉफ़्टवेयर के बीटा परीक्षण में जाने से पहले अल्फा परीक्षण को प्रायः ऑफ़-द-शेल्फ सॉफ़्टवेयर के लिए आंतरिक स्वीकृति परीक्षण के रूप में नियोजित किया जाता है।<ref>{{Cite web |title=सॉफ्टवेयर परीक्षण में उपयोग की जाने वाली शर्तों की मानक शब्दावली|url=https://www.astqb.org/documents/Glossary-of-Software-Testing-Terms-v3.pdf |access-date=January 9, 2018 |publisher=International Software Testing Qualifications Board |version=Version 3.1}}</ref>
=== बीटा परीक्षण ===
=== बीटा परीक्षण ===
{{See also|सॉफ्टवेयर रिलीज़ लाइफ साईकल बीटा}}
{{See also|सॉफ्टवेयर रिलीज़ लाइफ साईकल बीटा}}
Line 207: Line 218:
=== कार्यात्मक बनाम गैर-कार्यात्मक परीक्षण ===
=== कार्यात्मक बनाम गैर-कार्यात्मक परीक्षण ===


कार्यात्मक परीक्षण उन गतिविधियों को संदर्भित करता है जो कोड की एक विशिष्ट क्रिया या कार्य को सत्यापित करते हैं। ये आमतौर पर कोड आवश्यकताओं के दस्तावेज में पाए जाते हैं, हालांकि कुछ विकास पद्धतियां उपयोग के मामलों या उपयोगकर्ता कहानियों से काम करती हैं। कार्यात्मक परीक्षण "क्या उपयोगकर्ता ऐसा कर सकता है" या "क्या यह विशेष सुविधा काम करती है" के प्रश्न का उत्तर देने की प्रवृत्ति है।
कार्यात्मक परीक्षण उन गतिविधियों को संदर्भित करता है जो कोड की विशिष्ट क्रिया या कार्य को सत्यापित करते हैं। ये सामान्यतः कोड आवश्यकताओं के दस्तावेज में पाए जाते हैं, हालांकि कुछ विकास पद्धतियां उपयोग के मामलों या उपयोगकर्ता कहानियों से काम करती हैं। कार्यात्मक परीक्षण "क्या उपयोगकर्ता ऐसा कर सकता है" या "क्या यह विशेष सुविधा काम करती है" के प्रश्न का उत्तर देने की प्रवृत्ति है।


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


{{Main|निरंतर परीक्षण}}
{{Main|निरंतर परीक्षण}}


निरंतर परीक्षण सॉफ्टवेयर डिलीवरी पाइपलाइन के हिस्से के रूप में स्वचालित परीक्षणों को निष्पादित करने की प्रक्रिया है, जो सॉफ़्टवेयर रिलीज़ उम्मीदवार से जुड़े व्यावसायिक जोखिमों पर तत्काल प्रतिक्रिया प्राप्त करने के लिए है।<ref name="essential">{{Cite web |last=Auerbach |first=Adam |date=August 3, 2015 |title=पाइपलाइन का हिस्सा: निरंतर परीक्षण क्यों आवश्यक है|url=https://www.techwell.com/techwell-insights/2015/08/part-pipeline-why-continuous-testing-essential |access-date=January 12, 2018 |website=TechWell Insights |publisher=TechWell Corp.}}</ref><ref name="stickym">{{Cite web |last=Philipp-Edmonds |first=Cameron |date=December 5, 2014 |title=जोखिम और सतत परीक्षण के बीच संबंध: वेन एरियोला के साथ एक साक्षात्कार|url=http://www.stickyminds.com/interview/relationship-between-risk-and-continuous-testing-interview-wayne-ariola |access-date=January 16, 2018 |website=Stickyminds}}</ref> सतत परीक्षण में कार्यात्मक आवश्यकताओं और गैर-कार्यात्मक आवश्यकताओं दोनों की मान्यता शामिल है; परीक्षण का दायरा व्यापक व्यावसायिक लक्ष्यों से जुड़ी सिस्टम आवश्यकताओं का आकलन करने के लिए नीचे-ऊपर की आवश्यकताओं या उपयोगकर्ता कहानियों को मान्य करने तक विस्तृत है।<ref name="pnsqc">{{Cite conference |last1=Ariola |first1=Wayne |last2=Dunlop |first2=Cynthia |date=October 2015 |title=DevOps: क्या आप ग्राहकों के लिए बग्स को तेजी से आगे बढ़ा रहे हैं?|url=http://uploads.pnsqc.org/2015/papers/t-007_Ariola_paper.pdf |conference=Pacific Northwest Software Quality Conference |access-date=January 16, 2018}}</ref><ref name="shift">{{Cite web |last=Auerbach |first=Adam |date=October 2, 2014 |title=बाएं शिफ्ट करें और गुणवत्ता पहले रखें|url=https://www.techwell.com/techwell-insights/2014/10/shift-left-and-put-quality-first |access-date=January 16, 2018 |website=TechWell Insights |publisher=TechWell Corp.}}</ref>
निरंतर परीक्षण सॉफ्टवेयर डिलीवरी पाइपलाइन के हिस्से के रूप में स्वचालित परीक्षणों को निष्पादित करने की प्रक्रिया है, जो सॉफ़्टवेयर रिलीज़ उम्मीदवार से जुड़े व्यावसायिक जोखिमों पर तत्काल प्रतिक्रिया प्राप्त करने के लिए है।<ref name="essential">{{Cite web |last=Auerbach |first=Adam |date=August 3, 2015 |title=पाइपलाइन का हिस्सा: निरंतर परीक्षण क्यों आवश्यक है|url=https://www.techwell.com/techwell-insights/2015/08/part-pipeline-why-continuous-testing-essential |access-date=January 12, 2018 |website=TechWell Insights |publisher=TechWell Corp.}}</ref><ref name="stickym">{{Cite web |last=Philipp-Edmonds |first=Cameron |date=December 5, 2014 |title=जोखिम और सतत परीक्षण के बीच संबंध: वेन एरियोला के साथ एक साक्षात्कार|url=http://www.stickyminds.com/interview/relationship-between-risk-and-continuous-testing-interview-wayne-ariola |access-date=January 16, 2018 |website=Stickyminds}}</ref> सतत परीक्षण में कार्यात्मक आवश्यकताओं और गैर-कार्यात्मक आवश्यकताओं दोनों की मान्यता सम्मिलित है; परीक्षण का दायरा व्यापक व्यावसायिक लक्ष्यों से जुड़ी सिस्टम आवश्यकताओं का आकलन करने के लिए नीचे-ऊपर की आवश्यकताओं या उपयोगकर्ता कहानियों को मान्य करने तक विस्तृत है।<ref name="pnsqc">{{Cite conference |last1=Ariola |first1=Wayne |last2=Dunlop |first2=Cynthia |date=October 2015 |title=DevOps: क्या आप ग्राहकों के लिए बग्स को तेजी से आगे बढ़ा रहे हैं?|url=http://uploads.pnsqc.org/2015/papers/t-007_Ariola_paper.pdf |conference=Pacific Northwest Software Quality Conference |access-date=January 16, 2018}}</ref><ref name="shift">{{Cite web |last=Auerbach |first=Adam |date=October 2, 2014 |title=बाएं शिफ्ट करें और गुणवत्ता पहले रखें|url=https://www.techwell.com/techwell-insights/2014/10/shift-left-and-put-quality-first |access-date=January 16, 2018 |website=TechWell Insights |publisher=TechWell Corp.}}</ref>
=== विध्वंसक परीक्षण ===
=== विध्वंसक परीक्षण ===
{{Main|विध्वंसक परीक्षण}}
{{Main|विध्वंसक परीक्षण}}
Line 221: Line 232:
{{further|एक्सेप्शन हैंडलिंग|रिकवरी परीक्षण}}
{{further|एक्सेप्शन हैंडलिंग|रिकवरी परीक्षण}}
=== सॉफ्टवेयर प्रदर्शन परीक्षण ===
=== सॉफ्टवेयर प्रदर्शन परीक्षण ===
{{Main|Software performance testing}}
{{Main|सॉफ्टवेयर  परफॉरमेंस  टेस्टिंग }}
प्रदर्शन परीक्षण आम तौर पर यह निर्धारित करने के लिए निष्पादित किया जाता है कि किसी विशेष वर्कलोड के तहत जवाबदेही और स्थिरता के संदर्भ में सिस्टम या उप-सिस्टम कैसे प्रदर्शन करता है। यह सिस्टम की अन्य गुणवत्ता विशेषताओं, जैसे मापनीयता, विश्वसनीयता और संसाधन उपयोग की जांच, माप, सत्यापन या सत्यापन करने के लिए भी सेवा प्रदान कर सकता है।
प्रदर्शन परीक्षण सामान्यतः यह निर्धारित करने के लिए निष्पादित किया जाता है कि किसी विशेष वर्कलोड के तहत जवाबदेही और स्थिरता के संदर्भ में सिस्टम या उप-सिस्टम कैसे प्रदर्शन करता है। यह सिस्टम की अन्य गुणवत्ता विशेषताओं, जैसे मापनीयता, विश्वसनीयता और संसाधन उपयोग की जांच, माप, सत्यापन या सत्यापन करने के लिए भी सेवा प्रदान कर सकता है।


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


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


[[रीयल-टाइम कंप्यूटिंग|रीयल-टाइम]] सॉफ़्टवेयर सिस्टम में सख्त समय की कमी है। यह जांचने के लिए कि क्या समय की कमी पूरी हुई है, वास्तविक समय परीक्षण का उपयोग किया जाता है।
[[रीयल-टाइम कंप्यूटिंग|रीयल-टाइम]] सॉफ़्टवेयर सिस्टम में सख्त समय की कमी है। यह जांचने के लिए कि क्या समय की कमी पूरी हुई है, वास्तविक समय परीक्षण का उपयोग किया जाता है।
Line 260: Line 271:
वैश्वीकरण परीक्षण सत्यापित करता है कि सॉफ्टवेयर एक नई संस्कृति (जैसे विभिन्न मुद्राओं या समय क्षेत्रों) के लिए अनुकूलित है।<ref>{{Cite web |title=वैश्वीकरण चरण-दर-चरण: परीक्षण के लिए विश्व-तैयार दृष्टिकोण। माइक्रोसॉफ्ट डेवलपर नेटवर्क|url=https://msdn.microsoft.com/en-us/goglobal/bb688148 |access-date=January 13, 2012 |publisher=Msdn.microsoft.com |archive-url=https://web.archive.org/web/20120623050851/https://msdn.microsoft.com/en-us/goglobal/bb688148 |archive-date=June 23, 2012}}</ref>
वैश्वीकरण परीक्षण सत्यापित करता है कि सॉफ्टवेयर एक नई संस्कृति (जैसे विभिन्न मुद्राओं या समय क्षेत्रों) के लिए अनुकूलित है।<ref>{{Cite web |title=वैश्वीकरण चरण-दर-चरण: परीक्षण के लिए विश्व-तैयार दृष्टिकोण। माइक्रोसॉफ्ट डेवलपर नेटवर्क|url=https://msdn.microsoft.com/en-us/goglobal/bb688148 |access-date=January 13, 2012 |publisher=Msdn.microsoft.com |archive-url=https://web.archive.org/web/20120623050851/https://msdn.microsoft.com/en-us/goglobal/bb688148 |archive-date=June 23, 2012}}</ref>


मानव भाषाओं में वास्तविक अनुवाद का भी परीक्षण किया जाना चाहिए। संभावित स्थानीयकरण और वैश्वीकरण विफलताओं में शामिल हैं:
मानव भाषाओं में वास्तविक अनुवाद का भी परीक्षण किया जाना चाहिए। संभावित स्थानीयकरण और वैश्वीकरण विफलताओं में सम्मिलित हैं:


* सॉफ्टवेयर अक्सर संदर्भ से बाहर [[स्ट्रिंग (कंप्यूटर विज्ञान)]] की एक सूची का अनुवाद करके स्थानीयकृत होता है, और अनुवादक अस्पष्ट स्रोत स्ट्रिंग के लिए गलत अनुवाद चुन सकता है।
* सॉफ्टवेयर प्रायः संदर्भ से बाहर [[स्ट्रिंग (कंप्यूटर विज्ञान)]] की एक सूची का अनुवाद करके स्थानीयकृत होता है, और अनुवादक अस्पष्ट स्रोत स्ट्रिंग के लिए गलत अनुवाद चुन सकता है।
* तकनीकी शब्दावली असंगत हो सकती है, यदि परियोजना का अनुवाद कई लोगों द्वारा उचित समन्वय के बिना किया जाता है या यदि अनुवादक अविवेकपूर्ण है।
* तकनीकी शब्दावली असंगत हो सकती है, यदि परियोजना का अनुवाद कई लोगों द्वारा उचित समन्वय के बिना किया जाता है या यदि अनुवादक अविवेकपूर्ण है।
* लक्षित भाषा में शाब्दिक शब्द-दर-शब्द अनुवाद अनुपयुक्त, कृत्रिम या अत्यधिक तकनीकी लग सकता है।
* लक्षित भाषा में शाब्दिक शब्द-दर-शब्द अनुवाद अनुपयुक्त, कृत्रिम या अत्यधिक तकनीकी लग सकता है।
Line 278: Line 289:
{{Main|विकास परीक्षण}}
{{Main|विकास परीक्षण}}


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


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


=== ए/बी परीक्षण ===
=== ए/बी परीक्षण ===
Line 289: Line 300:
=== समवर्ती परीक्षण ===
=== समवर्ती परीक्षण ===
{{Main|समवर्ती परीक्षण}}
{{Main|समवर्ती परीक्षण}}
समवर्ती या समवर्ती परीक्षण सॉफ्टवेयर और सिस्टम के व्यवहार और प्रदर्शन का आकलन करता है जो आम तौर पर सामान्य उपयोग की शर्तों के तहत [[समवर्ती कंप्यूटिंग]] का उपयोग करते हैं। इस प्रकार के परीक्षण से सामने आने वाली विशिष्ट समस्याएं गतिरोध, दौड़ की स्थिति और साझा मेमोरी/संसाधन प्रबंधन के साथ समस्याएं हैं।
समवर्ती या समवर्ती परीक्षण सॉफ्टवेयर और सिस्टम के व्यवहार और प्रदर्शन का आकलन करता है जो सामान्यतः सामान्य उपयोग की शर्तों के तहत [[समवर्ती कंप्यूटिंग]] का उपयोग करते हैं। इस प्रकार के परीक्षण से सामने आने वाली विशिष्ट समस्याएं गतिरोध, दौड़ की स्थिति और साझा मेमोरी/संसाधन प्रबंधन के साथ समस्याएं हैं।


=== अनुरूपता परीक्षण या टाइप परीक्षण ===
=== अनुरूपता परीक्षण या टाइप परीक्षण ===
{{Main|अनुरूपता परीक्षण}}
{{Main|अनुरूपता परीक्षण}}
सॉफ्टवेयर परीक्षण में, अनुरूपता परीक्षण यह सत्यापित करता है कि एक उत्पाद अपने निर्दिष्ट मानकों के अनुसार प्रदर्शन करता है। उदाहरण के लिए, कंपाइलर्स का यह निर्धारित करने के लिए बड़े पैमाने पर परीक्षण किया जाता है कि वे उस भाषा के लिए मान्यता प्राप्त मानक को पूरा करते हैं या नहीं।
सॉफ्टवेयर परीक्षण में, अनुरूपता परीक्षण यह सत्यापित करता है कि उत्पाद अपने निर्दिष्ट मानकों के अनुसार प्रदर्शन करता है। उदाहरण के लिए, कंपाइलर्स का यह निर्धारित करने के लिए बड़े पैमाने पर परीक्षण किया जाता है कि वे उस भाषा के लिए मान्यता प्राप्त मानक को पूरा करते हैं या नहीं।


=== आउटपुट तुलना परीक्षण ===
=== आउटपुट तुलना परीक्षण ===
Line 315: Line 326:
=== वीसीआर परीक्षण ===
=== वीसीआर परीक्षण ===


वीसीआर परीक्षण, जिसे "प्लेबैक परीक्षण" या "रिकॉर्ड/रीप्ले" परीक्षण के रूप में भी जाना जाता है, प्रतिगमन परीक्षणों की विश्वसनीयता और गति को बढ़ाने के लिए एक परीक्षण तकनीक है जिसमें एक घटक शामिल होता है जो धीमा या अविश्वसनीय होता है, अक्सर एक तृतीय-पक्ष एपीआई परीक्षक के नियंत्रण के बाहर इसमें बाहरी घटक के साथ सिस्टम के इंटरैक्शन की एक रिकॉर्डिंग ("कैसेट") बनाना शामिल है, और फिर परीक्षण के बाद के रन पर बाहरी सिस्टम के साथ संचार करने के विकल्प के रूप में रिकॉर्ड किए गए इंटरैक्शन को फिर से चलाना शामिल है।
वीसीआर परीक्षण, जिसे "प्लेबैक परीक्षण" या "रिकॉर्ड/रीप्ले" परीक्षण के रूप में भी जाना जाता है, प्रतिगमन परीक्षणों की विश्वसनीयता और गति को बढ़ाने के लिए एक परीक्षण तकनीक है जिसमें एक घटक सम्मिलित होता है जो धीमा या अविश्वसनीय होता है, प्रायः एक तृतीय-पक्ष एपीआई परीक्षक के नियंत्रण के बाहर इसमें बाहरी घटक के साथ सिस्टम के इंटरैक्शन की रिकॉर्डिंग ("कैसेट") बनाना सम्मिलित है, और फिर परीक्षण के बाद के रन पर बाहरी सिस्टम के साथ संचार करने के विकल्प के रूप में रिकॉर्ड किए गए इंटरैक्शन को फिर से चलाना सम्मिलित है।


इस तकनीक को रूबी लाइब्रेरी द्वारा वेब विकास में लोकप्रिय बनाया गया था।
इस तकनीक को रूबी लाइब्रेरी द्वारा वेब विकास में लोकप्रिय बनाया गया था।
Line 323: Line 334:
=== परंपरागत जलप्रपात विकास मॉडल ===
=== परंपरागत जलप्रपात विकास मॉडल ===


जलप्रपात विकास में एक सामान्य अभ्यास यह है कि परीक्षण परीक्षकों के एक स्वतंत्र समूह द्वारा किया जाता है। ऐसा हो सकता है:
जलप्रपात विकास में सामान्य अभ्यास यह है कि परीक्षण परीक्षकों के स्वतंत्र समूह द्वारा किया जाता है। ऐसा हो सकता है:


* कार्यक्षमता विकसित होने के बाद, लेकिन ग्राहक को भेजने से पहले।<ref>{{Cite web |title=सॉफ्टवेयर परीक्षण जीवनचक्र|url=http://www.etestinghub.com/testing_lifecycles.php#2 |access-date=January 13, 2012 |website=etestinghub |at=Testing Phase in Software Testing}}</ref> इस अभ्यास के परिणामस्वरूप अक्सर परीक्षण चरण का उपयोग [[परियोजना प्रबंधन]] बफर के रूप में किया जाता है ताकि परियोजना में देरी की भरपाई की जा सके, जिससे परीक्षण के लिए समर्पित समय से समझौता किया जा सके।<ref name="Myers 1979" />{{rp|145–146}}
* कार्यक्षमता विकसित होने के बाद, लेकिन ग्राहक को भेजने से पहले।<ref>{{Cite web |title=सॉफ्टवेयर परीक्षण जीवनचक्र|url=http://www.etestinghub.com/testing_lifecycles.php#2 |access-date=January 13, 2012 |website=etestinghub |at=Testing Phase in Software Testing}}</ref> इस अभ्यास के परिणामस्वरूप प्रायः परीक्षण चरण का उपयोग [[परियोजना प्रबंधन]] बफर के रूप में किया जाता है ताकि परियोजना में देरी की भरपाई की जा सके, जिससे परीक्षण के लिए समर्पित समय से समझौता किया जा सके।<ref name="Myers 1979" />{{rp|145–146}}
* उसी क्षण विकास परियोजना शुरू होती है, एक सतत प्रक्रिया के रूप में जब तक परियोजना समाप्त नहीं हो जाती।<ref>{{Cite book |last=Dustin |first=Elfriede |url=https://books.google.com/books?id=K0qWBUOAf6IC&pg=PA3 |title=प्रभावी सॉफ्टवेयर परीक्षण|publisher=Addison-Wesley Professional |year=2002 |isbn=978-0-201-79429-8 |page=3}}</ref>
* उसी क्षण विकास परियोजना शुरू होती है, सतत प्रक्रिया के रूप में जब तक परियोजना समाप्त नहीं हो जाती।<ref>{{Cite book |last=Dustin |first=Elfriede |url=https://books.google.com/books?id=K0qWBUOAf6IC&pg=PA3 |title=प्रभावी सॉफ्टवेयर परीक्षण|publisher=Addison-Wesley Professional |year=2002 |isbn=978-0-201-79429-8 |page=3}}</ref>
हालांकि, जलप्रपात विकास मॉडल में भी, इकाई परीक्षण अक्सर सॉफ्टवेयर विकास दल द्वारा किया जाता है, तब भी जब आगे का परीक्षण एक अलग टीम द्वारा किया जाता है।<ref>{{Cite book |last1=Brown |first1=Chris |url=http://www.informit.com/articles/article.aspx?p=26320&seqNum=6 |title=रैपिड सॉफ्टवेयर टेस्टिंग का परिचय|last2=Cobb |first2=Gary |last3=Culbertson |first3=Robert |date=April 12, 2002}}</ref>
हालांकि, जलप्रपात विकास मॉडल में भी, इकाई परीक्षण प्रायः सॉफ्टवेयर विकास दल द्वारा किया जाता है, तब भी जब आगे का परीक्षण अलग टीम द्वारा किया जाता है।<ref>{{Cite book |last1=Brown |first1=Chris |url=http://www.informit.com/articles/article.aspx?p=26320&seqNum=6 |title=रैपिड सॉफ्टवेयर टेस्टिंग का परिचय|last2=Cobb |first2=Gary |last3=Culbertson |first3=Robert |date=April 12, 2002}}</ref>


{{further|क्षमता परिपक्वता मॉडल एकीकरण|जलप्रपात (वॉटरफॉल) मॉडल}}
{{further|क्षमता परिपक्वता मॉडल एकीकरण|जलप्रपात (वॉटरफॉल) मॉडल}}
=== कुशल या एक्सपी विकास मॉडल ===
=== कुशल या एक्सपी विकास मॉडल ===


इसके विपरीत, कुछ उभरते हुए सॉफ्टवेयर अनुशासन जैसे एक्सट्रीम प्रोग्रामिंग और कुशल सॉफ्टवेयर विकास आंदोलन, "परीक्षण-संचालित सॉफ़्टवेयर विकास" मॉडल का पालन करते हैं। इस प्रक्रिया में, यूनिट टेस्ट पहले [[सॉफ्टवेयर इंजीनियरिंग|सॉफ्टवेयर]] इंजीनियरों द्वारा लिखे जाते हैं (अक्सर एक्सट्रीम प्रोग्रामिंग मेथडोलॉजी में पेयर प्रोग्रामिंग के साथ)। परीक्षणों के शुरू में असफल होने की उम्मीद है। प्रत्येक असफल परीक्षा के बाद उसे उत्तीर्ण करने के लिए पर्याप्त कोड लिखना होता है।<ref name="AgileAllianceTDD">{{Cite web |date=December 5, 2015 |title=टेस्ट ड्रिवेन डेवलपमेंट (TDD) क्या है?|url=https://www.agilealliance.org/glossary/tdd/ |access-date=March 17, 2018 |website=Agile Alliance}}</ref> इसका मतलब यह है कि परीक्षण सूट लगातार अपडेट किए जाते हैं क्योंकि नई विफलता की स्थिति और कोने के मामलों की खोज की जाती है, और वे किसी भी प्रतिगमन परीक्षण के साथ एकीकृत होते हैं जो विकसित होते हैं। यूनिट परीक्षण बाकी सॉफ्टवेयर स्रोत कोड के साथ बनाए रखा जाता है और आम तौर पर निर्माण प्रक्रिया में एकीकृत किया जाता है (आंशिक रूप से मैन्युअल निर्माण स्वीकृति प्रक्रिया के लिए स्वाभाविक रूप से इंटरैक्टिव परीक्षणों को हटा दिया जाता है)।
इसके विपरीत, कुछ उभरते हुए सॉफ्टवेयर अनुशासन जैसे एक्सट्रीम प्रोग्रामिंग और कुशल सॉफ्टवेयर विकास आंदोलन, "परीक्षण-संचालित सॉफ़्टवेयर विकास" मॉडल का पालन करते हैं। इस प्रक्रिया में, यूनिट टेस्ट पहले [[सॉफ्टवेयर इंजीनियरिंग|सॉफ्टवेयर]] इंजीनियरों द्वारा लिखे जाते हैं (प्रायः एक्सट्रीम प्रोग्रामिंग मेथडोलॉजी में पेयर प्रोग्रामिंग के साथ)। परीक्षणों के शुरू में असफल होने की उम्मीद है। प्रत्येक असफल परीक्षा के बाद उसे उत्तीर्ण करने के लिए पर्याप्त कोड लिखना होता है।<ref name="AgileAllianceTDD">{{Cite web |date=December 5, 2015 |title=टेस्ट ड्रिवेन डेवलपमेंट (TDD) क्या है?|url=https://www.agilealliance.org/glossary/tdd/ |access-date=March 17, 2018 |website=Agile Alliance}}</ref> इसका मतलब यह है कि परीक्षण सूट लगातार अपडेट किए जाते हैं क्योंकि नई विफलता की स्थिति और कोने के मामलों की खोज की जाती है, और वे किसी भी प्रतिगमन परीक्षण के साथ एकीकृत होते हैं जो विकसित होते हैं। यूनिट परीक्षण बाकी सॉफ्टवेयर स्रोत कोड के साथ बनाए रखा जाता है और सामान्यतः निर्माण प्रक्रिया में एकीकृत किया जाता है (आंशिक रूप से मैन्युअल निर्माण स्वीकृति प्रक्रिया के लिए स्वाभाविक रूप से इंटरैक्टिव परीक्षणों को हटा दिया जाता है)।


इस परीक्षण प्रक्रिया का अंतिम लक्ष्य निरंतर एकीकरण का समर्थन करना और दोष दरों को कम करना है।<ref>{{Cite web |title=मोबाइल अनुप्रयोगों के लिए परीक्षण-संचालित विकास और सतत एकीकरण|url=https://msdn.microsoft.com/en-us/library/bb985498.aspx#_Continuous_Integration |access-date=March 17, 2018 |website=msdn.microsoft.com}}</ref><ref name="AgileAllianceTDD" />
इस परीक्षण प्रक्रिया का अंतिम लक्ष्य निरंतर एकीकरण का समर्थन करना और दोष दरों को कम करना है।<ref>{{Cite web |title=मोबाइल अनुप्रयोगों के लिए परीक्षण-संचालित विकास और सतत एकीकरण|url=https://msdn.microsoft.com/en-us/library/bb985498.aspx#_Continuous_Integration |access-date=March 17, 2018 |website=msdn.microsoft.com}}</ref><ref name="AgileAllianceTDD" />
Line 340: Line 351:
=== नमूना परीक्षण चक्र ===
=== नमूना परीक्षण चक्र ===


हालांकि संगठनों के बीच भिन्नताएं मौजूद हैं, परीक्षण के लिए एक विशिष्ट चक्र है।<ref name="pan" /> [[जलप्रपात विकास]] मॉडल को नियोजित करने वाले संगठनों के बीच नीचे दिया गया नमूना सामान्य है। अन्य विकास मॉडलों में आमतौर पर समान प्रथाएं पाई जाती हैं, लेकिन यह उतनी स्पष्ट या स्पष्ट नहीं हो सकती हैं।
हालांकि संगठनों के बीच भिन्नताएं मौजूद हैं, परीक्षण के लिए एक विशिष्ट चक्र है।<ref name="pan" /> [[जलप्रपात विकास]] मॉडल को नियोजित करने वाले संगठनों के बीच नीचे दिया गया नमूना सामान्य है। अन्य विकास मॉडलों में सामान्यतः समान प्रथाएं पाई जाती हैं, लेकिन यह उतनी स्पष्ट या स्पष्ट नहीं हो सकती हैं।


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


Line 361: Line 372:
=== परीक्षण उपकरण ===
=== परीक्षण उपकरण ===


प्रोग्राम टेस्टिंग और फॉल्ट डिटेक्शन को टेस्टिंग टूल्स और डिबगर्स द्वारा काफी मदद मिल सकती है। परीक्षण/डीबग टूल में विशेषताएं शामिल हैं जैसे:
प्रोग्राम टेस्टिंग और फॉल्ट डिटेक्शन को टेस्टिंग टूल्स और डिबगर्स द्वारा काफी मदद मिल सकती है। परीक्षण/डीबग टूल में विशेषताएं सम्मिलित हैं जैसे:


* प्रोग्राम मॉनिटर, प्रोग्राम कोड की पूर्ण या आंशिक निगरानी की अनुमति देना, जिसमें निम्न शामिल हैं:
* प्रोग्राम मॉनिटर, प्रोग्राम कोड की पूर्ण या आंशिक निगरानी की अनुमति देना, जिसमें निम्न सम्मिलित हैं:
** निर्देश सेट सिम्युलेटर, पूर्ण निर्देश स्तर की निगरानी और सुविधाओं का पता लगाने की अनुमति
** निर्देश सेट सिम्युलेटर, पूर्ण निर्देश स्तर की निगरानी और सुविधाओं का पता लगाने की अनुमति
** हाइपरवाइजर, प्रोग्राम कोड के निष्पादन के पूर्ण नियंत्रण की अनुमति देता है, जिसमें शामिल हैं: -
** हाइपरवाइजर, प्रोग्राम कोड के निष्पादन के पूर्ण नियंत्रण की अनुमति देता है, जिसमें सम्मिलित हैं: -
** प्रोग्राम एनीमेशन, स्रोत स्तर पर या मशीन कोड में चरण-दर-चरण निष्पादन और सशर्त ब्रेकपॉइंट की अनुमति
** प्रोग्राम एनीमेशन, स्रोत स्तर पर या मशीन कोड में चरण-दर-चरण निष्पादन और सशर्त ब्रेकपॉइंट की अनुमति
** कोड कवरेज रिपोर्ट
** कोड कवरेज रिपोर्ट
Line 373: Line 384:
* प्रोफाइलिंग (कंप्यूटर प्रोग्रामिंग) (या प्रोफाइलिंग टूल) जो हॉट स्पॉट (कंप्यूटर विज्ञान) और संसाधन उपयोग को उजागर करने में मदद कर सकता है
* प्रोफाइलिंग (कंप्यूटर प्रोग्रामिंग) (या प्रोफाइलिंग टूल) जो हॉट स्पॉट (कंप्यूटर विज्ञान) और संसाधन उपयोग को उजागर करने में मदद कर सकता है


इनमें से कुछ विशेषताओं को एक समग्र उपकरण या एक [[एकीकृत विकास पर्यावरण]] (आईडीई) में शामिल किया जा सकता है।
इनमें से कुछ विशेषताओं को एक समग्र उपकरण या एक [[एकीकृत विकास पर्यावरण]] (आईडीई) में सम्मिलित किया जा सकता है।


=== कैप्चर और रीप्ले ===
=== कैप्चर और रीप्ले ===


कैप्चर और रीप्ले टेस्टिंग में एप्लिकेशन के साथ इंटरैक्ट करते समय एंड-टू-एंड उपयोग परिदृश्यों को इकट्ठा करना और इन परिदृश्यों को टेस्ट केस में बदलना शामिल है। कैप्चर और रीप्ले के संभावित अनुप्रयोगों में प्रतिगमन परीक्षणों की पीढ़ी शामिल है। एससीएआरपीई टूल<ref>{{Cite journal |last1=Joshi |first1=Shrinivas |last2=Orso |first2=Alessandro |date=October 2007 |title=SCARPE: चयनात्मक कब्जा करने और कार्यक्रम निष्पादन की पुनरावृत्ति के लिए एक तकनीक और उपकरण|url=https://ieeexplore.ieee.org/document/4362636 |journal=2007 IEEE International Conference on Software Maintenance |pages=234–243 |doi=10.1109/ICSM.2007.4362636 |isbn=978-1-4244-1255-6 |s2cid=17718313}}</ref> चुनिंदा रूप से अध्ययन के तहत आवेदन के एक सबसेट को कैप्चर करता है क्योंकि यह निष्पादित होता है। जे रैप्चर एक निष्पादित जावा प्रोग्राम और होस्ट सिस्टम पर घटकों जैसे फाइल, या ग्राफिकल यूजर इंटरफेस पर घटनाओं के बीच बातचीत के अनुक्रम को कैप्चर करता है। फिर इन दृश्यों को अवलोकन-आधारित परीक्षण के लिए फिर से चलाया जा सकता है।<ref>{{Cite journal |last1=Steven |first1=John |last2=Chandra |first2=Pravir |last3=Fleck |first3=Bob |last4=Podgurski |first4=Andy |date=September 2000 |title=jRapture: अवलोकन-आधारित परीक्षण के लिए एक कैप्चर/रीप्ले टूल|url=https://dl.acm.org/doi/10.1145/347636.348993 |journal=ACM SIGSOFT Software Engineering Notes |language=en |volume=25 |issue=5 |pages=158–167 |doi=10.1145/347636.348993 |issn=0163-5948}}</ref>
कैप्चर और रीप्ले टेस्टिंग में एप्लिकेशन के साथ इंटरैक्ट करते समय एंड-टू-एंड उपयोग परिदृश्यों को इकट्ठा करना और इन परिदृश्यों को टेस्ट केस में बदलना सम्मिलित है। कैप्चर और रीप्ले के संभावित अनुप्रयोगों में प्रतिगमन परीक्षणों की पीढ़ी सम्मिलित है। एससीएआरपीई टूल<ref>{{Cite journal |last1=Joshi |first1=Shrinivas |last2=Orso |first2=Alessandro |date=October 2007 |title=SCARPE: चयनात्मक कब्जा करने और कार्यक्रम निष्पादन की पुनरावृत्ति के लिए एक तकनीक और उपकरण|url=https://ieeexplore.ieee.org/document/4362636 |journal=2007 IEEE International Conference on Software Maintenance |pages=234–243 |doi=10.1109/ICSM.2007.4362636 |isbn=978-1-4244-1255-6 |s2cid=17718313}}</ref> चुनिंदा रूप से अध्ययन के तहत आवेदन के एक सबसेट को कैप्चर करता है क्योंकि यह निष्पादित होता है। जे रैप्चर एक निष्पादित जावा प्रोग्राम और होस्ट सिस्टम पर घटकों जैसे फाइल, या ग्राफिकल यूजर इंटरफेस पर घटनाओं के बीच बातचीत के अनुक्रम को कैप्चर करता है। फिर इन दृश्यों को अवलोकन-आधारित परीक्षण के लिए फिर से चलाया जा सकता है।<ref>{{Cite journal |last1=Steven |first1=John |last2=Chandra |first2=Pravir |last3=Fleck |first3=Bob |last4=Podgurski |first4=Andy |date=September 2000 |title=jRapture: अवलोकन-आधारित परीक्षण के लिए एक कैप्चर/रीप्ले टूल|url=https://dl.acm.org/doi/10.1145/347636.348993 |journal=ACM SIGSOFT Software Engineering Notes |language=en |volume=25 |issue=5 |pages=158–167 |doi=10.1145/347636.348993 |issn=0163-5948}}</ref>


सायवा एट अल। महत्वपूर्ण सुरक्षा बगों के लिए उम्मीदवार पैच का परीक्षण करने के लिए तदर्थ परीक्षणों को उत्पन्न करने का प्रस्ताव है जो रिकॉर्ड किए गए उपयोगकर्ता निष्पादन निशान को फिर से चलाते हैं।<ref>{{Cite journal |last1=Saieva |first1=Anthony |last2=Singh |first2=Shirish |last3=Kaiser |first3=Gail |date=September 2020 |title=बाइनरी पुनर्लेखन के माध्यम से एड हॉक टेस्ट जनरेशन|url=https://ieeexplore.ieee.org/document/9252025 |journal=2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM) |location=Adelaide, Australia |publisher=IEEE |pages=115–126 |doi=10.1109/SCAM51674.2020.00018 |isbn=978-1-7281-9248-2 |s2cid=219618921}}</ref> पंक्ति फोकस्ड डिफरेंशियल यूनिट टेस्ट जेनरेट करने के लिए प्रोडक्शन में ऑब्जेक्ट प्रोफाइल कलेक्ट करती है। यह उपकरण व्युत्पन्न परीक्षण ऑरेकल के व्यवस्थित उत्पादन के साथ कैप्चर और रिप्ले को बढ़ाता है।<ref>{{Cite journal |last1=Tiwari |first1=Deepika |last2=Zhang |first2=Long |last3=Monperrus |first3=Martin |last4=Baudry |first4=Benoit |date=2021 |title=परीक्षण सूट में सुधार के लिए उत्पादन निगरानी|url=https://ieeexplore.ieee.org/document/9526340 |journal=IEEE Transactions on Reliability |volume=71 |issue=3 |pages=1381–1397 |arxiv=2012.01198 |doi=10.1109/TR.2021.3101318 |issn=0018-9529 |s2cid=227248080}}</ref> ऑटोग्राफ क्यूएल, ग्राफक्यूएल एपीआई पर उपयोगकर्ता के अनुरोधों की निगरानी करता है और परीक्षण मामले उत्पन्न करता है जो स्कीमा दोषों का पता लगा सकता है।<ref>{{Cite journal |last1=Zetterlund |first1=Louise |last2=Tiwari |first2=Deepika |last3=Monperrus |first3=Martin |last4=Baudry |first4=Benoit |date=April 2022 |title=स्कीमा दोषों का पता लगाने के लिए हार्वेस्टिंग प्रोडक्शन ग्राफक्यूएल क्वेरीज़|url=https://ieeexplore.ieee.org/document/9787849 |journal=2022 IEEE Conference on Software Testing, Verification and Validation (ICST) |location=Valencia, Spain |publisher=IEEE |pages=365–376 |doi=10.1109/ICST53961.2022.00014 |arxiv=2112.08267 |isbn=978-1-6654-6679-0|s2cid=245144782 }}</ref>
सायवा एट अल। महत्वपूर्ण सुरक्षा बगों के लिए उम्मीदवार पैच का परीक्षण करने के लिए तदर्थ परीक्षणों को उत्पन्न करने का प्रस्ताव है जो रिकॉर्ड किए गए उपयोगकर्ता निष्पादन निशान को फिर से चलाते हैं।<ref>{{Cite journal |last1=Saieva |first1=Anthony |last2=Singh |first2=Shirish |last3=Kaiser |first3=Gail |date=September 2020 |title=बाइनरी पुनर्लेखन के माध्यम से एड हॉक टेस्ट जनरेशन|url=https://ieeexplore.ieee.org/document/9252025 |journal=2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM) |location=Adelaide, Australia |publisher=IEEE |pages=115–126 |doi=10.1109/SCAM51674.2020.00018 |isbn=978-1-7281-9248-2 |s2cid=219618921}}</ref> पंक्ति फोकस्ड डिफरेंशियल यूनिट टेस्ट जेनरेट करने के लिए प्रोडक्शन में ऑब्जेक्ट प्रोफाइल कलेक्ट करती है। यह उपकरण व्युत्पन्न परीक्षण ऑरेकल के व्यवस्थित उत्पादन के साथ कैप्चर और रिप्ले को बढ़ाता है।<ref>{{Cite journal |last1=Tiwari |first1=Deepika |last2=Zhang |first2=Long |last3=Monperrus |first3=Martin |last4=Baudry |first4=Benoit |date=2021 |title=परीक्षण सूट में सुधार के लिए उत्पादन निगरानी|url=https://ieeexplore.ieee.org/document/9526340 |journal=IEEE Transactions on Reliability |volume=71 |issue=3 |pages=1381–1397 |arxiv=2012.01198 |doi=10.1109/TR.2021.3101318 |issn=0018-9529 |s2cid=227248080}}</ref> ऑटोग्राफ क्यूएल, ग्राफक्यूएल एपीआई पर उपयोगकर्ता के अनुरोधों की निगरानी करता है और परीक्षण मामले उत्पन्न करता है जो स्कीमा दोषों का पता लगा सकता है।<ref>{{Cite journal |last1=Zetterlund |first1=Louise |last2=Tiwari |first2=Deepika |last3=Monperrus |first3=Martin |last4=Baudry |first4=Benoit |date=April 2022 |title=स्कीमा दोषों का पता लगाने के लिए हार्वेस्टिंग प्रोडक्शन ग्राफक्यूएल क्वेरीज़|url=https://ieeexplore.ieee.org/document/9787849 |journal=2022 IEEE Conference on Software Testing, Verification and Validation (ICST) |location=Valencia, Spain |publisher=IEEE |pages=365–376 |doi=10.1109/ICST53961.2022.00014 |arxiv=2112.08267 |isbn=978-1-6654-6679-0|s2cid=245144782 }}</ref>
Line 383: Line 394:
{{main|सॉफ़्टवेयर गुणवत्ता}}
{{main|सॉफ़्टवेयर गुणवत्ता}}


गुणवत्ता उपायों में शुद्धता, पूर्णता, सुरक्षा और आईएसओ/आईईसी 9126 आवश्यकताएं जैसे क्षमता, विश्वसनीयता, दक्षता, सुवाह्यता, रखरखाव, अनुकूलता और उपयोगिता जैसे विषय शामिल हैं।
गुणवत्ता उपायों में शुद्धता, पूर्णता, सुरक्षा और आईएसओ/आईईसी 9126 आवश्यकताएं जैसे क्षमता, विश्वसनीयता, दक्षता, सुवाह्यता, रखरखाव, अनुकूलता और उपयोगिता जैसे विषय सम्मिलित हैं।


कई बार उपयोग किए जाने वाले सॉफ़्टवेयर मेट्रिक्स, या उपाय हैं, जिनका उपयोग सॉफ़्टवेयर की स्थिति या परीक्षण की पर्याप्तता को निर्धारित करने में सहायता के लिए किया जाता है।
कई बार उपयोग किए जाने वाले सॉफ़्टवेयर मेट्रिक्स, या उपाय हैं, जिनका उपयोग सॉफ़्टवेयर की स्थिति या परीक्षण की पर्याप्तता को निर्धारित करने में सहायता के लिए किया जाता है।
Line 389: Line 400:
=== परीक्षण कठिनाई का पदानुक्रम ===
=== परीक्षण कठिनाई का पदानुक्रम ===


प्रत्येक संदर्भ में एक पूर्ण परीक्षण सूट बनाने के लिए आवश्यक परीक्षण मामलों की संख्या के आधार पर (यानी एक परीक्षण सूट जैसे कि, यदि इसे परीक्षण के तहत कार्यान्वयन पर लागू किया जाता है, तो हम यह निर्धारित करने के लिए पर्याप्त जानकारी एकत्र करते हैं कि सिस्टम सही है या गलत कुछ विनिर्देशों के अनुसार), परीक्षण कठिनाई का एक पदानुक्रम प्रस्तावित किया गया है।<ref>{{Cite journal |last1=Rodríguez |first1=Ismael |last2=Llana |first2=Luis |last3=Rabanal |first3=Pablo |year=2014 |title=एक सामान्य परीक्षण क्षमता सिद्धांत: वर्ग, गुण, जटिलता और परीक्षण में कमी|url=https://zenodo.org/record/1008509 |journal=IEEE Transactions on Software Engineering |volume=40 |issue=9 |pages=862–894 |doi=10.1109/TSE.2014.2331690 |issn=0098-5589 |s2cid=6015996}}</ref><ref>{{Cite conference |last=Rodríguez |first=Ismael |year=2009 |title=एक सामान्य टेस्टेबिलिटी थ्योरी|pages=572–586 |doi=10.1007/978-3-642-04081-8_38 |isbn=978-3-642-04080-1 |book-title=CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings}}</ref> इसमें निम्नलिखित सॉफ्टवेयर परीक्षण योग्यता वर्ग शामिल हैं:
प्रत्येक संदर्भ में एक पूर्ण परीक्षण सूट बनाने के लिए आवश्यक परीक्षण मामलों की संख्या के आधार पर (यानी एक परीक्षण सूट जैसे कि, यदि इसे परीक्षण के तहत कार्यान्वयन पर लागू किया जाता है, तो हम यह निर्धारित करने के लिए पर्याप्त जानकारी एकत्र करते हैं कि सिस्टम सही है या गलत कुछ विनिर्देशों के अनुसार), परीक्षण कठिनाई का एक पदानुक्रम प्रस्तावित किया गया है।<ref>{{Cite journal |last1=Rodríguez |first1=Ismael |last2=Llana |first2=Luis |last3=Rabanal |first3=Pablo |year=2014 |title=एक सामान्य परीक्षण क्षमता सिद्धांत: वर्ग, गुण, जटिलता और परीक्षण में कमी|url=https://zenodo.org/record/1008509 |journal=IEEE Transactions on Software Engineering |volume=40 |issue=9 |pages=862–894 |doi=10.1109/TSE.2014.2331690 |issn=0098-5589 |s2cid=6015996}}</ref><ref>{{Cite conference |last=Rodríguez |first=Ismael |year=2009 |title=एक सामान्य टेस्टेबिलिटी थ्योरी|pages=572–586 |doi=10.1007/978-3-642-04081-8_38 |isbn=978-3-642-04080-1 |book-title=CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings}}</ref> इसमें निम्नलिखित सॉफ्टवेयर परीक्षण योग्यता वर्ग सम्मिलित हैं:


* कक्षा I: एक परिमित पूर्ण परीक्षण सूट मौजूद है।
* कक्षा I: एक परिमित पूर्ण परीक्षण सूट मौजूद है।
Line 397: Line 408:
* कक्षा V: सभी मामले।
* कक्षा V: सभी मामले।


यह साबित हो गया है कि प्रत्येक वर्ग अगले में सख्ती से शामिल है। उदाहरण के लिए, परीक्षण जब हम मानते हैं कि परीक्षण के तहत कार्यान्वयन के व्यवहार को नियतात्मक परिमित-राज्य मशीन द्वारा निविष्टियों और आउटपुट के कुछ ज्ञात परिमित सेटों के लिए निरूपित किया जा सकता है और कुछ ज्ञात अवस्थाएँ कक्षा I (और सभी बाद की कक्षाओं) से संबंधित हैं ). हालाँकि, यदि राज्यों की संख्या ज्ञात नहीं है, तो यह केवल द्वितीय श्रेणी से सभी वर्गों के अंतर्गत आता है। यदि परीक्षण के तहत कार्यान्वयन एक निर्धारक परिमित-राज्य मशीन होना चाहिए जो एकल ट्रेस (और इसकी निरंतरता) के लिए विनिर्देश को विफल कर दे, और इसकी राज्यों की संख्या अज्ञात है, तो यह केवल कक्षा III से कक्षाओं के अंतर्गत आता है। टेम्पोरल मशीनों का परीक्षण जहां कुछ वास्तविक-बाध्य अंतराल के भीतर इनपुट का उत्पादन किया जाता है, केवल कक्षा IV से संबंधित है, जबकि कई गैर-नियतात्मक प्रणालियों का परीक्षण केवल कक्षा V से संबंधित है (लेकिन सभी नहीं, और कुछ भी कक्षा I से संबंधित हैं) ). कक्षा I में शामिल करने के लिए कल्पित संगणना मॉडल की सरलता की आवश्यकता नहीं है, क्योंकि कुछ परीक्षण मामलों में किसी प्रोग्रामिंग भाषा में लिखे गए कार्यान्वयन शामिल हैं, और निरंतर परिमाण के आधार पर मशीनों के रूप में परिभाषित परीक्षण कार्यान्वयन, कक्षा I में साबित हुए हैं। अन्य विस्तृत मामले, जैसे [[मैथ्यू हेनेसी]] द्वारा टेस्टिंग फ्रेमवर्क मस्ट सिमेंटिक्स के तहत, और तर्कसंगत टाइमआउट वाली टेम्पोरल मशीन, क्लास II से संबंधित हैं।
यह साबित हो गया है कि प्रत्येक वर्ग अगले में सख्ती से सम्मिलित है। उदाहरण के लिए, परीक्षण जब हम मानते हैं कि परीक्षण के तहत कार्यान्वयन के व्यवहार को नियतात्मक परिमित-राज्य मशीन द्वारा निविष्टियों और आउटपुट के कुछ ज्ञात परिमित सेटों के लिए निरूपित किया जा सकता है और कुछ ज्ञात अवस्थाएँ कक्षा I (और सभी बाद की कक्षाओं) से संबंधित हैं ). हालाँकि, यदि राज्यों की संख्या ज्ञात नहीं है, तो यह केवल द्वितीय श्रेणी से सभी वर्गों के अंतर्गत आता है। यदि परीक्षण के तहत कार्यान्वयन एक निर्धारक परिमित-राज्य मशीन होना चाहिए जो एकल ट्रेस (और इसकी निरंतरता) के लिए विनिर्देश को विफल कर दे, और इसकी राज्यों की संख्या अज्ञात है, तो यह केवल कक्षा III से कक्षाओं के अंतर्गत आता है। टेम्पोरल मशीनों का परीक्षण जहां कुछ वास्तविक-बाध्य अंतराल के भीतर इनपुट का उत्पादन किया जाता है, केवल कक्षा IV से संबंधित है, जबकि कई गैर-नियतात्मक प्रणालियों का परीक्षण केवल कक्षा V से संबंधित है (लेकिन सभी नहीं, और कुछ भी कक्षा I से संबंधित हैं) ). कक्षा I में सम्मिलित करने के लिए कल्पित संगणना मॉडल की सरलता की आवश्यकता नहीं है, क्योंकि कुछ परीक्षण मामलों में किसी प्रोग्रामिंग भाषा में लिखे गए कार्यान्वयन सम्मिलित हैं, और निरंतर परिमाण के आधार पर मशीनों के रूप में परिभाषित परीक्षण कार्यान्वयन, कक्षा I में साबित हुए हैं। अन्य विस्तृत मामले, जैसे [[मैथ्यू हेनेसी]] द्वारा टेस्टिंग फ्रेमवर्क मस्ट सिमेंटिक्स के तहत, और तर्कसंगत टाइमआउट वाली टेम्पोरल मशीन, क्लास II से संबंधित हैं।


== आर्टिफैक्ट परीक्षण ==
== आर्टिफैक्ट परीक्षण ==
Line 403: Line 414:
एक सॉफ्टवेयर परीक्षण प्रक्रिया कई आर्टिफैक्ट (सॉफ्टवेयर विकास) का उत्पादन कर सकती है। उत्पादित वास्तविक कलाकृतियाँ उपयोग किए गए सॉफ़्टवेयर विकास मॉडल, हितधारक और संगठनात्मक आवश्यकताओं का एक कारक हैं।
एक सॉफ्टवेयर परीक्षण प्रक्रिया कई आर्टिफैक्ट (सॉफ्टवेयर विकास) का उत्पादन कर सकती है। उत्पादित वास्तविक कलाकृतियाँ उपयोग किए गए सॉफ़्टवेयर विकास मॉडल, हितधारक और संगठनात्मक आवश्यकताओं का एक कारक हैं।


; परीक्षण योजना: एक परीक्षण योजना एक दस्तावेज है जो उस दृष्टिकोण का विवरण देता है जो इच्छित परीक्षण गतिविधियों के लिए लिया जाएगा। योजना में उद्देश्य, कार्यक्षेत्र, प्रक्रियाओं और प्रक्रियाओं, कर्मियों की आवश्यकताओं और आकस्मिक योजनाओं जैसे पहलुओं को शामिल किया जा सकता है।<ref name="LewisSoftware16-2">{{Cite book |last=Lewis, W.E. |url=https://books.google.com/books?id=fgaBDd0TfT8C&pg=PA92 |title=सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार|publisher=CRC Press |year=2016 |isbn=978-1-4398-3436-7 |edition=3rd |pages=92–6}}</ref> परीक्षण योजना एकल योजना के रूप में आ सकती है जिसमें सभी प्रकार के परीक्षण (जैसे स्वीकृति या सिस्टम परीक्षण योजना) और योजना संबंधी विचार शामिल हैं, या इसे मास्टर परीक्षण योजना के रूप में जारी किया जा सकता है जो एक से अधिक विस्तृत परीक्षण का अवलोकन प्रदान करता है योजना (एक योजना की एक योजना)।<ref name="LewisSoftware16-2" />एक परीक्षण योजना, कुछ मामलों में, एक व्यापक परीक्षण रणनीति का हिस्सा हो सकती है, जो समग्र परीक्षण दृष्टिकोणों का दस्तावेजीकरण करती है, जो स्वयं एक मास्टर परीक्षण योजना या एक अलग आर्टिफैक्ट भी हो सकती है।
; परीक्षण योजना: एक परीक्षण योजना एक दस्तावेज है जो उस दृष्टिकोण का विवरण देता है जो इच्छित परीक्षण गतिविधियों के लिए लिया जाएगा। योजना में उद्देश्य, कार्यक्षेत्र, प्रक्रियाओं और प्रक्रियाओं, कर्मियों की आवश्यकताओं और आकस्मिक योजनाओं जैसे पहलुओं को सम्मिलित किया जा सकता है।<ref name="LewisSoftware16-2">{{Cite book |last=Lewis, W.E. |url=https://books.google.com/books?id=fgaBDd0TfT8C&pg=PA92 |title=सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार|publisher=CRC Press |year=2016 |isbn=978-1-4398-3436-7 |edition=3rd |pages=92–6}}</ref> परीक्षण योजना एकल योजना के रूप में आ सकती है जिसमें सभी प्रकार के परीक्षण (जैसे स्वीकृति या सिस्टम परीक्षण योजना) और योजना संबंधी विचार सम्मिलित हैं, या इसे मास्टर परीक्षण योजना के रूप में जारी किया जा सकता है जो एक से अधिक विस्तृत परीक्षण का अवलोकन प्रदान करता है योजना (एक योजना की एक योजना)।<ref name="LewisSoftware16-2" />एक परीक्षण योजना, कुछ मामलों में, एक व्यापक परीक्षण रणनीति का हिस्सा हो सकती है, जो समग्र परीक्षण दृष्टिकोणों का दस्तावेजीकरण करती है, जो स्वयं एक मास्टर परीक्षण योजना या एक अलग आर्टिफैक्ट भी हो सकती है।
; पता लगाने की क्षमता मैट्रिक्स: एक [[पता लगाने की क्षमता का मापदंड]] एक तालिका है जो दस्तावेज़ों का परीक्षण करने के लिए आवश्यकताओं या डिज़ाइन दस्तावेज़ों को सहसंबंधित करती है। आवश्यकता कवरेज पर विचार करके प्रतिगमन परीक्षणों की योजना बनाते समय निष्पादन के लिए परीक्षण मामलों का चयन करने के लिए संबंधित स्रोत दस्तावेज़ों को बदलते समय परीक्षणों को बदलने के लिए इसका उपयोग किया जाता है।
; पता लगाने की क्षमता मैट्रिक्स: एक [[पता लगाने की क्षमता का मापदंड]] एक तालिका है जो दस्तावेज़ों का परीक्षण करने के लिए आवश्यकताओं या डिज़ाइन दस्तावेज़ों को सहसंबंधित करती है। आवश्यकता कवरेज पर विचार करके प्रतिगमन परीक्षणों की योजना बनाते समय निष्पादन के लिए परीक्षण मामलों का चयन करने के लिए संबंधित स्रोत दस्तावेज़ों को बदलते समय परीक्षणों को बदलने के लिए इसका उपयोग किया जाता है।
; परीक्षण का मामला: एक परीक्षण मामले में आम तौर पर एक विशिष्ट पहचानकर्ता, एक डिजाइन विनिर्देश, पूर्व शर्त, घटनाओं, चरणों की एक श्रृंखला (जिसे क्रियाओं के रूप में भी जाना जाता है), इनपुट, आउटपुट, अपेक्षित परिणाम और वास्तविक परिणाम से आवश्यकता संदर्भ होते हैं। चिकित्सकीय रूप से परिभाषित, एक परीक्षण मामला एक इनपुट और एक अपेक्षित परिणाम है।<ref>{{Cite book |last=IEEE |title=सॉफ्टवेयर परीक्षण प्रलेखन के लिए IEEE मानक|title-link=IEEE 829 |publisher=IEEE |year=1998 |isbn=978-0-7381-1443-9 |location=New York}}</ref> यह 'शर्त x के लिए आपका व्युत्पन्न परिणाम y है' के रूप में संक्षिप्त हो सकता है, हालांकि आम तौर पर परीक्षण के मामले इनपुट परिदृश्य का अधिक विस्तार से वर्णन करते हैं और क्या परिणाम अपेक्षित हो सकते हैं। यह कभी-कभी चरणों की एक श्रृंखला हो सकती है (लेकिन अक्सर चरणों को एक अलग परीक्षण प्रक्रिया में शामिल किया जाता है जिसे अर्थव्यवस्था के मामले में कई परीक्षण मामलों के विरुद्ध प्रयोग किया जा सकता है) लेकिन एक अपेक्षित परिणाम या अपेक्षित परिणाम के साथ। वैकल्पिक फ़ील्ड एक टेस्ट केस आईडी, टेस्ट स्टेप, या निष्पादन संख्या का क्रम, संबंधित आवश्यकताएं, गहराई, टेस्ट श्रेणी, लेखक और चेक बॉक्स हैं कि क्या परीक्षण स्वचालित है और स्वचालित किया गया है। बड़े परीक्षण मामलों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं। एक परीक्षण मामले में वास्तविक परिणाम के लिए भी एक स्थान होना चाहिए। इन चरणों को एक वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस, या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है। एक डेटाबेस सिस्टम में, आप पिछले परीक्षण परिणामों को देखने में भी सक्षम हो सकते हैं, जिन्होंने परिणाम उत्पन्न किए, और उन परिणामों को उत्पन्न करने के लिए किस सिस्टम कॉन्फ़िगरेशन का उपयोग किया गया था। ये पिछले परिणाम आमतौर पर एक अलग तालिका में संग्रहीत किए जाते हैं।
; परीक्षण का मामला: एक परीक्षण मामले में सामान्यतः एक विशिष्ट पहचानकर्ता, एक डिजाइन विनिर्देश, पूर्व शर्त, घटनाओं, चरणों की एक श्रृंखला (जिसे क्रियाओं के रूप में भी जाना जाता है), इनपुट, आउटपुट, अपेक्षित परिणाम और वास्तविक परिणाम से आवश्यकता संदर्भ होते हैं। चिकित्सकीय रूप से परिभाषित, एक परीक्षण मामला एक इनपुट और एक अपेक्षित परिणाम है।<ref>{{Cite book |last=IEEE |title=सॉफ्टवेयर परीक्षण प्रलेखन के लिए IEEE मानक|title-link=IEEE 829 |publisher=IEEE |year=1998 |isbn=978-0-7381-1443-9 |location=New York}}</ref> यह 'शर्त x के लिए आपका व्युत्पन्न परिणाम y है' के रूप में संक्षिप्त हो सकता है, हालांकि सामान्यतः परीक्षण के मामले इनपुट परिदृश्य का अधिक विस्तार से वर्णन करते हैं और क्या परिणाम अपेक्षित हो सकते हैं। यह कभी-कभी चरणों की एक श्रृंखला हो सकती है (लेकिन प्रायः चरणों को एक अलग परीक्षण प्रक्रिया में सम्मिलित किया जाता है जिसे अर्थव्यवस्था के मामले में कई परीक्षण मामलों के विरुद्ध प्रयोग किया जा सकता है) लेकिन एक अपेक्षित परिणाम या अपेक्षित परिणाम के साथ। वैकल्पिक फ़ील्ड एक टेस्ट केस आईडी, टेस्ट स्टेप, या निष्पादन संख्या का क्रम, संबंधित आवश्यकताएं, गहराई, टेस्ट श्रेणी, लेखक और चेक बॉक्स हैं कि क्या परीक्षण स्वचालित है और स्वचालित किया गया है। बड़े परीक्षण मामलों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं। एक परीक्षण मामले में वास्तविक परिणाम के लिए भी एक स्थान होना चाहिए। इन चरणों को एक वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस, या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है। एक डेटाबेस सिस्टम में, आप पिछले परीक्षण परिणामों को देखने में भी सक्षम हो सकते हैं, जिन्होंने परिणाम उत्पन्न किए, और उन परिणामों को उत्पन्न करने के लिए किस सिस्टम कॉन्फ़िगरेशन का उपयोग किया गया था। ये पिछले परिणाम सामान्यतः एक अलग तालिका में संग्रहीत किए जाते हैं।
; [[टेस्ट स्क्रिप्ट]]: एक टेस्ट स्क्रिप्ट एक प्रक्रिया या प्रोग्रामिंग कोड है जो उपयोगकर्ता क्रियाओं को दोहराता है। प्रारंभ में, यह शब्द स्वचालित प्रतिगमन परीक्षण उपकरण द्वारा बनाए गए कार्य के उत्पाद से लिया गया था। किसी टूल या प्रोग्राम का उपयोग करके टेस्ट स्क्रिप्ट बनाने के लिए एक टेस्ट केस बेसलाइन होगा।
; [[टेस्ट स्क्रिप्ट]]: टेस्ट स्क्रिप्ट एक प्रक्रिया या प्रोग्रामिंग कोड है जो उपयोगकर्ता क्रियाओं को दोहराता है। प्रारंभ में, यह शब्द स्वचालित प्रतिगमन परीक्षण उपकरण द्वारा बनाए गए कार्य के उत्पाद से लिया गया था। किसी टूल या प्रोग्राम का उपयोग करके टेस्ट स्क्रिप्ट बनाने के लिए एक टेस्ट केस बेसलाइन होगा।
; टेस्ट सूट: टेस्ट केस के संग्रह के लिए सबसे आम शब्द टेस्ट सूट है। परीक्षण सूट में अक्सर परीक्षण मामलों के प्रत्येक संग्रह के लिए अधिक विस्तृत निर्देश या लक्ष्य होते हैं। इसमें निश्चित रूप से एक खंड होता है जहां परीक्षक परीक्षण के दौरान उपयोग किए जाने वाले सिस्टम कॉन्फ़िगरेशन की पहचान करता है। परीक्षण मामलों के एक समूह में पूर्वापेक्षित अवस्थाएँ या चरण और निम्नलिखित परीक्षणों का विवरण भी हो सकता है।
; टेस्ट सूट: टेस्ट केस के संग्रह के लिए सबसे साधारण शब्द टेस्ट सूट है। परीक्षण सूट में प्रायः परीक्षण मामलों के प्रत्येक संग्रह के लिए अधिक विस्तृत निर्देश या लक्ष्य होते हैं। इसमें निश्चित रूप से एक खंड होता है जहां परीक्षक परीक्षण के दौरान उपयोग किए जाने वाले सिस्टम कॉन्फ़िगरेशन की पहचान करता है। परीक्षण मामलों के समूह में पूर्वापेक्षित अवस्थाएँ या चरण और निम्नलिखित परीक्षणों का विवरण भी हो सकता है।
; [[परीक्षण स्थिरता]] या परीक्षण डेटा: ज्यादातर मामलों में, किसी विशेष सुविधा की समान कार्यक्षमता का परीक्षण करने के लिए मूल्यों या डेटा के एकाधिक सेट का उपयोग किया जाता है। सभी परीक्षण मूल्यों और परिवर्तनशील पर्यावरणीय घटकों को अलग-अलग फाइलों में एकत्र किया जाता है और परीक्षण डेटा के रूप में संग्रहीत किया जाता है। यह डेटा क्लाइंट को और उत्पाद या प्रोजेक्ट के साथ प्रदान करने के लिए भी उपयोगी है। [[डेटा उत्पादन का परीक्षण करें]] जनरेट करने की तकनीकें हैं।
; [[परीक्षण स्थिरता]] या परीक्षण डेटा: ज्यादातर मामलों में, किसी विशेष सुविधा की समान कार्यक्षमता का परीक्षण करने के लिए मूल्यों या डेटा के एकाधिक सेट का उपयोग किया जाता है। सभी परीक्षण मूल्यों और परिवर्तनशील पर्यावरणीय घटकों को अलग-अलग फाइलों में एकत्र किया जाता है और परीक्षण डेटा के रूप में संग्रहीत किया जाता है। यह डेटा क्लाइंट को और उत्पाद या प्रोजेक्ट के साथ प्रदान करने के लिए भी उपयोगी है। [[डेटा उत्पादन का परीक्षण करें]] जनरेट करने की तकनीकें हैं।
; [[दोहन ​​परीक्षण]]: सॉफ्टवेयर, उपकरण, डेटा इनपुट और आउटपुट के नमूने, और कॉन्फ़िगरेशन सभी को सामूहिक रूप से टेस्ट हार्नेस के रूप में संदर्भित किया जाता है।
; [[दोहन ​​परीक्षण]]: सॉफ्टवेयर, उपकरण, डेटा इनपुट और आउटपुट के नमूने, और कॉन्फ़िगरेशन सभी को सामूहिक रूप से टेस्ट हार्नेस के रूप में संदर्भित किया जाता है।
Line 419: Line 430:
== विवाद ==
== विवाद ==


कुछ प्रमुख सॉफ्टवेयर परीक्षण विवादों में शामिल हैं:
कुछ प्रमुख सॉफ्टवेयर परीक्षण विवादों में सम्मिलित हैं:


; कुशल बनाम पारंपरिक: क्या परीक्षकों को अनिश्चितता और निरंतर परिवर्तन की शर्तों के तहत काम करना सीखना चाहिए या क्या उन्हें "परिपक्वता" प्रक्रिया का लक्ष्य रखना चाहिए? कुशल परीक्षण आंदोलन को 2006 से मुख्य रूप से व्यावसायिक हलकों में बढ़ती लोकप्रियता मिली है, <ref>{{Cite web |last=Strom |first=David |date=July 1, 2009 |title=हम सब कहानी का हिस्सा हैं|url=http://stpcollaborative.com/knowledge/272-were-all-part-of-the-story |archive-url=https://web.archive.org/web/20090831182649/http://stpcollaborative.com/knowledge/272-were-all-part-of-the-story |archive-date=August 31, 2009 |publisher=Software Test & Performance Collaborative}}</ref><ref>{{Cite book |last=Griffiths |first=M. |title=फुर्तीली विकास सम्मेलन (ADC'05)|work=ieee.org |year=2005 |isbn=978-0-7695-2487-0 |pages=318–322 |chapter=Teaching agile project management to the PMI |doi=10.1109/ADC.2005.45 |s2cid=30322339}}</ref> जबकि सरकार और सैन्य <ref>{{Cite journal |last=Willison, John S. |date=April 2004 |title=फुर्तीली सेना के लिए फुर्तीली सॉफ्टवेयर डेवलपमेंट|url=http://www.stsc.hill.af.mil/crosstalk/2004/04/0404willison.htm |journal=CrossTalk |publisher=STSC |issue=April 2004 |archive-url=https://web.archive.org/web/20051029135922/http://www.stsc.hill.af.mil/crosstalk/2004/04/0404willison.html |archive-date=October 29, 2005}}</ref> सॉफ्टवेयर प्रदाता इस पद्धति का उपयोग करते हैं, लेकिन पारंपरिक परीक्षण-अंतिम मॉडल (जैसे, वाटरफॉल मॉडल में)।  
; कुशल बनाम पारंपरिक: क्या परीक्षकों को अनिश्चितता और निरंतर परिवर्तन की शर्तों के तहत काम करना सीखना चाहिए या क्या उन्हें "परिपक्वता" प्रक्रिया का लक्ष्य रखना चाहिए? कुशल परीक्षण आंदोलन को 2006 से मुख्य रूप से व्यावसायिक हलकों में बढ़ती लोकप्रियता मिली है, <ref>{{Cite web |last=Strom |first=David |date=July 1, 2009 |title=हम सब कहानी का हिस्सा हैं|url=http://stpcollaborative.com/knowledge/272-were-all-part-of-the-story |archive-url=https://web.archive.org/web/20090831182649/http://stpcollaborative.com/knowledge/272-were-all-part-of-the-story |archive-date=August 31, 2009 |publisher=Software Test & Performance Collaborative}}</ref><ref>{{Cite book |last=Griffiths |first=M. |title=फुर्तीली विकास सम्मेलन (ADC'05)|work=ieee.org |year=2005 |isbn=978-0-7695-2487-0 |pages=318–322 |chapter=Teaching agile project management to the PMI |doi=10.1109/ADC.2005.45 |s2cid=30322339}}</ref> जबकि सरकार और सैन्य <ref>{{Cite journal |last=Willison, John S. |date=April 2004 |title=फुर्तीली सेना के लिए फुर्तीली सॉफ्टवेयर डेवलपमेंट|url=http://www.stsc.hill.af.mil/crosstalk/2004/04/0404willison.htm |journal=CrossTalk |publisher=STSC |issue=April 2004 |archive-url=https://web.archive.org/web/20051029135922/http://www.stsc.hill.af.mil/crosstalk/2004/04/0404willison.html |archive-date=October 29, 2005}}</ref> सॉफ्टवेयर प्रदाता इस पद्धति का उपयोग करते हैं, लेकिन पारंपरिक परीक्षण-अंतिम मॉडल (जैसे, वाटरफॉल मॉडल में)।  
Line 426: Line 437:
; कुछ चिकित्सक घोषणा करते हैं कि परीक्षण क्षेत्र प्रमाणन के लिए तैयार नहीं है:<ref>{{Cite web |last=Kaner |first=Cem |author-link=Cem Kaner |year=2001 |title=NSF अनुदान प्रस्ताव 'सॉफ्टवेयर परीक्षण में शैक्षणिक और व्यावसायिक पाठ्यक्रमों की गुणवत्ता में महत्वपूर्ण सुधार के लिए नींव रखना'|url=http://www.testingeducation.org/general/nsf_grant.pdf |access-date=October 13, 2006 |archive-date=November 27, 2009 |archive-url=https://web.archive.org/web/20091127210430/http://www.testingeducation.org/general/nsf_grant.pdf |url-status=dead }}</ref> प्रस्तुत किये गए किसी प्रमाणन के लिए वास्तव में आवेदक को सॉफ्टवेयर का परीक्षण करने की अपनी क्षमता दिखाने की आवश्यकता नहीं है। कोई प्रमाणन व्यापक रूप से स्वीकृत ज्ञान पर आधारित नहीं होता है। प्रमाणीकरण स्वयं किसी व्यक्ति की उत्पादकता, कौशल या व्यावहारिक ज्ञान को नहीं माप सकता है, और एक परीक्षक के रूप में उनकी क्षमता, या व्यावसायिकता की गारंटी नहीं दे सकता है।<ref>{{Cite conference |last=Kaner |first=Cem |author-link=Cem Kaner |year=2003 |title=सॉफ्टवेयर परीक्षकों की प्रभावशीलता को मापना|url=http://www.testingeducation.org/a/mest.pdf |conference=STAR East |access-date=January 18, 2018 |archive-date=March 26, 2010 |archive-url=https://web.archive.org/web/20100326042728/http://www.testingeducation.org/a/mest.pdf |url-status=dead }}</ref>
; कुछ चिकित्सक घोषणा करते हैं कि परीक्षण क्षेत्र प्रमाणन के लिए तैयार नहीं है:<ref>{{Cite web |last=Kaner |first=Cem |author-link=Cem Kaner |year=2001 |title=NSF अनुदान प्रस्ताव 'सॉफ्टवेयर परीक्षण में शैक्षणिक और व्यावसायिक पाठ्यक्रमों की गुणवत्ता में महत्वपूर्ण सुधार के लिए नींव रखना'|url=http://www.testingeducation.org/general/nsf_grant.pdf |access-date=October 13, 2006 |archive-date=November 27, 2009 |archive-url=https://web.archive.org/web/20091127210430/http://www.testingeducation.org/general/nsf_grant.pdf |url-status=dead }}</ref> प्रस्तुत किये गए किसी प्रमाणन के लिए वास्तव में आवेदक को सॉफ्टवेयर का परीक्षण करने की अपनी क्षमता दिखाने की आवश्यकता नहीं है। कोई प्रमाणन व्यापक रूप से स्वीकृत ज्ञान पर आधारित नहीं होता है। प्रमाणीकरण स्वयं किसी व्यक्ति की उत्पादकता, कौशल या व्यावहारिक ज्ञान को नहीं माप सकता है, और एक परीक्षक के रूप में उनकी क्षमता, या व्यावसायिकता की गारंटी नहीं दे सकता है।<ref>{{Cite conference |last=Kaner |first=Cem |author-link=Cem Kaner |year=2003 |title=सॉफ्टवेयर परीक्षकों की प्रभावशीलता को मापना|url=http://www.testingeducation.org/a/mest.pdf |conference=STAR East |access-date=January 18, 2018 |archive-date=March 26, 2010 |archive-url=https://web.archive.org/web/20100326042728/http://www.testingeducation.org/a/mest.pdf |url-status=dead }}</ref>
;अध्ययन दोषों को ठीक करने के सापेक्ष व्यय को दिखाते थे
;अध्ययन दोषों को ठीक करने के सापेक्ष व्यय को दिखाते थे
: उनके परिचय और पता लगाने के आधार पर दोषों को ठीक करने के सापेक्ष खर्च को दिखाने के लिए उपयोग किए जाने वाले अध्ययनों की प्रयोज्यता पर विरोधी विचार हैं। उदाहरण के लिए ::आमतौर पर यह माना जाता है कि जितनी जल्दी दोष का पता लगाया जाता है, उसे ठीक करना उतना ही सस्ता होता है। निम्न तालिका में पाई गई अवस्था के आधार पर दोष को ठीक करने की लागत दिखाई गई है।<ref>{{Cite book |last=McConnell |first=Steve |url=https://archive.org/details/codecomplete0000mcco |title=कोड पूर्ण|publisher=Microsoft Press |year=2004 |isbn=978-0-7356-1967-8 |edition=2nd |page=[https://archive.org/details/codecomplete0000mcco/page/29 29] |url-access=registration}}</ref> उदाहरण के लिए, यदि आवश्यकताओं में कोई समस्या केवल रिलीज़ के बाद पाई जाती है, तो इसे ठीक करने की लागत आवश्यकताओं की समीक्षा द्वारा पहले ही पाए जाने की तुलना में 10-100 गुना अधिक होगी। आधुनिक निरंतर तैनाती प्रथाओं और क्लाउड-आधारित सेवाओं के आगमन के साथ, समय के साथ पुन: तैनाती और रखरखाव की लागत कम हो सकती है।
: उनके परिचय और पता लगाने के आधार पर दोषों को ठीक करने के सापेक्ष खर्च को दिखाने के लिए उपयोग किए जाने वाले अध्ययनों की प्रयोज्यता पर विरोधी विचार हैं। उदाहरण के लिए ::सामान्यतः यह माना जाता है कि जितनी जल्दी दोष का पता लगाया जाता है, उसे ठीक करना उतना ही सस्ता होता है। निम्न तालिका में पाई गई अवस्था के आधार पर दोष को ठीक करने की लागत दिखाई गई है।<ref>{{Cite book |last=McConnell |first=Steve |url=https://archive.org/details/codecomplete0000mcco |title=कोड पूर्ण|publisher=Microsoft Press |year=2004 |isbn=978-0-7356-1967-8 |edition=2nd |page=[https://archive.org/details/codecomplete0000mcco/page/29 29] |url-access=registration}}</ref> उदाहरण के लिए, यदि आवश्यकताओं में कोई समस्या केवल रिलीज़ के बाद पाई जाती है, तो इसे ठीक करने की लागत आवश्यकताओं की समीक्षा द्वारा पहले ही पाए जाने की तुलना में 10-100 गुना अधिक होगी। आधुनिक निरंतर तैनाती प्रथाओं और क्लाउड-आधारित सेवाओं के आगमन के साथ, समय के साथ पुन: तैनाती और रखरखाव की लागत कम हो सकती है।


{| class="wikitable" style="text-align:center;"
{| class="wikitable" style="text-align:center;"
Line 463: Line 474:
जिस डेटा से यह तालिका एक्सट्रपलेशन की गई है वह कम है। लॉरेंट बॉसविट अपने विश्लेषण में कहते हैं:
जिस डेटा से यह तालिका एक्सट्रपलेशन की गई है वह कम है। लॉरेंट बॉसविट अपने विश्लेषण में कहते हैं:


"छोटी परियोजनाएं" वक्र प्रथम वर्ष के छात्रों की केवल दो टीमों से निकला है, एक नमूना आकार इतना छोटा है कि "सामान्य रूप से छोटी परियोजनाओं" को एक्सट्रपलेशन करना पूरी तरह से अनिश्चित है। जीटीई अध्ययन अपने डेटा की व्याख्या नहीं करता है, इसके अलावा यह कहना है कि यह दो परियोजनाओं से आया है, एक बड़ी और एक छोटी। बेल लैब्स "सेफगार्ड" प्रोजेक्ट के लिए उद्धृत पेपर विशेष रूप से यह दावा करता है कि बोहेम के डेटा बिंदुओं का सुझाव देने वाले ठीक-ठाक डेटा एकत्र किए गए हैं। आईबीएम अध्ययन (फगन का पेपर) में ऐसे दावे शामिल हैं जो बोहेम के ग्राफ के विपरीत प्रतीत होते हैं और कोई संख्यात्मक परिणाम नहीं है जो स्पष्ट रूप से उनके डेटा बिंदुओं के अनुरूप हो।
"छोटी परियोजनाएं" वक्र प्रथम वर्ष के छात्रों की केवल दो टीमों से निकला है, एक नमूना आकार इतना छोटा है कि "सामान्य रूप से छोटी परियोजनाओं" को एक्सट्रपलेशन करना पूरी तरह से अनिश्चित है। जीटीई अध्ययन अपने डेटा की व्याख्या नहीं करता है, इसके अलावा यह कहना है कि यह दो परियोजनाओं से आया है, एक बड़ी और एक छोटी। बेल लैब्स "सेफगार्ड" प्रोजेक्ट के लिए उद्धृत पेपर विशेष रूप से यह दावा करता है कि बोहेम के डेटा बिंदुओं का सुझाव देने वाले ठीक-ठाक डेटा एकत्र किए गए हैं। आईबीएम अध्ययन (फगन का पेपर) में ऐसे दावे सम्मिलित हैं जो बोहेम के ग्राफ के विपरीत प्रतीत होते हैं और कोई संख्यात्मक परिणाम नहीं है जो स्पष्ट रूप से उनके डेटा बिंदुओं के अनुरूप हो।


2010 में "मेकिंग सॉफ्टवेयर" के लिए लिखने के अलावा, बोहेम ने टीआरडब्ल्यू डेटा के लिए एक पेपर का हवाला भी नहीं दिया, और वहां उन्होंने 1976 के मूल लेख का हवाला दिया। सही समय पर टीआरडब्ल्यू में बोहेम द्वारा इसका हवाला देने के लिए एक बड़ा अध्ययन किया गया था, लेकिन उस पेपर में उस तरह का डेटा नहीं है जो बोहेम के दावों का समर्थन करता हो।<ref name="Bossavit-Leprechauns">{{Cite book |last=Bossavit |first=Laurent |title=सॉफ्टवेयर इंजीनियरिंग के लेप्रेचौंस: कैसे लोककथाएं वास्तविकता में बदल जाती हैं और इसके बारे में क्या करना है|date=November 20, 2013 |publisher=leanpub |chapter=The cost of defects: an illustrated history}}</ref>
2010 में "मेकिंग सॉफ्टवेयर" के लिए लिखने के अलावा, बोहेम ने टीआरडब्ल्यू डेटा के लिए एक पेपर का हवाला भी नहीं दिया, और वहां उन्होंने 1976 के मूल लेख का हवाला दिया। सही समय पर टीआरडब्ल्यू में बोहेम द्वारा इसका हवाला देने के लिए एक बड़ा अध्ययन किया गया था, लेकिन उस पेपर में उस तरह का डेटा नहीं है जो बोहेम के दावों का समर्थन करता हो।<ref name="Bossavit-Leprechauns">{{Cite book |last=Bossavit |first=Laurent |title=सॉफ्टवेयर इंजीनियरिंग के लेप्रेचौंस: कैसे लोककथाएं वास्तविकता में बदल जाती हैं और इसके बारे में क्या करना है|date=November 20, 2013 |publisher=leanpub |chapter=The cost of defects: an illustrated history}}</ref>
Line 470: Line 481:


=== सॉफ्टवेयर सत्यापन और सत्यापन ===
=== सॉफ्टवेयर सत्यापन और सत्यापन ===
{{main|Verification and validation (software)|Software quality control}}
{{main|सत्यापन और प्रमाणीकरण (सॉफ्टवेयर)|सॉफ्टवेयर गुणवत्ता नियंत्रण}}
[[सत्यापन और सत्यापन (सॉफ्टवेयर)]] के सहयोग से सॉफ्टवेयर परीक्षण का उपयोग किया जाता है:<ref name="tran">{{Cite web |last=Tran |first=Eushiuan |year=1999 |title=सत्यापन/सत्यापन/प्रमाणन|url=http://www.ece.cmu.edu/~koopman/des_s99/verification/index.html |access-date=August 13, 2008 |publisher=Carnegie Mellon University |type=coursework}}</ref>
[[सत्यापन और सत्यापन (सॉफ्टवेयर)]] के सहयोग से सॉफ्टवेयर परीक्षण का उपयोग किया जाता है:<ref name="tran">{{Cite web |last=Tran |first=Eushiuan |year=1999 |title=सत्यापन/सत्यापन/प्रमाणन|url=http://www.ece.cmu.edu/~koopman/des_s99/verification/index.html |access-date=August 13, 2008 |publisher=Carnegie Mellon University |type=coursework}}</ref>
* सत्यापन: क्या हमने सॉफ्टवेयर सही बनाया है? (यानी, क्या यह आवश्यकताओं को लागू करता है)।
* सत्यापन: क्या हमने सॉफ्टवेयर सही बनाया है? (यानी, क्या यह आवश्यकताओं को लागू करता है)।
* मान्यता: क्या हमने सही सॉफ्टवेयर बनाया है? (यानी, क्या डिलिवरेबल्स ग्राहक को संतुष्ट करते हैं)।
* मान्यता: क्या हमने सही सॉफ्टवेयर बनाया है? (यानी, क्या डिलिवरेबल्स ग्राहक को संतुष्ट करते हैं)।


सत्यापन और सत्यापन शब्द आमतौर पर उद्योग में परस्पर विनिमय के लिए उपयोग किए जाते हैं; विरोधाभासी परिभाषाओं के साथ परिभाषित इन दो शब्दों को देखना भी आम है। सॉफ्टवेयर इंजीनियरिंग शब्दावली की IEEE मानक एसोसिएशन शब्दावली के अनुसार:<ref name=IEEEglossary />{{rp|80–81}}
सत्यापन और सत्यापन शब्द सामान्यतः उद्योग में परस्पर विनिमय के लिए उपयोग किए जाते हैं; विरोधाभासी परिभाषाओं के साथ परिभाषित इन दो शब्दों को देखना भी साधारण है। सॉफ्टवेयर इंजीनियरिंग शब्दावली की आईईईई  मानक एसोसिएशन शब्दावली के अनुसार:<ref name=IEEEglossary />{{rp|80–81}}
: सत्यापन एक प्रणाली या घटक के मूल्यांकन की प्रक्रिया है जो यह निर्धारित करती है कि किसी दिए गए विकास चरण के उत्पाद उस चरण की शुरुआत में लगाए गए शर्तों को पूरा करते हैं या नहीं।
: सत्यापन एक प्रणाली या घटक के मूल्यांकन की प्रक्रिया है जो यह निर्धारित करती है कि किसी दिए गए विकास चरण के उत्पाद उस चरण आरंभ में लगाए गए शर्तों को पूरा करते हैं या नहीं।
: सत्यापन विकास प्रक्रिया के दौरान या उसके अंत में एक प्रणाली या घटक का मूल्यांकन करने की प्रक्रिया है, यह निर्धारित करने के लिए कि क्या यह निर्दिष्ट आवश्यकताओं को पूरा करता है।
: सत्यापन विकास प्रक्रिया के दौरान या उसके अंत में एक प्रणाली या घटक का मूल्यांकन करने की प्रक्रिया है, यह निर्धारित करने के लिए कि क्या यह निर्दिष्ट आवश्यकताओं को पूरा करता है।


और, ISO 9000 मानक के अनुसार:
और, आईएसओ 9000 मानक के अनुसार:


: सत्यापन परीक्षा द्वारा और वस्तुनिष्ठ साक्ष्य के प्रावधान के माध्यम से पुष्टि है कि निर्दिष्ट आवश्यकताओं को पूरा किया गया है।
: सत्यापन परीक्षा द्वारा और वस्तुनिष्ठ साक्ष्य के प्रावधान के माध्यम से पुष्टि है कि निर्दिष्ट आवश्यकताओं को पूरा किया गया है।
Line 486: Line 497:
विरोधाभास आवश्यकताओं और निर्दिष्ट आवश्यकताओं की अवधारणाओं के उपयोग के कारण होता है लेकिन विभिन्न अर्थों के साथ।
विरोधाभास आवश्यकताओं और निर्दिष्ट आवश्यकताओं की अवधारणाओं के उपयोग के कारण होता है लेकिन विभिन्न अर्थों के साथ।


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


लेकिन, आईएसओ 9000 के लिए, निर्दिष्ट आवश्यकताएं विशिष्टताओं का समूह हैं, जैसा कि अभी ऊपर बताया गया है, जिसे सत्यापित किया जाना चाहिए। एक विनिर्देश, जैसा कि पहले बताया गया है, एक सॉफ्टवेयर विकास प्रक्रिया चरण का उत्पाद है जो इनपुट के रूप में एक और विनिर्देश प्राप्त करता है। एक विनिर्देश सफलतापूर्वक सत्यापित होता है जब वह अपने इनपुट विनिर्देश को सही ढंग से लागू करता है। एसआरएस को छोड़कर सभी विनिर्देशों को सत्यापित किया जा सकता है क्योंकि यह पहला है (हालांकि इसे मान्य किया जा सकता है)। उदाहरण: डिज़ाइन विशिष्टता को SRS लागू करना चाहिए; और, निर्माण चरण की कलाकृतियों को डिजाइन विशिष्टता को लागू करना चाहिए।
लेकिन, आईएसओ 9000 के लिए, निर्दिष्ट आवश्यकताएं विशिष्टताओं का समूह हैं, जैसा कि अभी ऊपर बताया गया है, जिसे सत्यापित किया जाना चाहिए। एक विनिर्देश, जैसा कि पहले बताया गया है, एक सॉफ्टवेयर विकास प्रक्रिया चरण का उत्पाद है जो इनपुट के रूप में एक और विनिर्देश प्राप्त करता है। एक विनिर्देश सफलतापूर्वक सत्यापित होता है जब वह अपने इनपुट विनिर्देश को सही ढंग से लागू करता है। एसआरएस को छोड़कर सभी विनिर्देशों को सत्यापित किया जा सकता है क्योंकि यह पहला है (हालांकि इसे मान्य किया जा सकता है)। उदाहरण: डिज़ाइन विशिष्टता को एसआरएस लागू करना चाहिए; और, निर्माण चरण की कलाकृतियों को डिजाइन विशिष्टता को लागू करना चाहिए।


इसलिए, जब इन शब्दों को सामान्य शब्दों में परिभाषित किया जाता है, तो स्पष्ट विरोधाभास गायब हो जाता है।
इसलिए, जब इन शब्दों को सामान्य शब्दों में परिभाषित किया जाता है, तो स्पष्ट विरोधाभास गायब हो जाता है।


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


कुछ लोग यह तर्क दे सकते हैं कि, SRS के लिए, इनपुट हितधारकों के शब्द हैं और इसलिए, SRS सत्यापन SRS सत्यापन के समान है। इस तरह से सोचना उचित नहीं है क्योंकि यह केवल अधिक भ्रम पैदा करता है। एक औपचारिक और तकनीकी इनपुट दस्तावेज़ को शामिल करने वाली प्रक्रिया के रूप में सत्यापन के बारे में सोचना बेहतर है।
कुछ लोग यह तर्क दे सकते हैं कि, एसआरएस के लिए, इनपुट हितधारकों के शब्द हैं और इसलिए, एसआरएस सत्यापन एसआरएस सत्यापन के समान है। इस तरह से सोचना उचित नहीं है क्योंकि यह केवल अधिक भ्रम पैदा करता है। एक औपचारिक और तकनीकी इनपुट दस्तावेज़ को सम्मिलित करने वाली प्रक्रिया के रूप में सत्यापन के बारे में सोचना बेहतर है।


=== सॉफ्टवेयर गुणवत्ता आश्वासन ===
=== सॉफ्टवेयर गुणवत्ता आश्वासन ===


सॉफ़्टवेयर परीक्षण को सॉफ़्टवेयर गुणवत्ता आश्वासन (SQA) प्रक्रिया का एक भाग माना जा सकता है।<ref name="Kaner2" />{{rp|347}} SQA में, सॉफ़्टवेयर प्रक्रिया विशेषज्ञ और लेखा परीक्षक दस्तावेज़ीकरण, कोड और सिस्टम जैसी कलाकृतियों के बजाय सॉफ़्टवेयर विकास प्रक्रिया से संबंधित हैं। वे वितरित सॉफ़्टवेयर में समाप्त होने वाले दोषों की संख्या को कम करने के लिए सॉफ़्टवेयर इंजीनियरिंग प्रक्रिया की जाँच और परिवर्तन करते हैं: तथाकथित दोष दर। स्वीकार्य दोष दर क्या है यह सॉफ्टवेयर की प्रकृति पर निर्भर करता है; एक वास्तविक हवाई जहाज के लिए सॉफ्टवेयर की तुलना में एक उड़ान सिम्युलेटर वीडियो गेम में बहुत अधिक दोष सहिष्णुता होगी। हालांकि एसक्यूए के साथ घनिष्ठ संबंध हैं, परीक्षण विभाग अक्सर स्वतंत्र रूप से मौजूद होते हैं, और कुछ कंपनियों में कोई एसक्यूए कार्य नहीं हो सकता है।{{citation needed|reason=archive July 2012|date=December 2017}}
सॉफ़्टवेयर परीक्षण को सॉफ़्टवेयर गुणवत्ता आश्वासन (एसक्यूए) प्रक्रिया का एक हिस्सा माना जा सकता है।<ref name="Kaner2" />  एसक्यूए में, सॉफ़्टवेयर प्रक्रिया विशेषज्ञ और लेखा परीक्षक दस्तावेज़, कोड और सिस्टम जैसी कलाकृतियों के बजाय सॉफ़्टवेयर विकास प्रक्रिया से संबंधित होते हैं। वे वितरित सॉफ़्टवेयर में समाप्त होने वाले दोषों की संख्या को कम करने के लिए स्वयं सॉफ़्टवेयर इंजीनियरिंग प्रक्रिया की जाँच करते हैं और उसे बदलते हैं: तथाकथित दोष दर। एक स्वीकार्य दोष दर क्या होती है यह सॉफ्टवेयर की प्रकृति पर निर्भर करता है; एक उड़ान सिम्युलेटर वीडियो गेम में एक वास्तविक हवाई जहाज के सॉफ्टवेयर की तुलना में बहुत अधिक दोष सहनशीलता होगी। हालांकि एसक्यूए के साथ घनिष्ठ संबंध हैं, परीक्षण विभाग प्रायः स्वतंत्र रूप से मौजूद होते हैं, और हो सकता है कि कुछ कंपनियों में एसक्यूए का कोई कार्य न हो।
सॉफ्टवेयर परीक्षण हितधारकों को गुणवत्ता संबंधी जानकारी प्रदान करने के लिए परीक्षण के तहत सॉफ्टवेयर की जांच करने की गतिविधि है। इसके विपरीत, क्यूए ([[गुणवत्ता आश्वासन]]) ग्राहकों तक पहुंचने से दोषों को रोकने के उद्देश्य से नीतियों और प्रक्रियाओं का कार्यान्वयन है।
 
सॉफ्टवेयर परीक्षण हितधारकों को गुणवत्ता संबंधी जानकारी प्रदान करने के लिए परीक्षण के तहत सॉफ्टवेयर की जांच करने के लिए एक गतिविधि है। इसके विपरीत, क्यूए ([[गुणवत्ता आश्वासन]]) नीतियों और प्रक्रियाओं का कार्यान्वयन है, जो दोषों को ग्राहकों तक पहुंचने से रोकने के उद्देश्य से है।


== यह भी देखें ==
== यह भी देखें ==
{{Div col|colwidth=40em}}
{{Div col|colwidth=40em}}
* {{Annotated link|Data validation}}
* {{Annotated link|डेटा प्रमाणीकरण}}
* {{Annotated link|Dynamic program analysis}}
* {{Annotated link|डायनेमिक प्रोग्राम विश्लेषण}}
* {{Annotated link|Formal verification}}
* {{Annotated link|औपचारिक सत्यापन}}
* {{Annotated link|Graphical user interface testing}}
* {{Annotated link|ग्राफिकल यूजर इंटरफेस परीक्षण}}
* {{Annotated link|Independent test organization}}
* {{Annotated link|स्वतंत्र परीक्षण संगठन}}
* {{Annotated link|Manual testing}}
* {{Annotated link|मैनुअल परीक्षण}}
* {{Annotated link|Orthogonal array testing}}
* {{Annotated link|ऑर्थोगोनल ऐरे परिक्षण}}
* {{Annotated link|Pair testing}}
* {{Annotated link|पेअर परीक्षण}}
* {{Annotated link|Reverse semantic traceability}}
* {{Annotated link|रिवर्स सिमेंटिक ट्रैसेबिलिटी}}
* {{Annotated link|Software testing tactics}}
* {{Annotated link|सॉफ्टवेयर परीक्षण रणनीति}}
* {{Annotated link|Test management tool}}
* {{Annotated link|परीक्षण प्रबंधन उपकरण}}
* {{Annotated link|Trace table}}
* {{Annotated link|ट्रेस टेबल}}
* {{Annotated link|Web testing}}
* {{Annotated link|वेब परीक्षण}}
{{div col end}}
{{div col end}}
== संदर्भ ==
== संदर्भ ==
{{Reflist}}
{{Reflist}}


 
== अग्रिम पठन ==
== आगे की पढाई ==


* {{Cite magazine |last=Meyer |first=Bertrand |date=August 2008 |title=Seven Principles of Software Testing |url=http://se.ethz.ch/~meyer/publications/testing/principles.pdf |magazine=Computer |volume=41 |pages=99–101 |doi=10.1109/MC.2008.306 |access-date=November 21, 2017 |number=8}}
* {{Cite magazine |last=Meyer |first=Bertrand |date=August 2008 |title=Seven Principles of Software Testing |url=http://se.ethz.ch/~meyer/publications/testing/principles.pdf |magazine=Computer |volume=41 |pages=99–101 |doi=10.1109/MC.2008.306 |access-date=November 21, 2017 |number=8}}
==इस पेज में लापता आंतरिक लिंक की सूची==
*परीक्षण ओरेकल
*दोष (प्रौद्योगिकी)
*सोर्स कोड
*मानव त्रुटि
*कंप्यूटर का प्रदर्शन
*रख-रखाव
*प्रयोज्य
*अनिच्छुक अनुकूलता
*स्थिरता अभियांत्रिकी)
*सॉफ्टवेयर पूर्वाभ्यास
*सॉफ्टवेयर निरीक्षण
*को़ड समीक्षा
*परीक्षण मामला
*समारोह (कंप्यूटर विज्ञान)
*स्थैतिक कार्यक्रम विश्लेषण
*विधि ठूंठ
*सॉफ्टवेयर सत्यापन
*सॉफ्टवेयर सत्यापन
*सं कनेर
*खोजपूर्ण परीक्षण
*समारोह अंक
*बहाव को काबू करें
*समान विभाजन
*मॉडल आधारित परीक्षण
*उदाहरण
*क्रियात्मक परीक्षण
*अध्याय परीक्षा
*स्वीकरण परीक्षा
*एक्सेप्शन हेंडलिंग
*कोने का मामला
*सॉफ्टवेयर की रखरखाव
*गुणवत्ता संचालकीय प्रणाली
*सॉफ्टवेयर डेवलपमेंट
*सॉफ्टवेयर परीक्षण रणनीति
*मतिहीनता (कंप्यूटर विज्ञान)
*सॉफ्टवेयर वर्जनिंग
*कंप्यूटर अनुकूलता
*सत्यापन परीक्षण बनाएँ
*धुआँ परीक्षण (सॉफ्टवेयर)
*सॉफ्टवेयर प्रतिगमन
*सदा बीटा
*बाधा (गणित)
*कार्यकारी आवश्यकताएं
*वास्तविक समय परीक्षण
*1990 के अमेरिकी विकलांग अधिनियम
*1973 के पुनर्वास अधिनियम में धारा 508 संशोधन
*पर्यावरणपरिवर्ती तारक
*सीजेके वर्ण
*देश द्वारा दिनांक और समय अंकन
*अक्षरों को सांकेतिक अक्षरों में बदलना
*परीक्षण संचालित विकास
*लगातार एकीकरण
*टेस्ट परिदृश्य
*आवश्यकताओं के विश्लेषण
*ब्रेकपाइंट
*रूपरेखा (कंप्यूटर प्रोग्रामिंग)
*हॉट स्पॉट (कंप्यूटर साइंस)
*कार्यक्रम एनिमेशन
*स्थिरता अभियांत्रिकी
*परिमित अवस्था मशीन
*विरूपण साक्ष्य (सॉफ्टवेयर विकास)
*झरना मॉडल
*निरंतर तैनाती
*IEEE मानक संघ
*सॉफ्टवेयर क्वालिटी एश्योरेंस
== बाहरी कड़ियाँ ==
== बाहरी कड़ियाँ ==
{{commons category}}
{{WVD}}
* {{curlie|Computers/Programming/Software_Testing/Products_and_Tools|Software testing tools and products}}
* {{curlie|Computers/Programming/Software_Testing/Products_and_Tools|Software testing tools and products}}
* [http://www.economist.com/science/tq/displaystory.cfm?story_id=10789417 "Software that makes Software better" Economist.com]
* [http://www.economist.com/science/tq/displaystory.cfm?story_id=10789417 "Software that makes Software better" Economist.com]


{{Computer science}}
{{Computer science}}
{{Software engineering}}
{{Software testing}}
{{Authority control}}
[[श्रेणी: सॉफ्टवेयर परीक्षण| ]]
[[श्रेणी:कंप्यूटर व्यवसाय]]


[[Category: Machine Translated Page]]
[[Category:All articles with unsourced statements]]
[[Category:Articles with Curlie links]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:Articles with invalid date parameter in template]]
[[Category:Articles with unsourced statements from January 2008]]
[[Category:CS1 English-language sources (en)]]
[[Category:Citation Style 1 templates|M]]
[[Category:Collapse templates]]
[[Category:Created On 17/12/2022]]
[[Category:Created On 17/12/2022]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Multi-column templates]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists]]
[[Category:Pages using div col with small parameter]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Sidebars with styles needing conversion]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates Translated in Hindi]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates based on the Citation/CS1 Lua module]]
[[Category:Templates generating COinS|Cite magazine]]
[[Category:Templates generating microformats]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that are not mobile friendly]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Templates using under-protected Lua modules]]
[[Category:Wikipedia fully protected templates|Cite magazine]]
[[Category:Wikipedia metatemplates]]

Latest revision as of 15:17, 4 September 2023

Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries
Outlines

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

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

सॉफ्टवेयर परीक्षण, सॉफ्टवेयर की गुणवत्ता और उपयोगकर्ताओं या प्रायोजकों को इसकी विफलता के जोखिम के बारे में उद्देश्यपूर्ण, स्वतंत्र जानकारी प्रदान कर सकता है।[1]

सॉफ्टवेयर परीक्षण कुछ विशिष्ट परिकल्पनाओं की धारणा के तहत सॉफ्टवेयर की शुद्धता का निर्धारण कर सकता है (नीचे परीक्षण कठिनाई का पदानुक्रम देखें), परीक्षण सॉफ्टवेयर के भीतर सभी विफलताओं की पहचान नहीं कर सकता है।[2] इसके बजाय, यह एक आलोचना या तुलना प्रस्तुत करता है जो उत्पाद की स्थिति और व्यवहार की तुलना परीक्षण ऑरेकल - सिद्धांतों या तंत्रों से करता है जिसके द्वारा कोई समस्या को पहचान सकता है। इन भविष्यवाणियों में विनिर्देश, अनुबंध,[3] तुलनीय उत्पाद, एक ही उत्पाद के पिछले संस्करण, इच्छित या अपेक्षित उद्देश्य के बारे में अनुमान, उपयोगकर्ता या ग्राहक अपेक्षाएं, प्रासंगिक मानक, लागू कानून, या अन्य मानदंड सम्मिलित हो सकते हैं (लेकिन इन तक सीमित नहीं हैं) .

परीक्षण का प्राथमिक उद्देश्य सॉफ़्टवेयर विफलताओं का पता लगाना है ताकि दोषों को खोजा और ठीक किया जा सके। परीक्षण यह स्थापित नहीं कर सकता है कि कोई उत्पाद सभी परिस्थितियों में ठीक से काम करता है, लेकिन केवल यह कि यह विशिष्ट परिस्थितियों में ठीक से काम नहीं करता है।[4] सॉफ्टवेयर परीक्षण के दायरे में कोड की परीक्षा के साथ-साथ विभिन्न वातावरणों और स्थितियों में उस कोड के निष्पादन के साथ-साथ कोड के पहलुओं की जांच भी सम्मिलित हो सकती है: क्या यह वह करता है जो इसे करना चाहिए और इसे करने की आवश्यकता होती है। सॉफ़्टवेयर विकास की वर्तमान संस्कृति में, परीक्षण संगठन विकास टीम से अलग हो सकता है। परीक्षण टीम के सदस्यों के लिए विभिन्न भूमिकाएँ हैं। सॉफ़्टवेयर परीक्षण से प्राप्त जानकारी का उपयोग उस प्रक्रिया को ठीक करने के लिए किया जा सकता है जिसके द्वारा सॉफ़्टवेयर विकसित किया जाता है।[5]: 41–43 

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

दोष और असफलता

सॉफ़्टवेयर दोष निम्न प्रक्रिया के माध्यम से होते हैं: प्रोग्रामर एक त्रुटि (गलती) करता है, जिसके परिणामस्वरूप सॉफ़्टवेयर स्रोत कोड में एक दोष (दोष, बग) होता है। यदि यह दोष निष्पादित किया जाता है, तो कुछ स्थितियों में सिस्टम गलत परिणाम देगा, जिससे विफलता होगी।[6]: 31 

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

कोडिंग त्रुटियों के कारण सभी सॉफ़्टवेयर दोष नहीं होते हैं। महंगे दोषों का सामान्य स्रोत आवश्यकता अंतराल है, अर्थात, अपरिचित आवश्यकताएं जिसके परिणामस्वरूप प्रोग्राम डिजाइनर द्वारा चूक की त्रुटियां होती हैं।[5]: 426 

इनपुट संयोजन और पूर्व शर्त

सॉफ्टवेयर परीक्षण के साथ मौलिक समस्या यह है कि इनपुट और पूर्व शर्त (प्रारंभिक स्थिति) के सभी संयोजनों के तहत परीक्षण संभव नहीं है, यहां तक कि एक साधारण उत्पाद के साथ भी।[4]: 17–18 [8] इसका मतलब है कि एक सॉफ्टवेयर में दोषों की संख्या उत्पाद बहुत बड़ा हो सकता है और दोष जो कभी-कभी होते हैं, परीक्षण और डिबगिंग में खोजना मुश्किल होता है। अधिक महत्वपूर्ण रूप से, गुणवत्ता के गैर-कार्यात्मक आयाम (इसे कैसे माना जाता है बनाम इसे क्या करना चाहिए) - उपयोगिता, मापनीयता, प्रदर्शन, संगतता और विश्वसनीयता - अत्यधिक व्यक्तिपरक हो सकते हैं; कुछ ऐसा जो एक व्यक्ति के लिए पर्याप्त मूल्य का गठन करता है, दूसरे के लिए असहनीय हो सकता है।

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

अर्थशास्त्र

एनआईएसटी द्वारा 2002 में किए गए अध्ययन में बताया गया है कि सॉफ्टवेयर बग से अमेरिकी अर्थव्यवस्था को सालाना 59.5 बिलियन डॉलर का नुकसान होता है। यदि बेहतर सॉफ्टवेयर परीक्षण किया जाता है तो इस लागत के एक तिहाई से अधिक से बचा जा सकता है।[10]

लागत के कारण आउटसोर्सिंग सॉफ्टवेयर परीक्षण बहुत साधारण है, चीन, फिलीपींस और भारत पसंदीदा स्थान हैं।[11]

भूमिकाएं

सॉफ्टवेयर परीक्षण समर्पित सॉफ्टवेयर परीक्षकों द्वारा किया जा सकता है; 1980 के दशक तक, "सॉफ़्टवेयर टेस्टर" शब्द का उपयोग सामान्यतः किया जाता था, लेकिन बाद में इसे एक अलग पेशे के रूप में भी देखा जाने लगा। सॉफ़्टवेयर परीक्षण में अवधियों और विभिन्न लक्ष्यों के संबंध में,[12] विभिन्न भूमिकाएँ स्थापित की गई हैं, जैसे कि टेस्ट मैनेजर, टेस्ट लीड, टेस्ट एनालिस्ट, टेस्ट डिज़ाइनर, टेस्टर, ऑटोमेशन डेवलपर और टेस्ट एडमिनिस्ट्रेटर। सॉफ़्टवेयर परीक्षण गैर-समर्पित सॉफ़्टवेयर परीक्षकों द्वारा भी किया जा सकता है।[13]

इतिहास

ग्लेनफोर्ड जे. मायर्स ने शुरू में 1979 में डिबगिंग को परीक्षण से अलग करने की आरंभ की।[14] हालांकि उनका ध्यान ब्रेकडाउन टेस्टिंग पर था ("एक सफल परीक्षण मामला वह है जो अभी तक अनदेखे त्रुटि का पता लगाता है।[14]

इसने सॉफ्टवेयर इंजीनियरिंग समुदाय की बुनियादी विकास गतिविधियों, जैसे डीबगिंग, को सत्यापन से अलग करने की इच्छा को स्पष्ट किया था ।

परीक्षण दृष्टिकोण

स्थिर, गतिशील और निष्क्रिय परीक्षण

सॉफ़्टवेयर परीक्षण में कई दृष्टिकोण उपलब्ध हैं। समीक्षा, पूर्वाभ्यास, या निरीक्षण को स्थैतिक परीक्षण के रूप में संदर्भित किया जाता है, जबकि परीक्षण मामलों के दिए गए सेट के साथ क्रमादेशित कोड को क्रियान्वित करना गतिशील परीक्षण के रूप में संदर्भित किया जाता है।[15][16]

स्टेटिक परीक्षण प्रायः अंतर्निहित होता है, जैसे प्रूफरीडिंग, प्लस जब प्रोग्रामिंग टूल/टेक्स्ट एडिटर स्रोत कोड संरचना या कंपाइलर्स (प्री-कंपाइलर) की जांच करते हैं तो सिंटैक्स और डेटा प्रवाह को स्थिर प्रोग्राम विश्लेषण के रूप में चेक करते हैं। गतिशील परीक्षण तब होता है जब प्रोग्राम स्वयं चलाया जाता है। असतत कार्यों या मॉड्यूल पर लागू कोड के विशेष वर्गों का परीक्षण करने के लिए कार्यक्रम के 100% पूर्ण होने से पहले गतिशील परीक्षण शुरू हो सकता है।[15][16] इनके लिए विशिष्ट तकनीकें या तो स्टब्स/ड्राइवर्स का उपयोग कर रही हैं या डिबगर वातावरण से निष्पादन कर रही हैं।[16]

स्थिर परीक्षण में सत्यापन सम्मिलित है, जबकि गतिशील परीक्षण में सत्यापन भी सम्मिलित है।[16]

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

अन्वेषणात्मक दृष्टिकोण

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

बॉक्स दृष्टिकोण

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

व्हाइट-बॉक्स परीक्षण

Main article: व्हाइट-बॉक्स परीक्षण
White Box Testing Diagram
व्हाइट बॉक्स परीक्षण आरेख

व्हाइट-बॉक्स टेस्टिंग (क्लियर बॉक्स टेस्टिंग, ग्लास बॉक्स टेस्टिंग, ट्रांसपेरेंट बॉक्स टेस्टिंग और स्ट्रक्चरल टेस्टिंग के रूप में भी जाना जाता है) एंड-यूज़र के सामने आने वाली कार्यक्षमता के विपरीत, किसी प्रोग्राम की आंतरिक संरचनाओं या कार्यप्रणाली की पुष्टि करता है। व्हाइट-बॉक्स परीक्षण में, सिस्टम के एक आंतरिक परिप्रेक्ष्य (स्रोत कोड) के साथ-साथ प्रोग्रामिंग कौशल का परीक्षण मामलों को डिजाइन करने के लिए उपयोग किया जाता है। परीक्षक कोड के माध्यम से पथ का प्रयोग करने के लिए इनपुट चुनता है और उचित आउटपुट निर्धारित करता है।[19][20] यह सर्किट में परीक्षण नोड्स के अनुरूप है, उदाहरण के लिए, इन-सर्किट परीक्षण (आईसीटी)।

जबकि व्हाइट-बॉक्स टेस्टिंग को इकाई, एकीकरण जांच और सॉफ्टवेयर टेस्टिंग प्रोसेस के सिस्टम परीक्षण लेवल पर लागू किया जा सकता है, यह सामान्यतः यूनिट लेवल पर किया जाता है।[21] यह एक इकाई के भीतर पथों का परीक्षण कर सकता है, एकीकरण के दौरान इकाइयों के बीच और सिस्टम-स्तरीय परीक्षण के दौरान उप-प्रणालियों के बीच पथों का परीक्षण कर सकता है। हालांकि परीक्षण डिजाइन की यह विधि कई त्रुटियों या समस्याओं को उजागर कर सकती है, यह विनिर्देश या लापता आवश्यकताओं के लागू नहीं किए गए भागों का पता नहीं लगा सकती है।

व्हाइट-बॉक्स परीक्षण में उपयोग की जाने वाली तकनीकों में सम्मिलित हैं:[20][22]

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

  • फंक्शन कवरेज, जो क्रियान्वित कार्यों पर रिपोर्ट करता है
  • स्टेटमेंट कवरेज, जो परीक्षण को पूरा करने के लिए निष्पादित लाइनों की संख्या पर रिपोर्ट करता है
  • निर्णय (डिसीज़न) कवरेज, जो इस बात की रिपोर्ट करता है कि किसी दिए गए परीक्षण की सही और गलत दोनों शाखाएँ निष्पादित की गई हैं या नहीं

100% स्टेटमेंट कवरेज यह सुनिश्चित करता है कि सभी कोड पथ या शाखाएं (नियंत्रण प्रवाह के संदर्भ में) कम से कम एक बार निष्पादित हों। यह सही कार्यक्षमता सुनिश्चित करने में मददगार है, लेकिन पर्याप्त नहीं है क्योंकि एक ही कोड अलग-अलग इनपुट को सही या गलत तरीके से संसाधित कर सकता है।[25] छद्म-परीक्षण कार्य और विधियाँ वे हैं जो कवर किए गए हैं लेकिन निर्दिष्ट नहीं हैं (बिना किसी परीक्षण मामले को तोड़े उनके शरीर को निकालना संभव है)।[26]

ब्लैक-बॉक्स परीक्षण

Main article: Black-box testing
ब्लैक बॉक्स आरेख

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







ब्लैक-बॉक्स परीक्षण

ब्लैक-बॉक्स परीक्षण (कार्यात्मक परीक्षण के रूप में भी जाना जाता है) सॉफ्टवेयर को "ब्लैक बॉक्स" के रूप में मानता है, आंतरिक कार्यान्वयन के किसी भी ज्ञान के बिना और स्रोत कोड को देखे बिना कार्यक्षमता की जांच करता है। परीक्षक केवल इस बात से अवगत होते हैं कि सॉफ्टवेयर को क्या करना चाहिए, न कि यह कैसे करता है। [27] ब्लैक-बॉक्स परीक्षण विधियों में तुल्यता विभाजन, सीमा मूल्य विश्लेषण, सभी जोड़े परीक्षण, राज्य संक्रमण तालिका, निर्णय तालिका परीक्षण, फ़ज़ परीक्षण, मॉडल-आधारित परीक्षण, केस परीक्षण, खोजपूर्ण परीक्षण और विनिर्देश-आधारित परीक्षण सम्मिलित हैं।[19][20][24]

विनिर्देश-आधारित परीक्षण का उद्देश्य लागू आवश्यकताओं के अनुसार सॉफ़्टवेयर की कार्यक्षमता का परीक्षण करना है।[28] परीक्षण के इस स्तर के लिए सामान्यतः परीक्षक को पूरी तरह से परीक्षण के मामलों की आवश्यकता होती है, जो तब केवल यह सत्यापित कर सकता है कि किसी दिए गए इनपुट के लिए, आउटपुट मान (या व्यवहार), या तो "है" या "नहीं है" अपेक्षित मान के समान परीक्षण के मामले में निर्दिष्ट है।

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

विशिष्टता-आधारित परीक्षण सही कार्यक्षमता सुनिश्चित करने के लिए आवश्यक हो सकता है, लेकिन यह जटिल या उच्च जोखिम वाली स्थितियों से बचाव के लिए अपर्याप्त है।[29]ब्लैक बॉक्स तकनीक का एक फायदा यह है कि किसी प्रोग्रामिंग ज्ञान की आवश्यकता नहीं है। प्रोग्रामर के पास जो भी पक्षपात हो सकता है, परीक्षक के पास अलग सेट हो सकता है और कार्यक्षमता के विभिन्न क्षेत्रों पर जोर दे सकता है। दूसरी ओर, ब्लैक-बॉक्स परीक्षण को बिना टॉर्च के अंधेरे भूलभुलैया में चलने जैसा कहा गया है।[30] क्योंकि वे स्रोत कोड की जांच नहीं करते हैं, ऐसे हालात होते हैं जब एक परीक्षक किसी चीज की जांच करने के लिए कई परीक्षण मामलों को लिखता है जो कि केवल एक परीक्षण मामले द्वारा परीक्षण किया जा सकता था या कार्यक्रम के कुछ हिस्सों को छोड़ देता है।

परीक्षण का यह तरीका सॉफ्टवेयर परीक्षण के सभी स्तरों पर लागू किया जा सकता है: इकाई परीक्षण, एकीकरण परीक्षण, सिस्टम परीक्षण और स्वीकृति परीक्षण।[21]यह सामान्यतः उच्च स्तर पर सभी परीक्षण नहीं होने पर सबसे अधिक सम्मिलित होता है, लेकिन यूनिट परीक्षण पर भी हावी हो सकता है।

घटक (कम्पोनेंट) इंटरफ़ेस परीक्षण

घटक इंटरफ़ेस परीक्षण ब्लैक-बॉक्स परीक्षण का एक प्रकार है, जिसमें सबसिस्टम घटक की संबंधित क्रियाओं से परे डेटा मूल्यों पर ध्यान केंद्रित किया जाता है।[31] घटक इंटरफ़ेस परीक्षण के अभ्यास का उपयोग उन इकाइयों के बीच पूर्ण एकीकरण परीक्षण से परे, विभिन्न इकाइयों, या सबसिस्टम घटकों के बीच पारित डेटा के प्रबंधन की जांच के लिए किया जा सकता है।[32][33] पारित होने वाले डेटा को "संदेश पैकेट" के रूप में माना जा सकता है और एक इकाई से उत्पन्न डेटा के लिए श्रेणी या डेटा प्रकार की जांच की जा सकती है, और किसी अन्य इकाई में पारित होने से पहले वैधता के लिए परीक्षण किया जा सकता है। इंटरफ़ेस परीक्षण के लिए एक विकल्प पास किए जा रहे डेटा आइटम की एक अलग लॉग फ़ाइल रखना है, प्रायः टाइमस्टैम्प लॉग के साथ दिनों या हफ्तों के लिए इकाइयों के बीच डेटा के हजारों मामलों के विश्लेषण की अनुमति देता है। टेस्ट में कुछ एक्सट्रीम डेटा मानों के प्रबंधन की जांच सम्मिलित हो सकती है जबकि अन्य इंटरफ़ेस चर सामान्य मान के रूप में पारित किए जाते हैं। [32] इंटरफ़ेस में असामान्य डेटा मान अगली इकाई में अनपेक्षित प्रदर्शन की व्याख्या करने में सहायता कर सकते हैं।

घटक इंटरफ़ेस परीक्षण ब्लैक-बॉक्स परीक्षण का एक रूप है, जिसमें सबसिस्टम घटक की संबंधित क्रियाओं से परे डेटा मानों पर ध्यान केंद्रित किया जाता है।[31] घटक इंटरफ़ेस परीक्षण के अभ्यास का उपयोग उन इकाइयों के बीच पूर्ण एकीकरण परीक्षण से परे, विभिन्न इकाइयों, या सबसिस्टम घटकों के बीच पारित डेटा के प्रबंधन की जांच के लिए किया जा सकता है।[32][33] पारित होने वाले डेटा को संदेश पैकेट के रूप में माना जा सकता है और एक इकाई से उत्पन्न डेटा के लिए श्रेणी या डेटा प्रकार की जांच की जा सकती है, और किसी अन्य इकाई में पारित होने से पहले वैधता के लिए परीक्षण किया जा सकता है। इंटरफ़ेस परीक्षण के लिए विकल्प डेटा आइटम की एक अलग लॉग फ़ाइल को पास करना है, प्रायः टाइमस्टैम्प लॉग के साथ दिनों या हफ्तों के लिए इकाइयों के बीच डेटा के हजारों मामलों के विश्लेषण की अनुमति देता है। टेस्ट में कुछ चरम डेटा मानों की हैंडलिंग की जांच सम्मिलित हो सकती है जबकि अन्य इंटरफ़ेस चर सामान्य मान के रूप में पारित किए जाते हैं।[32] इंटरफ़ेस में असामान्य डेटा मान अगली इकाई में अनपेक्षित प्रदर्शन की व्याख्या करने में सहायता कर सकते हैं।

विजुअल परीक्षण

विजुअल परीक्षण का उद्देश्य डेवलपर्स को यह जांचने की क्षमता प्रदान करना है कि सॉफ़्टवेयर विफलता के बिंदु पर क्या हो रहा था, डेटा को इस तरह से प्रस्तुत करके कि डेवलपर आसानी से वह जानकारी पा सके जिसकी उसे आवश्यकता है, और जानकारी स्पष्ट रूप से व्यक्त की गई है .[34][35]

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

विजुअल परीक्षण कई लाभ प्रदान करता है। संचार की गुणवत्ता में भारी वृद्धि हुई है क्योंकि परीक्षक समस्या का वर्णन करने के बजाय डेवलपर को समस्या (और इसके आगे आने वाली घटनाओं) को दिखा सकते हैं और कई मामलों में परीक्षण विफलताओं को दोहराने की आवश्यकता समाप्त हो जाएगी। डेवलपर के पास परीक्षण विफलता के लिए आवश्यक सभी सबूत होंगे और इसके बजाय गलती के कारण पर ध्यान केंद्रित कर सकते हैं और इसे कैसे ठीक किया जाना चाहिए।

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

Further information: ग्राफिकल यूजर इंटरफेस परीक्षण

ग्रे-बॉक्स परीक्षण

Main article: ग्रे-बॉक्स परीक्षण

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

सॉफ़्टवेयर कैसे काम करता है, इसकी अंतर्निहित अवधारणाओं को जानकर, परीक्षक बाहर से सॉफ़्टवेयर का परीक्षण करते समय बेहतर-सूचित परीक्षण विकल्प बनाता है। सामान्यतः, एक ग्रे-बॉक्स टेस्टर को डेटाबेस सीडिंग जैसी गतिविधियों के साथ एक पृथक परीक्षण वातावरण स्थापित करने की अनुमति दी जाएगी। परीक्षक कुछ क्रियाओं को करने के बाद परीक्षण किए जा रहे उत्पाद की स्थिति का निरीक्षण कर सकता है जैसे कि डेटाबेस के विरुद्ध SQL कथनों को निष्पादित करना और फिर यह सुनिश्चित करने के लिए प्रश्नों को निष्पादित करना कि अपेक्षित परिवर्तन परिलक्षित हुए हैं। ग्रे-बॉक्स परीक्षण सीमित जानकारी के आधार पर बुद्धिमान परीक्षण परिदृश्यों को लागू करता है। यह विशेष रूप से डेटा टाइप हैंडलिंग, अपवाद हैंडलिंग आदि पर लागू होगा।[38]

परीक्षण स्तर

मोटे तौर पर, परीक्षण के कम से कम तीन स्तर हैं: इकाई परीक्षण, एकीकरण परीक्षण और सिस्टम परीक्षण।[39][40][41][42] हालाँकि, एक चौथा स्तर, स्वीकृति परीक्षण, डेवलपर्स द्वारा सम्मिलित किया जा सकता है। यह परिचालन स्वीकृति परीक्षण के रूप में हो सकता है या सरल एंड-यूज़र (बीटा) परीक्षण हो सकता है, यह सुनिश्चित करने के लिए परीक्षण कि सॉफ्टवेयर कार्यात्मक अपेक्षाओं को पूरा करता है।[43][44][45] आईएसटीक्यूबी सर्टिफाइड टेस्ट फाउंडेशन लेवल सिलेबस के आधार पर, टेस्ट लेवल में वे चार लेवल सम्मिलित होते हैं, और चौथे लेवल को एक्सेप्टेंस टेस्टिंग कहा जाता है।[46] परीक्षणों को प्रायः इन स्तरों में से एक में समूहीकृत किया जाता है, जहां उन्हें सॉफ्टवेयर डेवलपमेंट प्रोसेस में जोड़ा जाता है, या टेस्ट की विशिष्टता के स्तर के अनुसार।

यूनिट परीक्षण

Main article: यूनिट परीक्षण

यूनिट परीक्षण उन परीक्षणों को संदर्भित करता है जो कोड के विशिष्ट खंड की कार्यक्षमता को सत्यापित करते हैं, सामान्यतः फ़ंक्शन स्तर पर। वस्तु-उन्मुख वातावरण में, यह सामान्यतः वर्ग स्तर पर होता है, और न्यूनतम इकाई परीक्षणों में निर्माणकर्ता और विध्वंसक सम्मिलित होते हैं।[47]

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

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

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

एकीकरण परीक्षण

Main article: एकीकरण परीक्षण

एकीकरण परीक्षण किसी भी प्रकार का सॉफ़्टवेयर परीक्षण है जो सॉफ़्टवेयर डिज़ाइन के विरुद्ध घटकों के बीच इंटरफेस को सत्यापित करने का प्रयास करता है। सॉफ़्टवेयर घटकों को पुनरावृत्त तरीके से या सभी को एक साथ (बिग बैंग) एकीकृत किया जा सकता है। सामान्यतः पूर्व को एक बेहतर अभ्यास माना जाता है क्योंकि यह इंटरफ़ेस के मुद्दों को अधिक तेज़ी से और ठीक करने की अनुमति देता है।

एकीकरण परीक्षण इंटरफेस और एकीकृत घटकों (मॉड्यूल) के बीच बातचीत में दोषों को उजागर करने के लिए काम करता है। आर्किटेक्चरल डिज़ाइन के तत्वों के अनुरूप परीक्षण किए गए सॉफ़्टवेयर घटकों के उत्तरोत्तर बड़े समूहों को तब तक एकीकृत और परीक्षण किया जाता है जब तक कि सॉफ़्टवेयर सिस्टम के रूप में काम नहीं करता है।[48]

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

सिस्टम परीक्षण

Main article: सिस्टम परीक्षण

सिस्टम परीक्षण यह सत्यापित करने के लिए पूरी तरह से एकीकृत प्रणाली का परीक्षण करता है कि सिस्टम अपनी आवश्यकताओं को पूरा करता है।[6] उदाहरण के लिए, एक सिस्टम परीक्षण में एक लॉगिन इंटरफ़ेस का परीक्षण करना, फिर एक प्रविष्टि बनाना और संपादित करना, साथ ही भेजने या प्रिंट करने के परिणाम सम्मिलित हो सकते हैं, इसके बाद प्रविष्टियों का सारांश प्रसंस्करण या विलोपन (या संग्रह), फिर लॉगऑफ़।

स्वीकार्यता परीक्षण

Main article: स्वीकार्यता परीक्षण

स्वीकृति परीक्षण में सामान्यतः निम्नलिखित चार प्रकार सम्मिलित होते हैं:[46]

  • उपयोगकर्ता स्वीकृति परीक्षण (यूएटी)
  • परिचालन स्वीकृति परीक्षण (ओएटी)
  • संविदात्मक और नियामक स्वीकृति परीक्षण
  • अल्फा और बीटा परीक्षण

ओएटी के साथ-साथ अल्फ़ा और बीटा परीक्षण का वर्णन अगले परीक्षण प्रकार अनुभाग में किया गया है।

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

इसके अलावा, सॉफ्टवेयर परीक्षण को यह सुनिश्चित करना चाहिए कि सिस्टम की सुवाह्यता, साथ ही अपेक्षित रूप से काम करने से, इसके ऑपरेटिंग वातावरण को नुकसान या आंशिक रूप से दूषित नहीं होता है या उस वातावरण के भीतर अन्य प्रक्रियाओं को निष्क्रिय होने का कारण नहीं बनता है।[50]

संविदात्मक स्वीकृति परीक्षण अनुबंध के अनुबंध के दौरान परिभाषित अनुबंध की स्वीकृति मानदंड के आधार पर किया जाता है, जबकि नियामक स्वीकृति परीक्षण सॉफ्टवेयर उत्पाद के प्रासंगिक नियमों के आधार पर किया जाता है। ये दोनों परीक्षण उपयोगकर्ताओं या स्वतंत्र परीक्षकों द्वारा किए जा सकते हैं। विनियमन स्वीकृति परीक्षण में कभी-कभी नियामक एजेंसियां ​​​​परीक्षण परिणामों का लेखा-जोखा करती हैं।[46]

परीक्षण प्रकार, तकनीक और रणनीति

अलग-अलग लेबल और समूहीकरण परीक्षण के तरीके परीक्षण प्रकार, सॉफ़्टवेयर परीक्षण रणनीति या तकनीक हो सकते हैं।[51]

टेस्टिंग कप - सॉफ्टवेयर परीक्षण में पोलिश चैम्पियनशिप, कैटोविस, मई 2016

स्थापना (इंस्टालेशन) परीक्षण

Main article: स्थापना (इंस्टालेशन) परीक्षण

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

संगतता परीक्षण

Main article: संगतता परीक्षण

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

धूम्रपान और स्वच्छता परीक्षण

Main article: धूम्रपान परीक्षण (सॉफ्टवेयर)

सैनिटी परीक्षण यह निर्धारित करता है कि क्या आगे के परीक्षण के साथ आगे बढ़ना उचित है।

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

प्रतिगमन परीक्षण

Main article: प्रतिगमन परीक्षण

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

प्रतिगमन परीक्षण के सामान्य तरीकों में परीक्षण मामलों के पिछले सेटों को फिर से चलाना और यह जाँचना सम्मिलित है कि क्या पहले से तय किए गए दोष फिर से उभर आए हैं। परीक्षण की गहराई रिलीज़ प्रक्रिया के चरण और जोड़ी गई सुविधाओं के जोखिम प्रबंधन पर निर्भर करती है। वे या तो पूर्ण हो सकते हैं, रिलीज में देर से जोड़े गए परिवर्तनों के लिए या जोखिम भरा माना जाता है, या बहुत उथला हो सकता है, जिसमें प्रत्येक सुविधा पर सकारात्मक परीक्षण सम्मिलित हैं, यदि परिवर्तन रिलीज में जल्दी हैं या कम जोखिम वाले माने जाते हैं। प्रतिगमन परीक्षण में, मौजूदा व्यवहार पर मजबूत अभिकथन होना महत्वपूर्ण है। इसके लिए, मौजूदा परीक्षण मामलों में नए अभिकथन उत्पन्न करना और जोड़ना संभव है,[53] इसे स्वचालित परीक्षण प्रवर्धन के रूप में जाना जाता है।[54]

स्वीकार्यता परीक्षण

Main article: स्वीकार्यता परीक्षण

स्वीकार्यता परीक्षण का अर्थ दो चीजों में से एक हो सकता है:

  1. धूम्रपान परीक्षण (सॉफ्टवेयर) का उपयोग आगे के परीक्षण से पहले निर्माण स्वीकृति परीक्षण के रूप में किया जाता है, उदाहरण के लिए, एकीकरण परीक्षण या प्रतिगमन परीक्षण से पहले।
  2. ग्राहक द्वारा किया गया स्वीकृति परीक्षण, प्रायः उनके स्वयं के हार्डवेयर पर प्रयोगशाला वातावरण में, उपयोगकर्ता स्वीकृति परीक्षण (यूएटी) के रूप में जाना जाता है। विकास के किन्हीं दो चरणों के बीच हैंड-ऑफ़ प्रक्रिया के भाग के रूप में स्वीकृति परीक्षण किया जा सकता है।[citation needed]

अल्फा परीक्षण

Main article: अल्फा परीक्षण

अल्फा परीक्षण संभावित उपयोगकर्ताओं/ग्राहकों या डेवलपर्स की साइट पर एक स्वतंत्र परीक्षण टीम द्वारा सिम्युलेटेड या वास्तविक परिचालन परीक्षण है। सॉफ़्टवेयर के बीटा परीक्षण में जाने से पहले अल्फा परीक्षण को प्रायः ऑफ़-द-शेल्फ सॉफ़्टवेयर के लिए आंतरिक स्वीकृति परीक्षण के रूप में नियोजित किया जाता है।[55]

बीटा परीक्षण

See also: सॉफ्टवेयर रिलीज़ लाइफ साईकल बीटा

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

कार्यात्मक बनाम गैर-कार्यात्मक परीक्षण

कार्यात्मक परीक्षण उन गतिविधियों को संदर्भित करता है जो कोड की विशिष्ट क्रिया या कार्य को सत्यापित करते हैं। ये सामान्यतः कोड आवश्यकताओं के दस्तावेज में पाए जाते हैं, हालांकि कुछ विकास पद्धतियां उपयोग के मामलों या उपयोगकर्ता कहानियों से काम करती हैं। कार्यात्मक परीक्षण "क्या उपयोगकर्ता ऐसा कर सकता है" या "क्या यह विशेष सुविधा काम करती है" के प्रश्न का उत्तर देने की प्रवृत्ति है।

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

Main article: निरंतर परीक्षण

निरंतर परीक्षण सॉफ्टवेयर डिलीवरी पाइपलाइन के हिस्से के रूप में स्वचालित परीक्षणों को निष्पादित करने की प्रक्रिया है, जो सॉफ़्टवेयर रिलीज़ उम्मीदवार से जुड़े व्यावसायिक जोखिमों पर तत्काल प्रतिक्रिया प्राप्त करने के लिए है।[57][58] सतत परीक्षण में कार्यात्मक आवश्यकताओं और गैर-कार्यात्मक आवश्यकताओं दोनों की मान्यता सम्मिलित है; परीक्षण का दायरा व्यापक व्यावसायिक लक्ष्यों से जुड़ी सिस्टम आवश्यकताओं का आकलन करने के लिए नीचे-ऊपर की आवश्यकताओं या उपयोगकर्ता कहानियों को मान्य करने तक विस्तृत है।[59][60]

विध्वंसक परीक्षण

Main article: विध्वंसक परीक्षण

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

Further information: एक्सेप्शन हैंडलिंग and रिकवरी परीक्षण

सॉफ्टवेयर प्रदर्शन परीक्षण

Main article: सॉफ्टवेयर परफॉरमेंस टेस्टिंग

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

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

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

रीयल-टाइम सॉफ़्टवेयर सिस्टम में सख्त समय की कमी है। यह जांचने के लिए कि क्या समय की कमी पूरी हुई है, वास्तविक समय परीक्षण का उपयोग किया जाता है।

उपयोगिता परीक्षण

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

अभिगम्यता परीक्षण

अभिगम्यता परीक्षण यह सुनिश्चित करने के लिए किया जाता है कि सॉफ्टवेयर विकलांग व्यक्तियों के लिए सुलभ है। कुछ सामान्य वेब सरल उपयोग टेस्ट हैं

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

अनुपालन के लिए सामान्य मानक

सुरक्षा परीक्षण

हैकर्स द्वारा सिस्टम में घुसपैठ को रोकने के लिए गोपनीय डेटा को प्रोसेस करने वाले सॉफ़्टवेयर के लिए सुरक्षा परीक्षण आवश्यक है।

मानकीकरण के लिए अंतर्राष्ट्रीय संगठन (आईएसओ) इसे "एक परीक्षण आइटम, और संबंधित डेटा और जानकारी की डिग्री का मूल्यांकन करने के लिए किए गए परीक्षण के रूप में परिभाषित करता है, ताकि अनधिकृत व्यक्ति या सिस्टम उनका उपयोग, पढ़ या संशोधित नहीं कर सकें, और अधिकृत व्यक्तियों या सिस्टमों को उन तक पहुंच से वंचित नहीं किया जाता है।" [61]

अंतर्राष्ट्रीयकरण और स्थानीयकरण

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

वैश्वीकरण परीक्षण सत्यापित करता है कि सॉफ्टवेयर एक नई संस्कृति (जैसे विभिन्न मुद्राओं या समय क्षेत्रों) के लिए अनुकूलित है।[62]

मानव भाषाओं में वास्तविक अनुवाद का भी परीक्षण किया जाना चाहिए। संभावित स्थानीयकरण और वैश्वीकरण विफलताओं में सम्मिलित हैं:

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

विकास परीक्षण

Main article: विकास परीक्षण

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

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

ए/बी परीक्षण

Main article: ए/बी परीक्षण

ए/बी टेस्टिंग एक नियंत्रित प्रयोग चलाने की एक विधि है, जो यह निर्धारित करती है कि प्रस्तावित परिवर्तन मौजूदा दृष्टिकोण से अधिक प्रभावी है या नहीं। ग्राहकों को सुविधा के वर्तमान संस्करण (नियंत्रण) या संशोधित संस्करण (उपचार) पर भेजा जाता है और यह निर्धारित करने के लिए डेटा एकत्र किया जाता है कि वांछित परिणाम प्राप्त करने के लिए कौन सा संस्करण बेहतर है।

समवर्ती परीक्षण

Main article: समवर्ती परीक्षण

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

अनुरूपता परीक्षण या टाइप परीक्षण

Main article: अनुरूपता परीक्षण

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

आउटपुट तुलना परीक्षण

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

गुण परीक्षण

Not to be confused with गुण परीक्षण एल्गोरिद्म.

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

गुण परीक्षण पुस्तकालय उपयोगकर्ता को उस रणनीति को नियंत्रित करने की अनुमति देते हैं जिसके द्वारा यादृच्छिक इनपुट का निर्माण किया जाता है, पतित मामलों के कवरेज को सुनिश्चित करने के लिए, या विशिष्ट पैटर्न वाले इनपुट जो परीक्षण के तहत कार्यान्वयन के पहलुओं को पूरी तरह से अभ्यास करने के लिए आवश्यक हैं।

गुण परीक्षण को कभी-कभी "जनरेटिव टेस्टिंग" या "क्विकचेक टेस्टिंग" के रूप में भी जाना जाता है, क्योंकि इसे हास्केल लाइब्रेरी क्विकचेक द्वारा पेश किया गया था और इसे लोकप्रिय बनाया गया था।[63]

रूपान्तरित परीक्षण

Main article: रूपान्तरित परीक्षण

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

वीसीआर परीक्षण

वीसीआर परीक्षण, जिसे "प्लेबैक परीक्षण" या "रिकॉर्ड/रीप्ले" परीक्षण के रूप में भी जाना जाता है, प्रतिगमन परीक्षणों की विश्वसनीयता और गति को बढ़ाने के लिए एक परीक्षण तकनीक है जिसमें एक घटक सम्मिलित होता है जो धीमा या अविश्वसनीय होता है, प्रायः एक तृतीय-पक्ष एपीआई परीक्षक के नियंत्रण के बाहर इसमें बाहरी घटक के साथ सिस्टम के इंटरैक्शन की रिकॉर्डिंग ("कैसेट") बनाना सम्मिलित है, और फिर परीक्षण के बाद के रन पर बाहरी सिस्टम के साथ संचार करने के विकल्प के रूप में रिकॉर्ड किए गए इंटरैक्शन को फिर से चलाना सम्मिलित है।

इस तकनीक को रूबी लाइब्रेरी द्वारा वेब विकास में लोकप्रिय बनाया गया था।

परीक्षण प्रक्रिया

परंपरागत जलप्रपात विकास मॉडल

जलप्रपात विकास में सामान्य अभ्यास यह है कि परीक्षण परीक्षकों के स्वतंत्र समूह द्वारा किया जाता है। ऐसा हो सकता है:

  • कार्यक्षमता विकसित होने के बाद, लेकिन ग्राहक को भेजने से पहले।[64] इस अभ्यास के परिणामस्वरूप प्रायः परीक्षण चरण का उपयोग परियोजना प्रबंधन बफर के रूप में किया जाता है ताकि परियोजना में देरी की भरपाई की जा सके, जिससे परीक्षण के लिए समर्पित समय से समझौता किया जा सके।[14]: 145–146 
  • उसी क्षण विकास परियोजना शुरू होती है, सतत प्रक्रिया के रूप में जब तक परियोजना समाप्त नहीं हो जाती।[65]

हालांकि, जलप्रपात विकास मॉडल में भी, इकाई परीक्षण प्रायः सॉफ्टवेयर विकास दल द्वारा किया जाता है, तब भी जब आगे का परीक्षण अलग टीम द्वारा किया जाता है।[66]

Further information: क्षमता परिपक्वता मॉडल एकीकरण and जलप्रपात (वॉटरफॉल) मॉडल

कुशल या एक्सपी विकास मॉडल

इसके विपरीत, कुछ उभरते हुए सॉफ्टवेयर अनुशासन जैसे एक्सट्रीम प्रोग्रामिंग और कुशल सॉफ्टवेयर विकास आंदोलन, "परीक्षण-संचालित सॉफ़्टवेयर विकास" मॉडल का पालन करते हैं। इस प्रक्रिया में, यूनिट टेस्ट पहले सॉफ्टवेयर इंजीनियरों द्वारा लिखे जाते हैं (प्रायः एक्सट्रीम प्रोग्रामिंग मेथडोलॉजी में पेयर प्रोग्रामिंग के साथ)। परीक्षणों के शुरू में असफल होने की उम्मीद है। प्रत्येक असफल परीक्षा के बाद उसे उत्तीर्ण करने के लिए पर्याप्त कोड लिखना होता है।[67] इसका मतलब यह है कि परीक्षण सूट लगातार अपडेट किए जाते हैं क्योंकि नई विफलता की स्थिति और कोने के मामलों की खोज की जाती है, और वे किसी भी प्रतिगमन परीक्षण के साथ एकीकृत होते हैं जो विकसित होते हैं। यूनिट परीक्षण बाकी सॉफ्टवेयर स्रोत कोड के साथ बनाए रखा जाता है और सामान्यतः निर्माण प्रक्रिया में एकीकृत किया जाता है (आंशिक रूप से मैन्युअल निर्माण स्वीकृति प्रक्रिया के लिए स्वाभाविक रूप से इंटरैक्टिव परीक्षणों को हटा दिया जाता है)।

इस परीक्षण प्रक्रिया का अंतिम लक्ष्य निरंतर एकीकरण का समर्थन करना और दोष दरों को कम करना है।[68][67]

यह कार्यप्रणाली किसी भी औपचारिक परीक्षण दल तक पहुँचने से पहले, विकास द्वारा किए गए परीक्षण के प्रयास को बढ़ा देती है। कुछ अन्य विकास मॉडलों में, अधिकांश परीक्षण निष्पादन आवश्यकताओं को परिभाषित किए जाने और कोडिंग प्रक्रिया पूरी होने के बाद होता है।

नमूना परीक्षण चक्र

हालांकि संगठनों के बीच भिन्नताएं मौजूद हैं, परीक्षण के लिए एक विशिष्ट चक्र है।[2] जलप्रपात विकास मॉडल को नियोजित करने वाले संगठनों के बीच नीचे दिया गया नमूना सामान्य है। अन्य विकास मॉडलों में सामान्यतः समान प्रथाएं पाई जाती हैं, लेकिन यह उतनी स्पष्ट या स्पष्ट नहीं हो सकती हैं।

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

स्वचालित परीक्षण

Main article: परीक्षण स्वचालन

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

जबकि स्वचालन वह सब कुछ पुन: उत्पन्न नहीं कर सकता जो एक मानव कर सकता है (और वे सभी तरीके जो वे ऐसा करने के बारे में सोचते हैं), यह प्रतिगमन परीक्षण के लिए बहुत उपयोगी हो सकता है। हालाँकि, इसे वास्तव में उपयोगी होने के लिए परीक्षण स्क्रिप्ट के एक अच्छी तरह से विकसित टेस्ट सूट की आवश्यकता होती है।

परीक्षण उपकरण

प्रोग्राम टेस्टिंग और फॉल्ट डिटेक्शन को टेस्टिंग टूल्स और डिबगर्स द्वारा काफी मदद मिल सकती है। परीक्षण/डीबग टूल में विशेषताएं सम्मिलित हैं जैसे:

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

इनमें से कुछ विशेषताओं को एक समग्र उपकरण या एक एकीकृत विकास पर्यावरण (आईडीई) में सम्मिलित किया जा सकता है।

कैप्चर और रीप्ले

कैप्चर और रीप्ले टेस्टिंग में एप्लिकेशन के साथ इंटरैक्ट करते समय एंड-टू-एंड उपयोग परिदृश्यों को इकट्ठा करना और इन परिदृश्यों को टेस्ट केस में बदलना सम्मिलित है। कैप्चर और रीप्ले के संभावित अनुप्रयोगों में प्रतिगमन परीक्षणों की पीढ़ी सम्मिलित है। एससीएआरपीई टूल[69] चुनिंदा रूप से अध्ययन के तहत आवेदन के एक सबसेट को कैप्चर करता है क्योंकि यह निष्पादित होता है। जे रैप्चर एक निष्पादित जावा प्रोग्राम और होस्ट सिस्टम पर घटकों जैसे फाइल, या ग्राफिकल यूजर इंटरफेस पर घटनाओं के बीच बातचीत के अनुक्रम को कैप्चर करता है। फिर इन दृश्यों को अवलोकन-आधारित परीक्षण के लिए फिर से चलाया जा सकता है।[70]

सायवा एट अल। महत्वपूर्ण सुरक्षा बगों के लिए उम्मीदवार पैच का परीक्षण करने के लिए तदर्थ परीक्षणों को उत्पन्न करने का प्रस्ताव है जो रिकॉर्ड किए गए उपयोगकर्ता निष्पादन निशान को फिर से चलाते हैं।[71] पंक्ति फोकस्ड डिफरेंशियल यूनिट टेस्ट जेनरेट करने के लिए प्रोडक्शन में ऑब्जेक्ट प्रोफाइल कलेक्ट करती है। यह उपकरण व्युत्पन्न परीक्षण ऑरेकल के व्यवस्थित उत्पादन के साथ कैप्चर और रिप्ले को बढ़ाता है।[72] ऑटोग्राफ क्यूएल, ग्राफक्यूएल एपीआई पर उपयोगकर्ता के अनुरोधों की निगरानी करता है और परीक्षण मामले उत्पन्न करता है जो स्कीमा दोषों का पता लगा सकता है।[73]

सॉफ्टवेयर परीक्षण में माप

Main article: सॉफ़्टवेयर गुणवत्ता

गुणवत्ता उपायों में शुद्धता, पूर्णता, सुरक्षा और आईएसओ/आईईसी 9126 आवश्यकताएं जैसे क्षमता, विश्वसनीयता, दक्षता, सुवाह्यता, रखरखाव, अनुकूलता और उपयोगिता जैसे विषय सम्मिलित हैं।

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

परीक्षण कठिनाई का पदानुक्रम

प्रत्येक संदर्भ में एक पूर्ण परीक्षण सूट बनाने के लिए आवश्यक परीक्षण मामलों की संख्या के आधार पर (यानी एक परीक्षण सूट जैसे कि, यदि इसे परीक्षण के तहत कार्यान्वयन पर लागू किया जाता है, तो हम यह निर्धारित करने के लिए पर्याप्त जानकारी एकत्र करते हैं कि सिस्टम सही है या गलत कुछ विनिर्देशों के अनुसार), परीक्षण कठिनाई का एक पदानुक्रम प्रस्तावित किया गया है।[74][75] इसमें निम्नलिखित सॉफ्टवेयर परीक्षण योग्यता वर्ग सम्मिलित हैं:

  • कक्षा I: एक परिमित पूर्ण परीक्षण सूट मौजूद है।
  • कक्षा II: किसी भी आंशिक विभेदक दर (अर्थात्, सही प्रणालियों को गलत प्रणालियों से अलग करने की कोई अपूर्ण क्षमता) तक सीमित परीक्षण सूट के साथ पहुँचा जा सकता है।
  • कक्षा III: एक गणनीय पूर्ण परीक्षण सूट मौजूद है।
  • चतुर्थ श्रेणी: एक पूर्ण परीक्षण सूट मौजूद है।
  • कक्षा V: सभी मामले।

यह साबित हो गया है कि प्रत्येक वर्ग अगले में सख्ती से सम्मिलित है। उदाहरण के लिए, परीक्षण जब हम मानते हैं कि परीक्षण के तहत कार्यान्वयन के व्यवहार को नियतात्मक परिमित-राज्य मशीन द्वारा निविष्टियों और आउटपुट के कुछ ज्ञात परिमित सेटों के लिए निरूपित किया जा सकता है और कुछ ज्ञात अवस्थाएँ कक्षा I (और सभी बाद की कक्षाओं) से संबंधित हैं ). हालाँकि, यदि राज्यों की संख्या ज्ञात नहीं है, तो यह केवल द्वितीय श्रेणी से सभी वर्गों के अंतर्गत आता है। यदि परीक्षण के तहत कार्यान्वयन एक निर्धारक परिमित-राज्य मशीन होना चाहिए जो एकल ट्रेस (और इसकी निरंतरता) के लिए विनिर्देश को विफल कर दे, और इसकी राज्यों की संख्या अज्ञात है, तो यह केवल कक्षा III से कक्षाओं के अंतर्गत आता है। टेम्पोरल मशीनों का परीक्षण जहां कुछ वास्तविक-बाध्य अंतराल के भीतर इनपुट का उत्पादन किया जाता है, केवल कक्षा IV से संबंधित है, जबकि कई गैर-नियतात्मक प्रणालियों का परीक्षण केवल कक्षा V से संबंधित है (लेकिन सभी नहीं, और कुछ भी कक्षा I से संबंधित हैं) ). कक्षा I में सम्मिलित करने के लिए कल्पित संगणना मॉडल की सरलता की आवश्यकता नहीं है, क्योंकि कुछ परीक्षण मामलों में किसी प्रोग्रामिंग भाषा में लिखे गए कार्यान्वयन सम्मिलित हैं, और निरंतर परिमाण के आधार पर मशीनों के रूप में परिभाषित परीक्षण कार्यान्वयन, कक्षा I में साबित हुए हैं। अन्य विस्तृत मामले, जैसे मैथ्यू हेनेसी द्वारा टेस्टिंग फ्रेमवर्क मस्ट सिमेंटिक्स के तहत, और तर्कसंगत टाइमआउट वाली टेम्पोरल मशीन, क्लास II से संबंधित हैं।

आर्टिफैक्ट परीक्षण

एक सॉफ्टवेयर परीक्षण प्रक्रिया कई आर्टिफैक्ट (सॉफ्टवेयर विकास) का उत्पादन कर सकती है। उत्पादित वास्तविक कलाकृतियाँ उपयोग किए गए सॉफ़्टवेयर विकास मॉडल, हितधारक और संगठनात्मक आवश्यकताओं का एक कारक हैं।

परीक्षण योजना
एक परीक्षण योजना एक दस्तावेज है जो उस दृष्टिकोण का विवरण देता है जो इच्छित परीक्षण गतिविधियों के लिए लिया जाएगा। योजना में उद्देश्य, कार्यक्षेत्र, प्रक्रियाओं और प्रक्रियाओं, कर्मियों की आवश्यकताओं और आकस्मिक योजनाओं जैसे पहलुओं को सम्मिलित किया जा सकता है।[43] परीक्षण योजना एकल योजना के रूप में आ सकती है जिसमें सभी प्रकार के परीक्षण (जैसे स्वीकृति या सिस्टम परीक्षण योजना) और योजना संबंधी विचार सम्मिलित हैं, या इसे मास्टर परीक्षण योजना के रूप में जारी किया जा सकता है जो एक से अधिक विस्तृत परीक्षण का अवलोकन प्रदान करता है योजना (एक योजना की एक योजना)।[43]एक परीक्षण योजना, कुछ मामलों में, एक व्यापक परीक्षण रणनीति का हिस्सा हो सकती है, जो समग्र परीक्षण दृष्टिकोणों का दस्तावेजीकरण करती है, जो स्वयं एक मास्टर परीक्षण योजना या एक अलग आर्टिफैक्ट भी हो सकती है।
पता लगाने की क्षमता मैट्रिक्स
एक पता लगाने की क्षमता का मापदंड एक तालिका है जो दस्तावेज़ों का परीक्षण करने के लिए आवश्यकताओं या डिज़ाइन दस्तावेज़ों को सहसंबंधित करती है। आवश्यकता कवरेज पर विचार करके प्रतिगमन परीक्षणों की योजना बनाते समय निष्पादन के लिए परीक्षण मामलों का चयन करने के लिए संबंधित स्रोत दस्तावेज़ों को बदलते समय परीक्षणों को बदलने के लिए इसका उपयोग किया जाता है।
परीक्षण का मामला
एक परीक्षण मामले में सामान्यतः एक विशिष्ट पहचानकर्ता, एक डिजाइन विनिर्देश, पूर्व शर्त, घटनाओं, चरणों की एक श्रृंखला (जिसे क्रियाओं के रूप में भी जाना जाता है), इनपुट, आउटपुट, अपेक्षित परिणाम और वास्तविक परिणाम से आवश्यकता संदर्भ होते हैं। चिकित्सकीय रूप से परिभाषित, एक परीक्षण मामला एक इनपुट और एक अपेक्षित परिणाम है।[76] यह 'शर्त x के लिए आपका व्युत्पन्न परिणाम y है' के रूप में संक्षिप्त हो सकता है, हालांकि सामान्यतः परीक्षण के मामले इनपुट परिदृश्य का अधिक विस्तार से वर्णन करते हैं और क्या परिणाम अपेक्षित हो सकते हैं। यह कभी-कभी चरणों की एक श्रृंखला हो सकती है (लेकिन प्रायः चरणों को एक अलग परीक्षण प्रक्रिया में सम्मिलित किया जाता है जिसे अर्थव्यवस्था के मामले में कई परीक्षण मामलों के विरुद्ध प्रयोग किया जा सकता है) लेकिन एक अपेक्षित परिणाम या अपेक्षित परिणाम के साथ। वैकल्पिक फ़ील्ड एक टेस्ट केस आईडी, टेस्ट स्टेप, या निष्पादन संख्या का क्रम, संबंधित आवश्यकताएं, गहराई, टेस्ट श्रेणी, लेखक और चेक बॉक्स हैं कि क्या परीक्षण स्वचालित है और स्वचालित किया गया है। बड़े परीक्षण मामलों में पूर्वापेक्षित अवस्थाएँ या चरण और विवरण भी हो सकते हैं। एक परीक्षण मामले में वास्तविक परिणाम के लिए भी एक स्थान होना चाहिए। इन चरणों को एक वर्ड प्रोसेसर दस्तावेज़, स्प्रेडशीट, डेटाबेस, या अन्य सामान्य रिपॉजिटरी में संग्रहीत किया जा सकता है। एक डेटाबेस सिस्टम में, आप पिछले परीक्षण परिणामों को देखने में भी सक्षम हो सकते हैं, जिन्होंने परिणाम उत्पन्न किए, और उन परिणामों को उत्पन्न करने के लिए किस सिस्टम कॉन्फ़िगरेशन का उपयोग किया गया था। ये पिछले परिणाम सामान्यतः एक अलग तालिका में संग्रहीत किए जाते हैं।
टेस्ट स्क्रिप्ट
टेस्ट स्क्रिप्ट एक प्रक्रिया या प्रोग्रामिंग कोड है जो उपयोगकर्ता क्रियाओं को दोहराता है। प्रारंभ में, यह शब्द स्वचालित प्रतिगमन परीक्षण उपकरण द्वारा बनाए गए कार्य के उत्पाद से लिया गया था। किसी टूल या प्रोग्राम का उपयोग करके टेस्ट स्क्रिप्ट बनाने के लिए एक टेस्ट केस बेसलाइन होगा।
टेस्ट सूट
टेस्ट केस के संग्रह के लिए सबसे साधारण शब्द टेस्ट सूट है। परीक्षण सूट में प्रायः परीक्षण मामलों के प्रत्येक संग्रह के लिए अधिक विस्तृत निर्देश या लक्ष्य होते हैं। इसमें निश्चित रूप से एक खंड होता है जहां परीक्षक परीक्षण के दौरान उपयोग किए जाने वाले सिस्टम कॉन्फ़िगरेशन की पहचान करता है। परीक्षण मामलों के समूह में पूर्वापेक्षित अवस्थाएँ या चरण और निम्नलिखित परीक्षणों का विवरण भी हो सकता है।
परीक्षण स्थिरता या परीक्षण डेटा
ज्यादातर मामलों में, किसी विशेष सुविधा की समान कार्यक्षमता का परीक्षण करने के लिए मूल्यों या डेटा के एकाधिक सेट का उपयोग किया जाता है। सभी परीक्षण मूल्यों और परिवर्तनशील पर्यावरणीय घटकों को अलग-अलग फाइलों में एकत्र किया जाता है और परीक्षण डेटा के रूप में संग्रहीत किया जाता है। यह डेटा क्लाइंट को और उत्पाद या प्रोजेक्ट के साथ प्रदान करने के लिए भी उपयोगी है। डेटा उत्पादन का परीक्षण करें जनरेट करने की तकनीकें हैं।
दोहन ​​परीक्षण
सॉफ्टवेयर, उपकरण, डेटा इनपुट और आउटपुट के नमूने, और कॉन्फ़िगरेशन सभी को सामूहिक रूप से टेस्ट हार्नेस के रूप में संदर्भित किया जाता है।
टेस्ट रन
परीक्षण केस या परीक्षण सूट चलाने से परिणामों की रिपोर्ट प्रदान करता है।

प्रमाणपत्र

Further information: सॉफ्टवेयर परीक्षण में प्रमाणन

सॉफ्टवेयर परीक्षकों और गुणवत्ता आश्वासन विशेषज्ञों की व्यावसायिक आकांक्षाओं का समर्थन करने के लिए कई प्रमाणीकरण कार्यक्रम मौजूद हैं। ध्यान दें कि कुछ व्यवसायियों का तर्क है कि परीक्षण क्षेत्र प्रमाणीकरण के लिए तैयार नहीं है, जैसा कि विवाद खंड में उल्लेख किया गया है।

विवाद

कुछ प्रमुख सॉफ्टवेयर परीक्षण विवादों में सम्मिलित हैं:

कुशल बनाम पारंपरिक
क्या परीक्षकों को अनिश्चितता और निरंतर परिवर्तन की शर्तों के तहत काम करना सीखना चाहिए या क्या उन्हें "परिपक्वता" प्रक्रिया का लक्ष्य रखना चाहिए? कुशल परीक्षण आंदोलन को 2006 से मुख्य रूप से व्यावसायिक हलकों में बढ़ती लोकप्रियता मिली है, [77][78] जबकि सरकार और सैन्य [79] सॉफ्टवेयर प्रदाता इस पद्धति का उपयोग करते हैं, लेकिन पारंपरिक परीक्षण-अंतिम मॉडल (जैसे, वाटरफॉल मॉडल में)।
मैनुअल बनाम स्वचालित परीक्षण
कुछ लेखकों का मानना ​​है कि परीक्षण स्वचालन इसके मूल्य की तुलना में इतना महंगा है कि इसे कम से कम इस्तेमाल किया जाना चाहिए।[80] परीक्षण स्वचालन को आवश्यकताओं को पकड़ने और कार्यान्वित करने का एक तरीका माना जा सकता है। एक सामान्य नियम के रूप में, सिस्टम जितना बड़ा होगा और जटिलता जितनी अधिक होगी, टेस्ट ऑटोमेशन में आरओआई उतना ही अधिक होगा। साथ ही, एक संगठन के भीतर ज्ञान साझा करने के सही स्तर के साथ कई परियोजनाओं पर उपकरण और विशेषज्ञता में निवेश को परिशोधित किया जा सकता है।
क्या आईएसओ 29119 सॉफ्टवेयर परीक्षण मानक का अस्तित्व उचित है?
आईएसओ 29119 मानक के संदर्भ में सॉफ़्टवेयर परीक्षण के संदर्भ-संचालित स्कूल के रैंक से महत्वपूर्ण विरोध का गठन किया गया है। सॉफ्टवेयर परीक्षण के लिए अंतर्राष्ट्रीय सोसायटी जैसे व्यावसायिक परीक्षण संघों ने मानक वापस लेने का प्रयास किया है।[81][82]
कुछ चिकित्सक घोषणा करते हैं कि परीक्षण क्षेत्र प्रमाणन के लिए तैयार नहीं है
[83] प्रस्तुत किये गए किसी प्रमाणन के लिए वास्तव में आवेदक को सॉफ्टवेयर का परीक्षण करने की अपनी क्षमता दिखाने की आवश्यकता नहीं है। कोई प्रमाणन व्यापक रूप से स्वीकृत ज्ञान पर आधारित नहीं होता है। प्रमाणीकरण स्वयं किसी व्यक्ति की उत्पादकता, कौशल या व्यावहारिक ज्ञान को नहीं माप सकता है, और एक परीक्षक के रूप में उनकी क्षमता, या व्यावसायिकता की गारंटी नहीं दे सकता है।[84]
अध्ययन दोषों को ठीक करने के सापेक्ष व्यय को दिखाते थे
उनके परिचय और पता लगाने के आधार पर दोषों को ठीक करने के सापेक्ष खर्च को दिखाने के लिए उपयोग किए जाने वाले अध्ययनों की प्रयोज्यता पर विरोधी विचार हैं। उदाहरण के लिए ::सामान्यतः यह माना जाता है कि जितनी जल्दी दोष का पता लगाया जाता है, उसे ठीक करना उतना ही सस्ता होता है। निम्न तालिका में पाई गई अवस्था के आधार पर दोष को ठीक करने की लागत दिखाई गई है।[85] उदाहरण के लिए, यदि आवश्यकताओं में कोई समस्या केवल रिलीज़ के बाद पाई जाती है, तो इसे ठीक करने की लागत आवश्यकताओं की समीक्षा द्वारा पहले ही पाए जाने की तुलना में 10-100 गुना अधिक होगी। आधुनिक निरंतर तैनाती प्रथाओं और क्लाउड-आधारित सेवाओं के आगमन के साथ, समय के साथ पुन: तैनाती और रखरखाव की लागत कम हो सकती है।
दोष को ठीक करने की लागत कुल समय
आवश्यकताएं आर्किटेक्चर निर्माण सिस्टम परिक्षण पोस्ट-रिलीज़
समय आवश्यकताएं 1× 3× 5–10× 10× 10–100×
आर्किटेक्चर – 1× 10× 15× 25–100×
निर्माण – – 1× 10× 10–25×

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

"छोटी परियोजनाएं" वक्र प्रथम वर्ष के छात्रों की केवल दो टीमों से निकला है, एक नमूना आकार इतना छोटा है कि "सामान्य रूप से छोटी परियोजनाओं" को एक्सट्रपलेशन करना पूरी तरह से अनिश्चित है। जीटीई अध्ययन अपने डेटा की व्याख्या नहीं करता है, इसके अलावा यह कहना है कि यह दो परियोजनाओं से आया है, एक बड़ी और एक छोटी। बेल लैब्स "सेफगार्ड" प्रोजेक्ट के लिए उद्धृत पेपर विशेष रूप से यह दावा करता है कि बोहेम के डेटा बिंदुओं का सुझाव देने वाले ठीक-ठाक डेटा एकत्र किए गए हैं। आईबीएम अध्ययन (फगन का पेपर) में ऐसे दावे सम्मिलित हैं जो बोहेम के ग्राफ के विपरीत प्रतीत होते हैं और कोई संख्यात्मक परिणाम नहीं है जो स्पष्ट रूप से उनके डेटा बिंदुओं के अनुरूप हो।

2010 में "मेकिंग सॉफ्टवेयर" के लिए लिखने के अलावा, बोहेम ने टीआरडब्ल्यू डेटा के लिए एक पेपर का हवाला भी नहीं दिया, और वहां उन्होंने 1976 के मूल लेख का हवाला दिया। सही समय पर टीआरडब्ल्यू में बोहेम द्वारा इसका हवाला देने के लिए एक बड़ा अध्ययन किया गया था, लेकिन उस पेपर में उस तरह का डेटा नहीं है जो बोहेम के दावों का समर्थन करता हो।[86]

संबंधित प्रक्रियाएं

सॉफ्टवेयर सत्यापन और सत्यापन

Main articles: सत्यापन और प्रमाणीकरण (सॉफ्टवेयर) and सॉफ्टवेयर गुणवत्ता नियंत्रण

सत्यापन और सत्यापन (सॉफ्टवेयर) के सहयोग से सॉफ्टवेयर परीक्षण का उपयोग किया जाता है:[87]

  • सत्यापन: क्या हमने सॉफ्टवेयर सही बनाया है? (यानी, क्या यह आवश्यकताओं को लागू करता है)।
  • मान्यता: क्या हमने सही सॉफ्टवेयर बनाया है? (यानी, क्या डिलिवरेबल्स ग्राहक को संतुष्ट करते हैं)।

सत्यापन और सत्यापन शब्द सामान्यतः उद्योग में परस्पर विनिमय के लिए उपयोग किए जाते हैं; विरोधाभासी परिभाषाओं के साथ परिभाषित इन दो शब्दों को देखना भी साधारण है। सॉफ्टवेयर इंजीनियरिंग शब्दावली की आईईईई मानक एसोसिएशन शब्दावली के अनुसार:[6]: 80–81 

सत्यापन एक प्रणाली या घटक के मूल्यांकन की प्रक्रिया है जो यह निर्धारित करती है कि किसी दिए गए विकास चरण के उत्पाद उस चरण आरंभ में लगाए गए शर्तों को पूरा करते हैं या नहीं।
सत्यापन विकास प्रक्रिया के दौरान या उसके अंत में एक प्रणाली या घटक का मूल्यांकन करने की प्रक्रिया है, यह निर्धारित करने के लिए कि क्या यह निर्दिष्ट आवश्यकताओं को पूरा करता है।

और, आईएसओ 9000 मानक के अनुसार:

सत्यापन परीक्षा द्वारा और वस्तुनिष्ठ साक्ष्य के प्रावधान के माध्यम से पुष्टि है कि निर्दिष्ट आवश्यकताओं को पूरा किया गया है।
सत्यापन परीक्षा द्वारा और वस्तुनिष्ठ साक्ष्य के प्रावधान के माध्यम से पुष्टि है कि एक विशिष्ट इच्छित उपयोग या आवेदन के लिए आवश्यकताओं को पूरा किया गया है।

विरोधाभास आवश्यकताओं और निर्दिष्ट आवश्यकताओं की अवधारणाओं के उपयोग के कारण होता है लेकिन विभिन्न अर्थों के साथ।

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

लेकिन, आईएसओ 9000 के लिए, निर्दिष्ट आवश्यकताएं विशिष्टताओं का समूह हैं, जैसा कि अभी ऊपर बताया गया है, जिसे सत्यापित किया जाना चाहिए। एक विनिर्देश, जैसा कि पहले बताया गया है, एक सॉफ्टवेयर विकास प्रक्रिया चरण का उत्पाद है जो इनपुट के रूप में एक और विनिर्देश प्राप्त करता है। एक विनिर्देश सफलतापूर्वक सत्यापित होता है जब वह अपने इनपुट विनिर्देश को सही ढंग से लागू करता है। एसआरएस को छोड़कर सभी विनिर्देशों को सत्यापित किया जा सकता है क्योंकि यह पहला है (हालांकि इसे मान्य किया जा सकता है)। उदाहरण: डिज़ाइन विशिष्टता को एसआरएस लागू करना चाहिए; और, निर्माण चरण की कलाकृतियों को डिजाइन विशिष्टता को लागू करना चाहिए।

इसलिए, जब इन शब्दों को सामान्य शब्दों में परिभाषित किया जाता है, तो स्पष्ट विरोधाभास गायब हो जाता है।

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

कुछ लोग यह तर्क दे सकते हैं कि, एसआरएस के लिए, इनपुट हितधारकों के शब्द हैं और इसलिए, एसआरएस सत्यापन एसआरएस सत्यापन के समान है। इस तरह से सोचना उचित नहीं है क्योंकि यह केवल अधिक भ्रम पैदा करता है। एक औपचारिक और तकनीकी इनपुट दस्तावेज़ को सम्मिलित करने वाली प्रक्रिया के रूप में सत्यापन के बारे में सोचना बेहतर है।

सॉफ्टवेयर गुणवत्ता आश्वासन

सॉफ़्टवेयर परीक्षण को सॉफ़्टवेयर गुणवत्ता आश्वासन (एसक्यूए) प्रक्रिया का एक हिस्सा माना जा सकता है।[4]  एसक्यूए में, सॉफ़्टवेयर प्रक्रिया विशेषज्ञ और लेखा परीक्षक दस्तावेज़, कोड और सिस्टम जैसी कलाकृतियों के बजाय सॉफ़्टवेयर विकास प्रक्रिया से संबंधित होते हैं। वे वितरित सॉफ़्टवेयर में समाप्त होने वाले दोषों की संख्या को कम करने के लिए स्वयं सॉफ़्टवेयर इंजीनियरिंग प्रक्रिया की जाँच करते हैं और उसे बदलते हैं: तथाकथित दोष दर। एक स्वीकार्य दोष दर क्या होती है यह सॉफ्टवेयर की प्रकृति पर निर्भर करता है; एक उड़ान सिम्युलेटर वीडियो गेम में एक वास्तविक हवाई जहाज के सॉफ्टवेयर की तुलना में बहुत अधिक दोष सहनशीलता होगी। हालांकि एसक्यूए के साथ घनिष्ठ संबंध हैं, परीक्षण विभाग प्रायः स्वतंत्र रूप से मौजूद होते हैं, और हो सकता है कि कुछ कंपनियों में एसक्यूए का कोई कार्य न हो।

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

यह भी देखें

संदर्भ

  1. ↑ Kaner, Cem (November 17, 2006). खोजपूर्ण परीक्षण (PDF). Quality Assurance Institute Worldwide Annual Software Testing Conference. Orlando, FL. Retrieved November 22, 2014.
  2. ↑ 2.0 2.1 Pan, Jiantao (Spring 1999). "सॉफ्टवेयर परिक्षण" (coursework). Carnegie Mellon University. Retrieved November 21, 2017.
  3. ↑ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand; Fiva, Arno (September 2007). अनुबंध संचालित विकास = टेस्ट संचालित विकास - टेस्ट केस लिखना (PDF). ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007. Dubrovnik, Croatia. Retrieved December 8, 2017.
  4. ↑ 4.0 4.1 4.2 4.3 Kaner, Cem; Falk, Jack; Nguyen, Hung Quoc (1999). कंप्यूटर सॉफ्टवेयर का परीक्षण (2nd ed.). New York: John Wiley and Sons. ISBN 978-0-471-35846-6.
  5. ↑ 5.0 5.1 Kolawa, Adam; Huizinga, Dorota (2007). स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
  6. ↑ 6.0 6.1 6.2 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990, doi:10.1109/IEEESTD.1990.101064, ISBN 978-1-55937-067-7
  7. ↑ "सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस" (pdf). International Software Testing Qualifications Board. March 31, 2011. Section 1.1.2. Retrieved December 15, 2017.
  8. ↑ "सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस" (PDF). International Software Testing Qualifications Board. July 1, 2005. Principle 2, Section 1.3. Archived from the original (PDF) on December 17, 2008. Retrieved December 15, 2017.
  9. ↑ Ramler, Rudolf; Kopetzky, Theodorich; Platz, Wolfgang (April 17, 2012). TOSCA टेस्टसुइट में कॉम्बिनेटरियल टेस्ट डिज़ाइन: सीखे गए सबक और व्यावहारिक निहितार्थ. IEEE Fifth International Conference on Software Testing and Validation (ICST). Montreal, QC, Canada. doi:10.1109/ICST.2012.142.
  10. ↑ "सॉफ्टवेयर परीक्षण के लिए अपर्याप्त बुनियादी ढांचे का आर्थिक प्रभाव" (PDF). National Institute of Standards and Technology. May 2002. Retrieved December 19, 2017.
  11. ↑ Sharma, Bharadwaj (April 2016). "अर्देंटिया टेक्नोलॉजीज: अत्याधुनिक सॉफ्टवेयर समाधान और व्यापक परीक्षण सेवाएं प्रदान करना". CIO Review (India ed.). Retrieved December 20, 2017.
  12. ↑ Gelperin, David; Hetzel, Bill (June 1, 1988). "सॉफ्टवेयर परीक्षण की वृद्धि". Communications of the ACM. 31 (6): 687–695. doi:10.1145/62959.62965. S2CID 14731341.
  13. ↑ Gregory, Janet; Crispin, Lisa (2014). अधिक चुस्त परीक्षण. Addison-Wesley Professional. pp. 23–39. ISBN 978-0-13-374956-4.
  14. ↑ 14.0 14.1 14.2 Myers, Glenford J. (1979). सॉफ्टवेयर परीक्षण की कला. John Wiley and Sons. ISBN 978-0-471-04328-7.
  15. ↑ 15.0 15.1 Graham, D.; Van Veenendaal, E.; Evans, I. (2008). सॉफ्टवेयर परीक्षण की नींव. Cengage Learning. pp. 57–58. ISBN 978-1-84480-989-9.
  16. ↑ 16.0 16.1 16.2 16.3 Oberkampf, W.L.; Roy, C.J. (2010). वैज्ञानिक कंप्यूटिंग में सत्यापन और मान्यता. Cambridge University Press. pp. 154–5. ISBN 978-1-139-49176-1.
  17. ↑ Lee, D.; Netravali, A.N.; Sabnani, K.K.; Sugla, B.; John, A. (1997). "नेटवर्क प्रबंधन के लिए निष्क्रिय परीक्षण और अनुप्रयोग". Proceedings 1997 International Conference on Network Protocols. IEEE Comput. Soc: 113–122. doi:10.1109/icnp.1997.643699. ISBN 978-0-8186-8061-8. S2CID 42596126.
  18. ↑ 18.0 18.1 Cem Kaner (2008), A Tutorial in Exploratory Testing (PDF)
  19. ↑ 19.0 19.1 19.2 19.3 Limaye, M.G. (2009). सॉफ्टवेयर परिक्षण. Tata McGraw-Hill Education. pp. 108–11. ISBN 978-0-07-013990-9.
  20. ↑ 20.0 20.1 20.2 20.3 Saleh, K.A. (2009). सॉफ्टवेयर इंजीनियरिंग. J. Ross Publishing. pp. 224–41. ISBN 978-1-932159-94-3.
  21. ↑ 21.0 21.1 21.2 Ammann, P.; Offutt, J. (2016). सॉफ्टवेयर परीक्षण का परिचय. Cambridge University Press. p. 26. ISBN 978-1-316-77312-3.
  22. ↑ Everatt, G.D.; McLeod Jr., R. (2007). "Chapter 7: Functional Testing". सॉफ्टवेयर परीक्षण: संपूर्ण सॉफ्टवेयर विकास जीवन चक्र का परीक्षण. John Wiley & Sons. pp. 99–121. ISBN 978-0-470-14634-7.
  23. ↑ 23.0 23.1 Cornett, Steve (c. 1996). "कोड कवरेज विश्लेषण". Bullseye Testing Technology. Introduction. Retrieved November 21, 2017.
  24. ↑ 24.0 24.1 Black, R. (2011). व्यावहारिक सॉफ्टवेयर परीक्षण: एक प्रभावी और कुशल परीक्षण पेशेवर बनना. John Wiley & Sons. pp. 44–6. ISBN 978-1-118-07938-6.
  25. ↑ As a simple example, the C function int f(int x){return x*x-6*x+8;} consists of only one statement. All tests against a specification f(x)>=0 will succeed, except if x=3 happens to be chosen.
  26. ↑ Vera-Pérez, Oscar Luis; Danglot, Benjamin; Monperrus, Martin; Baudry, Benoit (2018). "छद्म परीक्षण विधियों का व्यापक अध्ययन". Empirical Software Engineering. 24 (3): 1195–1225. arXiv:1807.05030. Bibcode:2018arXiv180705030V. doi:10.1007/s10664-018-9653-2. S2CID 49744829.
  27. ↑ Patton, Ron (2005). सॉफ्टवेयर परिक्षण (2nd ed.). Indianapolis: Sams Publishing. ISBN 978-0-672-32798-8.
  28. ↑ Laycock, Gilbert T. (1993). विशिष्टता आधारित सॉफ्टवेयर परीक्षण का सिद्धांत और अभ्यास (PDF) (dissertation thesis). Department of Computer Science, University of Sheffield. Retrieved January 2, 2018.
  29. ↑ Bach, James (June 1999). "जोखिम और आवश्यकता-आधारित परीक्षण" (PDF). Computer. 32 (6): 113–114. Retrieved August 19, 2008.
  30. ↑ Savenkov, Roman (2008). सॉफ्टवेयर टेस्टर कैसे बनें. Roman Savenkov Consulting. p. 159. ISBN 978-0-615-23372-7.
  31. ↑ 31.0 31.1 Mathur, A.P. (2011). सॉफ्टवेयर परीक्षण की नींव. Pearson Education India. p. 63. ISBN 978-81-317-5908-0.
  32. ↑ 32.0 32.1 32.2 Clapp, Judith A. (1995). सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण. p. 313. ISBN 978-0-8155-1363-6. Retrieved January 5, 2018.
  33. ↑ 33.0 33.1 Mathur, Aditya P. (2007). सॉफ्टवेयर परीक्षण की नींव. Pearson Education India. p. 18. ISBN 978-81-317-1660-1.
  34. ↑ Lönnberg, Jan (October 7, 2003). सॉफ्टवेयर का दृश्य परीक्षण (PDF) (MSc thesis). Helsinki University of Technology. Retrieved January 13, 2012.
  35. ↑ Chima, Raspal. "दृश्य परीक्षण". TEST Magazine. Archived from the original on July 24, 2012. Retrieved January 13, 2012.
  36. ↑ 36.0 36.1 36.2 Lewis, W.E. (2016). सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार (3rd ed.). CRC Press. pp. 68–73. ISBN 978-1-4398-3436-7.
  37. ↑ 37.0 37.1 Ransome, J.; Misra, A. (2013). कोर सॉफ्टवेयर सुरक्षा: स्रोत पर सुरक्षा. CRC Press. pp. 140–3. ISBN 978-1-4665-6095-6.
  38. ↑ "ब्लैक, व्हाइट और ग्रे बॉक्स के लिए SOA टेस्टिंग टूल्स" (white paper). Crosscheck Networks. Archived from the original on October 1, 2018. Retrieved December 10, 2012.
  39. ↑ Bourque, Pierre; Fairley, Richard E., eds. (2014). "Chapter 5". ज्ञान के सॉफ्टवेयर इंजीनियरिंग निकाय के लिए गाइड. 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. Retrieved January 2, 2018.
  40. ↑ Bourque, P.; Fairley, R.D., eds. (2014). "Chapter 4: Software Testing" (PDF). SWEBOK v3.0: सॉफ़्टवेयर इंजीनियरिंग बॉडी ऑफ़ नॉलेज के लिए गाइड. IEEE. pp. 4–1–4–17. ISBN 978-0-7695-5166-1. Archived from the original (PDF) on June 19, 2018. Retrieved July 13, 2018.
  41. ↑ Dooley, J. (2011). सॉफ्टवेयर विकास और व्यावसायिक अभ्यास. APress. pp. 193–4. ISBN 978-1-4302-3801-0.
  42. ↑ Wiegers, K. (2013). एक सॉफ्टवेयर इंजीनियरिंग संस्कृति बनाना. Addison-Wesley. pp. 211–2. ISBN 978-0-13-348929-3.
  43. ↑ 43.0 43.1 43.2 Lewis, W.E. (2016). सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार (3rd ed.). CRC Press. pp. 92–6. ISBN 978-1-4398-3436-7.
  44. ↑ Machado, P.; Vincenzi, A.; Maldonado, J.C. (2010). "Chapter 1: Software Testing: An Overview". In Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcook, J. (eds.). सॉफ्टवेयर इंजीनियरिंग में परीक्षण तकनीक. Springer Science & Business Media. pp. 13–14. ISBN 978-3-642-14334-2.
  45. ↑ Clapp, J.A.; Stanten, S.F.; Peng, W.W.; et al. (1995). सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण. Nova Data Corporation. p. 254. ISBN 978-0-8155-1363-6.
  46. ↑ 46.0 46.1 46.2 "आईएसटीक्यूबी सीटीएफएल पाठ्यक्रम 2018" (PDF). ISTQB - International Software Testing Qualifications Board. Archived (PDF) from the original on 2022-03-24. Retrieved 2022-04-11.
  47. ↑ Binder, Robert V. (1999). टेस्टिंग ऑब्जेक्ट-ओरिएंटेड सिस्टम्स: ऑब्जेक्ट्स, पैटर्न्स एंड टूल्स. Addison-Wesley Professional. p. 45. ISBN 978-0-201-80938-1.
  48. ↑ Beizer, Boris (1990). सॉफ्टवेयर परीक्षण तकनीक (Second ed.). New York: Van Nostrand Reinhold. pp. 21, 430. ISBN 978-0-442-20672-7.
  49. ↑ Xuan, Jifeng; Monperrus, Martin (2014). "गलती स्थानीयकरण में सुधार के लिए टेस्ट केस शुद्धि". Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2014: 52–63. arXiv:1409.3176. Bibcode:2014arXiv1409.3176X. doi:10.1145/2635868.2635906. ISBN 978-1-4503-3056-5. S2CID 14540841.
  50. ↑ Woods, Anthony J. (June 5, 2015). "परिचालनात्मक स्वीकृति - ISO 29119 सॉफ़्टवेयर परीक्षण मानक का एक अनुप्रयोग" (Whitepaper). Capgemini Australia. Retrieved January 9, 2018.
  51. ↑ Kaner, Cem; Bach, James; Pettichord, Bret (2001). सॉफ़्टवेयर परीक्षण में सीखे गए पाठ: एक प्रसंग-संचालित दृष्टिकोण. Wiley. pp. 31–43. ISBN 978-0-471-08112-8.
  52. ↑ Ammann, Paul; Offutt, Jeff (January 28, 2008). सॉफ्टवेयर परीक्षण का परिचय. Cambridge University Press. p. 215. ISBN 978-0-521-88038-1. Retrieved November 29, 2017.
  53. ↑ Danglot, Benjamin; Vera-Pérez, Oscar Luis; Baudry, Benoit; Monperrus, Martin (2019). "डीस्पॉट के साथ स्वत: परीक्षण सुधार: दस परिपक्व ओपन-सोर्स परियोजनाओं के साथ एक अध्ययन". Empirical Software Engineering (in English). 24 (4): 2603–2635. arXiv:1811.08330. doi:10.1007/s10664-019-09692-y. S2CID 53748524.
  54. ↑ Danglot, Benjamin; Vera-Perez, Oscar; Yu, Zhongxing; Zaidman, Andy; Monperrus, Martin; Baudry, Benoit (November 2019). "परीक्षण प्रवर्धन पर एक स्नोबॉलिंग साहित्य अध्ययन" (PDF). Journal of Systems and Software (in English). 157: 110398. arXiv:1705.10692. doi:10.1016/j.jss.2019.110398. S2CID 20959692.
  55. ↑ "सॉफ्टवेयर परीक्षण में उपयोग की जाने वाली शर्तों की मानक शब्दावली" (PDF). Version 3.1. International Software Testing Qualifications Board. Retrieved January 9, 2018.
  56. ↑ O'Reilly, Tim (September 30, 2005). "वेब 2.0 क्या है". O'Reilly Media. Section 4. End of the Software Release Cycle. Retrieved January 11, 2018.
  57. ↑ Auerbach, Adam (August 3, 2015). "पाइपलाइन का हिस्सा: निरंतर परीक्षण क्यों आवश्यक है". TechWell Insights. TechWell Corp. Retrieved January 12, 2018.
  58. ↑ Philipp-Edmonds, Cameron (December 5, 2014). "जोखिम और सतत परीक्षण के बीच संबंध: वेन एरियोला के साथ एक साक्षात्कार". Stickyminds. Retrieved January 16, 2018.
  59. ↑ Ariola, Wayne; Dunlop, Cynthia (October 2015). DevOps: क्या आप ग्राहकों के लिए बग्स को तेजी से आगे बढ़ा रहे हैं? (PDF). Pacific Northwest Software Quality Conference. Retrieved January 16, 2018.
  60. ↑ Auerbach, Adam (October 2, 2014). "बाएं शिफ्ट करें और गुणवत्ता पहले रखें". TechWell Insights. TechWell Corp. Retrieved January 16, 2018.
  61. ↑ "Section 4.38". ISO/IEC/IEEE 29119-1:2013 - सॉफ्टवेयर और सिस्टम इंजीनियरिंग - सॉफ्टवेयर परीक्षण - भाग 1 - अवधारणाएं और परिभाषाएं. International Organization for Standardization. Retrieved January 17, 2018.
  62. ↑ "वैश्वीकरण चरण-दर-चरण: परीक्षण के लिए विश्व-तैयार दृष्टिकोण। माइक्रोसॉफ्ट डेवलपर नेटवर्क". Msdn.microsoft.com. Archived from the original on June 23, 2012. Retrieved January 13, 2012.
  63. ↑ ""क्विकचेक: हास्केल कार्यक्रमों के यादृच्छिक परीक्षण के लिए एक हल्का उपकरण"". Proceedings of the Fifth ACM SIGPLAN International Conference on Functional Programming. Icfp '00: 268–279. 2000. doi:10.1145/351240.351266. ISBN 978-1-58113-202-1. S2CID 5668071.
  64. ↑ "सॉफ्टवेयर परीक्षण जीवनचक्र". etestinghub. Testing Phase in Software Testing. Retrieved January 13, 2012.
  65. ↑ Dustin, Elfriede (2002). प्रभावी सॉफ्टवेयर परीक्षण. Addison-Wesley Professional. p. 3. ISBN 978-0-201-79429-8.
  66. ↑ Brown, Chris; Cobb, Gary; Culbertson, Robert (April 12, 2002). रैपिड सॉफ्टवेयर टेस्टिंग का परिचय.
  67. ↑ 67.0 67.1 "टेस्ट ड्रिवेन डेवलपमेंट (TDD) क्या है?". Agile Alliance. December 5, 2015. Retrieved March 17, 2018.
  68. ↑ "मोबाइल अनुप्रयोगों के लिए परीक्षण-संचालित विकास और सतत एकीकरण". msdn.microsoft.com. Retrieved March 17, 2018.
  69. ↑ Joshi, Shrinivas; Orso, Alessandro (October 2007). "SCARPE: चयनात्मक कब्जा करने और कार्यक्रम निष्पादन की पुनरावृत्ति के लिए एक तकनीक और उपकरण". 2007 IEEE International Conference on Software Maintenance: 234–243. doi:10.1109/ICSM.2007.4362636. ISBN 978-1-4244-1255-6. S2CID 17718313.
  70. ↑ Steven, John; Chandra, Pravir; Fleck, Bob; Podgurski, Andy (September 2000). "jRapture: अवलोकन-आधारित परीक्षण के लिए एक कैप्चर/रीप्ले टूल". ACM SIGSOFT Software Engineering Notes (in English). 25 (5): 158–167. doi:10.1145/347636.348993. ISSN 0163-5948.
  71. ↑ Saieva, Anthony; Singh, Shirish; Kaiser, Gail (September 2020). "बाइनरी पुनर्लेखन के माध्यम से एड हॉक टेस्ट जनरेशन". 2020 IEEE 20th International Working Conference on Source Code Analysis and Manipulation (SCAM). Adelaide, Australia: IEEE: 115–126. doi:10.1109/SCAM51674.2020.00018. ISBN 978-1-7281-9248-2. S2CID 219618921.
  72. ↑ Tiwari, Deepika; Zhang, Long; Monperrus, Martin; Baudry, Benoit (2021). "परीक्षण सूट में सुधार के लिए उत्पादन निगरानी". IEEE Transactions on Reliability. 71 (3): 1381–1397. arXiv:2012.01198. doi:10.1109/TR.2021.3101318. ISSN 0018-9529. S2CID 227248080.
  73. ↑ Zetterlund, Louise; Tiwari, Deepika; Monperrus, Martin; Baudry, Benoit (April 2022). "स्कीमा दोषों का पता लगाने के लिए हार्वेस्टिंग प्रोडक्शन ग्राफक्यूएल क्वेरीज़". 2022 IEEE Conference on Software Testing, Verification and Validation (ICST). Valencia, Spain: IEEE: 365–376. arXiv:2112.08267. doi:10.1109/ICST53961.2022.00014. ISBN 978-1-6654-6679-0. S2CID 245144782.
  74. ↑ Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "एक सामान्य परीक्षण क्षमता सिद्धांत: वर्ग, गुण, जटिलता और परीक्षण में कमी". IEEE Transactions on Software Engineering. 40 (9): 862–894. doi:10.1109/TSE.2014.2331690. ISSN 0098-5589. S2CID 6015996.
  75. ↑ Rodríguez, Ismael (2009). "एक सामान्य टेस्टेबिलिटी थ्योरी". CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings. pp. 572–586. doi:10.1007/978-3-642-04081-8_38. ISBN 978-3-642-04080-1.
  76. ↑ IEEE (1998). सॉफ्टवेयर परीक्षण प्रलेखन के लिए IEEE मानक. New York: IEEE. ISBN 978-0-7381-1443-9.
  77. ↑ Strom, David (July 1, 2009). "हम सब कहानी का हिस्सा हैं". Software Test & Performance Collaborative. Archived from the original on August 31, 2009.
  78. ↑ Griffiths, M. (2005). "Teaching agile project management to the PMI". फुर्तीली विकास सम्मेलन (ADC'05). pp. 318–322. doi:10.1109/ADC.2005.45. ISBN 978-0-7695-2487-0. S2CID 30322339. {{cite book}}: |work= ignored (help)
  79. ↑ Willison, John S. (April 2004). "फुर्तीली सेना के लिए फुर्तीली सॉफ्टवेयर डेवलपमेंट". CrossTalk. STSC (April 2004). Archived from the original on October 29, 2005.
  80. ↑ An example is Mark Fewster, Dorothy Graham: Software Test Automation. Addison Wesley, 1999, ISBN 978-0-201-33140-0.
  81. ↑ "stop29119". commonsensetesting.org. Archived from the original on October 2, 2014.
  82. ↑ Paul Krill (August 22, 2014). "सॉफ्टवेयर परीक्षक आईएसओ 29119 मानकों के प्रस्ताव पर अड़े हुए हैं". InfoWorld.
  83. ↑ Kaner, Cem (2001). "NSF अनुदान प्रस्ताव 'सॉफ्टवेयर परीक्षण में शैक्षणिक और व्यावसायिक पाठ्यक्रमों की गुणवत्ता में महत्वपूर्ण सुधार के लिए नींव रखना'" (PDF). Archived from the original (PDF) on November 27, 2009. Retrieved October 13, 2006.
  84. ↑ Kaner, Cem (2003). सॉफ्टवेयर परीक्षकों की प्रभावशीलता को मापना (PDF). STAR East. Archived from the original (PDF) on March 26, 2010. Retrieved January 18, 2018.
  85. ↑ McConnell, Steve (2004). कोड पूर्ण (2nd ed.). Microsoft Press. p. 29. ISBN 978-0-7356-1967-8.
  86. ↑ Bossavit, Laurent (November 20, 2013). "The cost of defects: an illustrated history". सॉफ्टवेयर इंजीनियरिंग के लेप्रेचौंस: कैसे लोककथाएं वास्तविकता में बदल जाती हैं और इसके बारे में क्या करना है. leanpub.
  87. ↑ Tran, Eushiuan (1999). "सत्यापन/सत्यापन/प्रमाणन" (coursework). Carnegie Mellon University. Retrieved August 13, 2008.

अग्रिम पठन

बाहरी कड़ियाँ

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सॉफ्टवेयर_परिक्षण&oldid=255400’