सॉफ्टवेयर परीक्षण - त्वरित गाइड

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

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

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

परीक्षण कौन करता है?

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

  • सॉफ्टवेयर परीक्षक
  • सॉफ्टवेयर डेवलपर
  • प्रोजेक्ट लीड / मैनेजर
  • अंतिम उपयोगकर्ता

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

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

परीक्षण कब शुरू करें?

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

यह उस विकास मॉडल पर भी निर्भर करता है जिसका उपयोग किया जा रहा है। उदाहरण के लिए, झरना मॉडल में, परीक्षण चरण में औपचारिक परीक्षण किया जाता है; लेकिन वृद्धिशील मॉडल में, परीक्षण प्रत्येक वृद्धि / पुनरावृत्ति के अंत में किया जाता है और पूरे आवेदन का अंत में परीक्षण किया जाता है।

एसडीएलसी के प्रत्येक चरण में विभिन्न रूपों में परीक्षण किया जाता है -

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

  • डिज़ाइन में सुधार करने के इरादे से डिज़ाइन चरण में डिज़ाइन की समीक्षा करना भी परीक्षण के रूप में माना जाता है।

  • एक डेवलपर द्वारा कोड पूरा होने पर किया गया परीक्षण भी परीक्षण के रूप में वर्गीकृत किया गया है।

परीक्षण कब रोकें?

परीक्षण कब रोकना है यह निर्धारित करना मुश्किल है, क्योंकि परीक्षण एक कभी न खत्म होने वाली प्रक्रिया है और कोई भी दावा नहीं कर सकता है कि एक सॉफ्टवेयर 100% परीक्षण किया गया है। परीक्षण प्रक्रिया को रोकने के लिए निम्नलिखित पहलुओं पर विचार किया जाना चाहिए -

  • परीक्षण की समय सीमा

  • परीक्षण मामले के निष्पादन का समापन

  • एक निश्चित बिंदु पर कार्यात्मक और कोड कवरेज का समापन

  • बग दर एक निश्चित स्तर से नीचे आती है और किसी भी उच्च प्राथमिकता वाले कीड़े की पहचान नहीं की जाती है

  • प्रबंधन निर्णय

सत्यापन प्रमाणीकरण

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

अनु क्रमांक। सत्यापन मान्यकरण
1 सत्यापन चिंता को संबोधित करता है: "क्या आप इसे सही तरीके से बना रहे हैं?" मान्यता चिंता को संबोधित करती है: "क्या आप सही चीज़ का निर्माण कर रहे हैं?"
2 सुनिश्चित करता है कि सॉफ्टवेयर सिस्टम सभी कार्यक्षमता को पूरा करता है। यह सुनिश्चित करता है कि कार्यात्मकता इच्छित व्यवहार को पूरा करती है।
3 सत्यापन पहले होता है और इसमें प्रलेखन, कोड आदि के लिए जाँच शामिल होती है। सत्यापन के बाद सत्यापन होता है और मुख्य रूप से समग्र उत्पाद की जाँच शामिल है।
4 डेवलपर्स द्वारा किया गया। परीक्षकों द्वारा किया गया।
5 इसमें स्थिर गतिविधियाँ हैं, क्योंकि इसमें किसी सॉफ़्टवेयर को सत्यापित करने के लिए समीक्षाएं, walkthroughs और निरीक्षण एकत्र करना शामिल है। इसमें गतिशील गतिविधियाँ हैं, क्योंकि इसमें आवश्यकताओं के विरुद्ध सॉफ्टवेयर को निष्पादित करना शामिल है।
6 यह एक उद्देश्य प्रक्रिया है और किसी सॉफ्टवेयर को सत्यापित करने के लिए किसी व्यक्तिपरक निर्णय की आवश्यकता नहीं होनी चाहिए। यह एक व्यक्तिपरक प्रक्रिया है और एक सॉफ्टवेयर कितनी अच्छी तरह काम करता है, इस पर व्यक्तिपरक निर्णय शामिल होते हैं।

नीचे दिए गए सॉफ़्टवेयर परीक्षण के बारे में कुछ सबसे आम मिथक हैं।

मिथक 1: परीक्षण बहुत महंगा है

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

मिथक 2: परीक्षण समय-उपभोक्ता है

Reality- एसडीएलसी चरणों के दौरान, परीक्षण कभी भी समय लेने वाली प्रक्रिया नहीं है। हालाँकि उचित परीक्षण के दौरान पहचानी गई त्रुटियों का निदान करना और ठीक करना एक समय लेने वाली लेकिन उत्पादक गतिविधि है।

मिथक 3: केवल पूरी तरह से विकसित उत्पादों का परीक्षण किया जाता है

Reality- इसमें कोई संदेह नहीं है, परीक्षण स्रोत कोड पर निर्भर करता है लेकिन आवश्यकताओं की समीक्षा करना और विकसित मामलों की जाँच करना विकसित कोड से स्वतंत्र है। हालांकि विकास जीवन चक्र मॉडल के रूप में पुनरावृत्त या वृद्धिशील दृष्टिकोण पूरी तरह से विकसित सॉफ्टवेयर पर परीक्षण की निर्भरता को कम कर सकता है।

मिथक 4: पूर्ण परीक्षण संभव है

Reality- यह एक मुद्दा बन जाता है जब एक ग्राहक या परीक्षक सोचता है कि पूर्ण परीक्षण संभव है। यह संभव है कि टीम द्वारा सभी रास्तों का परीक्षण किया गया हो लेकिन पूर्ण परीक्षण की घटना कभी संभव नहीं है। सॉफ्टवेयर विकास जीवन चक्र के दौरान कुछ परिदृश्य हो सकते हैं जो परीक्षण टीम या क्लाइंट द्वारा कभी निष्पादित नहीं किए जाते हैं और परियोजना को तैनात किए जाने के बाद निष्पादित किया जा सकता है।

मिथक 5: एक टेस्टेड सॉफ्टवेयर बग-फ्री है

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

मिथक 6: मिस्ड डिफेक्ट्स टेस्टर्स के कारण हैं

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

मिथक 7: उत्पाद की गुणवत्ता के लिए परीक्षक जिम्मेदार हैं

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

मिथक 8: टेस्ट ऑटोमेशन का इस्तेमाल जहां भी संभव हो समय कम करना चाहिए

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

मिथक 9: कोई भी एक सॉफ्टवेयर एप्लिकेशन का परीक्षण कर सकता है

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

मिथक 10: ए टेस्टर का एकमात्र टास्क है, फाइंड बग्स

Reality- एक सॉफ्टवेयर में बग ढूंढना परीक्षकों का काम है, लेकिन साथ ही, वे विशेष सॉफ्टवेयर के डोमेन विशेषज्ञ हैं। डेवलपर्स केवल उस विशिष्ट घटक या क्षेत्र के लिए जिम्मेदार हैं जो उन्हें सौंपा गया है लेकिन परीक्षक सॉफ्टवेयर के समग्र कामकाज को समझते हैं, निर्भरताएं क्या हैं, और एक मॉड्यूल के प्रभाव दूसरे मॉड्यूल पर हैं।

परीक्षण, गुणवत्ता आश्वासन और गुणवत्ता नियंत्रण

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

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

ऑडिट और निरीक्षण

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

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

औपचारिक निरीक्षण बैठकों में निम्नलिखित प्रक्रियाएं शामिल हो सकती हैं: योजना, अवलोकन तैयारी, निरीक्षण बैठक, नियम, और अनुवर्ती।

परीक्षण और डिबगिंग

Testing- इसमें बग को ठीक किए बिना बग / त्रुटि / दोष की पहचान करना शामिल है। आमतौर पर गुणवत्ता आश्वासन पृष्ठभूमि वाले पेशेवर बग पहचान में शामिल होते हैं। परीक्षण चरण में परीक्षण किया जाता है।

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

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

आईएसओ / आईईसी 9126

यह मानक सॉफ्टवेयर अनुप्रयोग की गुणवत्ता निर्धारित करने के लिए निम्नलिखित पहलुओं से संबंधित है -

  • गुणवत्ता मॉडल
  • बाहरी मैट्रिक्स
  • आंतरिक मैट्रिक्स
  • उपयोग मेट्रिक्स में गुणवत्ता

यह मानक किसी भी सॉफ्टवेयर के लिए गुणवत्ता विशेषताओं के कुछ सेट प्रस्तुत करता है जैसे -

  • Functionality
  • Reliability
  • Usability
  • Efficiency
  • Maintainability
  • Portability

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

आईएसओ / आईईसी 9241-11

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

इस मानक ने एक ढाँचा प्रस्तावित किया जो प्रयोज्य घटकों और उनके बीच संबंधों का वर्णन करता है। इस मानक में, उपयोगकर्ता के प्रदर्शन और संतुष्टि के संदर्भ में प्रयोज्यता पर विचार किया जाता है। आईएसओ 9241-11 के अनुसार, प्रयोज्य उपयोग के संदर्भ पर निर्भर करता है और उपयोगिता का स्तर संदर्भ के परिवर्तन के रूप में बदल जाएगा।

आईएसओ / आईईसी 25000: 2005

आईएसओ / आईईसी 25000: 2005 आमतौर पर मानक के रूप में जाना जाता है जो सॉफ्टवेयर गुणवत्ता आवश्यकताओं और मूल्यांकन (SQuaRE) के लिए दिशानिर्देश प्रदान करता है। यह मानक सॉफ़्टवेयर गुणवत्ता आवश्यकताओं और उनके मूल्यांकन से संबंधित प्रक्रिया को व्यवस्थित करने और बढ़ाने में मदद करता है। वास्तव में, ISO-25000 दो पुराने ISO मानकों की जगह लेता है, अर्थात ISO-9126 और ISO-14598।

SQuaRE उप-भागों में विभाजित है जैसे कि -

  • आईएसओ 2500n - गुणवत्ता प्रबंधन प्रभाग
  • आईएसओ 2501n - गुणवत्ता मॉडल प्रभाग
  • आईएसओ 2502n - गुणवत्ता मापन प्रभाग
  • आईएसओ 2503n - गुणवत्ता आवश्यकताएँ प्रभाग
  • आईएसओ 2504n - गुणवत्ता मूल्यांकन प्रभाग

SQuaRE की मुख्य सामग्री हैं -

  • नियम और परिभाषाएँ
  • संदर्भ मॉडल
  • सामान्य मार्गदर्शक
  • व्यक्तिगत विभाजन मार्गदर्शक
  • आवश्यकता इंजीनियरिंग से संबंधित मानक (यानी विनिर्देशन, योजना, माप और मूल्यांकन प्रक्रिया)

आईएसओ / आईईसी 12119

यह मानक क्लाइंट के लिए दिए गए सॉफ्टवेयर पैकेजों से संबंधित है। यह ग्राहकों की उत्पादन प्रक्रिया पर ध्यान केंद्रित नहीं करता है और न ही सौदा करता है। मुख्य सामग्री निम्नलिखित मदों से संबंधित हैं -

  • सॉफ्टवेयर पैकेज के लिए आवश्यकताओं का सेट।
  • निर्दिष्ट आवश्यकताओं के विरुद्ध वितरित सॉफ्टवेयर पैकेज का परीक्षण करने के निर्देश।

कई तरह का

क्यूए और परीक्षण प्रक्रियाओं से संबंधित कुछ अन्य मानक नीचे दिए गए हैं -

अनु क्रमांक मानक और विवरण
1

IEEE 829

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

2

IEEE 1061

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

3

IEEE 1059

सॉफ्टवेयर सत्यापन और सत्यापन योजनाओं के लिए गाइड।

4

IEEE 1008

इकाई परीक्षण के लिए एक मानक।

5

IEEE 1012

सॉफ्टवेयर सत्यापन और सत्यापन के लिए एक मानक।

6

IEEE 1028

सॉफ्टवेयर निरीक्षण के लिए एक मानक।

7

IEEE 1044

सॉफ्टवेयर विसंगतियों के वर्गीकरण के लिए एक मानक।

8

IEEE 1044-1

सॉफ्टवेयर विसंगतियों के वर्गीकरण के लिए एक गाइड।

9

IEEE 830

सिस्टम आवश्यकताओं के विनिर्देशों के विकास के लिए एक गाइड।

10

IEEE 730

सॉफ्टवेयर गुणवत्ता आश्वासन योजनाओं के लिए एक मानक।

1 1

IEEE 1061

सॉफ्टवेयर गुणवत्ता मैट्रिक्स और कार्यप्रणाली के लिए एक मानक।

12

IEEE 12207

सॉफ्टवेयर जीवन चक्र प्रक्रियाओं और जीवन चक्र डेटा के लिए एक मानक।

13

BS 7925-1

सॉफ्टवेयर टेस्टिंग में प्रयुक्त शब्दों की शब्दावली।

14

BS 7925-2

सॉफ्टवेयर घटक परीक्षण के लिए एक मानक।

यह खंड विभिन्न प्रकार के परीक्षण का वर्णन करता है जिसका उपयोग एसडीएलसी के दौरान एक सॉफ्टवेयर का परीक्षण करने के लिए किया जा सकता है।

मैनुअल परीक्षण

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

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

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

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

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

स्वचालित करने के लिए क्या?

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

इसके अलावा, सभी GUI आइटम, डेटाबेस के साथ कनेक्शन, क्षेत्र सत्यापन, आदि को मैन्युअल प्रक्रिया को स्वचालित करके कुशलतापूर्वक परीक्षण किया जा सकता है।

स्वचालित करने के लिए कब?

सॉफ्टवेयर के निम्नलिखित पहलुओं पर विचार करके टेस्ट ऑटोमेशन का उपयोग किया जाना चाहिए -

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

कैसे करें ऑटोमेट?

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

  • स्वचालन के लिए एक सॉफ्टवेयर के भीतर क्षेत्रों की पहचान करना
  • परीक्षण स्वचालन के लिए उपयुक्त उपकरण का चयन
  • टेस्ट स्क्रिप्ट लिखना
  • परीक्षण सूट का विकास
  • लिपियों का निष्पादन
  • परिणाम रिपोर्ट बनाएं
  • किसी भी संभावित बग या प्रदर्शन समस्याओं की पहचान करें

सॉफ्टवेयर परीक्षण उपकरण

स्वचालन परीक्षण के लिए निम्नलिखित उपकरणों का उपयोग किया जा सकता है -

  • एचपी क्विक टेस्ट प्रोफेशनल
  • Selenium
  • आईबीएम तर्कसंगत कार्यात्मक परीक्षक
  • SilkTest
  • TestComplete
  • कहीं भी परीक्षण
  • WinRunner
  • LoadRunner
  • विजुअल स्टूडियो टेस्ट प्रोफेशनल
  • WATIR

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

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

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

निम्न तालिका ब्लैक-बॉक्स परीक्षण के फायदे और नुकसान को सूचीबद्ध करती है।

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

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

व्हाइट-बॉक्स परीक्षण आंतरिक तर्क और कोड की संरचना की विस्तृत जांच है। व्हाइट-बॉक्स परीक्षण भी कहा जाता हैglass testing या open-box testing। प्रदर्शन के लिए पंक्तिबद्धwhite-box एक आवेदन पर परीक्षण, एक परीक्षक को कोड के आंतरिक कामकाज को जानना होगा।

परीक्षक को स्रोत कोड के अंदर एक नज़र रखने और यह पता लगाने की आवश्यकता है कि कोड की कौन सी इकाई / हिस्सा अनुचित व्यवहार कर रहा है।

निम्न तालिका व्हाइट-बॉक्स परीक्षण के फायदे और नुकसान को सूचीबद्ध करती है।

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

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

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

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

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

परीक्षण विधियों की तुलना

निम्न तालिका उन बिंदुओं को सूचीबद्ध करती है जो ब्लैक-बॉक्स परीक्षण, ग्रे-बॉक्स परीक्षण और व्हाइट-बॉक्स परीक्षण में अंतर करते हैं।

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

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

परीक्षण के स्तरों में अलग-अलग कार्यप्रणालियाँ शामिल हैं जिनका उपयोग सॉफ्टवेयर परीक्षण करते समय किया जा सकता है। सॉफ्टवेयर परीक्षण के मुख्य स्तर हैं -

  • क्रियात्मक परीक्षण

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

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

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

कार्यक्षमता के लिए एक आवेदन का परीक्षण करते समय पांच चरण शामिल होते हैं।

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

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

इकाई का परीक्षण

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

इकाई परीक्षण का लक्ष्य कार्यक्रम के प्रत्येक भाग को अलग करना और यह दिखाना है कि व्यक्तिगत भाग आवश्यकताओं और कार्यक्षमता के मामले में सही हैं।

यूनिट परीक्षण की सीमाएं

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

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

एकीकरण जांच

एकीकरण परीक्षण को किसी अनुप्रयोग के संयुक्त भागों के परीक्षण के रूप में परिभाषित किया जाता है ताकि यह निर्धारित किया जा सके कि वे सही ढंग से कार्य करते हैं। एकीकरण परीक्षण दो तरीकों से किया जा सकता है: नीचे-अप एकीकरण परीक्षण और टॉप-डाउन एकीकरण परीक्षण।

अनु क्रमांक। एकीकरण परीक्षण विधि
1

Bottom-up integration

यह परीक्षण इकाई परीक्षण से शुरू होता है, इसके बाद मॉड्यूल या बिल्ड नामक इकाइयों के उत्तरोत्तर उच्च-स्तरीय संयोजनों का परीक्षण किया जाता है।

2

Top-down integration

इस परीक्षण में, उच्चतम-स्तरीय मॉड्यूल का परीक्षण पहले और उत्तरोत्तर, निचले-स्तर के मॉड्यूल का परीक्षण किया जाता है।

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

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

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

निम्नलिखित कारणों से सिस्टम परीक्षण महत्वपूर्ण है -

  • सिस्टम टेस्टिंग सॉफ्टवेयर डेवलपमेंट लाइफ साइकल का पहला चरण है, जहाँ एप्लिकेशन का संपूर्ण रूप से परीक्षण किया जाता है।

  • यह सत्यापित करने के लिए कि यह कार्यात्मक और तकनीकी विशिष्टताओं को पूरा करता है, एप्लिकेशन को अच्छी तरह से जांचा जाता है।

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

  • सिस्टम परीक्षण हमें व्यावसायिक आवश्यकताओं के साथ-साथ एप्लिकेशन आर्किटेक्चर दोनों का परीक्षण, सत्यापन और सत्यापन करने में सक्षम बनाता है।

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

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

निम्नलिखित कारणों से प्रतिगमन परीक्षण महत्वपूर्ण है -

  • परीक्षण में अंतराल कम करें जब किए गए परिवर्तनों के साथ एक आवेदन का परीक्षण किया जाना है।

  • यह सत्यापित करने के लिए कि परिवर्तन किए गए नए परिवर्तनों का परीक्षण आवेदन के किसी अन्य क्षेत्र को प्रभावित नहीं करता है।

  • जब आवेदन पर प्रतिगमन परीक्षण किया जाता है, तो जोखिमों को कम करता है।

  • समयसीमा से समझौता किए बिना टेस्ट कवरेज बढ़ाया जाता है।

  • उत्पाद की मार्केटिंग के लिए गति बढ़ाएं।

स्वीकृति परीक्षण

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

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

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

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

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

  • वर्तनी त्रुटि

  • टूटे हुए लिंक

  • बादल की दिशाएँ

  • लोडिंग समय और किसी भी विलंबता समस्याओं का परीक्षण करने के लिए सबसे कम विनिर्देशन वाली मशीनों पर एप्लिकेशन का परीक्षण किया जाएगा।

बीटा परीक्षण

अल्फा परीक्षण सफलतापूर्वक किए जाने के बाद यह परीक्षण किया जाता है। बीटा परीक्षण में, इच्छित दर्शकों का एक नमूना अनुप्रयोग का परीक्षण करता है। बीटा परीक्षण के रूप में भी जाना जाता हैpre-release testing। सॉफ्टवेयर के बीटा परीक्षण संस्करणों को आदर्श रूप से वेब पर एक विस्तृत दर्शकों को वितरित किया जाता है, आंशिक रूप से कार्यक्रम को "वास्तविक दुनिया" परीक्षण देने के लिए और आंशिक रूप से अगली रिलीज का पूर्वावलोकन प्रदान करने के लिए। इस चरण में, दर्शक निम्नलिखित परीक्षण करेंगे -

  • उपयोगकर्ता एप्लिकेशन इंस्टॉल करेंगे, और प्रोजेक्ट टीम को अपनी प्रतिक्रिया भेजेंगे।

  • टंकण संबंधी त्रुटियां, भ्रामक अनुप्रयोग प्रवाह, और यहां तक ​​कि क्रैश भी।

  • प्रतिक्रिया प्राप्त करना, परियोजना टीम वास्तविक उपयोगकर्ताओं को सॉफ़्टवेयर जारी करने से पहले समस्याओं को ठीक कर सकती है।

  • आप वास्तविक उपयोगकर्ता की समस्याओं को हल करने वाले मुद्दों को जितना अधिक हल करेंगे, आपके आवेदन की गुणवत्ता उतनी ही अधिक होगी।

  • जब आप इसे आम जनता के लिए जारी करते हैं तो उच्च-गुणवत्ता वाला अनुप्रयोग होने से ग्राहकों की संतुष्टि बढ़ेगी।

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

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

कुछ महत्वपूर्ण और आमतौर पर उपयोग किए जाने वाले गैर-कार्यात्मक परीक्षण प्रकार नीचे चर्चा किए गए हैं।

प्रदर्शन का परीक्षण

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

  • नेटवर्क में देरी

  • ग्राहक-पक्ष प्रसंस्करण

  • डेटाबेस लेनदेन प्रसंस्करण

  • सर्वर के बीच लोड संतुलन

  • डेटा रेंडरिंग

प्रदर्शन परीक्षण को निम्नलिखित पहलुओं के संदर्भ में महत्वपूर्ण और अनिवार्य परीक्षण प्रकार में से एक माना जाता है -

  • स्पीड (यानी रिस्पांस टाइम, डेटा रेंडरिंग और एक्सेसिंग)

  • Capacity

  • Stability

  • Scalability

प्रदर्शन परीक्षण या तो गुणात्मक या मात्रात्मक हो सकता है और विभिन्न उप-प्रकारों में विभाजित किया जा सकता है जैसे कि Load testing तथा Stress testing

लोड परीक्षण

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

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

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

तनाव परीक्षण

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

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

  • नेटवर्क पोर्ट को बेतरतीब ढंग से बंद करना या फिर से शुरू करना

  • डेटाबेस को चालू या बंद करना

  • विभिन्न प्रक्रियाओं को चलाना जो CPU, मेमोरी, सर्वर आदि जैसे संसाधनों का उपभोग करते हैं।

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

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

नीलसन के अनुसार, प्रयोज्य को पाँच कारकों के संदर्भ में परिभाषित किया जा सकता है, अर्थात् उपयोग की दक्षता, सीखने की क्षमता, स्मृति-क्षमता, त्रुटियां / सुरक्षा और संतुष्टि। उनके अनुसार, किसी उत्पाद की प्रयोज्यता अच्छी होगी और उपरोक्त कारकों के पास होने पर यह प्रणाली प्रयोग करने योग्य होगी।

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

2000 में मोलिच ने कहा कि एक उपयोगकर्ता के अनुकूल प्रणाली को निम्नलिखित पांच लक्ष्यों को पूरा करना चाहिए, अर्थात, सीखना आसान, याद रखना आसान, उपयोग करने में कुशल, उपयोग करने में संतोषजनक और समझने में आसान।

प्रयोज्य की विभिन्न परिभाषाओं के अलावा, कुछ मानक और गुणवत्ता वाले मॉडल और विधियां हैं जो आईएसओ-9126, आईएसओ -9241-11, आईएसओ-13407, और आईईईई सीडी जैसी विशेषताओं और उप-विशेषताओं के रूप में प्रयोज्यता को परिभाषित करते हैं। 610.12, आदि।

यूआई बनाम उपयोगिता परीक्षण

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

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

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

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

  • Confidentiality

  • Integrity

  • Authentication

  • Availability

  • Authorization

  • Non-repudiation

  • सॉफ्टवेयर ज्ञात और अज्ञात कमजोरियों के खिलाफ सुरक्षित है

  • सॉफ्टवेयर डेटा सुरक्षित है

  • सॉफ्टवेयर सभी सुरक्षा नियमों के अनुसार है

  • इनपुट जाँच और सत्यापन

  • एसक्यूएल प्रविष्टि हमलों

  • इंजेक्शन की खामियां

  • सत्र प्रबंधन मुद्दे

  • क्रॉस-साइट स्क्रिप्टिंग हमले

  • बफर कमजोरियों को ओवरफ्लो करता है

  • निर्देशिका ट्रैवर्सल हमले

पोर्टेबिलिटी परीक्षण

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

  • एक कंप्यूटर से दूसरे में स्थापित सॉफ़्टवेयर को स्थानांतरित करना।

  • विभिन्न प्लेटफार्मों पर सॉफ्टवेयर को चलाने के लिए निष्पादन योग्य (.exe) का निर्माण।

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

  • पोर्टेबिलिटी आवश्यकताओं को ध्यान में रखते हुए सॉफ्टवेयर को डिज़ाइन और कोडित किया जाना चाहिए।

  • संबंधित घटकों पर यूनिट परीक्षण किया गया है।

  • एकीकरण परीक्षण किया गया है।

  • परीक्षण वातावरण स्थापित किया गया है।

टेस्टिंग डॉक्यूमेंटेशन में कलाकृतियों के प्रलेखन शामिल होते हैं जिन्हें सॉफ्टवेयर के परीक्षण से पहले या उसके दौरान विकसित किया जाना चाहिए।

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

  • जाँच की योजना
  • परिदृश्य का परीक्षण करें
  • परीक्षण का मामला
  • पता लगाने की क्षमता का मापदंड

जाँच की योजना

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

एक परीक्षण योजना में निम्नलिखित शामिल हैं -

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

परिदृश्य का परीक्षण करें

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

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

परीक्षण का मामला

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

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

  • टेस्ट केस आईडी
  • उत्पाद मॉड्यूल
  • उत्पाद संस्करण
  • संशोधन इतिहास
  • Purpose
  • Assumptions
  • Pre-conditions
  • Steps
  • अनुमानित परिणाम
  • वास्तविक परिणाम
  • Post-conditions

कई परीक्षण मामलों को एकल परीक्षण परिदृश्य से प्राप्त किया जा सकता है। इसके अलावा, कभी-कभी एकल सॉफ़्टवेयर के लिए कई परीक्षण मामले लिखे जाते हैं, जिन्हें सामूहिक रूप से परीक्षण सूट के रूप में जाना जाता है।

पता लगाने की क्षमता का मापदंड

Traceability Matrix (जिसे आवश्यकता Traceability Matrix - RTM के रूप में भी जाना जाता है) एक तालिका है जिसका उपयोग सॉफ़्टवेयर डेवलपमेंट लाइफ साइकिल के दौरान आवश्यकताओं का पता लगाने के लिए किया जाता है। इसे फॉरवर्ड ट्रेसिंग (यानी रिक्वायरमेंट्स से डिजाइन या कोडिंग) या बैकवर्ड (यानी कोडिंग से रिक्वायरमेंट्स तक) के लिए इस्तेमाल किया जा सकता है। आरटीएम के लिए कई उपयोगकर्ता-परिभाषित टेम्पलेट हैं।

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

  • सुनिश्चित करें कि सॉफ्टवेयर उल्लिखित आवश्यकताओं के अनुसार विकसित किया गया है।
  • किसी भी बग के मूल कारण का पता लगाने में मदद करता है।
  • एसडीएलसी के विभिन्न चरणों के दौरान विकसित दस्तावेजों को ट्रेस करने में मदद करता है।

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

कार्यात्मक बिंदु विश्लेषण

यह विधि निम्नलिखित श्रेणियों के साथ सॉफ्टवेयर की कार्यात्मक उपयोगकर्ता आवश्यकताओं के विश्लेषण पर आधारित है -

  • Outputs
  • Inquiries
  • Inputs
  • आंतरिक फ़ाइलें
  • बाहरी फाइलें

परीक्षण बिंदु विश्लेषण

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

मार्क- II विधि

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

  • दृष्टिकोण निर्धारित करें
  • उद्देश्य और गिनती के प्रकार
  • गिनती की सीमा को परिभाषित करें
  • तार्किक लेनदेन की पहचान करें
  • डेटा इकाई प्रकारों को पहचानें और वर्गीकृत करें
  • इनपुट डेटा तत्व प्रकारों की गणना करें
  • कार्यात्मक आकार की गणना करें

कई तरह का

आप अन्य लोकप्रिय अनुमान तकनीकों का उपयोग कर सकते हैं जैसे -

  • डेलफी तकनीक
  • सादृश्य आधारित अनुमान
  • टेस्ट केस एन्यूमरेशन आधारित अनुमान
  • कार्य (गतिविधि) आधारित अनुमान
  • IFPUG विधि