जहाँ आप देखते हैं, उसके आधार पर आपको थोड़े अलग उत्तर मिलेंगे। मैंने इस विषय के बारे में बहुत कुछ पढ़ा है, और यहाँ मेरा आसवन है; फिर से, ये थोड़े ऊनी होते हैं और अन्य असहमत हो सकते हैं।
यूनिट टेस्ट
कार्यक्षमता की सबसे छोटी इकाई का परीक्षण, आम तौर पर एक विधि / कार्य (जैसे एक विशेष राज्य के साथ एक वर्ग दिया जाता है, वर्ग पर x विधि को कॉल करने से y होने का कारण बनता है)। यूनिट परीक्षणों को एक विशेष सुविधा पर केंद्रित किया जाना चाहिए (जैसे, स्टैक खाली होने पर पॉप विधि को कॉल करना InvalidOperationException)। यह जो कुछ भी छूता है उसे स्मृति में किया जाना चाहिए; इसका मतलब यह है कि परीक्षण कोड और परीक्षण के तहत कोड नहीं होना चाहिए:
- (गैर-तुच्छ) सहयोगियों में कॉल करें
- नेटवर्क तक पहुंचें
- एक डेटाबेस मारो
- फ़ाइल सिस्टम का उपयोग करें
- एक धागा ऊपर स्पिन
- आदि।
किसी भी प्रकार की निर्भरता जो धीमी / कठिन है / समझने / आरंभ करने / हेरफेर करने के लिए उचित तकनीकों का उपयोग करते हुए ठूंसा / ठगा / ठगा जाना चाहिए, ताकि आप इस बात पर ध्यान केंद्रित कर सकें कि कोड की इकाई क्या कर रही है, न कि इसकी निर्भरता क्या है।
संक्षेप में, यूनिट परीक्षण यथासंभव सरल, डिबग करने में आसान, विश्वसनीय (बाहरी कारकों को कम करने के कारण) होते हैं, निष्पादित करने में तेजी से और यह साबित करने में मदद करते हैं कि आपके प्रोग्राम फ़ंक्शन के सबसे छोटे बिल्डिंग ब्लॉक पहले से ही एक साथ रखे गए हैं। चेतावनी यह है कि, यद्यपि आप यह साबित कर सकते हैं कि वे अलगाव में पूरी तरह से काम करते हैं, कोड की इकाइयाँ तब फूट सकती हैं, जब संयुक्त हो जाती हैं जो हमें ...
एकीकरण टेस्ट
एकीकरण परीक्षण कोड की इकाइयों को जोड़कर इकाई परीक्षणों का निर्माण करते हैं और परीक्षण करते हैं कि परिणामस्वरूप संयोजन सही ढंग से कार्य करता है। यह या तो किसी एक प्रणाली का जन्मदाता हो सकता है, या कुछ उपयोगी करने के लिए कई प्रणालियों को एक साथ जोड़ सकता है। इसके अलावा, एक और चीज जो इकाई परीक्षणों से एकीकरण परीक्षणों को अलग करती है वह है पर्यावरण। एकीकरण परीक्षण धागे का उपयोग कर सकते हैं, डेटाबेस तक पहुंच सकते हैं या यह सुनिश्चित करने के लिए कि सभी कोड और विभिन्न पर्यावरण परिवर्तन सही ढंग से काम करेंगे , जो कुछ भी आवश्यक है।
यदि आपने कुछ क्रमांकन कोड बनाए हैं और इकाई ने डिस्क को छुए बिना अपने सराय का परीक्षण किया है, तो आपको कैसे पता चलेगा कि जब आप लोड कर रहे हैं और डिस्क पर सहेज रहे हैं तो यह कैसे काम करेगा? हो सकता है कि आप फिल्म्स को फ्लश और डिस्पोज करना भूल गए हों। हो सकता है कि आपकी फ़ाइल अनुमतियां गलत हों और आपने मेमोरी स्ट्रीम का उपयोग करते हुए सराय का परीक्षण किया हो। सुनिश्चित करने के लिए पता लगाने का एकमात्र तरीका यह है कि इसे उत्पादन के लिए सबसे नज़दीकी वातावरण का उपयोग करके 'असली के लिए' परीक्षण किया जाए।
मुख्य लाभ यह है कि वे बग पाएंगे कि यूनिट परीक्षण वायरिंग बग (जैसे कि कक्षा ए का एक उदाहरण अप्रत्याशित रूप से बी का एक शून्य उदाहरण प्राप्त करता है) और पर्यावरण बग नहीं मिल सकता है (यह मेरे सिंगल-सीपीयू मशीन पर ठीक चलता है, लेकिन मेरी सहयोगी की 4 कोर मशीन परीक्षण पास नहीं कर सकती)। मुख्य नुकसान यह है कि एकीकरण परीक्षण अधिक कोड को छूते हैं, कम विश्वसनीय होते हैं, असफलताओं का निदान करना कठिन होता है और परीक्षण बनाए रखना कठिन होता है।
इसके अलावा, एकीकरण परीक्षण जरूरी नहीं है कि एक पूर्ण सुविधा काम करता है। उपयोगकर्ता मेरे कार्यक्रमों के आंतरिक विवरण की परवाह नहीं कर सकता है, लेकिन मैं करता हूं!
कार्यात्मक परीक्षण
विनिर्देश के खिलाफ दिए गए इनपुट के लिए परिणामों की तुलना करके कार्यात्मक परीक्षण शुद्धता के लिए एक विशेष सुविधा की जांच करते हैं। कार्यात्मक परीक्षण खुद को मध्यवर्ती परिणामों या साइड-इफेक्ट्स के साथ चिंतित नहीं करते हैं, बस परिणाम (वे परवाह नहीं करते हैं कि एक्स करने के बाद, ऑब्जेक्ट वाई में स्थिति है)। उन्हें विनिर्देश के भाग का परीक्षण करने के लिए लिखा जाता है जैसे, "कॉलिंग फंक्शन स्क्वायर (x) 2 रिटर्न 4 के तर्क के साथ"।
स्वीकृति टेस्ट
स्वीकृति परीक्षण को दो प्रकारों में विभाजित किया गया लगता है:
मानक स्वीकृति परीक्षण में पूर्ण प्रणाली पर परीक्षण करना शामिल है (उदाहरण के लिए वेब ब्राउज़र के माध्यम से आपके वेब पेज का उपयोग करना) यह देखने के लिए कि क्या एप्लिकेशन की कार्यक्षमता विनिर्देश को संतुष्ट करती है। उदाहरण के लिए "ज़ूम आइकन पर क्लिक करने से दस्तावेज़ का दृश्य 25% बढ़ जाना चाहिए।" परिणामों की कोई वास्तविक निरंतरता नहीं है, बस एक पास या असफल परिणाम है।
लाभ यह है कि परीक्षण सादे अंग्रेजी में वर्णित हैं और यह सुनिश्चित करता है कि सॉफ्टवेयर, एक संपूर्ण के रूप में, सुविधा पूर्ण है। नुकसान यह है कि आपने परीक्षण पिरामिड को एक और स्तर ऊपर ले जाया है। स्वीकृति परीक्षण कोड के पहाड़ों को छूते हैं, इसलिए विफलता को ट्रैक करना मुश्किल हो सकता है।
इसके अलावा, चुस्त सॉफ्टवेयर विकास में, उपयोगकर्ता स्वीकृति परीक्षण में विकास के दौरान सॉफ़्टवेयर के ग्राहक द्वारा / उसके लिए बनाई गई उपयोगकर्ता कहानियों को दर्पण करने के लिए परीक्षण बनाना शामिल है। यदि परीक्षण पास होते हैं, तो इसका मतलब है कि सॉफ़्टवेयर को ग्राहकों की आवश्यकताओं को पूरा करना चाहिए और कहानियों को पूर्ण माना जा सकता है। एक स्वीकृति परीक्षण सूट मूल रूप से एक निष्पादन योग्य विनिर्देश है जो एक डोमेन विशिष्ट भाषा में लिखा गया है जो सिस्टम के उपयोगकर्ताओं द्वारा उपयोग की जाने वाली भाषा में परीक्षणों का वर्णन करता है।
निष्कर्ष
वे सभी पूरक हैं। कभी-कभी एक प्रकार पर ध्यान केंद्रित करना या उन्हें पूरी तरह से बचाना फायदेमंद होता है। मेरे लिए मुख्य अंतर यह है कि कुछ परीक्षण प्रोग्रामर के दृष्टिकोण से चीजों को देखते हैं, जबकि अन्य ग्राहक / अंत उपयोगकर्ता फोकस का उपयोग करते हैं।