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

Revision as of 09:56, 24 January 2023

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

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

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

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

व्हाइट बॉक्स परीक्षण आरेख

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

परीक्षण स्तर

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

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

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

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

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

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

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

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

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

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

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

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

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

स्वीकृति परीक्षण में आमतौर पर निम्नलिखित चार प्रकार शामिल होते हैं:^[44]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बीटा परीक्षण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अमेरिकी विकलांग अधिनियम 1990
धारा 508 पुनर्वास अधिनियम 1973 में संशोधन
विश्वव्यापी वेब संकाय (W3C) की वेब अभिगम्यता पहल (WAI)

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

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

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

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

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

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

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

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

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

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

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

ए/बी परीक्षण

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

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

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

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

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

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

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

गुण परीक्षण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कलाकृतियों का परीक्षण

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

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

प्रमाणपत्र

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

विवाद

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

फुर्तीली बनाम पारंपरिक: क्या परीक्षकों को अनिश्चितता और निरंतर परिवर्तन की परिस्थितियों में काम करना सीखना चाहिए या उन्हें क्षमता परिपक्वता मॉडल | प्रक्रिया परिपक्वता का लक्ष्य रखना चाहिए? चुस्त परीक्षण आंदोलन को 2006 से मुख्य रूप से व्यावसायिक हलकों में बढ़ती लोकप्रियता मिली है,^[75]^[76] जबकि सरकार और सेना^[77] सॉफ्टवेयर प्रदाता इस पद्धति का उपयोग करते हैं, लेकिन पारंपरिक परीक्षण-अंतिम मॉडल (जैसे, जलप्रपात मॉडल में) का भी उपयोग करते हैं।^{[citation needed]}
मैनुअल बनाम स्वचालित परीक्षण: कुछ लेखकों का मानना है कि परीक्षण स्वचालन इसके मूल्य की तुलना में इतना महंगा है कि इसे कम से कम इस्तेमाल किया जाना चाहिए।^[78] परीक्षण स्वचालन को आवश्यकताओं को पकड़ने और कार्यान्वित करने का एक तरीका माना जा सकता है। एक सामान्य नियम के रूप में, सिस्टम जितना बड़ा होगा और जटिलता जितनी अधिक होगी, टेस्ट ऑटोमेशन में आरओआई उतना ही अधिक होगा। साथ ही, एक संगठन के भीतर ज्ञान साझा करने के सही स्तर के साथ कई परियोजनाओं पर उपकरण और विशेषज्ञता में निवेश को परिशोधित किया जा सकता है।
क्या ISO/IEC 29119 सॉफ़्टवेयर परीक्षण मानक का अस्तित्व उचित है?: ISO 29119 मानक के संदर्भ में सॉफ़्टवेयर परीक्षण के संदर्भ-संचालित स्कूल के रैंक से महत्वपूर्ण विरोध का गठन किया गया है। सॉफ्टवेयर परीक्षण के लिए अंतर्राष्ट्रीय सोसायटी जैसे व्यावसायिक परीक्षण संघों ने मानक वापस लेने का प्रयास किया है।^[79]^[80]
कुछ चिकित्सक घोषणा करते हैं कि परीक्षण क्षेत्र प्रमाणन के लिए तैयार नहीं है: ^[81] अब पेश किए जाने वाले किसी प्रमाणन के लिए वास्तव में आवेदक को सॉफ्टवेयर का परीक्षण करने की अपनी क्षमता दिखाने की आवश्यकता नहीं होती है। कोई प्रमाणीकरण ज्ञान के व्यापक रूप से स्वीकृत निकाय पर आधारित नहीं है। प्रमाणन स्वयं किसी व्यक्ति की उत्पादकता, उनके कौशल या व्यावहारिक ज्ञान को माप नहीं सकता है, और एक परीक्षक के रूप में उनकी क्षमता या व्यावसायिकता की गारंटी नहीं दे सकता है।^[82]
दोषों को ठीक करने के सापेक्ष खर्च दिखाने के लिए अध्ययन: उनके परिचय और पहचान के आधार पर दोषों को ठीक करने के सापेक्ष खर्च को दिखाने के लिए उपयोग किए जाने वाले अध्ययनों की प्रयोज्यता पर विरोधी विचार हैं। उदाहरण के लिए:

<ब्लॉककोट> आमतौर पर यह माना जाता है कि जितनी जल्दी कोई दोष पाया जाता है, उसे ठीक करना उतना ही सस्ता होता है। निम्न तालिका दोष के पता लगाने की अवस्था के आधार पर दोष को ठीक करने की लागत को दर्शाती है।^[83] उदाहरण के लिए, यदि आवश्यकताओं में कोई समस्या केवल रिलीज़ के बाद पाई जाती है, तो इसे ठीक करने की लागत आवश्यकताओं की समीक्षा द्वारा पहले ही पाए जाने की तुलना में 10–100 गुना अधिक होगी। आधुनिक निरंतर परिनियोजन प्रथाओं और क्लाउड-आधारित सेवाओं के आगमन के साथ, पुन: परिनियोजन और रखरखाव की लागत समय के साथ कम हो सकती है।

Cost to fix a defect		Time detected
Cost to fix a defect		Requirements	Architecture	Construction	System test	Post-release
Time introduced	Requirements	1×	3×	5–10×	10×	10–100×
	Architecture	–	1×	10×	15×	25–100×
	Construction	–	–	1×	10×	10–25×

</ब्लॉककोट>

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

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

यह भी देखें

संदर्भ

↑ Kaner, Cem (November 17, 2006). खोजपूर्ण परीक्षण (PDF). Quality Assurance Institute Worldwide Annual Software Testing Conference. Orlando, FL. Retrieved November 22, 2014.
↑ ^2.0 ^2.1 Pan, Jiantao (Spring 1999). "सॉफ्टवेयर परिक्षण" (coursework). Carnegie Mellon University. Retrieved November 21, 2017.
↑ 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.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.0 ^5.1 Kolawa, Adam; Huizinga, Dorota (2007). स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
↑ ^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
↑ "सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस" (pdf). International Software Testing Qualifications Board. March 31, 2011. Section 1.1.2. Retrieved December 15, 2017.
↑ "सर्टिफाइड टेस्टर फाउंडेशन लेवल सिलेबस" (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.
↑ 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.
↑ "सॉफ्टवेयर परीक्षण के लिए अपर्याप्त बुनियादी ढांचे का आर्थिक प्रभाव" (PDF). National Institute of Standards and Technology. May 2002. Retrieved December 19, 2017.
↑ Sharma, Bharadwaj (April 2016). "अर्देंटिया टेक्नोलॉजीज: अत्याधुनिक सॉफ्टवेयर समाधान और व्यापक परीक्षण सेवाएं प्रदान करना". CIO Review (India ed.). Retrieved December 20, 2017.
↑ Gelperin, David; Hetzel, Bill (June 1, 1988). "सॉफ्टवेयर परीक्षण की वृद्धि". Communications of the ACM. 31 (6): 687–695. doi:10.1145/62959.62965. S2CID 14731341.
↑ Gregory, Janet; Crispin, Lisa (2014). अधिक चुस्त परीक्षण. Addison-Wesley Professional. pp. 23–39. ISBN 978-0-13-374956-4.
↑ ^14.0 ^14.1 ^14.2 Myers, Glenford J. (1979). सॉफ्टवेयर परीक्षण की कला. John Wiley and Sons. ISBN 978-0-471-04328-7.
↑ ^15.0 ^15.1 Graham, D.; Van Veenendaal, E.; Evans, I. (2008). सॉफ्टवेयर परीक्षण की नींव. Cengage Learning. pp. 57–58. ISBN 978-1-84480-989-9.
↑ ^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.
↑ 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.0 ^18.1 Cem Kaner (2008), A Tutorial in Exploratory Testing (PDF)
↑ ^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.0 ^20.1 ^20.2 ^20.3 Saleh, K.A. (2009). सॉफ्टवेयर इंजीनियरिंग. J. Ross Publishing. pp. 224–41. ISBN 978-1-932159-94-3.
↑ ^21.0 ^21.1 ^21.2 Ammann, P.; Offutt, J. (2016). सॉफ्टवेयर परीक्षण का परिचय. Cambridge University Press. p. 26. ISBN 978-1-316-77312-3.
↑ Everatt, G.D.; McLeod Jr., R. (2007). "Chapter 7: Functional Testing". सॉफ्टवेयर परीक्षण: संपूर्ण सॉफ्टवेयर विकास जीवन चक्र का परीक्षण. John Wiley & Sons. pp. 99–121. ISBN 978-0-470-14634-7.
↑ ^23.0 ^23.1 Cornett, Steve (c. 1996). "कोड कवरेज विश्लेषण". Bullseye Testing Technology. Introduction. Retrieved November 21, 2017.
↑ ^24.0 ^24.1 Black, R. (2011). व्यावहारिक सॉफ्टवेयर परीक्षण: एक प्रभावी और कुशल परीक्षण पेशेवर बनना. John Wiley & Sons. pp. 44–6. ISBN 978-1-118-07938-6.
↑ 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.
↑ Laycock, Gilbert T. (1993). विशिष्टता आधारित सॉफ्टवेयर परीक्षण का सिद्धांत और अभ्यास (PDF) (dissertation thesis). Department of Computer Science, University of Sheffield. Retrieved January 2, 2018.
↑ Bach, James (June 1999). "जोखिम और आवश्यकता-आधारित परीक्षण" (PDF). Computer. 32 (6): 113–114. Retrieved August 19, 2008.
↑ Savenkov, Roman (2008). सॉफ्टवेयर टेस्टर कैसे बनें. Roman Savenkov Consulting. p. 159. ISBN 978-0-615-23372-7.
↑ ^29.0 ^29.1 Mathur, A.P. (2011). सॉफ्टवेयर परीक्षण की नींव. Pearson Education India. p. 63. ISBN 978-81-317-5908-0.
↑ ^30.0 ^30.1 ^30.2 Clapp, Judith A. (1995). सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण. p. 313. ISBN 978-0-8155-1363-6. Retrieved January 5, 2018.
↑ ^31.0 ^31.1 Mathur, Aditya P. (2007). सॉफ्टवेयर परीक्षण की नींव. Pearson Education India. p. 18. ISBN 978-81-317-1660-1.
↑ Lönnberg, Jan (October 7, 2003). सॉफ्टवेयर का दृश्य परीक्षण (PDF) (MSc thesis). Helsinki University of Technology. Retrieved January 13, 2012.
↑ Chima, Raspal. "दृश्य परीक्षण". TEST Magazine. Archived from the original on July 24, 2012. Retrieved January 13, 2012.
↑ ^34.0 ^34.1 ^34.2 Lewis, W.E. (2016). सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार (3rd ed.). CRC Press. pp. 68–73. ISBN 978-1-4398-3436-7.
↑ ^35.0 ^35.1 Ransome, J.; Misra, A. (2013). कोर सॉफ्टवेयर सुरक्षा: स्रोत पर सुरक्षा. CRC Press. pp. 140–3. ISBN 978-1-4665-6095-6.
↑ "ब्लैक, व्हाइट और ग्रे बॉक्स के लिए SOA टेस्टिंग टूल्स" (white paper). Crosscheck Networks. Archived from the original on October 1, 2018. Retrieved December 10, 2012.
↑ Bourque, Pierre; Fairley, Richard E., eds. (2014). "Chapter 5". ज्ञान के सॉफ्टवेयर इंजीनियरिंग निकाय के लिए गाइड. 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. Retrieved January 2, 2018.
↑ 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.
↑ Dooley, J. (2011). सॉफ्टवेयर विकास और व्यावसायिक अभ्यास. APress. pp. 193–4. ISBN 978-1-4302-3801-0.
↑ Wiegers, K. (2013). एक सॉफ्टवेयर इंजीनियरिंग संस्कृति बनाना. Addison-Wesley. pp. 211–2. ISBN 978-0-13-348929-3.
↑ ^41.0 ^41.1 ^41.2 Lewis, W.E. (2016). सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार (3rd ed.). CRC Press. pp. 92–6. ISBN 978-1-4398-3436-7.
↑ 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.
↑ Clapp, J.A.; Stanten, S.F.; Peng, W.W.; et al. (1995). सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण. Nova Data Corporation. p. 254. ISBN 978-0-8155-1363-6.
↑ ^44.0 ^44.1 ^44.2 "आईएसटीक्यूबी सीटीएफएल पाठ्यक्रम 2018" (PDF). ISTQB - International Software Testing Qualifications Board. Archived (PDF) from the original on 2022-03-24. Retrieved 2022-04-11.
↑ Binder, Robert V. (1999). टेस्टिंग ऑब्जेक्ट-ओरिएंटेड सिस्टम्स: ऑब्जेक्ट्स, पैटर्न्स एंड टूल्स. Addison-Wesley Professional. p. 45. ISBN 978-0-201-80938-1.
↑ Beizer, Boris (1990). सॉफ्टवेयर परीक्षण तकनीक (Second ed.). New York: Van Nostrand Reinhold. pp. 21, 430. ISBN 978-0-442-20672-7.
↑ 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.
↑ Woods, Anthony J. (June 5, 2015). "परिचालनात्मक स्वीकृति - ISO 29119 सॉफ़्टवेयर परीक्षण मानक का एक अनुप्रयोग" (Whitepaper). Capgemini Australia. Retrieved January 9, 2018.
↑ Kaner, Cem; Bach, James; Pettichord, Bret (2001). सॉफ़्टवेयर परीक्षण में सीखे गए पाठ: एक प्रसंग-संचालित दृष्टिकोण. Wiley. pp. 31–43. ISBN 978-0-471-08112-8.
↑ Ammann, Paul; Offutt, Jeff (January 28, 2008). सॉफ्टवेयर परीक्षण का परिचय. Cambridge University Press. p. 215. ISBN 978-0-521-88038-1. Retrieved November 29, 2017.
↑ 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.
↑ 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.
↑ "सॉफ्टवेयर परीक्षण में उपयोग की जाने वाली शर्तों की मानक शब्दावली" (PDF). Version 3.1. International Software Testing Qualifications Board. Retrieved January 9, 2018.
↑ O'Reilly, Tim (September 30, 2005). "वेब 2.0 क्या है". O'Reilly Media. Section 4. End of the Software Release Cycle. Retrieved January 11, 2018.
↑ Auerbach, Adam (August 3, 2015). "पाइपलाइन का हिस्सा: निरंतर परीक्षण क्यों आवश्यक है". TechWell Insights. TechWell Corp. Retrieved January 12, 2018.
↑ Philipp-Edmonds, Cameron (December 5, 2014). "जोखिम और सतत परीक्षण के बीच संबंध: वेन एरियोला के साथ एक साक्षात्कार". Stickyminds. Retrieved January 16, 2018.
↑ Ariola, Wayne; Dunlop, Cynthia (October 2015). DevOps: क्या आप ग्राहकों के लिए बग्स को तेजी से आगे बढ़ा रहे हैं? (PDF). Pacific Northwest Software Quality Conference. Retrieved January 16, 2018.
↑ Auerbach, Adam (October 2, 2014). "बाएं शिफ्ट करें और गुणवत्ता पहले रखें". TechWell Insights. TechWell Corp. Retrieved January 16, 2018.
↑ "Section 4.38". ISO/IEC/IEEE 29119-1:2013 - सॉफ्टवेयर और सिस्टम इंजीनियरिंग - सॉफ्टवेयर परीक्षण - भाग 1 - अवधारणाएं और परिभाषाएं. International Organization for Standardization. Retrieved January 17, 2018.
↑ "वैश्वीकरण चरण-दर-चरण: परीक्षण के लिए विश्व-तैयार दृष्टिकोण। माइक्रोसॉफ्ट डेवलपर नेटवर्क". Msdn.microsoft.com. Archived from the original on June 23, 2012. Retrieved January 13, 2012.
↑ ""क्विकचेक: हास्केल कार्यक्रमों के यादृच्छिक परीक्षण के लिए एक हल्का उपकरण"". 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.
↑ "सॉफ्टवेयर परीक्षण जीवनचक्र". etestinghub. Testing Phase in Software Testing. Retrieved January 13, 2012.
↑ Dustin, Elfriede (2002). प्रभावी सॉफ्टवेयर परीक्षण. Addison-Wesley Professional. p. 3. ISBN 978-0-201-79429-8.
↑ Brown, Chris; Cobb, Gary; Culbertson, Robert (April 12, 2002). रैपिड सॉफ्टवेयर टेस्टिंग का परिचय.
↑ ^65.0 ^65.1 "टेस्ट ड्रिवेन डेवलपमेंट (TDD) क्या है?". Agile Alliance. December 5, 2015. Retrieved March 17, 2018.
↑ "मोबाइल अनुप्रयोगों के लिए परीक्षण-संचालित विकास और सतत एकीकरण". msdn.microsoft.com. Retrieved March 17, 2018.
↑ 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.
↑ 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.
↑ 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.
↑ 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.
↑ 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.
↑ 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.
↑ 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.
↑ IEEE (1998). सॉफ्टवेयर परीक्षण प्रलेखन के लिए IEEE मानक. New York: IEEE. ISBN 978-0-7381-1443-9.
↑ Strom, David (July 1, 2009). "हम सब कहानी का हिस्सा हैं". Software Test & Performance Collaborative. Archived from the original on August 31, 2009.
↑ 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)
↑ Willison, John S. (April 2004). "फुर्तीली सेना के लिए फुर्तीली सॉफ्टवेयर डेवलपमेंट". CrossTalk. STSC (April 2004). Archived from the original on October 29, 2005.
↑ An example is Mark Fewster, Dorothy Graham: Software Test Automation. Addison Wesley, 1999, ISBN 978-0-201-33140-0.
↑ "stop29119". commonsensetesting.org. Archived from the original on October 2, 2014.
↑ Paul Krill (August 22, 2014). "सॉफ्टवेयर परीक्षक आईएसओ 29119 मानकों के प्रस्ताव पर अड़े हुए हैं". InfoWorld.
↑ Kaner, Cem (2001). "NSF अनुदान प्रस्ताव 'सॉफ्टवेयर परीक्षण में शैक्षणिक और व्यावसायिक पाठ्यक्रमों की गुणवत्ता में महत्वपूर्ण सुधार के लिए नींव रखना'" (PDF). Archived from the original (PDF) on November 27, 2009. Retrieved October 13, 2006.
↑ Kaner, Cem (2003). सॉफ्टवेयर परीक्षकों की प्रभावशीलता को मापना (PDF). STAR East. Archived from the original (PDF) on March 26, 2010. Retrieved January 18, 2018.
↑ McConnell, Steve (2004). कोड पूर्ण (2nd ed.). Microsoft Press. p. 29. ISBN 978-0-7356-1967-8.
↑ Bossavit, Laurent (November 20, 2013). "The cost of defects: an illustrated history". सॉफ्टवेयर इंजीनियरिंग के लेप्रेचौंस: कैसे लोककथाएं वास्तविकता में बदल जाती हैं और इसके बारे में क्या करना है. leanpub.
↑ Tran, Eushiuan (1999). "सत्यापन/सत्यापन/प्रमाणन" (coursework). Carnegie Mellon University. Retrieved August 13, 2008.

आगे की पढाई

Meyer, Bertrand (August 2008). "Seven Principles of Software Testing" (PDF). Computer. Vol. 41, no. 8. pp. 99–101. doi:10.1109/MC.2008.306. Retrieved November 21, 2017.

इस पेज में लापता आंतरिक लिंक की सूची

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

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

श्रेणी:कंप्यूटर व्यवसाय

[Kaner_1-1] Kaner, Cem (November 17, 2006). खोजपूर्ण परीक्षण (PDF). Quality Assurance Institute Worldwide Annual Software Testing Conference. Orlando, FL. Retrieved November 22, 2014.

[pan-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.

[Kaner2-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.

[kolawa-5] 5.0 ^5.1 Kolawa, Adam; Huizinga, Dorota (2007). स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.

[IEEEglossary-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.

[Myers_1979-14] 14.0 ^14.1 ^14.2 Myers, Glenford J. (1979). सॉफ्टवेयर परीक्षण की कला. John Wiley and Sons. ISBN 978-0-471-04328-7.

[GrahamFoundations08-15] 15.0 ^15.1 Graham, D.; Van Veenendaal, E.; Evans, I. (2008). सॉफ्टवेयर परीक्षण की नींव. Cengage Learning. pp. 57–58. ISBN 978-1-84480-989-9.

[OberkampfVerif10-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.

[KanerTutorial-18] 18.0 ^18.1 Cem Kaner (2008), A Tutorial in Exploratory Testing (PDF)

[LimayeSoftware09-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.

[SalehSoftware09-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.

[AmmannIntro16-21] 21.0 ^21.1 ^21.2 Ammann, P.; Offutt, J. (2016). सॉफ्टवेयर परीक्षण का परिचय. Cambridge University Press. p. 26. ISBN 978-1-316-77312-3.

[EverettSoftware07-22] Everatt, G.D.; McLeod Jr., R. (2007). "Chapter 7: Functional Testing". सॉफ्टवेयर परीक्षण: संपूर्ण सॉफ्टवेयर विकास जीवन चक्र का परीक्षण. John Wiley & Sons. pp. 99–121. ISBN 978-0-470-14634-7.

[CornettCode96-23] 23.0 ^23.1 Cornett, Steve (c. 1996). "कोड कवरेज विश्लेषण". Bullseye Testing Technology. Introduction. Retrieved November 21, 2017.

[BlackPragmatic11-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] Laycock, Gilbert T. (1993). विशिष्टता आधारित सॉफ्टवेयर परीक्षण का सिद्धांत और अभ्यास (PDF) (dissertation thesis). Department of Computer Science, University of Sheffield. Retrieved January 2, 2018.

[27] Bach, James (June 1999). "जोखिम और आवश्यकता-आधारित परीक्षण" (PDF). Computer. 32 (6): 113–114. Retrieved August 19, 2008.

[28] Savenkov, Roman (2008). सॉफ्टवेयर टेस्टर कैसे बनें. Roman Savenkov Consulting. p. 159. ISBN 978-0-615-23372-7.

[MathurFound11-63-29] 29.0 ^29.1 Mathur, A.P. (2011). सॉफ्टवेयर परीक्षण की नींव. Pearson Education India. p. 63. ISBN 978-81-317-5908-0.

[Clapp-30] 30.0 ^30.1 ^30.2 Clapp, Judith A. (1995). सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण. p. 313. ISBN 978-0-8155-1363-6. Retrieved January 5, 2018.

[Mathur-31] 31.0 ^31.1 Mathur, Aditya P. (2007). सॉफ्टवेयर परीक्षण की नींव. Pearson Education India. p. 18. ISBN 978-81-317-1660-1.

[32] Lönnberg, Jan (October 7, 2003). सॉफ्टवेयर का दृश्य परीक्षण (PDF) (MSc thesis). Helsinki University of Technology. Retrieved January 13, 2012.

[33] Chima, Raspal. "दृश्य परीक्षण". TEST Magazine. Archived from the original on July 24, 2012. Retrieved January 13, 2012.

[LewisSoftware16-34] 34.0 ^34.1 ^34.2 Lewis, W.E. (2016). सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार (3rd ed.). CRC Press. pp. 68–73. ISBN 978-1-4398-3436-7.

[RansomeCore13-35] 35.0 ^35.1 Ransome, J.; Misra, A. (2013). कोर सॉफ्टवेयर सुरक्षा: स्रोत पर सुरक्षा. CRC Press. pp. 140–3. ISBN 978-1-4665-6095-6.

[ref4-36] "ब्लैक, व्हाइट और ग्रे बॉक्स के लिए SOA टेस्टिंग टूल्स" (white paper). Crosscheck Networks. Archived from the original on October 1, 2018. Retrieved December 10, 2012.

[Computer.org-37] Bourque, Pierre; Fairley, Richard E., eds. (2014). "Chapter 5". ज्ञान के सॉफ्टवेयर इंजीनियरिंग निकाय के लिए गाइड. 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. Retrieved January 2, 2018.

[BourqueSWEBOK14-4-38] 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.

[DooleySoftware11-39] Dooley, J. (2011). सॉफ्टवेयर विकास और व्यावसायिक अभ्यास. APress. pp. 193–4. ISBN 978-1-4302-3801-0.

[WiegersCreating13-40] Wiegers, K. (2013). एक सॉफ्टवेयर इंजीनियरिंग संस्कृति बनाना. Addison-Wesley. pp. 211–2. ISBN 978-0-13-348929-3.

[LewisSoftware16-2-41] 41.0 ^41.1 ^41.2 Lewis, W.E. (2016). सॉफ्टवेयर परीक्षण और सतत गुणवत्ता सुधार (3rd ed.). CRC Press. pp. 92–6. ISBN 978-1-4398-3436-7.

[BorbaTesting10-42] 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.

[ClappSoftware95-43] Clapp, J.A.; Stanten, S.F.; Peng, W.W.; et al. (1995). सॉफ्टवेयर गुणवत्ता नियंत्रण, त्रुटि विश्लेषण और परीक्षण. Nova Data Corporation. p. 254. ISBN 978-0-8155-1363-6.

[:0-44] 44.0 ^44.1 ^44.2 "आईएसटीक्यूबी सीटीएफएल पाठ्यक्रम 2018" (PDF). ISTQB - International Software Testing Qualifications Board. Archived (PDF) from the original on 2022-03-24. Retrieved 2022-04-11.

[45] Binder, Robert V. (1999). टेस्टिंग ऑब्जेक्ट-ओरिएंटेड सिस्टम्स: ऑब्जेक्ट्स, पैटर्न्स एंड टूल्स. Addison-Wesley Professional. p. 45. ISBN 978-0-201-80938-1.

[46] Beizer, Boris (1990). सॉफ्टवेयर परीक्षण तकनीक (Second ed.). New York: Van Nostrand Reinhold. pp. 21, 430. ISBN 978-0-442-20672-7.

[47] 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.

[48] Woods, Anthony J. (June 5, 2015). "परिचालनात्मक स्वीकृति - ISO 29119 सॉफ़्टवेयर परीक्षण मानक का एक अनुप्रयोग" (Whitepaper). Capgemini Australia. Retrieved January 9, 2018.

[49] Kaner, Cem; Bach, James; Pettichord, Bret (2001). सॉफ़्टवेयर परीक्षण में सीखे गए पाठ: एक प्रसंग-संचालित दृष्टिकोण. Wiley. pp. 31–43. ISBN 978-0-471-08112-8.

[50] Ammann, Paul; Offutt, Jeff (January 28, 2008). सॉफ्टवेयर परीक्षण का परिचय. Cambridge University Press. p. 215. ISBN 978-0-521-88038-1. Retrieved November 29, 2017.

[51] 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.

[52] 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.

[53] "सॉफ्टवेयर परीक्षण में उपयोग की जाने वाली शर्तों की मानक शब्दावली" (PDF). Version 3.1. International Software Testing Qualifications Board. Retrieved January 9, 2018.

[54] O'Reilly, Tim (September 30, 2005). "वेब 2.0 क्या है". O'Reilly Media. Section 4. End of the Software Release Cycle. Retrieved January 11, 2018.

[essential-55] Auerbach, Adam (August 3, 2015). "पाइपलाइन का हिस्सा: निरंतर परीक्षण क्यों आवश्यक है". TechWell Insights. TechWell Corp. Retrieved January 12, 2018.

[stickym-56] Philipp-Edmonds, Cameron (December 5, 2014). "जोखिम और सतत परीक्षण के बीच संबंध: वेन एरियोला के साथ एक साक्षात्कार". Stickyminds. Retrieved January 16, 2018.

[pnsqc-57] Ariola, Wayne; Dunlop, Cynthia (October 2015). DevOps: क्या आप ग्राहकों के लिए बग्स को तेजी से आगे बढ़ा रहे हैं? (PDF). Pacific Northwest Software Quality Conference. Retrieved January 16, 2018.

[shift-58] Auerbach, Adam (October 2, 2014). "बाएं शिफ्ट करें और गुणवत्ता पहले रखें". TechWell Insights. TechWell Corp. Retrieved January 16, 2018.

[59] "Section 4.38". ISO/IEC/IEEE 29119-1:2013 - सॉफ्टवेयर और सिस्टम इंजीनियरिंग - सॉफ्टवेयर परीक्षण - भाग 1 - अवधारणाएं और परिभाषाएं. International Organization for Standardization. Retrieved January 17, 2018.

[60] "वैश्वीकरण चरण-दर-चरण: परीक्षण के लिए विश्व-तैयार दृष्टिकोण। माइक्रोसॉफ्ट डेवलपर नेटवर्क". Msdn.microsoft.com. Archived from the original on June 23, 2012. Retrieved January 13, 2012.

[61] ""क्विकचेक: हास्केल कार्यक्रमों के यादृच्छिक परीक्षण के लिए एक हल्का उपकरण"". 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.

[62] "सॉफ्टवेयर परीक्षण जीवनचक्र". etestinghub. Testing Phase in Software Testing. Retrieved January 13, 2012.

[63] Dustin, Elfriede (2002). प्रभावी सॉफ्टवेयर परीक्षण. Addison-Wesley Professional. p. 3. ISBN 978-0-201-79429-8.

[64] Brown, Chris; Cobb, Gary; Culbertson, Robert (April 12, 2002). रैपिड सॉफ्टवेयर टेस्टिंग का परिचय.

[AgileAllianceTDD-65] 65.0 ^65.1 "टेस्ट ड्रिवेन डेवलपमेंट (TDD) क्या है?". Agile Alliance. December 5, 2015. Retrieved March 17, 2018.

[66] "मोबाइल अनुप्रयोगों के लिए परीक्षण-संचालित विकास और सतत एकीकरण". msdn.microsoft.com. Retrieved March 17, 2018.

[67] 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.

[68] 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.

[69] 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.

[70] 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.

[71] 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.

[72] 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.

[73] 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.

[74] IEEE (1998). सॉफ्टवेयर परीक्षण प्रलेखन के लिए IEEE मानक. New York: IEEE. ISBN 978-0-7381-1443-9.

[75] Strom, David (July 1, 2009). "हम सब कहानी का हिस्सा हैं". Software Test & Performance Collaborative. Archived from the original on August 31, 2009.

[76] 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)

[77] Willison, John S. (April 2004). "फुर्तीली सेना के लिए फुर्तीली सॉफ्टवेयर डेवलपमेंट". CrossTalk. STSC (April 2004). Archived from the original on October 29, 2005.

[78] An example is Mark Fewster, Dorothy Graham: Software Test Automation. Addison Wesley, 1999, ISBN 978-0-201-33140-0.

[79] "stop29119". commonsensetesting.org. Archived from the original on October 2, 2014.

[80] Paul Krill (August 22, 2014). "सॉफ्टवेयर परीक्षक आईएसओ 29119 मानकों के प्रस्ताव पर अड़े हुए हैं". InfoWorld.

[81] Kaner, Cem (2001). "NSF अनुदान प्रस्ताव 'सॉफ्टवेयर परीक्षण में शैक्षणिक और व्यावसायिक पाठ्यक्रमों की गुणवत्ता में महत्वपूर्ण सुधार के लिए नींव रखना'" (PDF). Archived from the original (PDF) on November 27, 2009. Retrieved October 13, 2006.

[82] Kaner, Cem (2003). सॉफ्टवेयर परीक्षकों की प्रभावशीलता को मापना (PDF). STAR East. Archived from the original (PDF) on March 26, 2010. Retrieved January 18, 2018.

[83] McConnell, Steve (2004). कोड पूर्ण (2nd ed.). Microsoft Press. p. 29. ISBN 978-0-7356-1967-8.

[Bossavit-Leprechauns-84] Bossavit, Laurent (November 20, 2013). "The cost of defects: an illustrated history". सॉफ्टवेयर इंजीनियरिंग के लेप्रेचौंस: कैसे लोककथाएं वास्तविकता में बदल जाती हैं और इसके बारे में क्या करना है. leanpub.

[tran-85] Tran, Eushiuan (1999). "सत्यापन/सत्यापन/प्रमाणन" (coursework). Carnegie Mellon University. Retrieved August 13, 2008.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]

[74]

[75]

[76]

[77]

[78]

[79]

[80]

[81]

[82]

[83]

[84]

[85]

@@ Line 308: / Line 308: @@
 गुण परीक्षण को कभी-कभी "जनरेटिव टेस्टिंग" या "क्विकचेक टेस्टिंग" के रूप में भी जाना जाता है, क्योंकि इसे हास्केल लाइब्रेरी क्विकचेक द्वारा पेश किया गया था और इसे लोकप्रिय बनाया गया था।<ref>{{Cite journal |year=2000 |title="क्विकचेक: हास्केल कार्यक्रमों के यादृच्छिक परीक्षण के लिए एक हल्का उपकरण"|url=https://dl.acm.org/doi/abs/10.1145/351240.351266 |journal=Proceedings of the Fifth ACM SIGPLAN International Conference on Functional Programming |series=Icfp '00 |pages=268–279 |doi=10.1145/351240.351266 |isbn=978-1-58113-202-1 |s2cid=5668071}}</ref>
-=== ''रूपांतरित परीक्षण'' ===
+=== रूपान्तरित परीक्षण ===
-{{Main|Metamorphic testing}}
+{{Main|रूपान्तरित परीक्षण}}
-मेटामॉर्फिक टेस्टिंग (एमटी) एक गुण-आधारित सॉफ्टवेयर टेस्टिंग तकनीक है, जो टेस्ट ऑरेकल समस्या और टेस्ट केस जेनरेशन प्रॉब्लम को संबोधित करने के लिए एक प्रभावी तरीका हो सकता है। परीक्षण ऑरेकल समस्या चयनित परीक्षण मामलों के अपेक्षित परिणामों को निर्धारित करने या यह निर्धारित करने में कठिनाई है कि वास्तविक आउटपुट अपेक्षित परिणामों से सहमत हैं या नहीं।
+रूपान्तरित परीक्षण (एमटी) एक गुण-आधारित सॉफ्टवेयर टेस्टिंग तकनीक है, जो टेस्ट ऑरेकल समस्या और टेस्ट केस जेनरेशन प्रॉब्लम को संबोधित करने के लिए एक प्रभावी तरीका हो सकता है। परीक्षण ऑरेकल समस्या चयनित परीक्षण मामलों के अपेक्षित परिणामों को निर्धारित करने या यह निर्धारित करने में कठिनाई है कि वास्तविक आउटपुट अपेक्षित परिणामों से सहमत हैं या नहीं।
 === वीसीआर परीक्षण ===
-वीसीआर परीक्षण, जिसे प्लेबैक परीक्षण या रिकॉर्ड/रीप्ले परीक्षण के रूप में भी जाना जाता है, प्रतिगमन परीक्षणों की विश्वसनीयता और गति को बढ़ाने के लिए एक परीक्षण तकनीक है जिसमें एक घटक शामिल होता है जो धीमा या अविश्वसनीय होता है, अक्सर परीक्षक के बाहर एक तृतीय-पक्ष एपीआई नियंत्रण। इसमें बाहरी घटक के साथ सिस्टम की बातचीत की रिकॉर्डिंग (कैसेट) बनाना शामिल है, और फिर परीक्षण के बाद के रन पर बाहरी सिस्टम के साथ संचार करने के विकल्प के रूप में रिकॉर्ड किए गए इंटरैक्शन को फिर से चलाना शामिल है।
+वीसीआर परीक्षण, जिसे "प्लेबैक परीक्षण" या "रिकॉर्ड/रीप्ले" परीक्षण के रूप में भी जाना जाता है, प्रतिगमन परीक्षणों की विश्वसनीयता और गति को बढ़ाने के लिए एक परीक्षण तकनीक है जिसमें एक घटक शामिल होता है जो धीमा या अविश्वसनीय होता है, अक्सर एक तृतीय-पक्ष एपीआई परीक्षक के नियंत्रण के बाहर इसमें बाहरी घटक के साथ सिस्टम के इंटरैक्शन की एक रिकॉर्डिंग ("कैसेट") बनाना शामिल है, और फिर परीक्षण के बाद के रन पर बाहरी सिस्टम के साथ संचार करने के विकल्प के रूप में रिकॉर्ड किए गए इंटरैक्शन को फिर से चलाना शामिल है।
-इस तकनीक को रूबी लाइब्रेरी [https://github.com/vcr/vcr vcr] द्वारा वेब विकास में लोकप्रिय बनाया गया था।
+इस तकनीक को रूबी लाइब्रेरी द्वारा वेब विकास में लोकप्रिय बनाया गया था।
 == परीक्षण प्रक्रिया ==
-=== पारंपरिक जलप्रपात विकास मॉडल ===
+=== परंपरागत जलप्रपात विकास मॉडल ===
 जलप्रपात विकास में एक सामान्य अभ्यास यह है कि परीक्षण परीक्षकों के एक स्वतंत्र समूह द्वारा किया जाता है। ऐसा हो सकता है:
@@ Line 326: / Line 327: @@
 * कार्यक्षमता विकसित होने के बाद, लेकिन ग्राहक को भेजने से पहले।<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 |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|Capability Maturity Model Integration|Waterfall model}}
-=== चुस्त या XP विकास मॉडल ===
+{{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" />
-यह पद्धति किसी भी औपचारिक परीक्षण दल तक पहुँचने से पहले, विकास द्वारा किए गए परीक्षण प्रयास को बढ़ा देती है। कुछ अन्य विकास मॉडल में, अधिकांश परीक्षण निष्पादन आवश्यकताओं को परिभाषित करने और कोडिंग प्रक्रिया पूरी होने के बाद होता है।
+यह कार्यप्रणाली किसी भी औपचारिक परीक्षण दल तक पहुँचने से पहले, विकास द्वारा किए गए परीक्षण के प्रयास को बढ़ा देती है। कुछ अन्य विकास मॉडलों में, अधिकांश परीक्षण निष्पादन आवश्यकताओं को परिभाषित किए जाने और कोडिंग प्रक्रिया पूरी होने के बाद होता है।
-=== एक नमूना परीक्षण चक्र ===
+=== नमूना परीक्षण चक्र ===
-हालांकि संगठनों के बीच भिन्नताएं मौजूद हैं, परीक्षण के लिए एक विशिष्ट चक्र है।<ref name="pan" />[[जलप्रपात विकास]] मॉडल को नियोजित करने वाले संगठनों के बीच नीचे दिया गया नमूना सामान्य है। अन्य विकास मॉडलों में आमतौर पर समान प्रथाएं पाई जाती हैं, लेकिन यह उतनी स्पष्ट या स्पष्ट नहीं हो सकती हैं।
+हालांकि संगठनों के बीच भिन्नताएं मौजूद हैं, परीक्षण के लिए एक विशिष्ट चक्र है।<ref name="pan" /> [[जलप्रपात विकास]] मॉडल को नियोजित करने वाले संगठनों के बीच नीचे दिया गया नमूना सामान्य है। अन्य विकास मॉडलों में आमतौर पर समान प्रथाएं पाई जाती हैं, लेकिन यह उतनी स्पष्ट या स्पष्ट नहीं हो सकती हैं।
 * आवश्यकताओं का विश्लेषण: परीक्षण [[सॉफ्टवेयर विकास जीवन चक्र]] की आवश्यकताओं के चरण में शुरू होना चाहिए। डिज़ाइन चरण के दौरान, परीक्षक यह निर्धारित करने के लिए काम करते हैं कि डिज़ाइन के कौन से पहलू परीक्षण योग्य हैं और वे परीक्षण किन मापदंडों के साथ काम करते हैं।
@@ Line 354: / Line 353: @@
 == स्वचालित परीक्षण ==
-{{Main|Test automation}}
+{{Main|परीक्षण स्वचालन}}
-कई प्रोग्रामिंग समूह {{Like whom?|date=August 2018}} ज्यादा से ज्यादा भरोसा कर रहे हैं {{Vague|date=August 2018}} परीक्षण स्वचालन पर, विशेष रूप से समूह जो परीक्षण-संचालित विकास का उपयोग करते हैं। कई रूपरेखाएँ हैं {{Specify|date=April 2019}} में परीक्षण लिखने के लिए, और निरंतर एकीकरण सॉफ़्टवेयर स्वचालित रूप से परीक्षण चलाएगा हर बार कोड को [[संस्करण नियंत्रण]] प्रणाली में चेक किया जाता है।
+कई प्रोग्रामिंग समूह अधिक से अधिक स्वचालित परीक्षण पर भरोसा कर रहे हैं, विशेष रूप से ऐसे समूह जो परीक्षण-संचालित विकास का उपयोग करते हैं। परीक्षण लिखने के लिए कई रूपरेखाएँ [निर्दिष्ट] हैं, और निरंतर एकीकरण सॉफ़्टवेयर स्वचालित रूप से परीक्षण चलाएगा हर बार कोड को [[संस्करण नियंत्रण]] प्रणाली में चेक किया जाता है।
-जबकि स्वचालन वह सब कुछ पुन: उत्पन्न नहीं कर सकता है जो एक मानव कर सकता है (और वे सभी तरीके जो वे इसे करने के बारे में सोचते हैं), यह प्रतिगमन परीक्षण के लिए बहुत उपयोगी हो सकता है। हालांकि, वास्तव में उपयोगी होने के लिए परीक्षण स्क्रिप्ट के एक अच्छी तरह से विकसित [[परीक्षण सूट]] की आवश्यकता होती है।
+जबकि स्वचालन वह सब कुछ पुन: उत्पन्न नहीं कर सकता जो एक मानव कर सकता है (और वे सभी तरीके जो वे ऐसा करने के बारे में सोचते हैं), यह प्रतिगमन परीक्षण के लिए बहुत उपयोगी हो सकता है। हालाँकि, इसे वास्तव में उपयोगी होने के लिए परीक्षण स्क्रिप्ट के एक अच्छी तरह से विकसित टेस्ट सूट की आवश्यकता होती है।
 === परीक्षण उपकरण ===
-परीक्षण उपकरण और डिबगर्स द्वारा कार्यक्रम परीक्षण और दोष का पता लगाने में महत्वपूर्ण सहायता की जा सकती है।
+प्रोग्राम टेस्टिंग और फॉल्ट डिटेक्शन को टेस्टिंग टूल्स और डिबगर्स द्वारा काफी मदद मिल सकती है। परीक्षण/डीबग टूल में विशेषताएं शामिल हैं जैसे:
-परीक्षण/डीबग टूल में निम्न विशेषताएं शामिल हैं:
-* प्रोग्राम मॉनिटर, प्रोग्राम कोड की पूर्ण या आंशिक निगरानी की अनुमति देता है, जिसमें शामिल हैं:
+* प्रोग्राम मॉनिटर, प्रोग्राम कोड की पूर्ण या आंशिक निगरानी की अनुमति देना, जिसमें निम्न शामिल हैं:
-** [[निर्देश सेट सिम्युलेटर]], पूर्ण निर्देश स्तर की निगरानी और ट्रेस सुविधाओं की अनुमति देता है
+** निर्देश सेट सिम्युलेटर, पूर्ण निर्देश स्तर की निगरानी और सुविधाओं का पता लगाने की अनुमति
-** [[सूत्र]], प्रोग्राम कोड के निष्पादन के पूर्ण नियंत्रण की अनुमति देता है जिसमें शामिल हैं: -
+** हाइपरवाइजर, प्रोग्राम कोड के निष्पादन के पूर्ण नियंत्रण की अनुमति देता है, जिसमें शामिल हैं: -
-** कार्यक्रम एनीमेशन, स्रोत स्तर पर या [[मशीन कोड]] में चरण-दर-चरण निष्पादन और सशर्त विराम बिंदु की अनुमति
+** प्रोग्राम एनीमेशन, स्रोत स्तर पर या मशीन कोड में चरण-दर-चरण निष्पादन और सशर्त ब्रेकपॉइंट की अनुमति
 ** कोड कवरेज रिपोर्ट
 * स्वरूपित डंप या [[प्रतीकात्मक डिबगिंग]], त्रुटि या चुने हुए बिंदुओं पर कार्यक्रम चर के निरीक्षण की अनुमति देने वाले उपकरण
@@ Line 378: / Line 377: @@
 === कैप्चर और रीप्ले ===
-कैप्चर और रीप्ले टेस्टिंग में एप्लिकेशन के साथ इंटरैक्ट करते समय एंड-टू-एंड उपयोग परिदृश्य एकत्र करना और इन परिदृश्यों को परीक्षण मामलों में बदलना शामिल है। कैप्चर और रीप्ले के संभावित अनुप्रयोगों में प्रतिगमन परीक्षणों की पीढ़ी शामिल है। SCARPE उपकरण <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> अध्ययन के तहत आवेदन के एक सबसेट को चुनिंदा रूप से कैप्चर करता है क्योंकि यह निष्पादित होता है। JRapture एक निष्पादित जावा प्रोग्राम और होस्ट सिस्टम पर घटकों जैसे फाइल, या ग्राफिकल यूजर इंटरफेस पर घटनाओं के बीच बातचीत के अनुक्रम को कैप्चर करता है। इन दृश्यों को अवलोकन-आधारित परीक्षण के लिए फिर से चलाया जा सकता है।<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> AutographQL, GraphQL API पर उपयोगकर्ता के अनुरोधों की निगरानी करता है और परीक्षण मामलों को उत्पन्न करता है जो स्कीमा दोषों का पता लगा सकते हैं <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>
+== सॉफ्टवेयर परीक्षण में माप ==
+{{main|सॉफ़्टवेयर गुणवत्ता}}
-== सॉफ्टवेयर परीक्षण में माप ==
+गुणवत्ता उपायों में शुद्धता, पूर्णता, सुरक्षा और आईएसओ/आईईसी 9126 आवश्यकताएं जैसे क्षमता, विश्वसनीयता, दक्षता, सुवाह्यता, रखरखाव, अनुकूलता और उपयोगिता जैसे विषय शामिल हैं।
-{{main|Software quality}}
-गुणवत्ता उपायों में [[शुद्धता (कंप्यूटर विज्ञान)]], पूर्णता, [[कंप्यूटर सुरक्षा ऑडिट]] और ISO/IEC 9126 आवश्यकताएं जैसे क्षमता, विश्वसनीयता इंजीनियरिंग, [[एल्गोरिथम दक्षता]], [[में porting]], रखरखाव, अनुकूलता और उपयोगिता जैसे विषय शामिल हैं।
-अक्सर उपयोग किए जाने वाले कई सॉफ़्टवेयर मेट्रिक्स या उपाय हैं, जिनका उपयोग सॉफ़्टवेयर की स्थिति या परीक्षण की पर्याप्तता को निर्धारित करने में सहायता के लिए किया जाता है।
+कई बार उपयोग किए जाने वाले सॉफ़्टवेयर मेट्रिक्स, या उपाय हैं, जिनका उपयोग सॉफ़्टवेयर की स्थिति या परीक्षण की पर्याप्तता को निर्धारित करने में सहायता के लिए किया जाता है।
 === परीक्षण कठिनाई का पदानुक्रम ===
-प्रत्येक संदर्भ में एक पूर्ण परीक्षण सूट बनाने के लिए आवश्यक परीक्षण मामलों की संख्या के आधार पर (यानी एक परीक्षण सूट जैसे कि, यदि इसे परीक्षण के तहत कार्यान्वयन पर लागू किया जाता है, तो हम यह निर्धारित करने के लिए पर्याप्त जानकारी एकत्र करते हैं कि सिस्टम सही है या गलत कुछ विनिर्देशों के अनुसार), परीक्षण कठिनाई का एक पदानुक्रम प्रस्तावित किया गया है।<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 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 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: एक परिमित पूर्ण परीक्षण सूट मौजूद है।
@@ Line 401: / Line 399: @@
 यह साबित हो गया है कि प्रत्येक वर्ग अगले में सख्ती से शामिल है। उदाहरण के लिए, परीक्षण जब हम मानते हैं कि परीक्षण के तहत कार्यान्वयन के व्यवहार को नियतात्मक परिमित-राज्य मशीन द्वारा निविष्टियों और आउटपुट के कुछ ज्ञात परिमित सेटों के लिए निरूपित किया जा सकता है और कुछ ज्ञात अवस्थाएँ कक्षा I (और सभी बाद की कक्षाओं) से संबंधित हैं ). हालाँकि, यदि राज्यों की संख्या ज्ञात नहीं है, तो यह केवल द्वितीय श्रेणी से सभी वर्गों के अंतर्गत आता है। यदि परीक्षण के तहत कार्यान्वयन एक निर्धारक परिमित-राज्य मशीन होना चाहिए जो एकल ट्रेस (और इसकी निरंतरता) के लिए विनिर्देश को विफल कर दे, और इसकी राज्यों की संख्या अज्ञात है, तो यह केवल कक्षा III से कक्षाओं के अंतर्गत आता है। टेम्पोरल मशीनों का परीक्षण जहां कुछ वास्तविक-बाध्य अंतराल के भीतर इनपुट का उत्पादन किया जाता है, केवल कक्षा IV से संबंधित है, जबकि कई गैर-नियतात्मक प्रणालियों का परीक्षण केवल कक्षा V से संबंधित है (लेकिन सभी नहीं, और कुछ भी कक्षा I से संबंधित हैं) ). कक्षा I में शामिल करने के लिए कल्पित संगणना मॉडल की सरलता की आवश्यकता नहीं है, क्योंकि कुछ परीक्षण मामलों में किसी प्रोग्रामिंग भाषा में लिखे गए कार्यान्वयन शामिल हैं, और निरंतर परिमाण के आधार पर मशीनों के रूप में परिभाषित परीक्षण कार्यान्वयन, कक्षा I में साबित हुए हैं। अन्य विस्तृत मामले, जैसे [[मैथ्यू हेनेसी]] द्वारा टेस्टिंग फ्रेमवर्क मस्ट सिमेंटिक्स के तहत, और तर्कसंगत टाइमआउट वाली टेम्पोरल मशीन, क्लास II से संबंधित हैं।
-== कलाकृतियों का परीक्षण ==
+== ''कलाकृतियों का परीक्षण'' ==
 एक सॉफ्टवेयर परीक्षण प्रक्रिया कई आर्टिफैक्ट (सॉफ्टवेयर विकास) का उत्पादन कर सकती है। उत्पादित वास्तविक कलाकृतियाँ उपयोग किए गए सॉफ़्टवेयर विकास मॉडल, हितधारक और संगठनात्मक आवश्यकताओं का एक कारक हैं।

v t e कंप्यूटर विज्ञान
Note: This template roughly follows the 2012 ACM Computing Classification System.
हार्डवेयर	मुद्रित सर्किट बोर्ड परिधीय एकीकृत परिपथ बड़े पैमाने पर एकीकरण चिप पर सिस्टम (एसओसी) ऊर्जा की खपत (ग्रीन कंप्यूटिंग) इलेक्ट्रॉनिक डिजाइन स्वचालन हार्डवेयर एक्सिलरेशन
कंप्यूटर सिस्टम संगठन	कंप्यूटर आर्किटेक्चर अंतः स्थापित प्रणाली रीयल-टाइम कंप्यूटिंग निर्भरता
नेटवर्क	नेटवर्क आर्किटेक्चर नेटवर्क प्रोटोकॉल नेटवर्क घटक नेटवर्क अनुसूचक नेटवर्क प्रदर्शन मूल्यांकन नेटवर्क सेवा
सॉफ्टवेयर संगठन	दुभाषिया मध्यस्थ आभासी मशीन ऑपरेटिंग सिस्टम सॉफ्टवेयर गुणवत्ता
सॉफ्टवेयर नोटेशन और टूल्स	प्रोग्रामिंग प्रतिमान प्रोग्रामिंग भाषा संकलक डोमेन-विशिष्ट भाषा मॉडलिंग भाषा सॉफ्टवेयर फ्रेमवर्क समन्वित विकास पर्यावरण सॉफ्टवेयर विन्यास प्रबंधन सॉफ्टवेयर लाइब्रेरी सॉफ्टवेयर रिपोजिटरी
सॉफ्टवेयर डेवलपमेंट	नियंत्रण चर सॉफ्टवेयर विकास प्रक्रिया आवश्यकताओं के विश्लेषण सॉफ्टवेर डिज़ाइन सॉफ्टवेयर निर्माण सॉफ्टवेयर परिनियोजन सॉफ्टवेयर इंजीनियरिंग सॉफ्टवेयर की रखरखाव प्रोग्रामिंग टीम ओपन-सोर्स मॉडल
गणना का सिद्धांत	गणना का मॉडल औपचारिक भाषा ऑटोमेटा सिद्धांत कम्प्यूटेबिलिटी सिद्धांत कम्प्यूटेशनल जटिलता सिद्धांत तर्क शब्दार्थ
कलन विधि	एल्गोरिदम डिजाइन एल्गोरिदम का विश्लेषण एल्गोरिदमिक दक्षता यादृच्छिक एल्गोरिदम कम्प्यूटेशनल ज्यामिति
कंप्यूटिंग का गणित	गणित पृथक करें संभावना सांख्यिकी गणितीय सॉफ्टवेयर सूचना सिद्धांत गणितीय विश्लेषण संख्यात्मक विश्लेषण सैद्धांतिक कंप्यूटर विज्ञान
सूचना प्रणाली	डेटाबेस प्रबंधन प्रणाली सूचना भंडारण प्रणाली उद्यम सूचना प्रणाली सामाजिक सूचना प्रणाली भौगोलिक सूचना प्रणाली निर्णय समर्थन प्रणाली प्रक्रिया नियंत्रण प्रणाली मल्टीमीडिया सूचना प्रणाली डेटा माइनिंग डिजिटल लाइब्रेरी कंप्यूटिंग प्लेटफॉर्म डिजिटल विपणन वर्ल्ड वाइड वेब सूचना की पुनर्प्राप्ति
सुरक्षा	क्रिप्टोग्राफी औपचारिक तरीके सुरक्षा सेवाएं अतिक्रमण संसूचन प्रणाली हार्डवेयर सुरक्षा नेटवर्क सुरक्षा सूचना सुरक्षा आवेदन सुरक्षा
मानव-कंप्यूटर संपर्क	पारस्परिक प्रभाव वाली डिज़ाइन सामाजिक कंप्यूटिंग सर्वव्यापक कंप्यूटिंग विज़ुअलाइज़ेशन एक्सेसिबिलिटी
Concurrency	समवर्ती कंप्यूटिंग समानांतर कंप्यूटिंग वितरित अभिकलन मल्टीथ्रेडिंग मल्टीप्रोसेसिंग
कृत्रिम बुद्धि	प्राकृतिक भाषा प्रसंस्करण ज्ञान प्रतिनिधित्व और तर्क कंप्यूटर दृष्टी स्वचालित योजना और समय-निर्धारण खोज पद्धति नियंत्रण विधि कृत्रिम बुद्धि का दर्शन डिस्ट्रिब्यूटेड आर्टिफिशियल इंटेलिजेंस
मशीन लर्निंग	पर्यवेक्षित अध्ययन अनपर्यवेक्षित लर्निंग सुदृढीकरण सीखना बहु-कार्य सीखने क्रॉस-सत्यापन
ग्राफिक्स	एनिमेशन रेंडरिंग छवि हेरफेर ग्राफ़िक्स प्रोसेसिंग युनिट मिश्रित वास्तविकता आभासी वास्तविकता छवि संपीड़न सॉलिड मॉडलिंग
एप्लाइड कंप्यूटिंग	ई-कॉमर्स उपक्रम सॉफ्टवेयर कम्प्यूटेशनल गणित कम्प्यूटेशनल भौतिकी कम्प्यूटेशनल केमिस्ट्री कम्प्यूटेशनल बायोलॉजी कम्प्यूटेशनल सामाजिक विज्ञान कम्प्यूटेशनल इंजीनियरिंग कम्प्यूटेशनल हेल्थकेयर डिजिटल कला इलेक्ट्रॉनिक प्रकाशन सायबर युद्ध इलेक्ट्रॉनिक वोटिंग वीडियो गेम वर्ड प्रोसेसिंग संचालन अनुसंधान शैक्षिक प्रौद्योगिकी दस्तावेज़ प्रबंधन
Category Outline WikiProject Commons

v t e Software testing
The "box" approach	Black-box testing All-pairs testing Exploratory testing Fuzz testing Model-based testing Scenario testing Grey-box testing White-box testing API testing Mutation testing Static testing
Testing levels	Acceptance testing Integration testing System testing Unit testing
Testing types, techniques, and tactics	A/B testing Benchmark Compatibility testing Concolic testing Concurrent testing Conformance testing Continuous testing Destructive testing Development testing Dynamic program analysis Installation testing Regression testing Security testing Smoke testing (software) Software performance testing Symbolic execution Test automation Usability testing
See also	Graphical user interface testing Manual testing Orthogonal array testing Pair testing Soak testing Software reliability testing Stress testing Web testing

Anonymous

Search

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

Revision as of 09:56, 24 January 2023

दोष और असफलता

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

अर्थशास्त्र

भूमिकाएं

इतिहास

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

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

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

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

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

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

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

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

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

परीक्षण स्तर

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

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

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

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

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

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

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

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

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

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

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

बीटा परीक्षण

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

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

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

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

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

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

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

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

ए/बी परीक्षण

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

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

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

गुण परीक्षण

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

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

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

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

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

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

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

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

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

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

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

कलाकृतियों का परीक्षण

प्रमाणपत्र

विवाद

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

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

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

यह भी देखें

संदर्भ

आगे की पढाई

इस पेज में लापता आंतरिक लिंक की सूची

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

Navigation

Wiki tools

Page tools

Other projects

Hidden categories