परीक्षण कुंजी अंक

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



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



मुझे ऐसा लगता है कि इस रिपोर्ट में व्याख्याता एक वैज्ञानिक और एक प्रोग्रामर के दृष्टिकोण से सबसे पर्याप्त रूप से और यथोचित रूप से "क्या परीक्षण कर रहा है" की व्याख्या करने में सक्षम था। यह अजीब है कि यह पाठ अभी तक हब पर दिखाई नहीं दिया है



मैं यहां इस रिपोर्ट का संक्षिप्त विवरण देता हूं। पाठ के अंत में पूर्ण संस्करण और साथ ही उल्लिखित वीडियो के लिंक हैं।

परीक्षण कुंजी अंक

प्रिय साथियों,



पहले समझने की कोशिश करो कि परीक्षण क्या नहीं है।



परीक्षण विकास नहीं है ,



भले ही परीक्षक परीक्षण (स्वचालन परीक्षण = प्रोग्रामिंग) सहित कार्यक्रम करने में सक्षम हों, वे कुछ सहायक कार्यक्रम (स्वयं के लिए) विकसित कर सकते हैं।



हालांकि, परीक्षण एक सॉफ्टवेयर विकास गतिविधि नहीं है।



परीक्षण एक विश्लेषण नहीं है ,



और आवश्यकताओं का संग्रह और विश्लेषण नहीं।



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



परीक्षण प्रबंधन नहीं है ,



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



परीक्षण तकनीकी लेखन नहीं है ,



हालाँकि, परीक्षकों को अपने परीक्षण और अपने काम का दस्तावेजीकरण करना होगा।



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



गतिविधि केवल तभी महत्वपूर्ण है जब यह मांग में है, अर्थात, परीक्षकों को "निर्यात के लिए" कुछ उत्पादन करना चाहिए। वे "निर्यात के लिए" क्या करते हैं?



दोष, दोष वर्णन या परीक्षण रिपोर्ट? यह आंशिक रूप से सच है।



लेकिन यह पूरी सच्चाई नहीं है।

परीक्षकों की मुख्य गतिविधि

इस तथ्य में निहित है कि वे सॉफ्टवेयर उत्पाद की गुणवत्ता पर नकारात्मक प्रतिक्रिया के साथ सॉफ्टवेयर विकास परियोजना में प्रतिभागियों को प्रदान करते हैं।







"नकारात्मक प्रतिक्रिया" कोई नकारात्मक अर्थ नहीं लेती है, और इसका मतलब यह नहीं है कि परीक्षक कुछ बुरा करते हैं, या वे कुछ बुरा करते हैं। यह सिर्फ एक तकनीकी शब्द है जिसका मतलब है एक काफी सरल बात।



लेकिन यह बात बहुत महत्वपूर्ण है, और शायद परीक्षकों की गतिविधियों का एकमात्र सबसे महत्वपूर्ण घटक है।



एक विज्ञान है - " सिस्टम सिद्धांत "। यह ऐसी चीज़ को "प्रतिक्रिया" के रूप में परिभाषित करता है।



"प्रतिक्रिया" कुछ डेटा है जो आउटपुट से इनपुट पर वापस जाता है, या डेटा का कुछ हिस्सा जो आउटपुट से इनपुट पर वापस जाता है। यह प्रतिक्रिया सकारात्मक और नकारात्मक हो सकती है।



दोनों प्रकार की प्रतिक्रियाएं समान रूप से महत्वपूर्ण हैं।



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



नकारात्मक प्रतिक्रिया कुछ प्रकार की नकारात्मक प्रतिक्रिया के रूप में अंत उपयोगकर्ताओं से भी आ सकती है। या यह परीक्षकों से आ सकता है।



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



वैसे, यह वह जगह है जहां परीक्षक बढ़ते गुणवत्ता के लिए जिम्मेदार नहीं हैं। वे उन लोगों की मदद करते हैं जो इसके लिए जिम्मेदार हैं।

शब्द "परीक्षण" के पर्यायवाची

इस दृष्टिकोण से कि परीक्षण नकारात्मक प्रतिक्रिया का प्रावधान है, विश्व-प्रसिद्ध संक्षिप्त नाम क्यूए (अंग्रेजी गुणवत्ता आश्वासन - गुणवत्ता आश्वासन) निश्चित रूप से "परीक्षण" शब्द का पर्याय नहीं है।



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



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







कभी-कभी परीक्षण गुणवत्ता नियंत्रण के कुछ अलग रूप के रूप में निहित होता है।



परीक्षण के इतिहास से भ्रम पैदा होता है। अलग-अलग समय में, "परीक्षण" शब्द का अर्थ था विभिन्न क्रियाएं जिन्हें 2 बड़े वर्गों में विभाजित किया जा सकता है: बाहरी और आंतरिक।

बाहरी परिभाषाएँ

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

आंतरिक परिभाषाएँ

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



ऐसी परिभाषाएँ रचनात्मक रूप से WHAT परीक्षण गतिविधियों की व्याख्या करती हैं, लेकिन वे WHAT परीक्षण के बारे में थोड़ा भी विचार नहीं करती हैं, जिसके लिए कार्यक्रम के वास्तविक व्यवहार और उसके अपेक्षित व्यवहार के बीच पत्राचार की जांच के सभी परिणाम तब उपयोग किए जाएंगे।



इस प्रकार,

परीक्षण है

• आवश्यकताओं के साथ कार्यक्रम के अनुपालन की जाँच करना,
• उसके काम को देखते हुए
• विशेष रूप से, कृत्रिम रूप से निर्मित स्थितियों को एक निश्चित तरीके से चुना जाता है।

यहां से हम इस पर "परीक्षण" की एक कार्यशील परिभाषा पर विचार करेंगे।







सामान्य परीक्षण योजना लगभग इस प्रकार है:

1. इनपुट परीक्षक प्रोग्राम और / या आवश्यकताओं को प्राप्त करता है।
2. वह उनके साथ कुछ करता है, कुछ स्थितियों में कार्यक्रम के काम की देखरेख करता है, कृत्रिम रूप से उसके द्वारा बनाई गई है।
3. आउटपुट पर, वह अनुरूपताओं और विसंगतियों के बारे में जानकारी प्राप्त करता है।
4. यह जानकारी तब किसी मौजूदा प्रोग्राम को बेहतर बनाने के लिए उपयोग की जाती है। या एक कार्यक्रम के लिए आवश्यकताओं को बदलने के लिए जो अभी भी विकसित हो रहा है।

टेस्ट क्या है?

• यह एक विशेष, कृत्रिम रूप से निर्मित स्थिति है, जिसे एक निश्चित तरीके से चुना जाता है,
• और कार्यक्रम की निगरानी किस प्रकार की जानी चाहिए, इसका विवरण दिया गया है
• एक निश्चित आवश्यकता के साथ इसके अनुपालन को सत्यापित करने के लिए।

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



परीक्षण डेवलपर परीक्षण के एक विशाल, संभावित अंतहीन सेट से सीमित सेट का चयन करने के लिए प्रतिबद्ध है।



खैर, इस तरह हम यह निष्कर्ष निकाल सकते हैं कि परीक्षक परीक्षण प्रक्रिया में दो चीजें करता है।



1. सबसे पहले, वह कार्यक्रम के निष्पादन को नियंत्रित करता है और इन बहुत ही कृत्रिम स्थितियों को बनाता है जिसमें हम कार्यक्रम के व्यवहार की जांच करने जा रहे हैं।



2. और, दूसरी बात, वह कार्यक्रम के व्यवहार का अवलोकन करता है और वह जो देखता है उसकी अपेक्षा करता है।



यदि परीक्षक परीक्षण को स्वचालित करता है, तो वह स्वयं कार्यक्रम के व्यवहार का निरीक्षण नहीं करता है - वह इस कार्य को एक विशेष उपकरण या एक विशेष कार्यक्रम के लिए सौंपता है जो उसने खुद लिखा था। यह वह है जो अवलोकन करता है, वह अपेक्षित व्यवहार की तुलना अपेक्षा के साथ करता है, और परीक्षक केवल कुछ अंतिम परिणाम देता है - चाहे मनाया व्यवहार अपेक्षित के साथ मेल खाता हो, या मेल नहीं खाता हो।



कोई भी कार्यक्रम प्रसंस्करण सूचना के लिए एक तंत्र है। इनपुट एक रूप में जानकारी प्राप्त करता है, कुछ अन्य रूप में आउटपुट जानकारी। एक ही समय में, कार्यक्रम में कई इनपुट और आउटपुट हो सकते हैं, वे अलग-अलग हो सकते हैं, अर्थात, कार्यक्रम में कई अलग-अलग इंटरफेस हो सकते हैं, और इन इंटरफेस के विभिन्न प्रकार हो सकते हैं:

• उपयोगकर्ता इंटरफ़ेस (UI)
• प्रोग्रामिंग इंटरफ़ेस (एपीआई)
• नेटवर्क प्रोटोकॉल
• फाइल सिस्टम
• पर्यावरण की स्थिति
• घटनाओं

सबसे आम इंटरफेस हैं

• कस्टम,
• ग्राफिक,
• पाठ,
• कंसोल,
• और भाषण।

इन सभी इंटरफेस का उपयोग करते हुए, परीक्षक:

• किसी भी तरह कृत्रिम स्थिति बनाता है
• और इन स्थितियों में जांच करता है कि कार्यक्रम कैसे व्यवहार करता है।

यह परीक्षण कर रहा है।

परीक्षण के प्रकारों के अन्य वर्गीकरण

तीन स्तरों में सबसे अधिक इस्तेमाल किया जाने वाला विभाजन, यह

1. इकाई परीक्षण
2. एकीकरण परीक्षण
3. प्रणाली परीक्षण।

यूनिट परीक्षण का मतलब आमतौर पर काफी निम्न स्तर पर परीक्षण होता है, अर्थात्, व्यक्तिगत संचालन, विधियों और कार्यों का परीक्षण करना।



सिस्टम परीक्षण उपयोगकर्ता इंटरफ़ेस परीक्षण को संदर्भित करता है।



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



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



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



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



समान उपकरणों का उपयोग किया जाता है, और यह सामान्य है, समान तकनीकों का उपयोग किया जाता है, प्रत्येक स्तर पर हम एक अलग तरह के परीक्षण के बारे में बात कर सकते हैं।



हम गठबंधन करते हैं:







यही है, हम कार्यक्षमता की इकाई परीक्षण के बारे में बात कर सकते हैं।



हम सिस्टम परीक्षण कार्यक्षमता के बारे में बात कर सकते हैं।



हम इकाई परीक्षण के बारे में बात कर सकते हैं, उदाहरण के लिए, दक्षता।



हम प्रभावशीलता के प्रणालीगत परीक्षण के बारे में बात कर सकते हैं।



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



अंत में, एकीकरण परीक्षण के दौरान, हम जांचते हैं कि मॉड्यूल किसी सिस्टम के भीतर एक-दूसरे के साथ सही तरीके से बातचीत करते हैं या नहीं। यही है, हम वास्तव में सिस्टम परीक्षण के समान परीक्षण करते हैं, हम केवल अतिरिक्त ध्यान देते हैं कि मॉड्यूल एक-दूसरे के साथ कैसे बातचीत करते हैं। हम कुछ अतिरिक्त जांच करते हैं। बस यही फर्क है।



सिस्टम और यूनिट परीक्षण के बीच के अंतर को समझने के लिए फिर से कोशिश करते हैं। चूंकि यह अलगाव काफी आम है, इसलिए यह अंतर होना चाहिए।



और यह अंतर तब प्रकट होता है जब हम तकनीकी वर्गीकरण नहीं करते हैं, लेकिन परीक्षण उद्देश्यों के अनुसार वर्गीकरण करते हैं।



उद्देश्य से वर्गीकरण आसानी से "जादू वर्ग" का उपयोग करके किया जाता है, जो मूल रूप से ब्रायन मारिक द्वारा आविष्कार किया गया था और फिर एरी टेनेन द्वारा सुधार किया गया था।







इस जादू वर्ग में, सभी प्रकार के परीक्षण चार चतुर्भुजों में व्यवस्थित किए जाते हैं, जो इन परीक्षणों में अधिक ध्यान देने पर निर्भर करता है।



कार्यक्षेत्र - परीक्षण का प्रकार जितना अधिक होता है, उतना ही कार्यक्रम के व्यवहार की कुछ बाहरी अभिव्यक्तियों पर ध्यान दिया जाता है, जितना कम होता है, उतना ही अधिक हम कार्यक्रम की आंतरिक तकनीकी संरचना पर ध्यान देते हैं।



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



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



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



इसलिए, लक्ष्यों के आधार पर वर्गीकरण के आधार पर, इकाई परीक्षण निचले बाएँ वृत्त का चतुर्थ भाग में है, और अन्य सभी चतुर्थांश सिस्टम परीक्षण हैं।



आपका ध्यान देने के लिए धन्यवाद।

इसके साथ ही

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