कोड कवरेज़: Difference between revisions
(Created page with "{{Short description|Metric for source code testing}} {{Program execution}} कंप्यूटर विज्ञान में, परीक्षण कवरे...") |
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" /><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> परीक्षण कवरेज की गणना के लिए कई अलग-अलग मीट्रिक का उपयोग किया जा सकता है। सबसे बुनियादी में से कुछ प्रोग्राम [[ सबरूटीन | सबरूटीन]] ्स का प्रतिशत और प्रोग्राम स्टेटमेंट (कंप्यूटर साइंस) का प्रतिशत है जिसे टेस्ट सूट के निष्पादन के दौरान कहा जाता है। | |||
टेस्ट कवरेज व्यवस्थित सॉफ्टवेयर परीक्षण के लिए आविष्कार किए गए पहले तरीकों में से एक था। पहला प्रकाशित संदर्भ मिलर और मैलोनी द्वारा 1963 में एसीएम के संचार में था।<ref>{{cite journal | टेस्ट कवरेज व्यवस्थित सॉफ्टवेयर परीक्षण के लिए आविष्कार किए गए पहले तरीकों में से एक था। पहला प्रकाशित संदर्भ मिलर और मैलोनी द्वारा 1963 में एसीएम के संचार में था।<ref>{{cite journal | ||
Revision as of 17:34, 21 October 2022
| कार्यक्रम निष्पादन |
|---|
| सामान्य अवधारणाएँ |
| कोड के प्रकार |
| संकलन रणनीतियाँ |
| उल्लेखनीय रनटाइम्स |
|
| उल्लेखनीय संकलक और टूलचेन |
|
कंप्यूटर विज्ञान में, परीक्षण कवरेज उस डिग्री का प्रतिशत माप लेता है उन तक किसी विशेष परीक्षण सूट को चलाने पर कंप्यूटर प्रोग्राम का स्रोत कोड निष्पादित किया जाता है। उच्च परीक्षण कवरेज वाले प्रोग्राम में परीक्षण के दौरान अधिक स्रोत कोड निष्पादित होता है, जो बताता है कि कम परीक्षण कवरेज वाले प्रोग्राम की तुलना में इसमें ज्ञात सॉफ्टवेयर बग होने की संभावना कम होती है।[1][2] परीक्षण कवरेज की गणना के लिए कई अलग-अलग मीट्रिक का उपयोग किया जा सकता है।और कुछ सबसे बुनियादी कार्यक्रम सबरूटीन ्स का प्रतिशत और प्रोग्राम स्टेटमेंट (कंप्यूटर साइंस) का प्रतिशत है जिसे टेस्ट सूट के निष्पादन के दौरान कहा जाता है
[1][2] परीक्षण कवरेज की गणना के लिए कई अलग-अलग मीट्रिक का उपयोग किया जा सकता है। सबसे बुनियादी में से कुछ प्रोग्राम सबरूटीन ्स का प्रतिशत और प्रोग्राम स्टेटमेंट (कंप्यूटर साइंस) का प्रतिशत है जिसे टेस्ट सूट के निष्पादन के दौरान कहा जाता है।
टेस्ट कवरेज व्यवस्थित सॉफ्टवेयर परीक्षण के लिए आविष्कार किए गए पहले तरीकों में से एक था। पहला प्रकाशित संदर्भ मिलर और मैलोनी द्वारा 1963 में एसीएम के संचार में था।[3]
कवरेज मानदंड
यह मापने के लिए कि परीक्षण सूट द्वारा कितने प्रतिशत कोड निष्पादित किया गया है, एक या अधिक कवरेज मानदंड का उपयोग किया जाता है। इन्हें आमतौर पर नियमों या आवश्यकताओं के रूप में परिभाषित किया जाता है, जिन्हें एक परीक्षण सूट को पूरा करना चाहिए।[4]
बुनियादी कवरेज मानदंड
कई कवरेज मानदंड हैं, लेकिन मुख्य हैं:[5]
- फंक्शन कवरेज – क्या कार्यक्रम में प्रत्येक फ़ंक्शन (या सबरूटीन) को बुलाया गया है?
- स्टेटमेंट कवरेज – क्या कार्यक्रम में प्रत्येक कथन (कंप्यूटर विज्ञान) को क्रियान्वित किया गया है?
- एज कवरेज – क्या नियंत्रण-प्रवाह ग्राफ में प्रत्येक ग्राफ सिद्धांत को क्रियान्वित किया गया है?
- शाखा कवरेज – क्या प्रत्येक नियंत्रण संरचना (जैसे सशर्त (प्रोग्रामिंग) में) की प्रत्येक शाखा (जिसे डीडी-पथ भी कहा जाता है) को निष्पादित किया गया है? उदाहरण के लिए, यदि एक कथन दिया गया है, तो क्या सही और गलत दोनों शाखाओं को निष्पादित किया गया है? (यह एज कवरेज का सबसेट है'।')
- 'हालत कवरेज' – क्या प्रत्येक बूलियन उप-अभिव्यक्ति का मूल्यांकन सही और गलत दोनों के लिए किया गया है? (इसे विधेय कवरेज भी कहा जाता है।)
उदाहरण के लिए, निम्नलिखित सी (प्रोग्रामिंग भाषा) फ़ंक्शन पर विचार करें: <वाक्यविन्यास हाइलाइट लैंग = सीपीपी> इंट फू (इंट एक्स, इंट वाई) {
इंट जेड = 0;
अगर ((x > 0) && (y > 0))
{
जेड = एक्स;
}
वापसी जेड;
} </वाक्यविन्यास हाइलाइट>
मान लें कि यह फ़ंक्शन किसी बड़े प्रोग्राम का हिस्सा है और यह प्रोग्राम कुछ टेस्ट सूट के साथ चलाया गया था।
- फ़ंक्शन कवरेज संतुष्ट होगा यदि, इस निष्पादन के दौरान, फ़ंक्शन
fooकम से कम एक बार बुलाया गया था। - इस फ़ंक्शन के लिए स्टेटमेंट कवरेज संतुष्ट होगा यदि इसे उदाहरण के लिए कहा जाता है:
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.
शर्त कवरेज अनिवार्य रूप से शाखा कवरेज का संकेत नहीं देता है। उदाहरण के लिए, निम्नलिखित कोड खंड पर विचार करें: <वाक्यविन्यास हाइलाइट लैंग = पास्कल> अगर ए और बी तो </वाक्यविन्यास हाइलाइट> कंडीशन कवरेज को दो परीक्षणों से संतुष्ट किया जा सकता है:
a=true,b=falsea=false,b=true
हालाँकि, परीक्षणों का यह सेट शाखा कवरेज को संतुष्ट नहीं करता है क्योंकि कोई भी मामला निम्नलिखित को पूरा नहीं करेगा if स्थिति।
दोष इंजेक्शन यह सुनिश्चित करने के लिए आवश्यक हो सकता है कि सभी स्थितियों और अपवाद हैंडलिंग की शाखाओं | अपवाद-हैंडलिंग कोड में परीक्षण के दौरान पर्याप्त कवरेज हो।
संशोधित स्थिति/निर्णय कवरेज
फ़ंक्शन कवरेज और शाखा कवरेज के संयोजन को कभी-कभी निर्णय कवरेज भी कहा जाता है। इस मानदंड की आवश्यकता है कि कार्यक्रम में प्रत्येक प्रवेश और निकास बिंदु ओं को कम से कम एक बार लागू किया गया है, और कार्यक्रम में प्रत्येक निर्णय कम से कम एक बार सभी संभावित परिणामों पर लिया गया है। इस संदर्भ में, निर्णय एक बूलियन अभिव्यक्ति है जिसमें शर्तें और शून्य या अधिक बूलियन ऑपरेटर शामिल हैं। यह परिभाषा शाखा कवरेज के समान नहीं है,[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]
व्यवहार में
 | This section needs additional citations for verification. (February 2015) (Learn how and when to remove this template message) |
लक्ष्य सॉफ्टवेयर विशेष विकल्पों या पुस्तकालयों के साथ बनाया गया है और एक नियंत्रित वातावरण के तहत चलाया जाता है, ताकि प्रत्येक निष्पादित फ़ंक्शन को स्रोत कोड में फ़ंक्शन बिंदुओं पर मैप किया जा सके। यह लक्ष्य सॉफ़्टवेयर के उन हिस्सों का परीक्षण करने की अनुमति देता है जिन्हें सामान्य परिस्थितियों में शायद ही कभी या कभी भी एक्सेस नहीं किया जाता है, और यह आश्वस्त करने में मदद करता है कि सबसे महत्वपूर्ण स्थितियों (फ़ंक्शन पॉइंट्स) का परीक्षण किया गया है। परिणामी आउटपुट का विश्लेषण यह देखने के लिए किया जाता है कि कोड के किन क्षेत्रों का प्रयोग नहीं किया गया है और इन क्षेत्रों को आवश्यकतानुसार शामिल करने के लिए परीक्षणों को अद्यतन किया जाता है। अन्य परीक्षण कवरेज विधियों के साथ संयुक्त, उद्देश्य एक कठोर, फिर भी प्रबंधनीय, प्रतिगमन परीक्षणों का सेट विकसित करना है।
एक सॉफ्टवेयर विकास वातावरण के भीतर परीक्षण कवरेज नीतियों को लागू करने में, निम्नलिखित पर विचार करना चाहिए:
- अंतिम उत्पाद प्रमाणन के लिए कवरेज आवश्यकताएं क्या हैं और यदि हां, तो किस स्तर के परीक्षण कवरेज की आवश्यकता है? कठोर प्रगति का विशिष्ट स्तर इस प्रकार है: विवरण, शाखा/निर्णय, संशोधित स्थिति/निर्णय कवरेज (एमसी/डीसी), एलसीएसएजे (रैखिक कोड अनुक्रम और कूद)
- क्या परीक्षण के तहत सिस्टम पर लगाए गए आवश्यकताओं को सत्यापित करने वाले परीक्षणों (डीओ-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.0 1.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.0 2.1 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.
==
