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

From Vigyanwiki
No edit summary
No edit summary
Line 1: Line 1:
{{Short description|Metric for source code testing}}
{{Short description|Metric for source code testing}}
{{Program execution}}
{{Program execution}}
[[ कंप्यूटर विज्ञान ]]में, परीक्षण कवरेज उस डिग्री का प्रतिशत माप लेता है उन तक किसी विशेष [[ परीक्षण सूट |परीक्षण सूट]] को चलाने पर [[ कंप्यूटर प्रोग्राम |कंप्यूटर प्रोग्राम]] का स्रोत कोड निष्पादित किया जाता है। उच्च परीक्षण कवरेज वाले प्रोग्राम में परीक्षण के दौरान अधिक स्रोत कोड निष्पादित होता है, जो बताता है कि कम परीक्षण कवरेज वाले प्रोग्राम की तुलना में इसमें ज्ञात [[ सॉफ्टवेयर बग |सॉफ्टवेयर बग]] होने की संभावना कम होती है।<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
टेस्ट कवरेज व्यवस्थित सॉफ्टवेयर परीक्षण के लिए आविष्कार किए गए पहले तरीकों में से एक था। पहला प्रकाशित संदर्भ मिलर और मैलोनी द्वारा 1963 में एसीएम के संचार में था।<ref>{{cite journal
  | author      = Joan C. Miller, Clifford J. Maloney
  | author      = Joan C. Miller, Clifford J. Maloney
  | title        = Systematic mistake analysis of digital computer programs
  | title        = Systematic mistake analysis of digital computer programs
Line 17: Line 17:
}}</ref>
}}</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>
कई कवरेज मानदंड हैं, लेकिन मुख्य हैं:<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>
*फंक्शन कवरेज – क्या कार्यक्रम में प्रत्येक कार्य (या सबरूटीन) को बुलाया जाता है?
*फंक्शन कवरेज – क्या कार्यक्रम में प्रत्येक कार्य (या सबरूटीन) को बुलाया जाता है?
*स्टेटमेंट कवरेज – क्या कार्यक्रम में प्रत्येक कथन (कंप्यूटर विज्ञान) को क्रियान्वित किया जाता है?
*स्टेटमेंट कवरेज – क्या कार्यक्रम में प्रत्येक कथन (कंप्यूटर विज्ञान) को क्रियान्वित किया जाता है?
* एज कवरेज – क्या [[ नियंत्रण-प्रवाह ग्राफ]] में प्रत्येक[[ ग्राफ सिद्धांत]] को क्रियान्वित किया जाता है?
* एज कवरेज – क्या [[ नियंत्रण-प्रवाह ग्राफ]] में प्रत्येक[[ ग्राफ सिद्धांत]] को क्रियान्वित किया जाता है?
**शाखा कवरेज – क्या ये प्रत्येक नियंत्रण संरचना (जैसे सशर्त (प्रोग्रामिंग) में) की प्रत्येक शाखा (जिसे [[ डीडी-पथ |डीडी-पथ]] भी कहा जाता है) को निष्पादित किया गया है? उदाहरण के लिए, यदि एक कथन दिया गया है, तो क्या सही और गलत दोनों शाखाओं को निष्पादित किया गया है? (यह एज कवरेज का सबसेट है।)
**शाखा कवरेज – इसमें प्रत्येक नियंत्रण संरचना की प्रत्येक शाखा (जिसे [[डीडी-पथ]] भी कहा जाता है) को निष्पादित किया गया है (जैसे कि इफ (if) और केस (case) स्टेटमेंट में)? उदाहरण के लिए, यदि एक कथन दिया गया है, तो क्या सही और गलत दोनों शाखाओं को निष्पादित किया गया है? (यह एज कवरेज का सबसेट है।)
* 'हालत कवरेज'{{snd}}क्या ये प्रत्येक बूलियन उप-अभिव्यक्ति का मूल्यांकन सही और गलत दोनों के लिए किया गया है? (इसे विधेय कवरेज भी कहा जाता है।)
* 'क्या प्रत्येक बूलियन उप-अभिव्यक्ति का मूल्यांकन सही और गलत दोनों के लिए किया गया है? (इसे विधेय कवरेज भी कहा जाता है।)


उदाहरण के लिए, निम्नलिखित [[ सी (प्रोग्रामिंग भाषा) | सी (प्रोग्रामिंग भाषा) कार्यो]] पर विचार करें:
उदाहरण के लिए, निम्नलिखित [[ सी (प्रोग्रामिंग भाषा) | सी (प्रोग्रामिंग भाषा) कार्यो]] पर विचार करें:
Line 30: Line 32:
इंट फू (इंट एक्स, इंट वाई)
इंट फू (इंट एक्स, इंट वाई)
{
{
    इंट जेड = 0;
  int foo (int x, int y)
    अगर ((x > 0) && (y > 0))
 
    {
{
        जेड = एक्स;
    int z = 0;
    }
    if ((x > 0) && (y > 0))
    वापसी जेड;
    {
        z = x;
    }
    return z;
}
}
}
</वाक्यविन्यास हाइलाइट>


मान लें कि यह फ़ंक्शन किसी बड़े प्रोग्राम का हिस्सा होते  है और यह प्रोग्राम कुछ टेस्ट सूट के साथ चलाया जाता था।
मान लें कि यह फ़ंक्शन किसी बड़े प्रोग्राम का हिस्सा है और यह प्रोग्राम कुछ टेस्ट सूट के साथ चलाया गया था।
* फ़ंक्शन में कवरेज संतुष्ट होगा यदि, इस निष्पादन के दौरान, फ़ंक्शन foo कम से कम एक बार बुलाया गया था।
* फ़ंक्शन कवरेज संतुष्ट होगा यदि, इस निष्पादन के दौरान, फ़ंक्शन फू को कम से कम एक बार कॉल किया गया था।
* इस फ़ंक्शन के लिए स्टेटमेंट में कवरेज संतुष्ट होगा तो यदि इसे उदाहरण के लिए कहा जाता है: <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,1)</code> तथा <code>foo(0,1)</code> क्योंकि, पहले मामले में, दोनों <code>if</code> शर्तें पूरी होती हैं और <code>z = x;</code> निष्पादित किया जाता है, जबकि दूसरे मामले में, पहली शर्त, <code>(x>0)</code>, संतुष्ट नहीं है, जो के निष्पादन को रोकता है <code>z = x;</code>.
Line 46: Line 51:


शर्त कवरेज अनिवार्य रूप से शाखा कवरेज का संकेत नहीं देता है। उदाहरण के लिए, निम्नलिखित कोड खंड पर विचार करें:
शर्त कवरेज अनिवार्य रूप से शाखा कवरेज का संकेत नहीं देता है। उदाहरण के लिए, निम्नलिखित कोड खंड पर विचार करें:
<वाक्यविन्यास हाइलाइट लैंग = पास्कल>
<वाक्यविन्यास हाइलाइट लैंग = पास्कल>
अगर ए और बी तो
 
if a and b then
 
</वाक्यविन्यास हाइलाइट>
</वाक्यविन्यास हाइलाइट>
कंडीशन कवरेज को दो परीक्षणों से संतुष्ट किया जा सकता है:
कंडीशन कवरेज को दो परीक्षणों से संतुष्ट किया जा सकता है:
* <code>a=true</code>, <code>b=false</code>
* <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> स्थि‍ति।
फॉल्ट इंजेक्शन यह सुनिश्चित करने के लिए आवश्यक हो सकता है कि परीक्षण के दौरान अपवाद-हैंडलिंग कोड की सभी स्थितियों और शाखाओं में पर्याप्त कवरेज हो।


=== संशोधित स्थिति/निर्णय कवरेज ===
{{Main|संशोधित शर्त/निर्णय कवरेज}}


हालाँकि, परीक्षणों का यह सेट शाखा कवरेज को संतुष्ट नहीं करता है क्योंकि कोई भी मामला निम्नलिखित को पूरा नहीं करेगा <code>if</code> स्थि‍ति।
फ़ंक्शन कवरेज और शाखा कवरेज के संयोजन को कभी-कभी निर्णय कवरेज भी कहा जाता है। इस मानदंड की आवश्यकता है कि कार्यक्रम में [[प्रवेश और निकास के प्रत्येक बिंदु]] को कम से कम एक बार लागू किया गया हो, और कार्यक्रम में हर निर्णय कम से कम एक बार सभी संभावित परिणामों पर लिया गया है। इस संदर्भ में, निर्णय एक बूलियन अभिव्यक्ति है जिसमें शर्तें और शून्य या अधिक [[बूलियन ऑपरेटर]] शामिल हैं। यह परिभाषा शाखा कवरेज के समान नहीं है,<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.''<nowiki/>'']''</ref>
ये सभी शर्त/निर्णय कवरेज के लिए आवश्यक होती है कि निर्णय और शर्त कवरेज दोनों संतुष्ट हों जाते है । हालांकि, सुरक्षा-महत्वपूर्ण अनुप्रयोगों (जैसे [[ एवियोनिक्स सॉफ्टवेयर |एवियोनिक्स सॉफ्टवेयर]]) के लिए सामान्यतः यह आवश्यक होता है कि संशोधित स्थिति/निर्णय कवरेज (एमसी/डीसी) संतुष्ट होते है। यह मानदंड शर्तों/निर्णय मानदंड को आवश्यकताओं के साथ विस्तारित करता है कि प्रत्येक शर्त स्वतंत्र रूप से निर्णय परिणाम को प्रभावित करते है।


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


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


=== पैरामीटर मान कवरेज ===
=== पैरामीटर मान कवरेज ===
पैरामीटर वैल्यू कवरेज (पीवीसी) के लिए आवश्यक है कि पैरामीटर लेने वाली विधि में, ऐसे पैरामीटर के लिए सभी सामान्य मानों पर विचार किया जाए। विचार यह है कि पैरामीटर के लिए सभी सामान्य संभावित मानों का परीक्षण किया जाता है।<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% पीवीसी है।


=== अन्य कवरेज मानदंड ===
=== अन्य कवरेज मानदंड ===
Line 94: Line 101:
*राज्य कवरेज{{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>
* डेटा प्रवाह कवरेज{{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" />
* क्या उत्पन्न किया गया ऑब्जेक्ट कोड सीधे सोर्स कोड स्टेटमेंट के लिए ट्रेस करने योग्य है? कुछ प्रमाणपत्र, (अर्थात डीओ-178बी स्तर ए) को असेंबली स्तर पर कवरेज की आवश्यकता होती है यदि ऐसा नहीं है: फिर, इस तरह के उत्पन्न कोड अनुक्रमों (डीओ-178बी) पैरा की शुद्धता को स्थापित करने के लिए ऑब्जेक्ट कोड पर अतिरिक्त सत्यापन किया जाना चाहिए। -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% स्टेटमेंट कवरेज से अधिक व्यापक है।
महत्वपूर्ण कार्यों पर कवरेज बढ़ाने के लिए अतिरिक्त परीक्षण और इनपुट या कॉन्फ़िगरेशन सेट तैयार करने के लिए सॉफ़्टवेयर लेखक परीक्षण कवरेज परिणामों को देख सकते हैं। परीक्षण कवरेज के दो सामान्य रूप हैं स्टेटमेंट (या लाइन) कवरेज और ब्रांच (या एज) कवरेज। परीक्षण के निष्पादन पदचिह्न पर लाइन कवरेज रिपोर्ट जिसके संदर्भ में परीक्षण को पूरा करने के लिए कोड की पंक्तियों को निष्पादित किया गया था। एज कवरेज रिपोर्ट करता है कि परीक्षण पूरा करने के लिए किन शाखाओं या कोड निर्णय बिंदुओं को निष्पादित किया गया था। वे दोनों एक कवरेज मीट्रिक की रिपोर्ट करते हैं, जिसे प्रतिशत के रूप में मापा जाता है। इसका अर्थ इस बात पर निर्भर करता है कि किस प्रकार के कवरेज का उपयोग किया गया है, क्योंकि 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) द्वारा एवियोनिक्स गियर को प्रमाणित करने वाले दिशानिर्देश DO-178B<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>
==यह भी देखें==
==यह भी देखें==


Revision as of 00:41, 28 October 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 स्थि‍ति।

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

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

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

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

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

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

  • ए = सच, बी = सच, सी = सच
  • ए = झूठा, बी = झूठा, सी = झूठा

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

  • ए = झूठा, बी = सच, सी = झूठा
  • ए = झूठा, बी = सच, सी = सच
  • ए = झूठा, बी = झूठा, सी = सच
  • ए = सच, बी = झूठा, सी = सच

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

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

  • ए = झूठा, बी = झूठा, सी = झूठा
  • ए = झूठा, बी = झूठा, सी = सच
  • ए = झूठा, बी = सच, सी = झूठा
  • ए = झूठा, बी = सच, सी = सच
  • ए = सच, बी = झूठा, सी = झूठा
  • ए = सच, बी = झूठा, सी = सच
  • ए = सच, बी = सच, सी = गलत
  • ए = सच, बी = सच, सी = सच

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

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

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

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

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

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

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

ऊपर वर्णित प्रकार का पूर्ण पथ कवरेज, आमतौर पर अव्यावहारिक या असंभव है। निर्णयों के अनुक्रम वाले किसी भी मॉड्यूल में अधिकतम पथ हो सकते हैं; लूप निर्माण के परिणामस्वरूप अनंत पथ हो सकते हैं।

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


व्यवहार में

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

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

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

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

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

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

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

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

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

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

यह भी देखें

संदर्भ

  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.
  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.
  6. ↑ Position Paper CAST-10 (June 2002). What is a "Decision" in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)?
  7. ↑ MathWorks. Types of Model Coverage.
  8. ↑ "Unit Testing with Parameter Value Coverage (PVC)".
  9. ↑ एम. आर. वुडवर्ड, एम. ए. हेनेल, दो नियंत्रण-प्रवाह कवरेज मानदंडों के बीच संबंध पर: सभी जेजे-पथ और एमसीडीसी, सूचना और सॉफ्टवेयर प्रौद्योगिकी 48 (2006) पीपी. 433-440
  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.
  11. ↑ ECSS-E-ST-40C: Space engineering - Software. ECSS Secretariat, ESA-ESTEC. March, 2009
  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
  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
  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.
  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.
  18. ↑ RTCA/DO-178C, Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, January, 2012.
  19. ↑ ISO 26262-6:2011(en) Road vehicles -- Functional safety -- Part 6: Product development at the software level. International Standardization Organization.


==

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=कोड_कवरेज़&oldid=21782’