2009-02-17 4 views
8

यदि किसी प्रोजेक्ट में 100% यूनिट परीक्षण कवरेज है, तो क्या एकीकरण परीक्षण अभी भी आवश्यक हैं?यदि किसी प्रोजेक्ट में 100% यूनिट परीक्षण कवरेज है, तो क्या एकीकरण परीक्षण अभी भी आवश्यक हैं?

मैंने कभी 100% यूनिट परीक्षण कवरेज के साथ एक परियोजना पर काम नहीं किया है, लेकिन मुझे आश्चर्य है कि क्या आपकी परियोजना इसे प्राप्त करती है (या 90% में), क्या आपका अनुभव था कि आपको अभी भी एकीकरण परीक्षण की आवश्यकता है? (क्या आपको कम की आवश्यकता है?)

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

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

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

उत्तर

16

परिभाषाएँ

मुझे लगता है कि इस चर्चा होने से पहले अपने शब्दों को परिभाषित करने के लिए महत्वपूर्ण है।

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

एकीकरण परीक्षण सिस्टम में दो घटकों के संयोजन का परीक्षण करता है। यह घटकों के बीच संबंधों पर केंद्रित है, न कि घटकों को स्वयं। यह सवाल का जवाब देता है "क्या ये घटक इरादे के साथ मिलकर काम करते हैं"।

सिस्टम परीक्षण पूरे सॉफ्टवेयर सिस्टम का परीक्षण करता है। यह सवाल का जवाब देता है "क्या यह सॉफ्टवेयर इरादे से काम करता है?"

स्वीकृति परीक्षण ग्राहक के प्रश्न का उत्तर देने का एक स्वचालित तरीका है "क्या यह सॉफ्टवेयर मुझे लगता है कि मैं चाहता हूं?"। यह एक प्रकार का सिस्टम टेस्ट है।

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

सभी स्वचालित परीक्षण अभिगृहीत के अनुसार "से अंत अंत आगे है की तुलना में आपको लगता है" सीमित हैं।

तुलना

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

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

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

सिफ़ारिश

लागत और प्रत्येक के मूल्यों को संतुलित करने के परीक्षण रणनीतियों के संयोजन का उपयोग करें।

+0

धन्यवाद। मुझे आपके जवाब से बहुत कुछ मिला। –

4

हाँ, वहाँ रहे हैं के अलावा कोड कवरेज के कुछ ही विभिन्न प्रकार

from wiki:

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

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

15

हां।

भले ही सभी "इकाइयां" जो करें उन्हें करना चाहिए, यह गारंटी नहीं है कि पूरी प्रणाली डिज़ाइन के रूप में काम करती है।

1

यूनिट परीक्षण एकीकरण परीक्षण से अलग हैं।

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

एकीकरण परीक्षण उत्पाद के साथ किया जाता है जो उपयोगकर्ताओं के अंत में दिखने के करीब दिखता है। यह भी महत्वपूर्ण है।

+0

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

+0

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

+0

मैं हमेशा जितनी जल्दी हो सके परीक्षण के विचार से जाता हूं। क्यूं कर? क्योंकि फिक्सिंग दोष सबसे सस्ता है, जो मेरी परियोजना को जीवित बना देता है ;-) –

1

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

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

0

हां क्योंकि आपके सॉफ़्टवेयर की कार्यक्षमता इस बात पर निर्भर करती है कि यह अलग-अलग टुकड़े कैसे इंटरैक्ट करते हैं। यूनिट टेस्ट इनपुट पर आने और अपेक्षित आउटपुट को परिभाषित करने पर निर्भर करते हैं। ऐसा करने से यह गारंटी नहीं मिलती है कि यह आपके बाकी सिस्टम के साथ काम करेगा।

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

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

2

पहला, 100% इकाई परीक्षण कवरेज इकाई परीक्षण स्तर पर भी पर्याप्त नहीं है: आप अपने कोड के निर्देशों में से केवल 100% को कवर करते हैं। आपके कोड में पथ के बारे में क्या? इनपुट या आउटपुट डोमेन के बारे में क्या?

दूसरा, आप नहीं जानते कि प्रेषक इकाई से आउटपुट इसकी रिसीवर इकाई से इनपुट के साथ संगत है या नहीं। यह एकीकरण परीक्षण का उद्देश्य है।

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

1

"अपारदर्शी (जब किसी को तोड़ने के लिए किसी को तोड़ने के लिए सभी परतों के माध्यम से गोता लगाने की ज़रूरत होती है)" - यही कारण है कि एकीकरण परीक्षण किए जाते हैं - अन्यथा उन अपारदर्शी मुद्दे उत्पादन वातावरण में दिखाई देंगे।

0

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

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

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

0

This exact question मूल रूप से सिर्फ एक दिन पहले पूछा गया था। 10012 कोड कवरेज के साथ भी कई त्रुटियों के लिए this question देखें।

2

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

0

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

2

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

संबंधित मुद्दे