कोड कवरेज़: Difference between revisions

Latest revision as of 21:56, 4 November 2022

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

टेस्ट कवरेज व्यवस्थित सॉफ्टवेयर परीक्षण के लिए आविष्कार किए गए पहले तरीकों में से एक था। पहला प्रकाशित संदर्भ मिलर और मैलोनी द्वारा 1963 में एसीएम के संचार में था।^[3]

कवरेज मानदंड

यह मापने के लिए कि परीक्षण सूट द्वारा कितने प्रतिशत कोड निष्पादित किया गया है, एक या अधिक कवरेज मानदंड का उपयोग किया जाता है। इन्हें सामान्यतः नियमों या आवश्यकताओं के रूप में परिभाषित किया जाता है, जिन्हें एक परीक्षण सूट को पूरा करना चाहिए।^[4]

बुनियादी कवरेज मानदंड

कई कवरेज मानदंड हैं, लेकिन मुख्य हैं:^[5]

फंक्शन कवरेज – क्या कार्यक्रम में प्रत्येक कार्य (या सबरूटीन) को बुलाया जाता है?
स्टेटमेंट कवरेज – क्या कार्यक्रम में प्रत्येक कथन (कंप्यूटर विज्ञान) को क्रियान्वित किया जाता है?
एज कवरेज – क्या नियंत्रण-प्रवाह ग्राफ में प्रत्येक ग्राफ सिद्धांत को क्रियान्वित किया जाता है?
- शाखा कवरेज – इसमें प्रत्येक नियंत्रण संरचना की प्रत्येक शाखा (जिसे डीडी-पथ भी कहा जाता है) को निष्पादित किया गया है (जैसे कि इफ (if) और केस (case) स्टेटमेंट में)? उदाहरण के लिए, यदि एक कथन दिया गया है, तो क्या सही और गलत दोनों शाखाओं को निष्पादित किया गया है? (यह एज कवरेज का सबसेट है।)
'क्या प्रत्येक बूलियन उप-अभिव्यक्ति का मूल्यांकन सही और गलत दोनों के लिए किया गया है? (इसे विधेय कवरेज भी कहा जाता है।)

उदाहरण के लिए, निम्नलिखित सी (प्रोग्रामिंग भाषा) कार्यो पर विचार करें:

  int foo (int x, int y)

{
    int z = 0;
    if ((x > 0) && (y > 0))
    {
        z = x;
    }
    return z;
}

}

मान लें कि यह फ़ंक्शन किसी बड़े प्रोग्राम का हिस्सा है और यह प्रोग्राम कुछ टेस्ट सूट के साथ चलाया गया था।

फ़ंक्शन कवरेज संतुष्ट होगा यदि, इस निष्पादन के दौरान, फ़ंक्शन फू को कम से कम एक बार कॉल किया गया था।
इस फ़ंक्शन के लिए स्टेटमेंट में कवरेज संतुष्ट होगा तो यदि इसे उदाहरण के लिए कहा जाता है: foo(1,1), क्योंकि इस मामले में, फ़ंक्शन में प्रत्येक पंक्ति को निष्पादित किया जाएगा-सहित z = x;.
परीक्षण कॉल करने से शाखा कवरेज संतुष्ट होगी foo(1,1) तथा foo(0,1) क्योंकि, पहले मामले में, दोनों if शर्तें पूरी होती हैं और z = x; निष्पादित किया जाता है, जबकि दूसरे मामले में, पहली शर्त, (x>0), संतुष्ट नहीं है, जो के निष्पादन को रोकता है z = x;.
कंडीशन कवरेज कॉल करने वाले परीक्षणों से संतुष्ट होगा foo(1,0), foo(0,1), तथा foo(1,1). ये आवश्यक हैं क्योंकि पहले मामलों में, (x>0) का मूल्यांकन किया जाता है true, जबकि दूसरे में, इसका मूल्यांकन किया जाता है false. वहीं, पहला मामला बनता है (y>0) false, दूसरा मामला मूल्यांकन नहीं करता है, (y>0) (बूलियन ऑपरेटर के आलसी मूल्यांकन के कारण),इसे तीसरा मामला बनाता है true.

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

<वाक्यविन्यास हाइलाइट लैंग = पास्कल>

if a and b then

</वाक्यविन्यास हाइलाइट>

कंडीशन कवरेज को दो परीक्षणों से संतुष्ट किया जा सकता है:

a=true, b=false
a=false, b=true
चूँकि, परीक्षणों का यह सेट शाखा कवरेज को संतुष्ट नहीं करता है क्योंकि कोई भी स्थिति निम्नलिखित if स्थि‍ति को पूरा नहीं करेगी।

फॉल्ट इंजेक्शन यह सुनिश्चित करने के लिए आवश्यक हो सकता है कि परीक्षण के दौरान अपवाद-हैंडलिंग कोड की सभी स्थितियों और शाखाओं में पर्याप्त कवरेज हो।

संशोधित स्थिति/निर्णय कवरेज

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

शर्त/निर्णय कवरेज के लिए आवश्यक है कि निर्णय और शर्त कवरेज दोनों संतुष्ट हों। चूँकि, सुरक्षा-महत्वपूर्ण अनुप्रयोगों (जैसे एवियोनिक्स सॉफ़्टवेयर) के लिए अक्सर यह आवश्यक होता है कि संशोधित स्थिति/निर्णय कवरेज (MC/DC) संतुष्ट हो। यह मानदंड आवश्यकताओं के साथ शर्त/निर्णय मानदंड का विस्तार करता है कि प्रत्येक शर्त स्वतंत्र रूप से निर्णय के परिणाम को प्रभावित करे।

उदाहरण के लिए, निम्नलिखित कोड पर विचार करने पर: <वाक्यविन्यास हाइलाइट लैंग = पास्कल> अगर (A या बB) और C तो </वाक्यविन्यास हाइलाइट> निम्नलिखित परीक्षणों के सेट से शर्त/निर्णय मानदंड संतुष्ट होंगे:

A = True, B = True, C = True
A = False, B = False, C = False

चूंकि, उपरोक्त परीक्षण सेट संशोधित स्थिति/निर्णय कवरेज को संतुष्ट नहीं करेंगे, क्योंकि पहले परीक्षण में, 'B' का मान और दूसरे परीक्षण में 'सी' का मान आउटपुट को प्रभावित नहीं करेगा। तो, एमसी/डीसी को संतुष्ट करने के लिए निम्नलिखित परीक्षण सेट की आवश्यकता होती है:

A = False, B = True, C = False
A = False, B = True, C = True
A = False, B = False, C = True
A = True, B = False, C = True

एकाधिक कंडीशन कवरेज

इस मानदंड के लिए आवश्यक है कि प्रत्येक निर्णय के भीतर स्थितियों के सभी संयोजनों का परीक्षण किया जाए। उदाहरण के लिए, पिछले खंड के कोड खंड के लिए आठ परीक्षणों की आवश्यकता होगी:

A = False, B = False, C = False
A = False, B = False, C = True
A = False, B = True, C = False
A = False, B = True, C = True
A = True, B = False, C = False
A = True, B = False, C = True
A = True, B = True, C = False
A = True, B = True, C = True

पैरामीटर मान कवरेज

पैरामीटर वैल्यू कवरेज (पीवीसी) के लिए आवश्यक है कि पैरामीटर लेने वाली विधि में, ऐसे मापदंडों के लिए सभी सामान्य मूल्यों पर विचार किया जाना चाहिए। विचार यह है कि एक पैरामीटर के लिए सभी सामान्य संभावित मानों का परीक्षण किया जाता है।^[8] उदाहरण के लिए, एक स्ट्रिंग के लिए सामान्य मान हैं: 1) नल, 2) खाली, 3) व्हाइटस्पेस (स्पेस, टैब्स, न्यूलाइन), 4) वैध स्ट्रिंग, 5) अमान्य स्ट्रिंग, 6) सिंगल-बाइट स्ट्रिंग, 7) डबल- बाइट स्ट्रिंग। बहुत लंबे तारों का उपयोग करना भी उपयुक्त हो सकता है। प्रत्येक संभावित पैरामीटर मान का परीक्षण करने में विफलता के परिणामस्वरूप एक बग हो सकता है। इनमें से केवल एक के परीक्षण के परिणामस्वरूप 100% कोड कवरेज हो सकता है क्योंकि प्रत्येक पंक्ति को कवर किया जाता है, लेकिन जैसा कि सात विकल्पों में से केवल एक का परीक्षण किया जाता है, केवल 14.2% पीवीसी है।

अन्य कवरेज मानदंड

आगे कवरेज मानदंड हैं, जिनका उपयोग कम बार किया जाता है:

रैखिक कोड अनुक्रम और जम्प (एलसीएसएजे) कवरेज या जेजे-पथ कवरेज – क्या प्रत्येक एलसीएसएजे/जेजे-पथ निष्पादित किया गया है?^[9]
पथ कवरेज – क्या कोड के किसी दिए गए हिस्से के माध्यम से हर संभव मार्ग निष्पादित किया गया है?
प्रवेश/निकास कवरेज – क्या हर संभव कॉल और फ़ंक्शन की वापसी निष्पादित की गई है?
लूप कवरेज – क्या हर संभव लूप को शून्य बार, एक बार और एक से अधिक बार निष्पादित किया गया है?
स्थिति कवरेज – क्या परिमित-स्थिति मशीन में प्रत्येक स्थिति तक पहुँचा और खोजा गया है?
डेटा प्रवाह कवरेज – क्या प्रत्येक परिवर्तनशील परिभाषा और उसके उपयोग तक पहुँच गया है और उसका पता लगाया गया है?^[10]

सुरक्षा-महत्वपूर्ण या भरोसेमंद अनुप्रयोगों को सामान्यतः परीक्षण कवरेज के किसी न किसी रूप का 100% प्रदर्शित करने की आवश्यकता होती है। उदाहरण के लिए, ईसीएसएस-ई-एसटी -40 सी मानक चार अलग-अलग महत्वपूर्ण स्तरों में से दो के लिए 100% विवरण और निर्णय कवरेज की मांग करता है; अन्य के लिए, लक्ष्य कवरेज मूल्य आपूर्तिकर्ता और ग्राहक के बीच बातचीत के लिए हैं।^[11] चूंकि, विशिष्ट लक्ष्य मान सेट करना - और, विशेष रूप से, 100% विभिन्न कारणों से चिकित्सकों द्वारा इसकी आलोचना की गई है (cf^[12]) मार्टिन फाउलर लिखते हैं: "मुझे 100% जैसी किसी भी चीज़ पर संदेह होगा - यह कवरेज नंबरों को खुश करने के लिए परीक्षण लिखने वाले किसी व्यक्ति की गंध करेगा, लेकिन यह नहीं सोचते कि वे क्या कर रहे हैं"।^[13]

ऊपर दिए गए कुछ कवरेज मानदंड जुड़े हुए हैं। उदाहरण के लिए, पथ कवरेज का तात्पर्य निर्णय, कथन और प्रवेश/निकास कवरेज से है। निर्णय कवरेज का तात्पर्य स्टेटमेंट कवरेज से है, क्योंकि हर स्टेटमेंट एक शाखा का हिस्सा होता है।

ऊपर वर्णित प्रकार का पूर्ण पथ कवरेज, सामान्यतः पर अव्यावहारिक या असंभव है। $n$ निर्णयों के अनुक्रम वाले किसी भी मॉड्यूल में अधिकतम $2^{n}$ पथ हो सकते हैं; लूप निर्माण के परिणामस्वरूप अनंत पथ हो सकते हैं।

कई पथ भी अक्षम हो सकते हैं, जिसमें परीक्षण के तहत कार्यक्रम में कोई इनपुट नहीं है जिससे उस विशेष पथ को निष्पादित किया जा सके। चूंकि, अव्यवहार्य पथों की पहचान के लिए एक सामान्य-उद्देश्य एल्गोरिथ्म असंभव साबित हुआ है (इस तरह के एक एल्गोरिथ्म को रोकने की समस्या को हल करने के लिए इस्तेमाल किया जा सकता है)।^[14] उदाहरण के लिए आधार पथ परीक्षण पूर्ण पथ कवरेज प्राप्त किए बिना पूर्ण शाखा कवरेज प्राप्त करने की एक विधि है।^[15] व्यावहारिक पथ कवरेज परीक्षण के तरीके इसके बजाय कोड पथ के वर्गों की पहचान करने का प्रयास करते हैं जो केवल लूप निष्पादन की संख्या में भिन्न होता है, और "आधार पथ" कवरेज प्राप्त करने के लिए परीक्षक को सभी पथ वर्गों को कवर करना होगा।^{[citation needed]}^{[clarification needed]}

व्यवहार में

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

एक सॉफ्टवेयर विकास वातावरण के भीतर परीक्षण कवरेज नीतियों को लागू करने में, निम्नलिखित पर विचार करना चाहिए:

अंतिम उत्पाद प्रमाणन के लिए कवरेज आवश्यकताएं क्या हैं और यदि हां, तो किस स्तर के परीक्षण कवरेज की आवश्यकता है? कठोर प्रगति का विशिष्ट स्तर इस प्रकार है: विवरण, शाखा/निर्णय, संशोधित स्थिति/निर्णय कवरेज (एमसी/डीसी), एलसीएसएजे (रैखिक कोड अनुक्रम और जम्प)
क्या परीक्षण के तहत सिस्टम पर लगाए गए आवश्यकताओं को सत्यापित करने वाले परीक्षणों ( डीओ-178B) के आधार पर कवरेज को मापा जाएगा?
क्या उत्पन्न किया गया ऑब्जेक्ट कोड सीधे सोर्स कोड स्टेटमेंट के लिए ट्रेस करने योग्य है? कुछ प्रमाणपत्र, (अर्थात डीओ-178B स्तर A) को असेंबली स्तर पर कवरेज की आवश्यकता होती है यदि ऐसा नहीं है: फिर, इस तरह के उत्पन्न कोड अनुक्रमों (डीओ-178B) पैरा की शुद्धता को स्थापित करने के लिए ऑब्जेक्ट कोड पर अतिरिक्त सत्यापन किया जाना चाहिए। -6.4.4.2।^[16]

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

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

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

अधिकांश पेशेवर सॉफ्टवेयर डेवलपर C1 और C2 कवरेज का उपयोग करते हैं। C1 स्टेटमेंट कवरेज के लिए है और C2 ब्रांच या कंडीशन कवरेज के लिए है। C1 और C2 के संयोजन के साथ, कोड बेस में अधिकांश स्टेटमेंट को कवर करना संभव है। स्टेटमेंट कवरेज में एंट्री और एक्जिट, लूप, पाथ, स्टेट फ्लो, कंट्रोल फ्लो और डेटा फ्लो कवरेज के साथ फंक्शन कवरेज भी शामिल होगा। इन विधियों के साथ, अधिकांश सॉफ्टवेयर परियोजनाओं में लगभग 100% कोड कवरेज प्राप्त करना संभव है।^[17]

उद्योग में उपयोग

एवियोनिक्स उपकरण के सुरक्षा प्रमाणन में परीक्षण कवरेज एक विचार है। संघीय विमानन प्रशासन (FAA) द्वारा एवियोनिक्स गियर को प्रमाणित करने वाले दिशानिर्देश डीओ -178सी^[16] और डीओ-178सी में प्रलेखित हैं।^[18]

ऑटोमोटिव सुरक्षा मानक आईएसओ 26262 सड़क वाहन - कार्यात्मक सुरक्षा के भाग 6 में परीक्षण कवरेज भी एक आवश्यकता है।^[19]

यह भी देखें

संदर्भ

↑ Brader, Larry; Hilliker, Howie; Wills, Alan (March 2, 2013). "Chapter 2 Unit Testing: Testing the Inside". Testing for Continuous Delivery with Visual Studio 2012. Microsoft. p. 30. ISBN 1621140180. Retrieved 16 June 2016.
↑ Williams, Laurie; Smith, Ben; Heckman, Sarah. "Test Coverage with EclEmma". Open Seminar Software Engineering. North Carolina State University. Archived from the original on 14 March 2016. Retrieved 16 June 2016.
↑ Joan C. Miller, Clifford J. Maloney (February 1963). "Systematic mistake analysis of digital computer programs". Communications of the ACM. New York, NY, USA: ACM. 6 (2): 58–63. doi:10.1145/366246.366248. ISSN 0001-0782.
↑ Paul Ammann, Jeff Offutt (2013). Introduction to Software Testing. Cambridge University Press.
↑ Glenford J. Myers (2004). The Art of Software Testing, 2nd edition. Wiley. ISBN 0-471-46912-2.
↑ Position Paper CAST-10 (June 2002). What is a "Decision" in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)?
↑ MathWorks. Types of Model Coverage.
↑ "Unit Testing with Parameter Value Coverage (PVC)".
↑ एम. आर. वुडवर्ड, एम. ए. हेनेल, दो नियंत्रण-प्रवाह कवरेज मानदंडों के बीच संबंध पर: सभी जेजे-पथ और एमसीडीसी, सूचना और सॉफ्टवेयर प्रौद्योगिकी 48 (2006) पीपी. 433-440
↑ Ting Su, Ke Wu, Weikai Miao, Geguang Pu, Jifeng He, Yuting Chen, and Zhendong Su. "A Survey on Data-Flow Testing". ACM Comput. Surv. 50, 1, Article 5 (March 2017), 35 pages.
↑ ECSS-E-ST-40C: Space engineering - Software. ECSS Secretariat, ESA-ESTEC. March, 2009
↑ C. Prause, J. Werner, K. Hornig, S. Bosecker, M. Kuhrmann (2017): Is 100% Test Coverage a Reasonable Requirement? Lessons Learned from a Space Software Project. In: PROFES 2017. Springer. Last accessed: 2017-11-17
↑ Martin Fowler's blog: TestCoverage. Last accessed: 2017-11-17
↑ Dorf, Richard C.: Computers, Software Engineering, and Digital Devices, Chapter 12, pg. 15. CRC Press, 2006. ISBN 0-8493-7340-9, ISBN 978-0-8493-7340-4; via Google Book Search
↑ Y.N. Srikant; Priti Shankar (2002). The Compiler Design Handbook: Optimizations and Machine Code Generation. CRC Press. p. 249. ISBN 978-1-4200-4057-9.
↑ ^16.0 ^16.1 RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, December 1, 1992
↑ Boris beizer (2009). Software testing techniques, 2nd edition. Dreamtech press. ISBN 978-81-7722-260-9.
↑ RTCA/DO-178C, Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, January, 2012.
↑ ISO 26262-6:2011(en) Road vehicles -- Functional safety -- Part 6: Product development at the software level. International Standardization Organization.

==

[Brader,_2013-1] Brader, Larry; Hilliker, Howie; Wills, Alan (March 2, 2013). "Chapter 2 Unit Testing: Testing the Inside". Testing for Continuous Delivery with Visual Studio 2012. Microsoft. p. 30. ISBN 1621140180. Retrieved 16 June 2016.

[Williams_2003-2] Williams, Laurie; Smith, Ben; Heckman, Sarah. "Test Coverage with EclEmma". Open Seminar Software Engineering. North Carolina State University. Archived from the original on 14 March 2016. Retrieved 16 June 2016.

[3] Joan C. Miller, Clifford J. Maloney (February 1963). "Systematic mistake analysis of digital computer programs". Communications of the ACM. New York, NY, USA: ACM. 6 (2): 58–63. doi:10.1145/366246.366248. ISSN 0001-0782.

[4] Paul Ammann, Jeff Offutt (2013). Introduction to Software Testing. Cambridge University Press.

[5] Glenford J. Myers (2004). The Art of Software Testing, 2nd edition. Wiley. ISBN 0-471-46912-2.

[Position_Paper_CAST10-6] Position Paper CAST-10 (June 2002). What is a "Decision" in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)?

[mathworks-7] MathWorks. Types of Model Coverage.

[8] "Unit Testing with Parameter Value Coverage (PVC)".

[On_the_relationship_between_two_control-flow_coverage_criteria:_all_JJ-paths_and_MCDC-9] एम. आर. वुडवर्ड, एम. ए. हेनेल, दो नियंत्रण-प्रवाह कवरेज मानदंडों के बीच संबंध पर: सभी जेजे-पथ और एमसीडीसी, सूचना और सॉफ्टवेयर प्रौद्योगिकी 48 (2006) पीपी. 433-440

[A_Survey_on_Data-Flow_Testing-10] Ting Su, Ke Wu, Weikai Miao, Geguang Pu, Jifeng He, Yuting Chen, and Zhendong Su. "A Survey on Data-Flow Testing". ACM Comput. Surv. 50, 1, Article 5 (March 2017), 35 pages.

[ECSS-E-ST-40C-11] ECSS-E-ST-40C: Space engineering - Software. ECSS Secretariat, ESA-ESTEC. March, 2009

[is_100_percent_reasonable-12] C. Prause, J. Werner, K. Hornig, S. Bosecker, M. Kuhrmann (2017): Is 100% Test Coverage a Reasonable Requirement? Lessons Learned from a Space Software Project. In: PROFES 2017. Springer. Last accessed: 2017-11-17

[fowler_blog-13] Martin Fowler's blog: TestCoverage. Last accessed: 2017-11-17

[14] Dorf, Richard C.: Computers, Software Engineering, and Digital Devices, Chapter 12, pg. 15. CRC Press, 2006. ISBN 0-8493-7340-9, ISBN 978-0-8493-7340-4; via Google Book Search

[SrikantShankar2002-15] Y.N. Srikant; Priti Shankar (2002). The Compiler Design Handbook: Optimizations and Machine Code Generation. CRC Press. p. 249. ISBN 978-1-4200-4057-9.

[DO-178B-16] 16.0 ^16.1 RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, December 1, 1992

[17] Boris beizer (2009). Software testing techniques, 2nd edition. Dreamtech press. ISBN 978-81-7722-260-9.

[DO-178C-18] RTCA/DO-178C, Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, January, 2012.

[ISO26262part6-19] ISO 26262-6:2011(en) Road vehicles -- Functional safety -- Part 6: Product development at the software level. International Standardization Organization.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

@@ Line 1: / Line 1: @@
 {{Short description|Metric for source code testing}}
 {{Program execution}}
-[[ कंप्यूटर विज्ञान ]]में, परीक्षण कवरेज उस डिग्री का प्रतिशत माप लेता है उन तक किसी विशेष [[ परीक्षण सूट |परीक्षण सूट]] को चलाने पर [[ कंप्यूटर प्रोग्राम |कंप्यूटर प्रोग्राम]] का स्रोत कोड निष्पादित किया जाता है। उच्च परीक्षण कवरेज वाले प्रोग्राम में परीक्षण के दौरान अधिक स्रोत कोड निष्पादित होता है, जो बताता है कि कम परीक्षण कवरेज वाले प्रोग्राम की तुलना में इसमें ज्ञात [[ सॉफ्टवेयर बग |सॉफ्टवेयर बग]] होने की संभावना कम होती है।<ref name="Brader, 2013" /><ref name="Williams 2003" /> परीक्षण कवरेज की गणना के लिए कई अलग-अलग मीट्रिक का उपयोग किया जा सकता है।और कुछ सबसे बुनियादी कार्यक्रम [[ सबरूटीन |सबरूटीन]] ्स का प्रतिशत और प्रोग्राम स्टेटमेंट (कंप्यूटर साइंस) का प्रतिशत है जिसे टेस्ट सूट के निष्पादन के दौरान कहा जाता है
+[[कंप्यूटर विज्ञान]] में, परीक्षण कवरेज डिग्री का एक प्रतिशत माप है जिस पर प्रोग्राम का सोर्स कोड निष्पादित किया जाता है जब एक विशेष [[परीक्षण सूट]] चलाया जाता है। उच्च परीक्षण कवरेज वाले प्रोग्राम में परीक्षण के दौरान इसके अधिक स्रोत कोड निष्पादित होते हैं, जो यह सुझाव देता है कि कम परीक्षण कवरेज वाले प्रोग्राम की तुलना में इसमें अज्ञात सॉफ़्टवेयर बग होने की संभावना कम होती है।<ref name="Brader, 2013">{{cite book|last1=Brader|first1=Larry|last2=Hilliker|first2=Howie|last3=Wills|first3=Alan|title=Testing for Continuous Delivery with Visual Studio 2012|date=March 2, 2013|publisher=Microsoft|isbn=1621140180|page=30|url=https://msdn.microsoft.com/en-us/library/jj159344.aspx|access-date=16 June 2016|chapter=Chapter 2 Unit Testing: Testing the Inside}}</ref><ref name="Williams 2003">{{cite web|last1=Williams|first1=Laurie|author1-link=Laurie Williams (software engineer)|last2=Smith|first2=Ben|last3=Heckman|first3=Sarah|title=Test Coverage with EclEmma|url=http://realsearchgroup.org/SEMaterials/tutorials/eclemma|website=Open Seminar Software Engineering|publisher=North Carolina State University|access-date=16 June 2016|archive-url=https://web.archive.org/web/20160314023040/http://realsearchgroup.org/SEMaterials/tutorials/eclemma/|archive-date=14 March 2016|url-status=dead}}</ref> परीक्षण कवरेज की गणना के लिए कई अलग-अलग मीट्रिक का उपयोग किया जा सकता है। कुछ सबसे बुनियादी कार्यक्रम [[सबरूटीन्स]] का प्रतिशत और परीक्षण सूट के निष्पादन के दौरान बुलाए गए प्रोग्राम स्टेटमेंट का प्रतिशत हैं।
-<ref name="Brader, 2013">{{cite book|last1=Brader|first1=Larry|last2=Hilliker|first2=Howie|last3=Wills|first3=Alan|title=Testing for Continuous Delivery with Visual Studio 2012|date=March 2, 2013|publisher=Microsoft|isbn=1621140180|page=30|url=https://msdn.microsoft.com/en-us/library/jj159344.aspx|access-date=16 June 2016|chapter=Chapter 2 Unit Testing: Testing the Inside}}</ref><ref name="Williams 2003">{{cite web|last1=Williams|first1=Laurie|author1-link=Laurie Williams (software engineer)|last2=Smith|first2=Ben|last3=Heckman|first3=Sarah|title=Test Coverage with EclEmma|url=http://realsearchgroup.org/SEMaterials/tutorials/eclemma|website=Open Seminar Software Engineering|publisher=North Carolina State University|access-date=16 June 2016|archive-url=https://web.archive.org/web/20160314023040/http://realsearchgroup.org/SEMaterials/tutorials/eclemma/|archive-date=14 March 2016|url-status=dead}}</ref> परीक्षण कवरेज की गणना के लिए कई अलग-अलग मीट्रिक का उपयोग किया जा सकता है। सबसे बुनियादी में से कुछ प्रोग्राम [[ सबरूटीन | सबरूटीन]] ्स का प्रतिशत और प्रोग्राम स्टेटमेंट (कंप्यूटर साइंस) का प्रतिशत है जिसे टेस्ट सूट के निष्पादन के दौरान कहा जाता है।
 टेस्ट कवरेज व्यवस्थित सॉफ्टवेयर परीक्षण के लिए आविष्कार किए गए पहले तरीकों में से एक था। पहला प्रकाशित संदर्भ मिलर और मैलोनी द्वारा 1963 में एसीएम के संचार में था।<ref>{{cite journal
@@ Line 18: / Line 16: @@
   | doi          = 10.1145/366246.366248
 }}</ref>
 == कवरेज मानदंड ==
-यह मापने के लिए कि परीक्षण सूट द्वारा कितने प्रतिशत कोड निष्पादित किया गया है, एक या अधिक कवरेज मानदंड का उपयोग किया जाता है। इन्हें आमतौर पर नियमों या आवश्यकताओं के रूप में परिभाषित किया जाता है, जिन्हें एक परीक्षण सूट को पूरा करना चाहिए।<ref>{{cite book | author=Paul Ammann, Jeff Offutt | title=Introduction to Software Testing |publisher=Cambridge University Press| year=2013}}</ref>
+यह मापने के लिए कि परीक्षण सूट द्वारा कितने प्रतिशत कोड निष्पादित किया गया है, एक या अधिक कवरेज मानदंड का उपयोग किया जाता है। इन्हें सामान्यतः नियमों या आवश्यकताओं के रूप में परिभाषित किया जाता है, जिन्हें एक परीक्षण सूट को पूरा करना चाहिए।<ref>{{cite book | author=Paul Ammann, Jeff Offutt | title=Introduction to Software Testing |publisher=Cambridge University Press| year=2013}}</ref>
 === बुनियादी कवरेज मानदंड ===
 कई कवरेज मानदंड हैं, लेकिन मुख्य हैं:<ref>{{cite book | author=Glenford J. Myers | title=The Art of Software Testing, 2nd edition |publisher=Wiley | year=2004| isbn=0-471-46912-2}}</ref>
-*फंक्शन कवरेज{{snd}}क्या कार्यक्रम में प्रत्येक फ़ंक्शन (या सबरूटीन) को बुलाया गया है?
+*फंक्शन कवरेज – क्या कार्यक्रम में प्रत्येक कार्य (या सबरूटीन) को बुलाया जाता है?
-*स्टेटमेंट कवरेज{{snd}}क्या कार्यक्रम में प्रत्येक कथन (कंप्यूटर विज्ञान) को क्रियान्वित किया गया है?
+*स्टेटमेंट कवरेज – क्या कार्यक्रम में प्रत्येक कथन (कंप्यूटर विज्ञान) को क्रियान्वित किया जाता है?
-* एज कवरेज{{snd}}क्या [[ नियंत्रण-प्रवाह ग्राफ ]] में प्रत्येक [[ ग्राफ सिद्धांत ]] को क्रियान्वित किया गया है?
+* एज कवरेज – क्या [[ नियंत्रण-प्रवाह ग्राफ]] में प्रत्येक [[ ग्राफ सिद्धांत|ग्राफ सिद्धांत]] को क्रियान्वित किया जाता है?
-**शाखा कवरेज{{snd}}क्या प्रत्येक नियंत्रण संरचना (जैसे सशर्त (प्रोग्रामिंग) में) की प्रत्येक शाखा (जिसे [[ डीडी-पथ ]] भी कहा जाता है) को निष्पादित किया गया है? उदाहरण के लिए, यदि एक कथन दिया गया है, तो क्या सही और गलत दोनों शाखाओं को निष्पादित किया गया है? (यह एज कवरेज का सबसेट है'।')
+**शाखा कवरेज – इसमें प्रत्येक नियंत्रण संरचना की प्रत्येक शाखा (जिसे [[डीडी-पथ]] भी कहा जाता है) को निष्पादित किया गया है (जैसे कि इफ (if) और केस (case) स्टेटमेंट में)? उदाहरण के लिए, यदि एक कथन दिया गया है, तो क्या सही और गलत दोनों शाखाओं को निष्पादित किया गया है? (यह एज कवरेज का सबसेट है।)
-* 'हालत कवरेज'{{snd}}क्या प्रत्येक बूलियन उप-अभिव्यक्ति का मूल्यांकन सही और गलत दोनों के लिए किया गया है? (इसे विधेय कवरेज भी कहा जाता है।)
+* 'क्या प्रत्येक बूलियन उप-अभिव्यक्ति का मूल्यांकन सही और गलत दोनों के लिए किया गया है? (इसे विधेय कवरेज भी कहा जाता है।)
-उदाहरण के लिए, निम्नलिखित [[ सी (प्रोग्रामिंग भाषा) ]] फ़ंक्शन पर विचार करें:
+उदाहरण के लिए, निम्नलिखित [[ सी (प्रोग्रामिंग भाषा) | सी (प्रोग्रामिंग भाषा) कार्यो]] पर विचार करें:
-<वाक्यविन्यास हाइलाइट लैंग = सीपीपी>
+   int foo (int x, int y)
-इंट फू (इंट एक्स, इंट वाई)
-{
+ {
-    इंट जेड = 0;
+     int z = 0;
-    अगर ((x > 0) && (y > 0))
+     if ((x > 0) && (y > 0))
-    {
+     {
-        जेड = एक्स;
+         z = x;
-    }
+     }
-    वापसी जेड;
+     return z;
+ }
 }
-</वाक्यविन्यास हाइलाइट>
 मान लें कि यह फ़ंक्शन किसी बड़े प्रोग्राम का हिस्सा है और यह प्रोग्राम कुछ टेस्ट सूट के साथ चलाया गया था।
-* फ़ंक्शन कवरेज संतुष्ट होगा यदि, इस निष्पादन के दौरान, फ़ंक्शन <code>foo</code> कम से कम एक बार बुलाया गया था।
+* फ़ंक्शन कवरेज संतुष्ट होगा यदि, इस निष्पादन के दौरान, फ़ंक्शन फू को कम से कम एक बार कॉल किया गया था।
-* इस फ़ंक्शन के लिए स्टेटमेंट कवरेज संतुष्ट होगा यदि इसे उदाहरण के लिए कहा जाता है: <code>foo(1,1)</code>, क्योंकि इस मामले में, फ़ंक्शन में प्रत्येक पंक्ति को निष्पादित किया जाएगा-सहित <code>z = x;</code>.
+* इस फ़ंक्शन के लिए स्टेटमेंट में कवरेज संतुष्ट होगा तो यदि इसे उदाहरण के लिए कहा जाता है: <code>foo(1,1)</code>, क्योंकि इस मामले में, फ़ंक्शन में प्रत्येक पंक्ति को निष्पादित किया जाएगा-सहित <code>z = x;</code>.
 * परीक्षण कॉल करने से शाखा कवरेज संतुष्ट होगी <code>foo(1,1)</code> तथा <code>foo(0,1)</code> क्योंकि, पहले मामले में, दोनों <code>if</code> शर्तें पूरी होती हैं और <code>z = x;</code> निष्पादित किया जाता है, जबकि दूसरे मामले में, पहली शर्त, <code>(x>0)</code>, संतुष्ट नहीं है, जो के निष्पादन को रोकता है <code>z = x;</code>.
-* कंडीशन कवरेज कॉल करने वाले परीक्षणों से संतुष्ट होगा <code>foo(1,0)</code>, <code>foo(0,1)</code>, तथा <code>foo(1,1)</code>. ये आवश्यक हैं क्योंकि पहले मामलों में, <code>(x>0)</code> का मूल्यांकन किया जाता है <code>true</code>, जबकि दूसरे में, इसका मूल्यांकन किया जाता है <code>false</code>. वहीं, पहला मामला बनता है <code>(y>0)</code> <code>false</code>, दूसरा मामला मूल्यांकन नहीं करता <code>(y>0)</code> (बूलियन ऑपरेटर के आलसी मूल्यांकन के कारण), तीसरा मामला इसे बनाता है <code>true</code>.
+* कंडीशन कवरेज कॉल करने वाले परीक्षणों से संतुष्ट होगा <code>foo(1,0)</code>, <code>foo(0,1)</code>, तथा <code>foo(1,1)</code>. ये आवश्यक हैं क्योंकि पहले मामलों में, <code>(x>0)</code> का मूल्यांकन किया जाता है <code>true</code>, जबकि दूसरे में, इसका मूल्यांकन किया जाता है <code>false</code>. वहीं, पहला मामला बनता है <code>(y>0)</code> <code>false</code>, दूसरा मामला मूल्यांकन नहीं करता है, <code>(y>0)</code> (बूलियन ऑपरेटर के आलसी मूल्यांकन के कारण),इसे तीसरा मामला बनाता है <code>true</code>.
 शर्त कवरेज अनिवार्य रूप से शाखा कवरेज का संकेत नहीं देता है। उदाहरण के लिए, निम्नलिखित कोड खंड पर विचार करें:
 <वाक्यविन्यास हाइलाइट लैंग = पास्कल>
-अगर ए और बी तो
+if a and b then
 </वाक्यविन्यास हाइलाइट>
 कंडीशन कवरेज को दो परीक्षणों से संतुष्ट किया जा सकता है:
 * <code>a=true</code>, <code>b=false</code>
-* <code>a=false</code>, <code>b=true</code>
+* <code>a=false</code>, <code>b=true</code><br />चूँकि, परीक्षणों का यह सेट शाखा कवरेज को संतुष्ट नहीं करता है क्योंकि कोई भी स्थिति निम्नलिखित  <code>if</code> स्थि‍ति को पूरा नहीं करेगी।
-हालाँकि, परीक्षणों का यह सेट शाखा कवरेज को संतुष्ट नहीं करता है क्योंकि कोई भी मामला निम्नलिखित को पूरा नहीं करेगा <code>if</code> स्थि‍ति।
+फॉल्ट इंजेक्शन यह सुनिश्चित करने के लिए आवश्यक हो सकता है कि परीक्षण के दौरान अपवाद-हैंडलिंग कोड की सभी स्थितियों और शाखाओं में पर्याप्त कवरेज हो।
-[[ दोष इंजेक्शन ]] यह सुनिश्चित करने के लिए आवश्यक हो सकता है कि सभी स्थितियों और अपवाद हैंडलिंग की शाखाओं | अपवाद-हैंडलिंग कोड में परीक्षण के दौरान पर्याप्त कवरेज हो।
+=== संशोधित स्थिति/निर्णय कवरेज ===
+{{Main|संशोधित शर्त/निर्णय कवरेज}}
-=== संशोधित स्थिति/निर्णय कवरेज ===
+फ़ंक्शन कवरेज और शाखा कवरेज के संयोजन को कभी-कभी निर्णय कवरेज भी कहा जाता है। इस मानदंड की आवश्यकता है कि कार्यक्रम में [[प्रवेश और निकास के प्रत्येक बिंदु]] को कम से कम एक बार लागू किया गया हो, और कार्यक्रम में हर निर्णय कम से कम एक बार सभी संभावित परिणामों पर लिया गया है। इस संदर्भ में, निर्णय एक बूलियन अभिव्यक्ति है जिसमें कंडीशन और शून्य या अधिक [[बूलियन ऑपरेटर]] शामिल हैं। यह परिभाषा शाखा कवरेज के समान नहीं है,<ref name="Position Paper CAST10">Position Paper CAST-10 (June 2002). ''[http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-10.pdf What is a "Decision" in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)?]''</ref>  चूँकि, निर्णय कवरेज शब्द को कभी-कभी इसके पर्याय के रूप में प्रयोग किया जाता है।<ref name="mathworks">MathWorks. ''[http://www.mathworks.com/help/slvnv/ug/types-of-model-coverage.html Types of Model Coverage.''<nowiki/>'']''</ref>
-{{Main|Modified Condition/Decision Coverage}}
-फ़ंक्शन कवरेज और शाखा कवरेज के संयोजन को कभी-कभी निर्णय कवरेज भी कहा जाता है। इस मानदंड की आवश्यकता है कि कार्यक्रम में प्रत्येक [[ प्रवेश और निकास बिंदु ]]ओं को कम से कम एक बार लागू किया गया है, और कार्यक्रम में प्रत्येक निर्णय कम से कम एक बार सभी संभावित परिणामों पर लिया गया है। इस संदर्भ में, निर्णय एक [[ बूलियन अभिव्यक्ति ]] है जिसमें शर्तें और शून्य या अधिक बूलियन ऑपरेटर शामिल हैं। यह परिभाषा शाखा कवरेज के समान नहीं है,<ref name ="Position Paper CAST10">Position Paper CAST-10 (June 2002). ''[http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-10.pdf What is a "Decision" in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)?]''</ref> हालाँकि, निर्णय कवरेज शब्द को कभी-कभी इसके पर्यायवाची के रूप में उपयोग किया जाता है।<ref name="mathworks">MathWorks. ''[http://www.mathworks.com/help/slvnv/ug/types-of-model-coverage.html Types of Model Coverage.'']</ref>
+शर्त/निर्णय कवरेज के लिए आवश्यक है कि निर्णय और शर्त कवरेज दोनों संतुष्ट हों। चूँकि, सुरक्षा-महत्वपूर्ण अनुप्रयोगों (जैसे [[एवियोनिक्स सॉफ़्टवेयर]]) के लिए अक्सर यह आवश्यक होता है कि संशोधित स्थिति/निर्णय कवरेज (MC/DC) संतुष्ट हो। यह मानदंड आवश्यकताओं के साथ शर्त/निर्णय मानदंड का विस्तार करता है कि प्रत्येक शर्त स्वतंत्र रूप से निर्णय के परिणाम को प्रभावित करे।
-शर्त/निर्णय कवरेज के लिए आवश्यक है कि निर्णय और शर्त कवरेज दोनों संतुष्ट हों। हालांकि, सुरक्षा-महत्वपूर्ण अनुप्रयोगों (जैसे [[ एवियोनिक्स सॉफ्टवेयर ]]) के लिए अक्सर यह आवश्यक होता है कि संशोधित स्थिति/निर्णय कवरेज (एमसी/डीसी) संतुष्ट हो। यह मानदंड शर्तों/निर्णय मानदंड को आवश्यकताओं के साथ विस्तारित करता है कि प्रत्येक शर्त स्वतंत्र रूप से निर्णय परिणाम को प्रभावित करे।
-उदाहरण के लिए, निम्नलिखित कोड पर विचार करें:
+उदाहरण के लिए, निम्नलिखित कोड पर विचार करने पर: <वाक्यविन्यास हाइलाइट लैंग = पास्कल> अगर (A या बB) और C तो </वाक्यविन्यास हाइलाइट> निम्नलिखित परीक्षणों के सेट से शर्त/निर्णय मानदंड संतुष्ट होंगे:
-<वाक्यविन्यास हाइलाइट लैंग = पास्कल>
+* A = True, B = True, C = True
-अगर (ए या बी) और सी तो
+* A = False, B = False, C = False
-</वाक्यविन्यास हाइलाइट>
+चूंकि, उपरोक्त परीक्षण सेट संशोधित स्थिति/निर्णय कवरेज को संतुष्ट नहीं करेंगे, क्योंकि पहले परीक्षण में, 'B' का मान और दूसरे परीक्षण में 'सी' का मान आउटपुट को प्रभावित नहीं करेगा। तो, एमसी/डीसी को संतुष्ट करने के लिए निम्नलिखित परीक्षण सेट की आवश्यकता होती है:
-निम्नलिखित परीक्षणों के सेट से शर्त/निर्णय मानदंड संतुष्ट होंगे:
+* A = False, B = True, C = False
-* ए = सच, बी = सच, सी = सच
+* A = False, B = True, C = True
-* ए = झूठा, बी = झूठा, सी = झूठा
+* A = False, B = False, C = True
-हालांकि, उपरोक्त परीक्षण सेट संशोधित स्थिति/निर्णय कवरेज को संतुष्ट नहीं करेंगे, क्योंकि पहले परीक्षण में, 'बी' का मान और दूसरे परीक्षण में 'सी' का मान आउटपुट को प्रभावित नहीं करेगा। तो, एमसी/डीसी को संतुष्ट करने के लिए निम्नलिखित परीक्षण सेट की आवश्यकता है:
+* A = True, B = False, C = True
-* ए = झूठा, बी = सच, सी = झूठा
-* ए = झूठा, बी = सच, सी = सच
-* ए = झूठा, बी = झूठा, सी = सच
-* ए = सच, बी = झूठा, सी = सच
-=== एकाधिक शर्त कवरेज ===
+=== एकाधिक कंडीशन कवरेज ===
 इस मानदंड के लिए आवश्यक है कि प्रत्येक निर्णय के भीतर स्थितियों के सभी संयोजनों का परीक्षण किया जाए। उदाहरण के लिए, पिछले खंड के कोड खंड के लिए आठ परीक्षणों की आवश्यकता होगी:
-* ए = झूठा, बी = झूठा, सी = झूठा
+* A = False, B = False, C = False
-* ए = झूठा, बी = झूठा, सी = सच
+* A = False, B = False, C = True
-* ए = झूठा, बी = सच, सी = झूठा
+* A = False, B = True, C = False
-* ए = झूठा, बी = सच, सी = सच
+* A = False, B = True, C = True
-* ए = सच, बी = झूठा, सी = झूठा
+* A = True, B = False, C = False
-* ए = सच, बी = झूठा, सी = सच
+* A = True, B = False, C = True
-* ए = सच, बी = सच, सी = गलत
+* A = True, B = True, C = False
-* ए = सच, बी = सच, सी = सच
+* A = True, B = True, C = True
 === पैरामीटर मान कवरेज ===
-पैरामीटर वैल्यू कवरेज (पीवीसी) के लिए आवश्यक है कि पैरामीटर लेने वाली विधि में, ऐसे पैरामीटर के लिए सभी सामान्य मानों पर विचार किया जाए। विचार यह है कि पैरामीटर के लिए सभी सामान्य संभावित मानों का परीक्षण किया जाता है।<ref>{{cite web| url = http://www.rhyous.com/2012/05/08/unit-testing-with-parameter-value-coverage-pvc/| title = Unit Testing with Parameter Value Coverage (PVC)}}</ref> उदाहरण के लिए, एक स्ट्रिंग के लिए सामान्य मान हैं: 1) [[ शून्य वस्तु ]], 2) खाली, 3) व्हाइटस्पेस (स्पेस, टैब्स, न्यूलाइन), 4) वैध स्ट्रिंग, 5) अमान्य स्ट्रिंग, 6) सिंगल-बाइट स्ट्रिंग, 7) डबल -बाइट स्ट्रिंग। बहुत लंबे तारों का उपयोग करना भी उपयुक्त हो सकता है। प्रत्येक संभावित पैरामीटर मान का परीक्षण करने में विफलता के परिणामस्वरूप एक बग हो सकता है। इनमें से केवल एक के परीक्षण के परिणामस्वरूप 100% कोड कवरेज हो सकता है क्योंकि प्रत्येक पंक्ति को कवर किया गया है, लेकिन जैसा कि सात विकल्पों में से केवल एक का परीक्षण किया जाता है, केवल 14.2% पीवीसी है।
+पैरामीटर वैल्यू कवरेज (पीवीसी) के लिए आवश्यक है कि पैरामीटर लेने वाली विधि में, ऐसे मापदंडों के लिए सभी सामान्य मूल्यों पर विचार किया जाना चाहिए। विचार यह है कि एक पैरामीटर के लिए सभी सामान्य संभावित मानों का परीक्षण किया जाता है।<ref>{{cite web| url = http://www.rhyous.com/2012/05/08/unit-testing-with-parameter-value-coverage-pvc/| title = Unit Testing with Parameter Value Coverage (PVC)}}</ref> उदाहरण के लिए, एक स्ट्रिंग के लिए सामान्य मान हैं: 1) नल, 2) खाली, 3) व्हाइटस्पेस (स्पेस, टैब्स, न्यूलाइन), 4) वैध स्ट्रिंग, 5) अमान्य स्ट्रिंग, 6) सिंगल-बाइट स्ट्रिंग, 7) डबल- बाइट स्ट्रिंग। बहुत लंबे तारों का उपयोग करना भी उपयुक्त हो सकता है। प्रत्येक संभावित पैरामीटर मान का परीक्षण करने में विफलता के परिणामस्वरूप एक बग हो सकता है। इनमें से केवल एक के परीक्षण के परिणामस्वरूप 100% कोड कवरेज हो सकता है क्योंकि प्रत्येक पंक्ति को कवर किया जाता है, लेकिन जैसा कि सात विकल्पों में से केवल एक का परीक्षण किया जाता है, केवल 14.2% पीवीसी है।
 === अन्य कवरेज मानदंड ===
 आगे कवरेज मानदंड हैं, जिनका उपयोग कम बार किया जाता है:
-* [[ रैखिक कोड अनुक्रम और कूद ]] (एलसीएसएजे) कवरेज उर्फ जेजे-पथ कवरेज{{snd}} क्या प्रत्येक एलसीएसएजे/जेजे-पथ निष्पादित किया गया है?<ref name="On the relationship between two control-flow coverage criteria: all JJ-paths and MCDC">एम. आर. वुडवर्ड, एम. ए. हेनेल, दो नियंत्रण-प्रवाह कवरेज मानदंडों के बीच संबंध पर: सभी जेजे-पथ और एमसीडीसी, सूचना और सॉफ्टवेयर प्रौद्योगिकी 48 (2006) पीपी. 433-440</ref>
+* [[ रैखिक कोड अनुक्रम और कूद | रैखिक कोड अनुक्रम और जम्प]]  (एलसीएसएजे) कवरेज या जेजे-पथ कवरेज{{snd}} क्या प्रत्येक एलसीएसएजे/जेजे-पथ निष्पादित किया गया है?<ref name="On the relationship between two control-flow coverage criteria: all JJ-paths and MCDC">एम. आर. वुडवर्ड, एम. ए. हेनेल, दो नियंत्रण-प्रवाह कवरेज मानदंडों के बीच संबंध पर: सभी जेजे-पथ और एमसीडीसी, सूचना और सॉफ्टवेयर प्रौद्योगिकी 48 (2006) पीपी. 433-440</ref>
 *पथ कवरेज{{snd}}क्या कोड के किसी दिए गए हिस्से के माध्यम से हर संभव मार्ग निष्पादित किया गया है?
 *प्रवेश/निकास कवरेज{{snd}}क्या हर संभव कॉल और फ़ंक्शन की वापसी निष्पादित की गई है?
 *लूप कवरेज{{snd}}क्या हर संभव लूप को शून्य बार, एक बार और एक से अधिक बार निष्पादित किया गया है?
-*राज्य कवरेज{{snd}}क्या परिमित-राज्य मशीन में प्रत्येक राज्य तक पहुँचा और खोजा गया है?
+*स्थिति कवरेज{{snd}}क्या परिमित-स्थिति मशीन में प्रत्येक स्थिति तक पहुँचा और खोजा गया है?
 * डेटा प्रवाह कवरेज{{snd}}क्या प्रत्येक परिवर्तनशील परिभाषा और उसके उपयोग तक पहुँच गया है और उसका पता लगाया गया है?<ref name="A Survey on Data-Flow Testing">Ting Su, Ke Wu, Weikai Miao, Geguang Pu, Jifeng He, Yuting Chen, and Zhendong Su. "A Survey on Data-Flow Testing". ACM Comput. Surv. 50, 1, Article 5 (March 2017), 35 pages.</ref>
-सुरक्षा-महत्वपूर्ण या [[ निर्भरता ]] अनुप्रयोगों को अक्सर परीक्षण कवरेज के किसी न किसी रूप का 100% प्रदर्शित करने की आवश्यकता होती है।
+सुरक्षा-महत्वपूर्ण या भरोसेमंद अनुप्रयोगों को सामान्यतः परीक्षण कवरेज के किसी न किसी रूप का 100% प्रदर्शित करने की आवश्यकता होती है। उदाहरण के लिए, [[ईसीएसएस-ई-एसटी]] -40 सी मानक चार अलग-अलग महत्वपूर्ण स्तरों में से दो के लिए 100% विवरण और निर्णय कवरेज की मांग करता है; अन्य के लिए, लक्ष्य कवरेज मूल्य आपूर्तिकर्ता और ग्राहक के बीच बातचीत के लिए हैं।<ref name="ECSS-E-ST-40C">ECSS-E-ST-40C: Space engineering - Software. ECSS Secretariat, ESA-ESTEC. March, 2009</ref> चूंकि, विशिष्ट लक्ष्य मान सेट करना - और, विशेष रूप से, 100% विभिन्न कारणों से चिकित्सकों द्वारा इसकी आलोचना की गई है (cf<ref name="is 100 percent reasonable">C. Prause, J. Werner, K. Hornig, S. Bosecker, M. Kuhrmann (2017): ''[https://www.researchgate.net/profile/Marco_Kuhrmann/publication/319141355_Is_100_Test_Coverage_a_Reasonable_Requirement_Lessons_Learned_from_a_Space_Software_Project/links/599467faaca272ec9087f82a/Is-100-Test-Coverage-a-Reasonable-Requirement-Lessons-Learned-from-a-Space-Software-Project.pdf Is 100% Test Coverage a Reasonable Requirement? Lessons Learned from a Space Software Project]''. In: PROFES 2017. Springer. Last accessed: 2017-11-17</ref>) मार्टिन फाउलर लिखते हैं: "मुझे 100% जैसी किसी भी चीज़ पर संदेह होगा - यह कवरेज नंबरों को खुश करने के लिए परीक्षण लिखने वाले किसी व्यक्ति की गंध करेगा, लेकिन यह नहीं सोचते कि वे क्या कर रहे हैं"।<ref name="fowler blog">Martin Fowler's blog: [https://martinfowler.com/bliki/TestCoverage.html TestCoverage.] Last accessed: 2017-11-17</ref>
-उदाहरण के लिए, [[ अंतरिक्ष मानकीकरण के लिए यूरोपीय सहयोग ]]-ई-एसटी -40 सी मानक चार अलग-अलग महत्वपूर्ण स्तरों में से दो के लिए 100% विवरण और निर्णय कवरेज की मांग करता है; अन्य के लिए, लक्ष्य कवरेज मूल्य आपूर्तिकर्ता और ग्राहक के बीच बातचीत तक हैं।<ref name="ECSS-E-ST-40C">ECSS-E-ST-40C: Space engineering - Software. ECSS Secretariat, ESA-ESTEC. March, 2009</ref>
-हालांकि, विशिष्ट लक्ष्य मान निर्धारित करना - और, विशेष रूप से, 100% - की विभिन्न कारणों से चिकित्सकों द्वारा आलोचना की गई है (cf.<ref name="is 100 percent reasonable">C. Prause, J. Werner, K. Hornig, S. Bosecker, M. Kuhrmann (2017): ''[https://www.researchgate.net/profile/Marco_Kuhrmann/publication/319141355_Is_100_Test_Coverage_a_Reasonable_Requirement_Lessons_Learned_from_a_Space_Software_Project/links/599467faaca272ec9087f82a/Is-100-Test-Coverage-a-Reasonable-Requirement-Lessons-Learned-from-a-Space-Software-Project.pdf Is 100% Test Coverage a Reasonable Requirement? Lessons Learned from a Space Software Project]''. In: PROFES 2017. Springer. Last accessed: 2017-11-17</ref>)
-[[ मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर) ]] लिखते हैं: मुझे 100% जैसी किसी भी चीज़ पर संदेह होगा - यह कवरेज संख्या को खुश करने के लिए परीक्षण लिखने वाले किसी व्यक्ति की गंध होगी, लेकिन यह नहीं सोच रहा कि वे क्या कर रहे हैं।<ref name="fowler blog">Martin Fowler's blog: [https://martinfowler.com/bliki/TestCoverage.html TestCoverage.] Last accessed: 2017-11-17</ref>
 ऊपर दिए गए कुछ कवरेज मानदंड जुड़े हुए हैं। उदाहरण के लिए, पथ कवरेज का तात्पर्य निर्णय, कथन और प्रवेश/निकास कवरेज से है। निर्णय कवरेज का तात्पर्य स्टेटमेंट कवरेज से है, क्योंकि हर स्टेटमेंट एक शाखा का हिस्सा होता है।
-ऊपर वर्णित प्रकार का पूर्ण पथ कवरेज, आमतौर पर अव्यावहारिक या असंभव है। के उत्तराधिकार के साथ कोई भी मॉड्यूल <math>n</math> इसमें निर्णय तक हो सकते हैं <math>2^n</math> इसके भीतर पथ; लूप निर्माण के परिणामस्वरूप अनंत पथ हो सकते हैं। कई पथ भी अक्षम हो सकते हैं, जिसमें परीक्षण के तहत कार्यक्रम में कोई इनपुट नहीं है जिससे उस विशेष पथ को निष्पादित किया जा सके। हालांकि, अव्यवहार्य पथों की पहचान करने के लिए एक सामान्य-उद्देश्य एल्गोरिथ्म असंभव साबित हुआ है (इस तरह के एक एल्गोरिथ्म को रोकने की समस्या को हल करने के लिए इस्तेमाल किया जा सकता है)।<ref>Dorf, Richard C.: ''Computers, Software Engineering, and Digital Devices'', Chapter 12, pg. 15. CRC Press, 2006. {{ISBN|0-8493-7340-9}}, {{ISBN|978-0-8493-7340-4}}; via [https://books.google.com/books?id=jykvlTCoksMC&pg=PT386&lpg=PT386&dq=%22infeasible+path%22+%22halting+problem%22&source=web&ots=WUWz3qMPRv&sig=dSAjrLHBSZJcKWZfGa_IxYlfSNA&hl=en&sa=X&oi=book_result&resnum=1&ct=result Google Book Search]</ref> उदाहरण के लिए [[ आधार पथ परीक्षण ]] पूर्ण पथ कवरेज प्राप्त किए बिना पूर्ण शाखा कवरेज प्राप्त करने की एक विधि है।<ref name="SrikantShankar2002">{{cite book|author1=Y.N. Srikant|author2=Priti Shankar|title=The Compiler Design Handbook: Optimizations and Machine Code Generation|year=2002|publisher=CRC Press|isbn=978-1-4200-4057-9|page=249}}</ref>
+ऊपर वर्णित प्रकार का पूर्ण पथ कवरेज, सामान्यतः पर अव्यावहारिक या असंभव है। <math>n</math> निर्णयों के अनुक्रम वाले किसी भी मॉड्यूल में अधिकतम <math>2^n</math> पथ हो सकते हैं; लूप निर्माण के परिणामस्वरूप अनंत पथ हो सकते हैं।
-व्यावहारिक पथ कवरेज परीक्षण के तरीके इसके बजाय कोड पथों के वर्गों की पहचान करने का प्रयास करते हैं जो केवल लूप निष्पादन की संख्या में भिन्न होते हैं, और आधार पथ कवरेज प्राप्त करने के लिए परीक्षक को सभी पथ वर्गों को कवर करना होगा।{{citation needed|date=July 2014}}{{clarify|date=July 2014}}
+कई पथ भी अक्षम हो सकते हैं, जिसमें परीक्षण के तहत कार्यक्रम में कोई इनपुट नहीं है जिससे उस विशेष पथ को निष्पादित किया जा सके। चूंकि, अव्यवहार्य पथों की पहचान के लिए एक सामान्य-उद्देश्य एल्गोरिथ्म असंभव साबित हुआ है (इस तरह के एक एल्गोरिथ्म को रोकने की समस्या को हल करने के लिए इस्तेमाल किया जा सकता है)।<ref>Dorf, Richard C.: ''Computers, Software Engineering, and Digital Devices'', Chapter 12, pg. 15. CRC Press, 2006. {{ISBN|0-8493-7340-9}}, {{ISBN|978-0-8493-7340-4}}; via [https://books.google.com/books?id=jykvlTCoksMC&pg=PT386&lpg=PT386&dq=%22infeasible+path%22+%22halting+problem%22&source=web&ots=WUWz3qMPRv&sig=dSAjrLHBSZJcKWZfGa_IxYlfSNA&hl=en&sa=X&oi=book_result&resnum=1&ct=result Google Book Search]</ref> उदाहरण के लिए [[आधार पथ परीक्षण]] पूर्ण पथ कवरेज प्राप्त किए बिना पूर्ण शाखा कवरेज प्राप्त करने की एक विधि है।<ref name="SrikantShankar2002">{{cite book|author1=Y.N. Srikant|author2=Priti Shankar|title=The Compiler Design Handbook: Optimizations and Machine Code Generation|year=2002|publisher=CRC Press|isbn=978-1-4200-4057-9|page=249}}</ref> व्यावहारिक पथ कवरेज परीक्षण के तरीके इसके बजाय कोड पथ के वर्गों की पहचान करने का प्रयास करते हैं जो केवल लूप निष्पादन की संख्या में भिन्न होता है, और "आधार पथ" कवरेज प्राप्त करने के लिए परीक्षक को सभी पथ वर्गों को कवर करना होगा।{{citation needed|date=July 2014}}{{clarify|date=July 2014}}
 == व्यवहार में ==
-{{more citations needed section|date=February 2015}}लक्ष्य सॉफ्टवेयर विशेष विकल्पों या पुस्तकालयों के साथ बनाया गया है और एक नियंत्रित वातावरण के तहत चलाया जाता है, ताकि प्रत्येक निष्पादित फ़ंक्शन को स्रोत कोड में फ़ंक्शन बिंदुओं पर मैप किया जा सके। यह लक्ष्य सॉफ़्टवेयर के उन हिस्सों का परीक्षण करने की अनुमति देता है जिन्हें सामान्य परिस्थितियों में शायद ही कभी या कभी भी एक्सेस नहीं किया जाता है, और यह आश्वस्त करने में मदद करता है कि सबसे महत्वपूर्ण स्थितियों (फ़ंक्शन पॉइंट्स) का परीक्षण किया गया है। परिणामी आउटपुट का विश्लेषण यह देखने के लिए किया जाता है कि कोड के किन क्षेत्रों का प्रयोग नहीं किया गया है और इन क्षेत्रों को आवश्यकतानुसार शामिल करने के लिए परीक्षणों को अद्यतन किया जाता है। अन्य परीक्षण कवरेज विधियों के साथ संयुक्त, उद्देश्य एक कठोर, फिर भी प्रबंधनीय, प्रतिगमन परीक्षणों का सेट विकसित करना है।
+{{more citations needed section|date=February 2015}}
+लक्ष्य सॉफ्टवेयर विशेष विकल्पों या पुस्तकालयों के साथ बनाया गया है और एक नियंत्रित वातावरण के तहत चलाया जाता है, ताकि प्रत्येक निष्पादित फ़ंक्शन को स्रोत कोड में फ़ंक्शन बिंदुओं पर मैप किया जा सके। यह लक्ष्य सॉफ़्टवेयर के उन हिस्सों का परीक्षण करने की अनुमति देता है जिन्हें सामान्य परिस्थितियों में शायद ही कभी या कभी भी एक्सेस नहीं किया जाता है, और यह आश्वस्त करने में मदद करता है कि सबसे महत्वपूर्ण स्थितियों (फ़ंक्शन पॉइंट्स) का परीक्षण किया गया है। परिणामी आउटपुट का विश्लेषण यह देखने के लिए किया जाता है कि कोड के किन क्षेत्रों का प्रयोग नहीं किया गया है और आवश्यकतानुसार इन क्षेत्रों को शामिल करने के लिए परीक्षणों को अद्यतन किया जाता है। अन्य परीक्षण कवरेज विधियों के साथ संयुक्त, उद्देश्य एक कठोर, फिर भी प्रबंधनीय, प्रतिगमन परीक्षणों का सेट विकसित करना है।
 एक सॉफ्टवेयर विकास वातावरण के भीतर परीक्षण कवरेज नीतियों को लागू करने में, निम्नलिखित पर विचार करना चाहिए:
-* अंतिम उत्पाद प्रमाणन के लिए कवरेज आवश्यकताएं क्या हैं और यदि हां, तो किस स्तर के परीक्षण कवरेज की आवश्यकता है? कठोर प्रगति का विशिष्ट स्तर इस प्रकार है: विवरण, शाखा/निर्णय, संशोधित स्थिति/निर्णय कवरेज (एमसी/डीसी), एलसीएसएजे (रैखिक कोड अनुक्रम और कूद)
+* अंतिम उत्पाद प्रमाणन के लिए कवरेज आवश्यकताएं क्या हैं और यदि हां, तो किस स्तर के परीक्षण कवरेज की आवश्यकता है? कठोर प्रगति का विशिष्ट स्तर इस प्रकार है: विवरण, शाखा/निर्णय, संशोधित स्थिति/निर्णय कवरेज (एमसी/डीसी), एलसीएसएजे (रैखिक कोड अनुक्रम और जम्प)
-* क्या परीक्षण के तहत सिस्टम पर लगाए गए आवश्यकताओं को सत्यापित करने वाले परीक्षणों ([[ डीओ-178B ]]ी) के आधार पर कवरेज को मापा जाएगा?
+* क्या परीक्षण के तहत सिस्टम पर लगाए गए आवश्यकताओं को सत्यापित करने वाले परीक्षणों ([[ डीओ-178B | डीओ-178B]]) के आधार पर कवरेज को मापा जाएगा?
-* क्या उत्पन्न किया गया ऑब्जेक्ट कोड सीधे सोर्स कोड स्टेटमेंट के लिए ट्रेस करने योग्य है? कुछ प्रमाणपत्र, (अर्थात डीओ-178बी स्तर ए) को असेंबली स्तर पर कवरेज की आवश्यकता होती है यदि ऐसा नहीं है: फिर, इस तरह के उत्पन्न कोड अनुक्रमों (डीओ-178बी) पैरा की शुद्धता को स्थापित करने के लिए ऑब्जेक्ट कोड पर अतिरिक्त सत्यापन किया जाना चाहिए। -6.4.4.2।<ref name="DO-178B" />
+* क्या उत्पन्न किया गया ऑब्जेक्ट कोड सीधे सोर्स कोड स्टेटमेंट के लिए ट्रेस करने योग्य है? कुछ प्रमाणपत्र, (अर्थात डीओ-178B स्तर A) को असेंबली स्तर पर कवरेज की आवश्यकता होती है यदि ऐसा नहीं है: फिर, इस तरह के उत्पन्न कोड अनुक्रमों (डीओ-178B) पैरा की शुद्धता को स्थापित करने के लिए ऑब्जेक्ट कोड पर अतिरिक्त सत्यापन किया जाना चाहिए। -6.4.4.2।<ref name="DO-178B">RTCA/[[DO-178B]], ''Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics,'' December 1, 1992</ref>
 महत्वपूर्ण कार्यों पर कवरेज बढ़ाने के लिए अतिरिक्त परीक्षण और इनपुट या कॉन्फ़िगरेशन सेट तैयार करने के लिए सॉफ़्टवेयर लेखक परीक्षण कवरेज परिणामों को देख सकते हैं। परीक्षण कवरेज के दो सामान्य रूप हैं स्टेटमेंट (या लाइन) कवरेज और ब्रांच (या एज) कवरेज। परीक्षण के निष्पादन पदचिह्न पर लाइन कवरेज रिपोर्ट जिसके संदर्भ में परीक्षण को पूरा करने के लिए कोड की पंक्तियों को निष्पादित किया गया था। एज कवरेज रिपोर्ट करता है कि परीक्षण पूरा करने के लिए किन शाखाओं या कोड निर्णय बिंदुओं को निष्पादित किया गया था। वे दोनों एक कवरेज मीट्रिक की रिपोर्ट करते हैं, जिसे प्रतिशत के रूप में मापा जाता है। इसका अर्थ इस बात पर निर्भर करता है कि किस प्रकार के कवरेज का उपयोग किया गया है, क्योंकि 67% शाखा कवरेज 67% स्टेटमेंट कवरेज से अधिक व्यापक है।
-आम तौर पर, परीक्षण कवरेज उपकरण वास्तविक कार्यक्रम के अतिरिक्त गणना और लॉगिंग करते हैं जिससे एप्लिकेशन धीमा हो जाता है, इसलिए आमतौर पर यह विश्लेषण उत्पादन में नहीं किया जाता है। जैसा कि कोई उम्मीद कर सकता है, ऐसे सॉफ़्टवेयर के वर्ग हैं जिन्हें इन कवरेज परीक्षणों के अधीन नहीं किया जा सकता है, हालांकि प्रत्यक्ष परीक्षण के बजाय विश्लेषण के माध्यम से कवरेज मैपिंग की एक डिग्री का अनुमान लगाया जा सकता है।
+सामान्यतः परीक्षण कवरेज उपकरण वास्तविक कार्यक्रम के स्थान पर गणना और लॉगिंग करते हैं जिससे आवेदन धीमा हो जाता है, इसलिए सामान्यतः पर यह विश्लेषण उत्पादन में नहीं किया जाता है।  जैसा कि कोई उम्मीद कर सकता है, सॉफ्टवेयर के वर्ग हैं जिसे इन कवरेज परीक्षणों के अधीन नहीं किया जा सकता है, सामान्यतः प्रत्यक्ष परीक्षण की जगह पर विश्लेषण के माध्यम से कवरेज मैपिंग की एक डिग्री का अनुमान लगाया जा सकता है।
-कुछ प्रकार के दोष भी हैं जो ऐसे उपकरणों से प्रभावित होते हैं। विशेष रूप से, कुछ [[ दौड़ की स्थिति ]] या इसी तरह के [[ रीयल-टाइम कंप्यूटिंग ]] संवेदनशील संचालन को परीक्षण वातावरण के तहत चलाए जाने पर मास्क किया जा सकता है; हालांकि इसके विपरीत, परीक्षण कोड के अतिरिक्त ओवरहेड के परिणामस्वरूप इनमें से कुछ दोषों को खोजना आसान हो सकता है।
-अधिकांश पेशेवर सॉफ्टवेयर डेवलपर C1 और C2 कवरेज का उपयोग करते हैं। C1 स्टेटमेंट कवरेज के लिए है और C2 ब्रांच या कंडीशन कवरेज के लिए है। C1 और C2 के संयोजन के साथ, कोड बेस में अधिकांश स्टेटमेंट को कवर करना संभव है। स्टेटमेंट कवरेज में एंट्री और एक्जिट, लूप, पाथ, स्टेट फ्लो, कंट्रोल फ्लो और डेटा फ्लो कवरेज के साथ फंक्शन कवरेज भी शामिल होगा। इन विधियों के साथ, अधिकांश सॉफ्टवेयर परियोजनाओं में लगभग 100% कोड कवरेज प्राप्त करना संभव है।
-<ref>{{cite book | author=Boris beizer | title=Software testing techniques, 2nd edition |publisher=Dreamtech press | year=2009| isbn=978-81-7722-260-9}}</ref>
+कुछ प्रकार के दोष भी हैं जो ऐसे उपकरणों से प्रभावित होते हैं। विशेष रूप से, कुछ [[ दौड़ की स्थिति |दौड़ की स्थिति]] या इसी तरह के [[ रीयल-टाइम कंप्यूटिंग ]] संवेदनशील संचालन को नकाबपोश किया जा सकता है जब परीक्षण वातावरण की जगह पर चलाया जाता है; चूंकि इसके विपरीत, परीक्षण कोड के अतिरिक्त ओवरहेड के परिणामस्वरूप इनमें से कुछ दोषों को खोजना आसान हो सकता है।
+अधिकांश पेशेवर सॉफ्टवेयर डेवलपर C1 और C2 कवरेज का उपयोग करते हैं। C1 स्टेटमेंट कवरेज के लिए है और C2 ब्रांच या कंडीशन कवरेज के लिए है। C1 और C2 के संयोजन के साथ, कोड बेस में अधिकांश स्टेटमेंट को कवर करना संभव है। स्टेटमेंट कवरेज में एंट्री और एक्जिट, लूप, पाथ, स्टेट फ्लो, कंट्रोल फ्लो और डेटा फ्लो कवरेज के साथ फंक्शन कवरेज भी शामिल होगा। इन विधियों के साथ, अधिकांश सॉफ्टवेयर परियोजनाओं में लगभग 100% कोड कवरेज प्राप्त करना संभव है।<ref>{{cite book | author=Boris beizer | title=Software testing techniques, 2nd edition |publisher=Dreamtech press | year=2009| isbn=978-81-7722-260-9}}</ref>
 ==उद्योग में उपयोग ==
-एवियोनिक्स उपकरण के सुरक्षा प्रमाणन में परीक्षण कवरेज एक विचार है। दिशा-निर्देश जिसके द्वारा एवियोनिक्स गियर को [[ संघीय विमानन प्रशासन ]] (FAA) द्वारा प्रमाणित किया जाता है, DO-178B में प्रलेखित है<ref name="DO-178B">RTCA/[[DO-178B]], ''Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics,'' December 1, 1992</ref> और [[ डीओ-178सी ]]।<ref name="DO-178C">RTCA/[[DO-178C]], ''Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics,'' January, 2012.</ref>
+एवियोनिक्स उपकरण के सुरक्षा प्रमाणन में परीक्षण कवरेज एक विचार है। [[ संघीय विमानन प्रशासन |संघीय विमानन प्रशासन]] (FAA) द्वारा एवियोनिक्स गियर को प्रमाणित करने वाले दिशानिर्देश डीओ -178सी<ref name="DO-178B" /> और [[ डीओ-178सी |डीओ-178सी]] में प्रलेखित हैं।<ref name="DO-178C">RTCA/[[DO-178C]], ''Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics,'' January, 2012.</ref>
-ऑटोमोटिव सुरक्षा मानक [[ आईएसओ 26262 ]] सड़क वाहन - कार्यात्मक सुरक्षा के भाग 6 में परीक्षण कवरेज भी एक आवश्यकता है।<ref name="ISO26262part6">{{cite book | title =ISO 26262-6:2011(en)  Road vehicles -- Functional safety -- Part 6: Product development at the software level | publisher =International Standardization Organization | url =http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51362}}</ref>
+ऑटोमोटिव सुरक्षा मानक [[ आईएसओ 26262 |आईएसओ 26262]] सड़क वाहन - कार्यात्मक सुरक्षा के भाग 6 में परीक्षण कवरेज भी एक आवश्यकता है।<ref name="ISO26262part6">{{cite book | title =ISO 26262-6:2011(en)  Road vehicles -- Functional safety -- Part 6: Product development at the software level | publisher =International Standardization Organization | url =http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51362}}</ref>
 ==यह भी देखें==
 * [[ साइक्लोमेटिक कम्पलेक्सिटी ]]
 *[[ बुद्धिमान सत्यापन ]]
-* रैखिक कोड अनुक्रम और कूद
+* रैखिक कोड अनुक्रम और जम्प
 * संशोधित स्थिति/निर्णय कवरेज
 * [[ उत्परिवर्तन परीक्षण ]]
@@ Line 152: / Line 144: @@
 {{reflist}}
-{{DEFAULTSORT:Code Coverage}}[[Category: सॉफ्टवेयर मेट्रिक्स]]
+{{DEFAULTSORT:Code Coverage}}
-[[Category: सॉफ्टवेयर परीक्षण उपकरण]]
 ==
+[[Category:All articles needing additional references|Code Coverage]]
-[[Category: Machine Translated Page]]
+[[Category:All articles with unsourced statements|Code Coverage]]
+[[Category:Articles needing additional references from February 2015|Code Coverage]]
+[[Category:Articles with hatnote templates targeting a nonexistent page|Code Coverage]]
+[[Category:Articles with invalid date parameter in template|Code Coverage]]
+[[Category:Articles with short description|Code Coverage]]
+[[Category:Articles with unsourced statements from July 2014|Code Coverage]]
+[[Category:Machine Translated Page|Code Coverage]]
+[[Category:Short description with empty Wikidata description|Code Coverage]]
+[[Category:Wikipedia articles needing clarification from July 2014|Code Coverage]]
+[[Category:सॉफ्टवेयर परीक्षण उपकरण|Code Coverage]]
+[[Category:सॉफ्टवेयर मेट्रिक्स|Code Coverage]]

Anonymous

Search

कोड कवरेज़: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 21:56, 4 November 2022

Contents

कवरेज मानदंड

बुनियादी कवरेज मानदंड

संशोधित स्थिति/निर्णय कवरेज

एकाधिक कंडीशन कवरेज

पैरामीटर मान कवरेज

अन्य कवरेज मानदंड

व्यवहार में

उद्योग में उपयोग

यह भी देखें

संदर्भ

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

कोड कवरेज़: Difference between revisions

Latest revision as of 21:56, 4 November 2022

कवरेज मानदंड

बुनियादी कवरेज मानदंड

संशोधित स्थिति/निर्णय कवरेज

एकाधिक कंडीशन कवरेज

पैरामीटर मान कवरेज

अन्य कवरेज मानदंड

व्यवहार में

उद्योग में उपयोग

यह भी देखें

संदर्भ

Navigation

Wiki tools

Page tools

Other projects

Categories