स्वचालित यूनिट परीक्षण के खिलाफ मैन्युअल यूनिट परीक्षण के पेशेवरों और विपक्ष क्या हैं?

Question

मैं फायदे और नुकसान मैनुअल इकाई परीक्षण कास्वचालित प्रक्रिया की तुलना मिल सकता है।

Answer 1

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

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

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

अपडेट: अब है कि आप अपने प्रश्न के लिए एक अधिक ठोस संदर्भ देने के लिए, यह :-)

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

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

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

मैं Working Effectively with Legacy Code की अनुशंसा करता हूं - इसमें उलझन में, बुरी तरह लिखित विरासत कोड के लिए यूनिट परीक्षण लिखने के तरीके पर मूल्यवान ज्ञान का भरपूर धन शामिल है।

Answer 2

मुझे लगता है कि आपके सवाल का जवाब केवल वास्तविक है यह कोई बात नहीं है, क्योंकि आप दोनों करना होगा।

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

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

Answer 3

"मैनुअल यूनिट परीक्षण" काफी असंभव है। यूनिट परीक्षण को अलगाव में कोड की छोटी इकाइयों के परीक्षण के रूप में परिभाषित किया जाता है। आप वास्तव में मैन्युअल रूप से ऐसा नहीं कर सकते हैं।

प्रो मैनुअल एकीकरण परीक्षणों:

अब, आप के बारे में एकीकरण परीक्षण बात कर रहे हैं, कि एक अलग बात है

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

कोन पुस्तिका एकीकरण परीक्षण:

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

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