यूनिट परीक्षण बनाम कार्यात्मक परीक्षण - नेता और डेवलपर का दृष्टिकोण

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



आमतौर पर दो प्रकार के स्वचालित परीक्षणों का उपयोग किया जाता है:
इकाई परीक्षण (किसी उत्पाद के व्यक्तिगत भागों का परीक्षण, आमतौर पर व्यक्तिगत कार्य / तरीके)
कार्यात्मक परीक्षण - एक निश्चित उत्पाद कार्यक्षमता का परीक्षण, जबकि उत्पाद को एक "ब्लैक बॉक्स" के रूप में माना जाता है।

लेकिन चलो एक दिलचस्प सवाल पूछते हैं - क्या दोनों प्रकार के परीक्षण की अभी तुरंत आवश्यकता है, और यदि नहीं, तो कौन सा अधिक महत्वपूर्ण है?

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

सबसे महत्वपूर्ण बात, यहां तक ​​कि सभी यूनिट परीक्षणों का सफल समापन उत्पाद के सही संचालन की गारंटी नहीं देता है: आखिरकार, एक ही फ़ंक्शन का उपयोग सिस्टम के विभिन्न हिस्सों में किया जा सकता है, जबकि इकाई परीक्षण केवल एक उपयोग के मामले पर एक आंख के साथ लिखा गया था।
एक सरल उदाहरण: मान लें कि हमारे पास फ़ंक्शन checkInt (a) {return /^-0-9†+$/.test(a)} है । इसी समय, इकाई परीक्षण में नकारात्मक संख्या के लिए कोई जांच नहीं होती है। इसका क्या मतलब है? और तथ्य यह है कि अगर एक निश्चित डेवलपर इस फ़ंक्शन को संशोधित करता है
checkInt (a) {वापसी / ^-? ई0-9$+$/.test(a)} , फिर यूनिट टेस्ट पास होगा जैसे कि कुछ भी नहीं हुआ था। लेकिन कार्यक्षमता क्षतिग्रस्त हो जाएगी। और त्रुटि पाए जाने और सही होने के बाद (फ़ंक्शन अपनी मूल स्थिति में लौटता है), कार्यात्मक का हिस्सा दूसरी जगह गिर जाएगा। यूनिट परीक्षणों के लगातार सफल समापन के साथ।

मेरे अभ्यास में, मेरी इकाई परीक्षण पर टिप्पणी करने का विकल्प भी था, क्योंकि यह मेरे कार्य को बदलने के बाद विफल हो गया।

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

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

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

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

• कार्यात्मक परीक्षण - आवश्यक
• यूनिट परीक्षण - अधिमानतः, लेकिन डेवलपर्स के मूड पर निर्भर करता है