क्या पथ कवरेज सभी कीड़े खोजने की गारंटी देता है?

64

यदि किसी प्रोग्राम के माध्यम से हर पथ का परीक्षण किया जाता है, तो क्या वह सभी कीड़े खोजने की गारंटी देता है?

यदि नहीं, तो क्यों नहीं? आप कार्यक्रम के प्रवाह के हर संभव संयोजन के माध्यम से कैसे जा सकते हैं और समस्या नहीं है यदि कोई मौजूद है?

मुझे यह सुझाव देने में संकोच है कि "सभी कीड़े" पाए जा सकते हैं, लेकिन शायद ऐसा इसलिए है क्योंकि पथ कवरेज व्यावहारिक नहीं है (जैसा कि यह दहनशील है) इसलिए यह कभी अनुभव नहीं हुआ है?

नोट: यह आलेख कवरेज प्रकारों का एक त्वरित सारांश देता है जैसा कि मैं उनके बारे में सोचता हूं।

testing test-coverage

33

यह रुकने की समस्या के बराबर है ।

31

क्या होगा अगर कोड जो वहाँ होना चाहिए था, है न?

— रेमकोगर्लिच

6

@ स्नोमैन: नहीं, यह नहीं है। सभी कार्यक्रमों के लिए रुकने की समस्या को हल करना संभव नहीं है, लेकिन कई विशिष्ट कार्यक्रमों के लिए यह हल है। इन कार्यक्रमों के लिए, सभी कोड रास्तों को एक परिमित (हालांकि संभवतः लंबे समय) राशि में गणना की जा सकती है।

— जोर्जेन फॉग

3

@ JørgenFogh जब किसी कार्यक्रम में बग ढूंढने की कोशिश की जाती है , तो क्या यह एक प्राथमिकता नहीं है कि यह कार्यक्रम रुकता है या नहीं? क्या "पथ कवरेज के माध्यम से किसी भी कार्यक्रम में सभी कीड़े खोजने" की सामान्य विधि के बारे में यह सवाल नहीं है ? किस मामले में, "क्या कोई कार्यक्रम रुकता है" यह खोजने के समान नहीं है?

— एंड्रेस एफ।

1

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

— लेउशेंको

128

यदि किसी प्रोग्राम के माध्यम से हर पथ का परीक्षण किया जाता है, तो क्या वह सभी कीड़े खोजने की गारंटी देता है?

नहीं

यदि नहीं, तो क्यों नहीं? आप कार्यक्रम के प्रवाह के हर संभव संयोजन के माध्यम से कैसे जा सकते हैं और समस्या नहीं है यदि कोई मौजूद है?

क्योंकि भले ही आप सभी संभावित रास्तों का परीक्षण करते हों , फिर भी आपने उन्हें सभी संभावित मूल्यों या मूल्यों के सभी संभावित संयोजनों के साथ नहीं देखा है । उदाहरण के लिए (स्यूडोकोड):

def Add(x as Int32, y as Int32) as Int32:
   return x + y

Test.Assert(Add(2, 2) == 4) //100% test coverage
Add(MAXINT, 5) //Throws an exception, despite 100% test coverage

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

- ईडब्ल्यू डेज्क्ट्रा (जोर पर जोर दिया गया। 1988 में लिखा गया। यह अब 2 दशक से ज्यादा हो गया है।)

— मेसन व्हीलर
स्रोत

7

@digitgopher: मुझे लगता है, लेकिन अगर किसी प्रोग्राम का कोई इनपुट नहीं है, तो यह क्या उपयोगी है?

— मेसन व्हीलर

34

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

— Ixrec

11

@Ixrec: SQLite एक बहुत बहादुर प्रयास करता है, हालांकि! लेकिन यह एक बहुत बड़ा प्रयास है कि देखो! यह बड़े कोडबेस के लिए अच्छा नहीं होगा।

— मेसन व्हीलर

13

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

— इविलनोटिक्सिस्ट इडोनाटेक्सिस्ट

14

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

— डेविड के

71

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

कल्पना कीजिए कि आपके पास 100% पथ कवरेज के साथ एक परीक्षण है। अब सभी अभिक्रियाओं को हटा दें और फिर से टेस्टयूसाइट चलाएं। Voilà, testuite में अभी भी 100% पथ कवरेज है, लेकिन यह बिल्कुल कुछ भी परीक्षण नहीं करता है।

— जोर्ग डब्ल्यू मित्तग
स्रोत

2

यह सुनिश्चित कर सकता है कि परीक्षण कोड (परीक्षण में मापदंडों के साथ) को कॉल करते समय कोई अपवाद नहीं है। यह कुछ नहीं से थोड़ा अधिक है।

— पाओलो एबरमैन

7

@ Pa @loEbermann सहमत, कुछ नहीं से थोड़ा अधिक। हालांकि, यह "सभी कीड़े ढूंढने" की तुलना में बहुत कम है;)

— एंड्रेस एफ।

1

@ Pa @loEbermann: अपवाद एक कोड पथ है। यदि कोड फेंक सकता है लेकिन कुछ परीक्षण डेटा के साथ नहीं फेंकते हैं, तो परीक्षण 100% पथ कवरेज प्राप्त नहीं करता है। यह त्रुटि-हैंडलिंग तंत्र के रूप में अपवादों के लिए विशिष्ट नहीं है। विजुअल बेसिक का ON ERROR GOTOभी एक रास्ता है, जैसा कि C का है if(errno)।

— MSalters

1

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

— पाओलो एबरमन

2

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

— EIS

34

यहाँ चीजों को गोल करने का एक सरल उदाहरण है। निम्नलिखित छँटाई एल्गोरिथ्म पर विचार करें (जावा में):

int[] sort(int[] x) { return new int[] { x[0] }; }

अब, परीक्षण करते हैं:

sort(new int[] { 0xCAFEBABE });

अब, विचार करें कि (ए) इस विशेष कॉल को sortसही परिणाम देता है, (बी) सभी कोड पथ इस परीक्षण द्वारा कवर किए गए हैं।

लेकिन, जाहिर है, कार्यक्रम वास्तव में सॉर्ट नहीं करता है।

यह इस प्रकार है कि सभी कोड रास्तों का कवरेज यह गारंटी देने के लिए पर्याप्त नहीं है कि कार्यक्रम में कोई बग नहीं है।

— Atsby
स्रोत

12

absफ़ंक्शन पर विचार करें , जो किसी संख्या का निरपेक्ष मान लौटाता है। यहाँ एक परीक्षण है (अजगर, कुछ परीक्षण ढांचे की कल्पना करें):

def test_abs_of_neg_number_returns_positive():
    assert abs(-3) == 3

यह कार्यान्वयन सही है, लेकिन इसे केवल 60% कोड कवरेज मिलता है:

def abs(x):
    if x < 0:
        return -x
    else:
        return x

यह कार्यान्वयन गलत है, लेकिन इसे 100% कोड कवरेज मिलता है:

def abs(x):
    return -x

— RemcoGerlich
स्रोत

2

यहां एक और कार्यान्वयन है जो परीक्षण को पारित करता है (कृपया गैर-लाइनब्रोकन पायथन को क्षमा करें): def abs(x): if x == -3: return 3 else: return 0आप संभवतः else: return 0भाग को समाप्त कर सकते हैं और 100% कवरेज प्राप्त कर सकते हैं , लेकिन यूनिट टेस्ट पास करने के बावजूद फ़ंक्शन अनिवार्य रूप से बेकार हो जाएगा।

— एक CVn

7

फिर भी मेसन के जवाब के अलावा , एक कार्यक्रम का व्यवहार रनटाइम वातावरण पर निर्भर हो सकता है।

निम्न कोड में एक उपयोग-बाद-मुक्त होता है:

int main(void)
{
    int* a = malloc(sizeof(a));
    int* b = a;
    *a = 0;
    free(a);
    *b = 12; /* UAF */
    return 0;
}

यह कोड अपरिभाषित व्यवहार है, जो कॉन्फ़िगरेशन (रिलीज | डिबग), ओएस और संकलक के आधार पर अलग-अलग व्यवहारों को प्राप्त करेगा। न केवल पथ कवरेज इस बात की गारंटी नहीं देगा कि आप UAF पाएंगे, बल्कि आपका परीक्षण सूट आमतौर पर UAF के विभिन्न संभावित व्यवहारों को कवर नहीं करेगा जो कॉन्फ़िगरेशन पर निर्भर करते हैं।

एक अन्य नोट पर, भले ही पथ कवरेज सभी बग्स को खोजने की गारंटी देने के लिए था, यह संभावना नहीं है कि यह किसी भी कार्यक्रम पर अभ्यास में प्राप्त किया जा सकता है। निम्नलिखित पर विचार करें:

int main(int a, int b)
{
    if (a != b) {
        if (cryptohash(a) == cryptohash(b)) {
            return ERROR;
        }
    }
    return 0;
}

यदि आपका टेस्ट-सूट इसके लिए सभी रास्ते तैयार कर सकता है, तो बधाई हो कि आप एक क्रिप्टोग्राफर हैं।

— dureuill
स्रोत

पर्याप्त रूप से छोटे पूर्णांकों के लिए आसान :)

— कोडइन्कॉस

कुछ भी जानने के बिना cryptohash, यह कहना थोड़ा कठिन है कि "पर्याप्त रूप से छोटा" क्या है। शायद एक सुपरक्यूलर पर पूरा होने में दो दिन लगते हैं। लेकिन हाँ, intथोड़ा हो सकता है short।

— dureuill

32 बिट पूर्णांक और विशिष्ट क्रिप्टोग्राफिक हैश (SHA2, SHA3, आदि) के साथ यह काफी सस्ता होना चाहिए। कुछ सेकंड या तो।

— कोडइन्चोस

7

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

इस प्रश्न का उत्तर देने का एक और तरीका अभ्यास से एक है:

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

एक उलझा हुआ प्रश्न इसलिए है:

कोड कवरेज टूल्स का क्या मतलब है?

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

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

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

कोड कवरेज के साथ, यह लुभावना हो सकता है, खासकर यदि आप मामलों को भरने के लिए लगभग 98% सही हैं, ताकि शेष मार्ग हिट हों।

यह वर्तनी जांच के साथ सही करने के बराबर है कि यह सभी शब्द मौसम है या गाँठ यह सभी उपयुक्त शब्द हैं। नतीजा एक बत्तख गड़बड़ है।

हालांकि, अगर आप विचार करते हैं कि गैर-कवर किए गए रास्तों का वास्तव में क्या परीक्षण है, तो कोड-कवरेज टूल ने अपना काम किया होगा; आपको सही करने का वादा करने में नहीं, लेकिन यह कुछ ऐसे कामों की ओर इशारा करता है, जिन्हें करने की जरूरत है।

— जॉन हैना
स्रोत

+1 मुझे यह उत्तर पसंद है क्योंकि यह रचनात्मक है और कवरेज के कुछ लाभों का उल्लेख करता है।

— एंड्रेस एफ।

4

पथ कवरेज आपको यह नहीं बता सकता है कि सभी आवश्यक सुविधाओं को लागू किया गया है या नहीं। एक सुविधा को छोड़ना एक बग है, लेकिन पथ कवरेज इसका पता नहीं लगाएगा।

— पीट बेकर
स्रोत

1

मुझे लगता है कि यह बग की परिभाषा पर निर्भर करता है। मुझे नहीं लगता कि लापता सुविधाओं या कार्यक्षमता को बग के रूप में माना जाना चाहिए।

— ईस

@eis - आपको एक उत्पाद के साथ कोई समस्या नहीं दिखती है जिसका प्रलेखन कहता है कि यह X करता है जब वास्तव में यह नहीं होता है? यह "बग" की एक संकीर्ण परिभाषा है। जब मैंने बोरलैंड के C ++ उत्पाद लाइन के लिए QA को प्रबंधित किया तो हम उस उदार नहीं थे।

— पीट बेकर

मैं यह नहीं देखता कि दस्तावेज़ीकरण यह क्यों कहता है कि यदि X को कभी लागू नहीं किया गया था

— eis

@eis - यदि मूल डिज़ाइन फीचर X के लिए कहा जाता है, तो दस्तावेज़ X का वर्णन करते हुए समाप्त हो सकता है। यदि किसी ने इसे लागू नहीं किया है, तो यह एक बग है, और पथ कवरेज (या किसी अन्य प्रकार का ब्लैक बॉक्स परीक्षण) इसे नहीं मिलेगा।

— पीट बेकर

उफ़, पथ कवरेज सफेद बॉक्स परीक्षण है, न कि ब्लैक बॉक्स । श्वेत बॉक्स परीक्षण लापता सुविधाओं को नहीं पकड़ सकता है।

— पीट बेकर

4

इस मुद्दे का हिस्सा यह है कि 100% कवरेज केवल गारंटी देता है कि एक एकल निष्पादन के बाद कोड सही ढंग से कार्य करेगा । मेमोरी लीक्स जैसे कुछ बग स्पष्ट या एकल निष्पादन के बाद समस्या का कारण नहीं हो सकते हैं, लेकिन समय के साथ आवेदन के लिए समस्याएं पैदा करेंगे।

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

— डेरेक डब्लू
स्रोत

सहमत है कि इस मुद्दे का हिस्सा है, लेकिन असली मुद्दा इससे अधिक मौलिक है। यहां तक कि अनंत स्मृति और कोई संगति के साथ एक सैद्धांतिक कंप्यूटर के साथ, 100% परीक्षण कवरेज कीड़े की अनुपस्थिति का मतलब नहीं है। यहाँ के जवाबों में इस लाजवाब उदाहरण के बारे में पता चलता है, लेकिन यहाँ एक और बात है: अगर मेरा कार्यक्रम है times_two(x) = x + 2, तो यह पूरी तरह से टेस्ट सूट द्वारा कवर किया जाएगा assert(times_two(2) == 4), लेकिन यह अभी भी स्पष्ट रूप से छोटी गाड़ी कोड है! मेमोरी लीक की कोई आवश्यकता नहीं है :)

— एंड्रेस एफ।

2

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

— डेरेक डब्ल्यू

अच्छी बात। माना।

— एंड्रेस एफ।

3

यदि किसी प्रोग्राम के माध्यम से हर पथ का परीक्षण किया जाता है, तो क्या वह सभी कीड़े खोजने की गारंटी देता है?

जैसा कि पहले ही कहा जा चुका है, इसका जवाब नहीं है।

यदि नहीं, तो क्यों नहीं?

इसके अलावा जो कहा जा रहा है, उसमें विभिन्न स्तरों पर दिखने वाले कीड़े हैं, जिन्हें इकाई परीक्षणों के साथ नहीं देखा जा सकता है। बस कुछ का उल्लेख करने के लिए:

एकीकरण परीक्षण के साथ पकड़े गए कीड़े (इकाई परीक्षण वास्तविक संसाधनों का उपयोग नहीं करना चाहिए)
आवश्यकताओं में कीड़े
डिजाइन और वास्तुकला में कीड़े

— BЈовић
स्रोत

2

हर पथ का परीक्षण करने का क्या मतलब है?

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

इस विधि पर विचार करें:

def add(num1, num2)
  foo = "bar"  # useless statement
  $global += 1 # side effect
  num1 + num2  # actual work
end

यदि आप एक परीक्षण लिखते हैं जो दावा करता है add(1, 2) == 3, तो एक कोड कवरेज टूल आपको बताएगा कि हर पंक्ति का उपयोग किया जाता है। लेकिन आपने वास्तव में वैश्विक दुष्प्रभाव या बेकार असाइनमेंट के बारे में कुछ भी नहीं कहा है। उन पंक्तियों को निष्पादित किया गया है, लेकिन वास्तव में परीक्षण नहीं किया गया है।

उत्परिवर्तन परीक्षण इस तरह के मुद्दों को खोजने में मदद करेगा। एक उत्परिवर्तन परीक्षण उपकरण में कोड को "म्यूट" करने के लिए पूर्व-निर्धारित तरीकों की एक सूची होगी और देखें कि क्या परीक्षण अभी भी गुजरते हैं। उदाहरण के लिए:

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

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

हर परीक्षण जो हम कर सकते हैं, बग-मुक्त कार्यक्रमों की ओर बढ़ने का एक अनुमान है। कुछ भी पूर्ण नहीं है।

— नाथन लोंग
स्रोत

0

अच्छी तरह से ... हाँ वास्तव में, अगर हर पथ "के माध्यम से" कार्यक्रम का परीक्षण किया जाता है। लेकिन इसका मतलब है कि, सभी संभावित राज्यों के पूरे स्थान के माध्यम से हर संभव पथ सभी चर सहित कार्यक्रम हो सकता है। यहां तक कि एक बहुत ही सरल रूप से संकलित कार्यक्रम के लिए - कहते हैं, एक पुराना फोरट्रान नंबर क्रंचर - यह संभव नहीं है, हालांकि यह कम से कम कल्पनाशील हो सकता है: यदि आपके पास सिर्फ दो पूर्णांक चर हैं, तो आप मूल रूप से बिंदुओं को जोड़ने के सभी संभावित तरीकों से निपट रहे हैं एक दो आयामी ग्रिड; यह वास्तव में ट्रैवलिंग सेल्समैन की तरह दिखता है। के लिए n ऐसे चर, तो आप एक साथ काम कर रहे एन आयामी अंतरिक्ष, इसलिए किसी भी वास्तविक कार्यक्रम के लिए, कार्य पूरी तरह से untractable है।

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

उस ने कहा ... वास्तव में चीजें बहुत धूमिल नहीं हैं। यह है करने के लिए संभव proove सही होने के लिए पूरे कार्यक्रम, लेकिन आप कुछ विचार देने के लिए करना होगा।

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

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

अब, आप कहते हैं कि यह अभी भी अचूक है ... आखिरकार, सभी संभावित तर्कों का स्थान भी सामान्य रूप से अनंत-आयामी है। यह सच है - हालांकि एक ही कार्य के लिए, यहां तक कि भोले कवरेज परीक्षण आपको आगे बढ़ने की तुलना में आगे बढ़ने की उम्मीद करता है! हालांकि, एक अविश्वसनीय शक्तिशाली उपकरण है जो खेल को बदलता है: सार्वभौमिक मात्रा का ठहराव / पैरामीट्रिक बहुरूपता । असल में, यह आपको बहुत सामान्य प्रकार के डेटा पर फ़ंक्शन लिखने की अनुमति देता है, इस गारंटी के साथ कि यदि यह डेटा के सरल उदाहरण के लिए काम करता है, तो यह किसी भी संभावित इनपुट के लिए काम करेगा।

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

— leftaroundabout
स्रोत

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

— मैथ्यू पढ़ें

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

— लेफ्टरेंबाउट