मेरे कोड में अभी भी कितनी त्रुटियां हो सकती हैं भले ही मेरे पास 100% कोड कवरेज हो?

Question

मेरे पास 100% कोड कवरेज होने पर भी मेरे कोड में किस प्रकार की त्रुटियां हो सकती हैं? मैं ऐसी त्रुटियों के ठोस उदाहरणों के ठोस उदाहरण या लिंक ढूंढ रहा हूं।

Answer 1

100% कोड कवरेज के बाद कि महान नहीं है जैसा कि कोई इसके बारे में सोच सकता है। एक trival उदाहरण पर विचार करें:

double Foo(double a, double b) 
{ 
    return a/b; 
} 

एक भी इकाई परीक्षण 100% करने के लिए इस विधि का कोड कवरेज बढ़ा देंगे, लेकिन कहा इकाई परीक्षण हमें बताओ नहीं होगा क्या कूट चल रहा है और क्या कोड नहीं है। यह एक पूरी तरह से वैध कोड हो सकता है, लेकिन किनारे की स्थिति के परीक्षण के बिना (जैसे b0.0 है) इकाई परीक्षण सर्वोत्तम रूप से अनिवार्य है।

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

एक दिलचस्प चर्चा के लिए this पर सुनें।

Answer 2

कोड कवरेज का मतलब यह नहीं है कि आपका कोड किसी भी तरह से बग मुक्त है। यह अनुमान है कि आप परीक्षण स्रोत कितने अच्छी तरह से अपने स्रोत कोड आधार को कवर करते हैं। 100% कोड कवरेज का अर्थ यह होगा कि कोड की प्रत्येक पंक्ति का परीक्षण किया जाता है लेकिन आपके कार्यक्रम की हर स्थिति निश्चित रूप से नहीं होती है। इस क्षेत्र में शोध किया जा रहा है, मुझे लगता है कि इसे परिमित राज्य मॉडलिंग के रूप में जाना जाता है लेकिन यह वास्तव में एक कार्यक्रम के हर राज्य का पता लगाने की कोशिश करने का एक क्रूर बल तरीका है।

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

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

कोड कवरेज अच्छा परीक्षण

संकेत नहीं करता है

Answer 3

वहाँ हमेशा क्रम अपवाद हो सकता है: स्मृति को भरने, डेटाबेस या अन्य कनेक्शन बंद किया जा रहा नहीं आदि ...

Answer 4

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

Answer 5

ठीक है अगर आपके परीक्षण कवर किए गए कोड में होने वाली चीज़ का परीक्षण नहीं करते हैं। आप इस विधि का जो उदाहरण के लिए गुणों के एक नंबर कहते हैं:

public void AddTo(int i) 
{ 
NumberA += i; 
NumberB -= i; 
} 

अपने परीक्षण केवल NumberA संपत्ति की जाँच करता है, लेकिन नहीं NumberB, तो आपको 100% कवरेज होगा, परीक्षण गुजरता है, लेकिन NumberB होगा तो अभी भी एक त्रुटि है।

निष्कर्ष: 100% के साथ एक इकाई परीक्षण गारंटी नहीं देगा कि कोड बग-फ्री है।

Answer 6

पर विचार करें निम्नलिखित कोड:

int add(int a, int b) 
{ 
    return a + b; 
} 

इस कोड को कुछ आवश्यक कार्यक्षमता को लागू करने के विफल हो सकता है (यानी एक अंतिम-उपयोगकर्ता आवश्यकताओं को पूरा नहीं): "100% कवरेज" जरूरी परीक्षण नहीं होता है/कार्यक्षमता का पता लगाने के जो लागू किया जाना चाहिए लेकिन जो नहीं है।

यह कोड कुछ के लिए काम कर सकता है लेकिन सभी इनपुट डेटा श्रेणियों (उदाहरण के लिए जब ए और बी दोनों बहुत बड़े होते हैं)।

Answer 7

1. "डेटा अंतरिक्ष" समस्याओं

आपका (बुरा) कोड:

void f(int n, int increment) 
{ 
    while(n < 500) 
    { 
    cout << n; 
    n += increment; 
    } 
} 

आपका परीक्षण:

f(200,0); 

: असली दुनिया में उपयोग में

f(200,100); 

बग

मेरा बिंदु: आपका परीक्षण आपके कोड की 100% पंक्तियों को कवर कर सकता है लेकिन यह आपके सभी संभावित इनपुट डेटा स्थान को कवर नहीं करेगा (यानी) इनपुट के सभी संभावित मूल्यों का सेट।

2. अपनी खुद की गलती

एक और शास्त्रीय उदाहरण के खिलाफ परीक्षण है जब तुम सिर्फ डिजाइन में एक खराब निर्णय लेते हैं, और अपने खुद के खराब निर्णय के खिलाफ अपने कोड का परीक्षण।

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

3. अपरिभाषित व्यवहार

अप्रारंभीकृत चर के मान का उपयोग करें, गलत स्मृति का उपयोग, आदि के कारण और अपने कोड (C++ या किसी अन्य भाषा है कि "अपरिभाषित व्यवहार" चिंतन) व्यवहार अपरिभाषित है। कभी-कभी यह आपके परीक्षणों को पारित करेगा, लेकिन यह वास्तविक दुनिया में दुर्घटनाग्रस्त हो जाएगा।

...

Answer 8

त्रुटियाँ में परीक्षण :)

Answer 9

कोड कवरेज कुछ भी मतलब नहीं है, यदि आपका परीक्षण बग हो, या आप गलत बात का परीक्षण कर रहे हैं।

संबंधित टेंगेंट के रूप में; जॉन स्कीट को

sorted = sort(2,1,6,4,3,1,6,2); 

for element in sorted { 
    if (is_defined(previousElement)) { 
    assert(element >= previousElement); 
    } 

    previousElement = element; 
} 

बोनस कर्म, जो उपाय बता मैं सोच रहा था ने कहा: मैं तुम्हें करने के लिए याद दिलाने के लिए है कि मैं तुच्छता से एक हे (1) विधि है जो निम्न छद्म कोड परीक्षण को संतुष्ट करता है निर्माण कर सकते हैं करना चाहते हैं के बारे में

Answer 10

जैसा कि मैंने नहीं देखा है यह अभी तक उल्लेख किया है, मैं इस सूत्र कोड कवरेज करता है कि नहीं आपको बता अपने कोड के कौन से भाग bugfree है जोड़ना चाहते हैं।

यह केवल आपको बताता है कि आपके कोड के कौन से हिस्से अनचाहे होने की गारंटी देते हैं।

Answer 11

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

Answer 12

हाल ही में आईईईई सॉफ्टवेयर पेपर "दो गलतियों और त्रुटि मुक्त सॉफ्टवेयर: एक कन्फेशंस" में, रॉबर्ट ग्लास ने तर्क दिया कि "वास्तविक दुनिया" में वह गुम तर्क या संयोजक (जिसे ' तर्क कवर त्रुटियों (जो कर सकते हैं) के मुकाबले कोड कवरेज टूल्स के खिलाफ सुरक्षा नहीं की जा सकती है।

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

कागज के संदर्भ here है और मैं एक किसी न किसी सारांश here पाया।

Answer 13

तर्क सत्यापन, उर्फ। नल चेक यदि आप कोई बाहरी इनपुट लेते हैं और उन्हें फ़ंक्शंस में पास करते हैं लेकिन कभी भी यह जांच नहीं करते कि वे वैध/शून्य हैं, तो आप 100% कवरेज प्राप्त कर सकते हैं, लेकिन अगर आप किसी भी तरह फ़ंक्शन में शून्य हो जाते हैं तो आपको अभी भी NullReferenceException मिलेगा क्योंकि आपका डेटाबेस यही देता है आप।

भी, गणित अतिप्रवाह,

int result = int.MAXVALUE + int.MAXVALUE; 

कोड कवरेज की तरह केवल मौजूदा कोड को शामिल किया गया है, यह इंगित करने के लिए जहां आप और अधिक कोड जोड़ने चाहिए में सक्षम नहीं होगा।

Answer 14

मेरी मशीन पर काम करता है

कई बातें स्थानीय मशीन पर अच्छी तरह से काम और हम उस स्टेजिंग/उत्पादन पर काम करने को आश्वस्त नहीं कर सकते। कोड कवरेज इसमें शामिल नहीं हो सकता है।

Answer 15

मुझे किसी और के बारे में पता नहीं है, लेकिन हमें 100% कवरेज के करीब कहीं भी नहीं मिलता है। हमारे किसी भी "यह कभी नहीं होना चाहिए" कैचियों को हमारे परीक्षणों में प्रयोग किया जाता है (ठीक है, कभी-कभी वे करते हैं, लेकिन फिर कोड ठीक हो जाता है ताकि वे और नहीं!)। मुझे डर है कि मुझे चिंता न करें कि कभी-कभी-कभी-सीएटीएच

Answer 16

आपका उत्पाद तकनीकी रूप से सही हो सकता है, लेकिन ग्राहक की ज़रूरतों को पूरा नहीं कर सकता है।

Answer 17

FYI करें, माइक्रोसॉफ्ट Pex शून्य से विभाजन, अतिप्रवाह, आदि

ही आप एक तकनीक पूर्वावलोकन स्थापित कर सकते हैं यह उपकरण, VS2010 का हिस्सा है की तरह अपने कोड खोज और खोजने "बढ़त" मामलों, द्वारा मदद करने के लिए प्रयास करता है वीएस 2008 में संस्करण। यह बहुत ही उल्लेखनीय है कि टूल को यह सामान मिल जाता है, हालांकि, आईएमई, यह अभी भी आपको "बुलेटप्रूफ" तक पहुंचने वाला नहीं है।

Answer 18

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

Answer 19

कोड कवरेज का मतलब बहुत अधिक नहीं है। क्या मायने रखता है कि व्यवहार के प्रभाव वाले तर्क मानों के सभी (या अधिकतर) शामिल हैं। compareTo(0,0) के लिए जब तक आप एक परीक्षण के रूप में

//Return Negative, 0 or positive depending on x is <, = or > y 
int compareTo(int x, int y) { 
    return x-y; 
} 

, आप कोड कवरेज मिलती है:

उदाहरण के लिए एक विशिष्ट compareTo विधि पर विचार (जावा में है, लेकिन अधिकांश भाषाओं में लागू होता है)। हालांकि, आपको यहां कम से कम 3 टेस्टकेस की आवश्यकता है (3 परिणामों के लिए)। फिर भी यह बग मुक्त नहीं है। यह असाधारण/त्रुटि स्थितियों को कवर करने के लिए परीक्षण जोड़ने का भी भुगतान करता है। उपर्युक्त मामले में, यदि आप compareTo(10, Integer.MAX_INT) आज़माते हैं, तो यह असफल हो जा रहा है।

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

QuickCheck (यदि आपकी भाषा के लिए उपलब्ध है) जैसे टूल की जांच करें।

Answer 20

जैसा कि यहां कई उत्तरों में बताया गया है, आपके पास 100% कोड कवरेज हो सकता है और अभी भी बग हो सकती है।

उस पर, आपके पास 0 बग हो सकते हैं लेकिन आपके कोड में तर्क गलत हो सकता है (आवश्यकताओं से मेल नहीं खाता)। कोड कवरेज, या 100% बग-फ्री होने से आप इसकी सहायता नहीं कर सकते हैं।

एक ठेठ कॉर्पोरेट सॉफ्टवेयर विकास अभ्यास के रूप में निम्नानुसार हो सकता है:

1. है एक स्पष्ट रूप से लिखा कार्यात्मक विनिर्देश
2. एक परीक्षण योजना है कि के खिलाफ (1) और इसकी समीक्षा सहकर्मी है
3. परीक्षण है लिखा है है (2) के खिलाफ लिखे गए मामलों और उन्हें पीयर की समीक्षा
4. कार्यात्मक विनिर्देश के खिलाफ कोड लिखें और इसे पीयर की समीक्षा
5. टेस के विरुद्ध अपना कोड परीक्षण करें टी मामले
6. अच्छा कवरेज प्राप्त करने के लिए कोड कवरेज विश्लेषण करें और अधिक परीक्षण केस लिखें।

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

कंक्रीट उदाहरण किसी भी कीड़े नहीं है और 100% कवरेज है:

/** 
* Returns the duration in milliseconds 
*/ 
int getDuration() { 
    return end - start; 
} 

// test: 

start = 0; 
end = 1; 
assertEquals(1, getDuration()); // yay! 

// but the requirement was: 
// The interface should have a method for returning the duration in *seconds*. 

Answer 21

लगभग कुछ भी।

क्या आपने Code Complete पढ़ा है? (क्योंकि स्टैक ओवरव्लो आपको वास्तव में should कहता है।) अध्याय 22 में यह कहता है कि "100% कथन कवरेज एक अच्छी शुरुआत है, लेकिन यह शायद ही पर्याप्त है"। शेष अध्याय बताता है कि यह निर्धारित करने के लिए कि कौन से अतिरिक्त परीक्षण जोड़े जाएंगे। यहां एक संक्षिप्त टस्टर है।

• संरचित आधार परीक्षण और डाटा प्रवाह परीक्षण कार्यक्रम के माध्यम से प्रत्येक तर्क पथ परीक्षण का मतलब है। ए और बी के मूल्यों के आधार पर नीचे दिए गए प्रदूषित कोड के माध्यम से चार पथ हैं। 100% कथन कवरेज को केवल चार पथों में से केवल दो का परीक्षण करके हासिल किया जा सकता है, शायद f=1:g=1/f और f=0:g=f+1। लेकिन शून्य त्रुटि से विभाजित करेगा। आप अगर बयान और जबकि और छोरों (पाश शरीर कभी नहीं क्रियान्वित किया जा सकता है) और एक की हर शाखा के लिए या स्विच बयान का चयन पर विचार करने के लिए है।

  If A Then
f = 1
Else
f = 0
End If
If B Then
g = f + 1
Else
g = f/0
End If

• अनुमान लगा त्रुटि - इनपुट है कि अक्सर त्रुटियों का कारण के प्रकार के बारे अनुमान को सूचित किया। उदाहरण के लिए सीमा की स्थिति (एक त्रुटियों से बंद), अमान्य डेटा, बहुत बड़े मान, बहुत छोटे मान, शून्य, शून्य, खाली संग्रह।

और यहां तक ​​कि आपकी आवश्यकताओं में त्रुटियां भी हो सकती हैं, आपके परीक्षणों में त्रुटियां इत्यादि - जैसा कि अन्य ने उल्लेख किया है।