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

From Vigyanwiki
m (8 revisions imported from alpha:कोड_कवरेज़)
No edit summary
 
Line 144: Line 144:
{{reflist}}
{{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:Vigyan Ready]]
[[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]]

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 स्थि‍ति को पूरा नहीं करेगी।

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

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

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

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

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

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

कई पथ भी अक्षम हो सकते हैं, जिसमें परीक्षण के तहत कार्यक्रम में कोई इनपुट नहीं है जिससे उस विशेष पथ को निष्पादित किया जा सके। चूंकि, अव्यवहार्य पथों की पहचान के लिए एक सामान्य-उद्देश्य एल्गोरिथ्म असंभव साबित हुआ है (इस तरह के एक एल्गोरिथ्म को रोकने की समस्या को हल करने के लिए इस्तेमाल किया जा सकता है)।[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]

यह भी देखें

संदर्भ

  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=22096’