2009-03-30 19 views
30

मैं कोड कवरेज के कुछ बुरे साइड इफेक्ट्स के असली दुनिया के उदाहरणों की तलाश में हूं।कोड कवरेज के नुकसान

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

मुझे लगता है कि आंशिक रूप से क्योंकि हमारे उपकरण ने केवल कथन कवरेज किया था। फिर भी, यह समय बेहतर खर्च हो सकता था।

यदि किसी के पास कोड कवरेज नीति होने का अन्य नकारात्मक दुष्प्रभाव हैं तो कृपया साझा करें। मैं जानना चाहता हूं कि असली दुनिया में किस तरह की अन्य समस्याएं हो रही हैं।

अग्रिम धन्यवाद।

संपादित करें: सभी वास्तव में अच्छे प्रतिक्रियाओं के लिए धन्यवाद। कुछ ऐसे हैं जिन्हें मैं उत्तर के रूप में चिह्नित करूंगा लेकिन मैं दुर्भाग्य से केवल एक को चिह्नित कर सकता हूं।

+0

जेफ पूछें - मुझे नहीं लगता कि उसे यह समस्या है। मुझे लगता है कि पिछली बार जब मैंने एक आंकड़ा सुना था तो स्टैक ओवरफ्लो में 5% कोड कवरेज था :-) –

+0

हाहा, मुझे लगता है कि अंतर यह है कि जेफ शायद मुझसे ज्यादा बेहतर कोड और मुझे पता है कि लोग =) – Fung

+0

परीक्षण में कोई महिमा नहीं है, बनाता है , या स्थापित करता है। आपको केवल तभी देखा जाता है जब चीजें बकवास होती हैं और यदि आप अपना काम सही नाडा करते हैं। अच्छा सवाल ... – ojblass

उत्तर

52

एक वाक्य में: कोड कवरेज बताता है कि आप निश्चित रूप से परीक्षण नहीं किया है, तो आप क्या नहीं किया है।

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

मेरे अनुभव में, आप कभी भी लिखने वाले सबसे महत्वपूर्ण परीक्षणों में से कई परीक्षण हैं जो कि किसी भी कवरेज को मुश्किल से जोड़ते हैं (किनारे के मामलों में जो कुछ अतिरिक्त% जोड़ते हैं, लेकिन बग का भार पाते हैं)।

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

इसके अलावा, लोग परीक्षण की गुणवत्ता पर ध्यान केंद्रित करने के बजाय संख्याओं के साथ जुनून/झुकाव शुरू करते हैं। मैंने बुरी तरह से लिखे गए परीक्षणों को देखा है जिनमें 90 +% कवरेज है, जैसा कि मैंने उत्कृष्ट परीक्षण देखा है जिनमें केवल 60-70% कवरेज है।

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

+2

+1 कोड कवरेज के साथ "समस्या" का बहुत अच्छा स्पष्टीकरण। –

+1

+1 मुझे हमेशा यह पसंद है जब मैं अपना जवाब देता हूं तब भी मैं किसी और को वोट देता हूं। :-) –

+0

+1। 40% -70% के मेरे अनुभव कोड कवरेज में जादू संख्या है। नीचे आपके पास पूर्ववर्ती बग के खिलाफ पर्याप्त सुरक्षा नहीं है। ऊपर आप लिखने वाले निर्णायक परीक्षणों को समाप्त करते हैं जैसे परीक्षण गेटर्स और सेटर्स जो बाधा डालते हैं, विकास में मदद नहीं करते हैं। बहुत अधिक कोड कवरेज इसे धीमा और प्रतिक्रिया करने के लिए कठिन बनाता है। जब आप कुछ गलत करते हैं तो आपको केवल आपको काटने की आवश्यकता होती है, न कि आप सहज नहीं हो सकते हैं। मूल्य-कम परीक्षणों पर भी विचार करें।यदि एक परीक्षण लगातार टूट रहा है लेकिन वास्तव में बहुत कुछ साबित नहीं करता है, तो इसे हटा दें! या .. –

5

कभी-कभी कोने के मामले इतने दुर्लभ होते हैं कि वे परीक्षण के लायक नहीं हैं, फिर भी एक सख्त कोड-कवरेज नियम के लिए आपको इसकी जांच करने की आवश्यकता होती है।

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

यह बहुत काम बर्बाद हो जाएगा।

+0

मैंने वास्तव में एक देव मशीन पर एक समस्या देखी है जो यूटीएफ -8 के लिए एक असमर्थित एन्कोडिंग अपवाद से उत्पन्न हुआ है। यह भी अंतर्निहित होना चाहिए, लेकिन उस मशीन में सूर्य के जेडीके का एक बीटा संस्करण स्थापित किया गया था जहां यह नहीं था ... –

+1

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

2
  1. बहुत लक्षित परीक्षण मामलों को लिखना।
  2. कोड
  3. की अपर्याप्त इनपुट परिवर्तनीयता परीक्षण निष्पादित कृत्रिम परीक्षण मामलों की बड़ी संख्या।
  4. शोर के कारण महत्वपूर्ण परीक्षण विफलताओं पर ध्यान केंद्रित नहीं करना।
  5. दोषों को निर्दिष्ट करने में कठिनाई क्योंकि कई घटकों से कई स्थितियों को निष्पादित करने के लिए एक पंक्ति के लिए बातचीत करनी चाहिए।

100% कवरेज लक्ष्य रखने का सबसे बुरा दुष्प्रभाव है परीक्षण परीक्षण चक्र (75% +) कोने के मामलों को छिपाने के लिए बहुत सारे खर्च करना है। ऐसी नीति का एक और खराब प्रभाव इनपुट की सीमा को संबोधित करने के बजाय कोड की एक विशेष पंक्ति को मारने की एकाग्रता है। मुझे सच में परवाह नहीं है कि strcpy समारोह कम से कम एक बार भाग गया। मुझे सच में परवाह है कि यह विभिन्न प्रकार के इनपुट के खिलाफ भाग गया। पॉलिसी रखना अच्छा है। लेकिन किसी भी बेहद कठोर नीति होने के कारण बुरा है। कोड कवरेज का 100% मीट्रिक न तो आवश्यक है और न ही कोड को ठोस माना जा सकता है।

16

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

if (A) { ... } else { ... } 
if (B) { ... } else { ... } 

हालांकि सिर्फ दो परीक्षण (जैसे एक के साथ एक और बी सच है, ए और बी झूठे के साथ):

उदाहरण के लिए, इस कोड को चार रास्तों है "100% कोड कवरेज।"

यह एक समस्या है क्योंकि जादू 100% संख्या प्राप्त करने के बाद प्रवृत्ति को रोकना है।

1

कोड कवरेज के साथ कुछ भी गलत नहीं - जो मैं गलत देखता हूं वह 100% आंकड़ा है। कुछ बिंदु पर कम रिटर्न का कानून इसमें शामिल होता है और यह 99% की तुलना में पिछले 1% की जांच करने के लिए और अधिक महंगा हो जाता है। कोड कवरेज एक योग्य लक्ष्य है लेकिन सामान्य ज्ञान एक लंबा रास्ता तय करता है।

18

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

for (int i = 0; i < MAX_RETRIES; ++i) { 
    if (someFunction() == MAGIC_NUMBER) { 
     break; 
    } 
} 

... कभी पाश के लिए पर समाप्ति हालत के परीक्षण के बिना।

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

सीधे शब्दों में कहें

, कम कोड कवरेज का स्तर निश्चित रूप से अपर्याप्त परीक्षण का एक संकेत है, लेकिन उच्च कवरेज स्तरों नहीं हैं पर्याप्त या सही परीक्षण का एक संकेत।

1

! 00% कोड कवरेज का मतलब है कि अच्छी तरह से परीक्षण कोड एक पूर्ण मिथक है। डेवलपर्स के रूप में हम एक सिस्टम के कठिन/जटिल/नाजुक हिस्सों को जानते हैं, और मैं उन क्षेत्रों को उचित रूप से परीक्षण करने के लिए बहुत अधिक देखता हूं, और अर्थहीन आंकड़े के बजाय केवल 50% कवरेज प्राप्त करता हूं कि प्रत्येक पंक्ति कम से कम एक बार चलती है।

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

3

मैं जानता हूँ कि क्या यह आपके प्रश्न के लिए एक सीधा जवाब नहीं है, लेकिन ...

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

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

बस बाकी विकास की तरह, परीक्षण के साथ शॉर्टकट न लें, यह केवल बग्स को ही देगा।

1

हमारे पास यूनिट परीक्षणों से कोड-कवरेज को मापने के लिए अच्छे उपकरण हैं। इसलिए यह प्रतिनिधित्व करने के लिए 100% के कोड-कवरेज पर निर्भर होना प्रलोभन है कि आप "परीक्षण कर रहे हैं।" यह सच नहीं है।

जैसा कि अन्य लोगों ने उल्लेख किया है, 100% कोड कवरेज यह साबित नहीं करता है कि आपने पर्याप्त रूप से परीक्षण किया है, न ही 50% कोड कवरेज का मतलब यह है कि आपने पर्याप्त रूप से परीक्षण नहीं किया है।

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

मैं भी हाल ही में इस बारे में भी ब्लॉग है: http://karwin.blogspot.com/2009/02/unit-test-coverage.html

5

मेरी राय में, एक टीम कोड कवरेज को मापने से चलने वाला सबसे बड़ा खतरा यह है कि यह बड़े परीक्षणों को पुरस्कृत करता है, और छोटे बच्चों को दंडित करता है। यदि आपके पास एक ऐसे परीक्षण को लिखने का विकल्प है जो आपके आवेदन की कार्यक्षमता के एक बड़े हिस्से को कवर करता है, और एक ही विधि का परीक्षण करने वाले दस छोटे परीक्षणों को लिखता है, केवल कोड कवरेज को मापने का तात्पर्य है कि आपको बड़ा परीक्षण लिखना चाहिए।

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

1

100% कोड कवरेज मतलब यह नहीं है आप पूरा कर लें usnit साथ

function int divide(int a, int b) { 
    return a/b; 
} 

परीक्षण सिर्फ 1 इकाई परीक्षण के साथ, मैं इस कार्य के लिए 100% कोड कवरेज मिलती है:

return divide(4,2) == 2; 

अब , कोई भी तर्क नहीं देगा कि 100% कवरेज वाला यह यूनिट कोड इंगित करता है कि वह केवल ठीक काम करता है।

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

2

कोड कवरेज के सबसे बड़े नुकसान में से एक यह है कि लोग वास्तव में निर्दिष्ट किए बिना कोड कवरेज के बारे में बात करते हैं वे किस प्रकार के कोड कवरेज के बारे में बात कर रहे हैं। सी 0, सी 1, सी 2 और कोड कवरेज के उच्च स्तर की विशेषताएं बहुत अलग हैं, इसलिए बस "कोड कवरेज" के बारे में बात करना भी समझ में नहीं आता है।

उदाहरण के लिए, 100% पूर्ण पथ कवरेज प्राप्त करना काफी असंभव है। यदि आपके प्रोग्राम में n निर्णय बिंदु हैं, तो आपको 2 n परीक्षणों की आवश्यकता है (और परिभाषा के आधार पर, मूल्य में प्रत्येक बिट एक निर्णय बिंदु है, इसलिए एक बेहद सरल फ़ंक्शन के लिए 100% पूर्ण पथ कवरेज प्राप्त करने के लिए जो केवल दो जोड़ता है int एस, आपको 18446744073709551616 परीक्षणों की आवश्यकता है)। यदि आपके पास केवल एक पाश है, तो आपको पहले से ही असीमित परीक्षणों की आवश्यकता है।

ओटीओएच, 100% सी 0 कवरेज प्राप्त करना मामूली है।

याद रखने की एक और महत्वपूर्ण बात यह है कि कोड कवरेज आपको बताता है कि कौन सा कोड परीक्षण किया गया था। यह केवल आपको बताता है कि रन चला गया था! आप इसे अपने आप आज़मा सकते हैं: एक कोडबेस लें जिसमें 100% कोड कवरेज हो। परीक्षण से सभी दावों को हटा दें। अब कोडबेस अभी भी में 100% कवरेज है, लेकिन एक चीज का परीक्षण नहीं करता है! इसलिए, कोड कवरेज आपको यह नहीं बताता कि क्या परीक्षण किया गया है, केवल परीक्षण नहीं किया गया है।

2

वहाँ उपकरण हैं, Jumble एक के लिए, जो शाखा कवरेज के माध्यम से विश्लेषण करते हैं, यह देखने के लिए कि आपका परीक्षण सभी अलग-अलग क्रमिकताओं के लिए विफल रहता है या नहीं।

उनकी वेबसाइट से

सीधे:

गड़बड़ी एक वर्ग स्तर उत्परिवर्तन परीक्षण उपकरण है जो JUnit साथ संयोजन के रूप में काम करता है है। उत्परिवर्तन परीक्षण का उद्देश्य परीक्षण मामलों की प्रभावशीलता का एक उपाय प्रदान करना है। एक उत्परिवर्तन कोड पर पर परीक्षण किया जाता है, इसी परीक्षण मामलों को तब निष्पादित किया जाता है। यदि संशोधित कोड परीक्षण विफल रहता है, तो इससे परीक्षणों में विश्वास बढ़ जाता है। इसके विपरीत, यदि संशोधित कोड परीक्षण पास करता है तो यह परीक्षण की कमी दर्शाता है।

+0

परीक्षण व्यक्त करने का एक बेहतर तरीका ढूंढें जेस्टर एक और समान "यूनिट टेस्ट परीक्षक" है। http://jester.sourceforge.net/ –

+0

जेस्टर छोटे खिलौनों की परियोजनाओं के अलावा किसी अन्य चीज़ के लिए वास्तव में उपयोगी नहीं है। जुम्बल एक सुधार है लेकिन इन दिनों देखे जाने के बेहतर विकल्प हैं - http://pitest.org/java_mutation_testing_systems/ – henry

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