सॉफ्टवेयर बग: Difference between revisions
From Vigyanwiki
| Line 1: | Line 1: | ||
{{Short description|Error, flaw, failure, or fault in a computer program or system}} | {{Short description|Error, flaw, failure, or fault in a computer program or system}} | ||
{{Information security}} | {{Information security}} | ||
सॉफ़्टवेयर बग | '''सॉफ़्टवेयर बग''' कंप्यूटर सॉफ्टवेयर के डिज़ाइन, डेवलोपमेन्ट या संचालन में एक त्रुटि, दोष या दोष (तकनीक) है जिसके कारण यह गलत या अप्रत्याशित परिणाम उत्पन्न करता है, या अनपेक्षित विधि से व्यवहार करता है। बग को खोजने और सुधारने की प्रक्रिया को डिबगिंग कहा जाता है और अधिकांशतः बग को इंगित करने के लिए औपचारिक तकनीकों या उपकरणों का उपयोग किया जाता है। 1950 के दशक के बाद से कुछ कंप्यूटर सिस्टम संचालन के समय विभिन्न कंप्यूटर बगों को रोकने, पहचानने या स्वत। ठीक करने के लिए डिज़ाइन किए गए हैं। | ||
सॉफ़्टवेयर में बग उपयोगकर्ताओं की आवश्यकता को समझने और निकालने में की गई गलतियों और त्रुटियों से उत्पन्न हो सकते हैं, प्रोग्राम के [[सॉफ़्टवेयर वास्तुशिल्प|सॉफ़्टवेयर डिजाइन]] की योजना बना सकते हैं, इसके सोर्स कोड लिख सकते हैं, और [[ऑपरेटिंग सिस्टम]] या [[पुस्तकालय (कम्प्यूटिंग)|लाइब्रेरी (कम्प्यूटिंग)]] जैसे मनुष्यों, हार्डवेयर और प्रोग्राम के साथ बातचीत से उत्पन्न हो सकते हैं। कई या गंभीर बग वाले प्रोग्राम को अधिकांशतः ''बग'' के रूप में वर्णित किया जाता है। बग उन त्रुटियों को ट्रिगर कर सकते हैं जिनके तरंग प्रभाव हो सकते हैं। बग के प्रभाव सूक्ष्म हो सकते हैं, जैसे अनपेक्षित पाठ स्वरूपण, अधिक स्पष्ट प्रभावों के माध्यम से जैसे प्रोग्राम को [[क्रैश (कंप्यूटिंग)]], कंप्यूटर को [[फ्रीज (कंप्यूटिंग)]] करना, या हार्डवेयर को नुकसान पहुंचाना। अन्य बग सुरक्षा बग के रूप में अर्हता प्राप्त करते हैं और उदाहरण के लिए, [[विशेषाधिकार वृद्धि]] के लिए [[पहुँच नियंत्रण|पहुँच नियंत्रण (एक्सेस कंट्रोल)]] को बायपास करने के लिए [[काली टोपी हैकिंग|ब्लैक कैप हैकिंग]] को सक्षम कर सकते हैं।<ref>{{Cite journal|last1=Mittal|first1=Varun|last2=Aditya|first2=Shivam|date=2015-01-01|title=बग फिक्सिंग के क्षेत्र में हालिया विकास|journal=Procedia Computer Science|series=International Conference on Computer, Communication and Convergence (ICCC 2015)|language=en|volume=48|pages=288–297|doi=10.1016/j.procs.2015.04.184|issn=1877-0509|doi-access=free}}</ref> | सॉफ़्टवेयर में बग उपयोगकर्ताओं की आवश्यकता को समझने और निकालने में की गई गलतियों और त्रुटियों से उत्पन्न हो सकते हैं, प्रोग्राम के [[सॉफ़्टवेयर वास्तुशिल्प|सॉफ़्टवेयर डिजाइन]] की योजना बना सकते हैं, इसके सोर्स कोड लिख सकते हैं, और [[ऑपरेटिंग सिस्टम]] या [[पुस्तकालय (कम्प्यूटिंग)|लाइब्रेरी (कम्प्यूटिंग)]] जैसे मनुष्यों, हार्डवेयर और प्रोग्राम के साथ बातचीत से उत्पन्न हो सकते हैं। कई या गंभीर बग वाले प्रोग्राम को अधिकांशतः ''बग'' के रूप में वर्णित किया जाता है। बग उन त्रुटियों को ट्रिगर कर सकते हैं जिनके तरंग प्रभाव हो सकते हैं। बग के प्रभाव सूक्ष्म हो सकते हैं, जैसे अनपेक्षित पाठ स्वरूपण, अधिक स्पष्ट प्रभावों के माध्यम से जैसे प्रोग्राम को [[क्रैश (कंप्यूटिंग)]], कंप्यूटर को [[फ्रीज (कंप्यूटिंग)]] करना, या हार्डवेयर को नुकसान पहुंचाना। अन्य बग सुरक्षा बग के रूप में अर्हता प्राप्त करते हैं और उदाहरण के लिए, [[विशेषाधिकार वृद्धि]] के लिए [[पहुँच नियंत्रण|पहुँच नियंत्रण (एक्सेस कंट्रोल)]] को बायपास करने के लिए [[काली टोपी हैकिंग|ब्लैक कैप हैकिंग]] को सक्षम कर सकते हैं।<ref>{{Cite journal|last1=Mittal|first1=Varun|last2=Aditya|first2=Shivam|date=2015-01-01|title=बग फिक्सिंग के क्षेत्र में हालिया विकास|journal=Procedia Computer Science|series=International Conference on Computer, Communication and Convergence (ICCC 2015)|language=en|volume=48|pages=288–297|doi=10.1016/j.procs.2015.04.184|issn=1877-0509|doi-access=free}}</ref> | ||
| Line 13: | Line 10: | ||
== इतिहास == | == इतिहास == | ||
{{main|बग (इंजीनियरिंग)}} | {{main|बग (इंजीनियरिंग)}} | ||
मध्य अंग्रेजी शब्द wikt।bugge#Noun शब्दों के लिए आधार है wikt।bugbear#Noun और wikt।bug-a-boo#Noun एक राक्षस के लिए प्रयुक्त शब्दों के रूप में।<ref>{{cite web |url= http://www.computerworld.com/article/2515435/app-development/moth-in-the-machine--debugging-the-origins-of--bug-.html |title= मशीन में कीट: 'बग' की उत्पत्ति को डीबग करना|author= Computerworld staff |date= September 3, 2011 |work= Computerworld |url-status= live |archive-url= https://web.archive.org/web/20150825040938/http://www.computerworld.com/article/2515435/app-development/moth-in-the-machine--debugging-the-origins-of--bug-.html |archive-date= August 25, 2015 |df= mdy-all }}</ref> | मध्य अंग्रेजी शब्द wikt।bugge#Noun शब्दों के लिए आधार है wikt।bugbear#Noun और wikt।bug-a-boo#Noun एक राक्षस के लिए प्रयुक्त शब्दों के रूप में।<ref>{{cite web |url= http://www.computerworld.com/article/2515435/app-development/moth-in-the-machine--debugging-the-origins-of--bug-.html |title= मशीन में कीट: 'बग' की उत्पत्ति को डीबग करना|author= Computerworld staff |date= September 3, 2011 |work= Computerworld |url-status= live |archive-url= https://web.archive.org/web/20150825040938/http://www.computerworld.com/article/2515435/app-development/moth-in-the-machine--debugging-the-origins-of--bug-.html |archive-date= August 25, 2015 |df= mdy-all }}</ref> | ||
| Line 41: | Line 39: | ||
=== टंकण त्रुटियाँ === | === टंकण त्रुटियाँ === | ||
बग साधारणतयः तब दिखाई देते हैं जब प्रोग्रामर एक तार्किक त्रुटि करता है। [[प्रोग्रामिंग शैली]] और [[रक्षात्मक प्रोग्रामिंग]] में विभिन्न नवाचारों को इन बगों की संभावना कम करने, या स्पॉट करने में आसान बनाने के लिए डिज़ाइन किया गया है। कुछ टाइपो, विशेष रूप से प्रतीकों या तार्किक/[[ऑपरेटर (गणित)]] के, प्रोग्राम को गलत विधि से संचालित करने की अनुमति देते हैं, जबकि अन्य जैसे लापता प्रतीक या गलत वर्तनी वाले नाम प्रोग्राम को संचालन से रोक सकते हैं। सोर्स कोड संकलित होने पर संकलित | बग साधारणतयः तब दिखाई देते हैं जब प्रोग्रामर एक तार्किक त्रुटि करता है। [[प्रोग्रामिंग शैली]] और [[रक्षात्मक प्रोग्रामिंग]] में विभिन्न नवाचारों को इन बगों की संभावना कम करने, या स्पॉट करने में आसान बनाने के लिए डिज़ाइन किया गया है। कुछ टाइपो, विशेष रूप से प्रतीकों या तार्किक/[[ऑपरेटर (गणित)]] के, प्रोग्राम को गलत विधि से संचालित करने की अनुमति देते हैं, जबकि अन्य जैसे लापता प्रतीक या गलत वर्तनी वाले नाम प्रोग्राम को संचालन से रोक सकते हैं। सोर्स कोड संकलित होने पर संकलित लैंग्वेजएँ कुछ टाइपो प्रकट कर सकती हैं। | ||
=== | === डेवलोपमेन्ट के विधि === | ||
कई योजनाएँ प्रोग्रामर गतिविधि को प्रबंधित करने में सहायता करती हैं जिससे कि कम बग उत्पन्न हों। [[सॉफ्टवेयर इंजीनियरिंग]] (जो सॉफ़्टवेयर डिज़ाइन के मुद्दों को भी संबोधित करती है) दोषों को रोकने के लिए कई विधियों को लागू करती है। उदाहरण के लिए, औपचारिक [[कार्यक्रम विनिर्देश]] कार्यक्रमों के सटीक व्यवहार को बताते हैं जिससे कि डिज़ाइन बग को समाप्त किया जा सके। दुर्भाग्य से, औपचारिक विनिर्देश किसी भी चीज के लिए अव्यावहारिक हैं, लेकिन कम से कम कार्यक्रमों के लिए, दहनशील विस्फोट और गैर-नियतात्मक एल्गोरिदम की समस्याओं के कारण। | कई योजनाएँ प्रोग्रामर गतिविधि को प्रबंधित करने में सहायता करती हैं जिससे कि कम बग उत्पन्न हों। [[सॉफ्टवेयर इंजीनियरिंग]] (जो सॉफ़्टवेयर डिज़ाइन के मुद्दों को भी संबोधित करती है) दोषों को रोकने के लिए कई विधियों को लागू करती है। उदाहरण के लिए, औपचारिक [[कार्यक्रम विनिर्देश]] कार्यक्रमों के सटीक व्यवहार को बताते हैं जिससे कि डिज़ाइन बग को समाप्त किया जा सके। दुर्भाग्य से, औपचारिक विनिर्देश किसी भी चीज के लिए अव्यावहारिक हैं, लेकिन कम से कम कार्यक्रमों के लिए, दहनशील विस्फोट और गैर-नियतात्मक एल्गोरिदम की समस्याओं के कारण। | ||
[[इकाई का परीक्षण]] में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना सम्मलित है जिसे प्रोग्राम को परफॉर्म करना है। | [[इकाई का परीक्षण]] में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना सम्मलित है जिसे प्रोग्राम को परफॉर्म करना है। | ||
परीक्षण-संचालित | परीक्षण-संचालित डेवलोपमेन्ट में इकाई परीक्षण कोड से पहले लिखे जाते हैं और कोड को तब तक पूर्ण नहीं माना जाता जब तक कि सभी परीक्षण सफलतापूर्वक पूर्ण नहीं हो जाते। | ||
अगिल सॉफ्टवेयर डेवलोपमेन्ट में अपेक्षाकृत छोटे बदलावों के साथ लगातार सॉफ्टवेयर रिलीज सम्मलित होते हैं। उपयोगकर्ता प्रतिक्रिया से दोष प्रकट होते हैं। | |||
ओपन सोर्स डेवलपमेंट किसी को भी सोर्स कोड की जांच करने की अनुमति देता है। लिनस के नियम के रूप में एरिक एस. रेमंड द्वारा लोकप्रिय विचार के एक स्कूल का कहना है कि लोकप्रिय ओपन सोर्स सॉफ्टवेयर में अन्य सॉफ़्टवेयर की तुलना में कम या कोई बग नहीं होने की अधिक संभावना है, क्योंकि पर्याप्त नेत्रगोलक दिए जाने पर, सभी बग उथले हैं।<ref>[http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html "Release Early, Release Often"] {{webarchive|url=https://web.archive.org/web/20110514032650/http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html |date=May 14, 2011 }}, [[Eric S. Raymond]], ''[[The Cathedral and the Bazaar]]''</ref> चूंकि, यह दावा विवादित रहा है। कंप्यूटर सुरक्षा विशेषज्ञ [[इलियास लेवी]] ने लिखा है कि जटिल, कम समझ में आने वाले और बिना दस्तावेज वाले सोर्स कोड में कमजोरियों को छिपाना आसान है, क्योंकि भले ही लोग कोड की समीक्षा कर रहे हों, इसका मतलब यह नहीं है कि वे योग्य हैं ऐसा करने के लिए।<ref>[http://www.securityfocus.com/news/19 "Wide Open Source"] {{webarchive|url=https://web.archive.org/web/20070929105937/http://www.securityfocus.com/news/19 |date=September 29, 2007 }}, [[Elias Levy]], ''SecurityFocus'', April 17, 2000</ref> ओपन-सोर्स सॉफ़्टवेयर बग का एक उदाहरण डेबियन 2008 ओपनएसएसएल भेद्यता थी। | ओपन सोर्स डेवलपमेंट किसी को भी सोर्स कोड की जांच करने की अनुमति देता है। लिनस के नियम के रूप में एरिक एस. रेमंड द्वारा लोकप्रिय विचार के एक स्कूल का कहना है कि लोकप्रिय ओपन सोर्स सॉफ्टवेयर में अन्य सॉफ़्टवेयर की तुलना में कम या कोई बग नहीं होने की अधिक संभावना है, क्योंकि पर्याप्त नेत्रगोलक दिए जाने पर, सभी बग उथले हैं।<ref>[http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html "Release Early, Release Often"] {{webarchive|url=https://web.archive.org/web/20110514032650/http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html |date=May 14, 2011 }}, [[Eric S. Raymond]], ''[[The Cathedral and the Bazaar]]''</ref> चूंकि, यह दावा विवादित रहा है। कंप्यूटर सुरक्षा विशेषज्ञ [[इलियास लेवी]] ने लिखा है कि जटिल, कम समझ में आने वाले और बिना दस्तावेज वाले सोर्स कोड में कमजोरियों को छिपाना आसान है, क्योंकि भले ही लोग कोड की समीक्षा कर रहे हों, इसका मतलब यह नहीं है कि वे योग्य हैं ऐसा करने के लिए।<ref>[http://www.securityfocus.com/news/19 "Wide Open Source"] {{webarchive|url=https://web.archive.org/web/20070929105937/http://www.securityfocus.com/news/19 |date=September 29, 2007 }}, [[Elias Levy]], ''SecurityFocus'', April 17, 2000</ref> ओपन-सोर्स सॉफ़्टवेयर बग का एक उदाहरण डेबियन 2008 ओपनएसएसएल भेद्यता थी। | ||
=== [[प्रोग्रामिंग भाषा]] समर्थन === | === [[प्रोग्रामिंग भाषा|प्रोग्रामिंग लैंग्वेज]] समर्थन === | ||
प्रोग्रामिंग लैंग्वेज में बग्स को रोकने में मदद करने के लिए फीचर्स सम्मलित हैं, जैसे स्टैटिक [[प्रकार प्रणाली]], प्रतिबंधित [[नाम स्थान]] और [[मॉड्यूलर प्रोग्रामिंग]] | प्रोग्रामिंग लैंग्वेज में बग्स को रोकने में मदद करने के लिए फीचर्स सम्मलित हैं, जैसे स्टैटिक [[प्रकार प्रणाली]], प्रतिबंधित [[नाम स्थान]] और [[मॉड्यूलर प्रोग्रामिंग]] है। उदाहरण के लिए, जब एक प्रोग्रामर लिखता है ([[स्यूडोकोड]]) <code>LET REAL_VALUE PI = "THREE AND A BIT"</code>, चूंकि यह वाक्यात्मक रूप से सही हो सकता है, कोड एक प्रकार की जाँच में विफल रहता है। संकलित लैंग्वेजएँ प्रोग्राम को चलाए बिना इसे पकड़ लेती हैं। व्याख्या की गई लैंग्वेजएँ रनटाइम पर ऐसी त्रुटियों को पकड़ती हैं। कुछ लैंग्वेजएं धीमी गति से प्रदर्शन की कीमत पर जानबूझकर उन विशेषताओं को बाहर करती हैं जो आसानी से बग की ओर ले जाती हैं। सामान्य सिद्धांत यह है कि, थोड़ा तेज चलने वाले रहस्यमय कोड की तुलना में सरल, धीमा कोड लिखना लगभग हमेशा बेहतर होता है, विशेष रूप से यह देखते हुए कि रखरखाव लागत पर्याप्त है . उदाहरण के लिए, [[जावा (प्रोग्रामिंग भाषा)|जावा (प्रोग्रामिंग लैंग्वेज)]] पॉइंटर (कंप्यूटर प्रोग्रामिंग) अंकगणित का समर्थन नहीं करता है; [[पास्कल (प्रोग्रामिंग भाषा)|पास्कल (प्रोग्रामिंग लैंग्वेज)]] और स्क्रिप्टिंग लैंग्वेजओं जैसी कुछ लैंग्वेजओं के कार्यान्वयन में अधिकांशतः कम से कम डिबगिंग बिल्ड में सरणी की रनटाइम सीमा जांच होती है। | ||
=== कोड विश्लेषण === | === कोड विश्लेषण === | ||
| Line 66: | Line 64: | ||
सॉफ़्टवेयर परीक्षक वे लोग होते हैं जिनका प्राथमिक कार्य बग ढूंढना या परीक्षण का समर्थन करने के लिए कोड लिखना होता है। कुछ परियोजनाओं पर, कार्यक्रम विकसित करने की तुलना में परीक्षण पर अधिक संसाधन खर्च किए जा सकते हैं। | सॉफ़्टवेयर परीक्षक वे लोग होते हैं जिनका प्राथमिक कार्य बग ढूंढना या परीक्षण का समर्थन करने के लिए कोड लिखना होता है। कुछ परियोजनाओं पर, कार्यक्रम विकसित करने की तुलना में परीक्षण पर अधिक संसाधन खर्च किए जा सकते हैं। | ||
परीक्षण के समय माप शेष संभावित बगों की संख्या का अनुमान प्रदान कर सकते हैं; यह अधिक विश्वसनीय हो जाता है क्योंकि किसी उत्पाद का परीक्षण और | परीक्षण के समय माप शेष संभावित बगों की संख्या का अनुमान प्रदान कर सकते हैं; यह अधिक विश्वसनीय हो जाता है क्योंकि किसी उत्पाद का परीक्षण और डेवलोपमेन्ट किया जाता है।{{citation needed|date=February 2017}} | ||
== डिबगिंग == | == डिबगिंग == | ||
| Line 97: | Line 95: | ||
== बग प्रबंधन == | == बग प्रबंधन == | ||
बग प्रबंधन में सही कोड को दस्तावेज करने, वर्गीकृत करने, असाइन करने, पुनरुत्पादित करने, सही करने और जारी करने की प्रक्रिया सम्मलित है। सॉफ़्टवेयर में प्रस्तावित परिवर्तन - बग के साथ-साथ एन्हांसमेंट अनुरोध और यहां तक कि संपूर्ण रिलीज़ - को साधारणतयः [[बग ट्रैकिंग सिस्टम]] या [[ट्रैकिंग प्रणाली जारी करें]] का उपयोग करके ट्रैक और प्रबंधित किया जाता है।<ref>{{cite magazine |last=Allen |first=Mitch |date=May–June 2002 |title=बग ट्रैकिंग मूल बातें: रिपोर्टिंग और ट्रैकिंग दोषों के लिए एक शुरुआती मार्गदर्शिका|magazine=Software Testing & Quality Engineering Magazine |volume=4 |issue=3 |pages=20–24 |url=https://www.stickyminds.com/better-software-magazine/bug-tracking-basics |access-date=December 19, 2017}}</ref> जोड़ी गई वस्तुओं को दोष, टिकट, विवाद, या | बग प्रबंधन में सही कोड को दस्तावेज करने, वर्गीकृत करने, असाइन करने, पुनरुत्पादित करने, सही करने और जारी करने की प्रक्रिया सम्मलित है। सॉफ़्टवेयर में प्रस्तावित परिवर्तन - बग के साथ-साथ एन्हांसमेंट अनुरोध और यहां तक कि संपूर्ण रिलीज़ - को साधारणतयः [[बग ट्रैकिंग सिस्टम]] या [[ट्रैकिंग प्रणाली जारी करें]] का उपयोग करके ट्रैक और प्रबंधित किया जाता है।<ref>{{cite magazine |last=Allen |first=Mitch |date=May–June 2002 |title=बग ट्रैकिंग मूल बातें: रिपोर्टिंग और ट्रैकिंग दोषों के लिए एक शुरुआती मार्गदर्शिका|magazine=Software Testing & Quality Engineering Magazine |volume=4 |issue=3 |pages=20–24 |url=https://www.stickyminds.com/better-software-magazine/bug-tracking-basics |access-date=December 19, 2017}}</ref> जोड़ी गई वस्तुओं को दोष, टिकट, विवाद, या अगिल डेवलोपमेन्ट प्रतिमान, कहानियों और महाकाव्यों के बाद कहा जा सकता है। श्रेणियां वस्तुनिष्ठ, व्यक्तिपरक या एक संयोजन हो सकती हैं, जैसे कि [[संस्करण संख्या]], सॉफ़्टवेयर का क्षेत्र, गंभीरता और प्राथमिकता, साथ ही यह किस प्रकार का मुद्दा है, जैसे कि सुविधा अनुरोध या बग। | ||
एक बग ट्राइएज बग की समीक्षा करता है और यह तय करता है कि उन्हें ठीक करना है या नहीं। निर्णय बग की प्राथमिकता और प्रोजेक्ट शेड्यूल जैसे कारकों पर आधारित है। ट्राइएज बग के कारण की जांच करने के लिए नहीं है, बल्कि उन्हें ठीक करने की लागत के लिए है। ट्राइएज नियमित रूप से होता है, और पिछली मीटिंग के बाद से खोले गए या फिर से खोले गए बग से गुजरता है। ट्राइएज प्रक्रिया के सहभागी साधारणतयः प्रोजेक्ट | एक बग ट्राइएज बग की समीक्षा करता है और यह तय करता है कि उन्हें ठीक करना है या नहीं। निर्णय बग की प्राथमिकता और प्रोजेक्ट शेड्यूल जैसे कारकों पर आधारित है। ट्राइएज बग के कारण की जांच करने के लिए नहीं है, बल्कि उन्हें ठीक करने की लागत के लिए है। ट्राइएज नियमित रूप से होता है, और पिछली मीटिंग के बाद से खोले गए या फिर से खोले गए बग से गुजरता है। ट्राइएज प्रक्रिया के सहभागी साधारणतयः प्रोजेक्ट, टेस्ट मैनेजर, बिल्ड मैनेजर और तकनीकी विशेषज्ञ होते हैं।<ref>{{cite book| url=https://www.google.co.in/books/edition/Managing_The_Testing_Process_2Nd_Ed/XN0izRhGylYC?hl=en&gbpv=1&dq=bug+triage&pg=PA139&printsec=frontcover| title=परीक्षण प्रक्रिया का प्रबंधन (दूसरा संस्करण)| author=Rex Black| date=2002| accessdate=19 June 2021| publisher=Wiley India Pvt. Limited| isbn=9788126503131| page=139}}</ref><ref>{{cite book| url=https://www.google.co.in/books/edition/Shipping_Greatness/BKj-M_FlU_kC?hl=en&gbpv=1&dq=bug+triage&pg=PA80&printsec=frontcover| title=नौवहन महानता - उत्कृष्ट सॉफ़्टवेयर बनाने और लॉन्च करने पर व्यावहारिक पाठ, Google और Amazon पर काम के दौरान सीखे गए| author=Chris Vander Mey| date=24 August 2012| publisher=[[O'Reilly Media]]| isbn=9781449336608| pages=79–81}}</ref> | ||
=== गंभीरता === | === गंभीरता === | ||
गंभीरता सिस्टम संचालन पर बग के प्रभाव की तीव्रता है।<ref>{{Cite journal|last1=Soleimani Neysiani|first1=Behzad|last2=Babamir|first2=Seyed Morteza|last3=Aritsugi|first3=Masayoshi|date=2020-10-01|title=सॉफ़्टवेयर बग ट्राइएज सिस्टम में डुप्लिकेट बग रिपोर्ट डिटेक्शन के सत्यापन प्रदर्शन सुधार के लिए कुशल सुविधा निष्कर्षण मॉडल|url=https://linkinghub.elsevier.com/retrieve/pii/S0950584920301117|journal=Information and Software Technology|language=en|volume=126|pages=106344|doi=10.1016/j.infsof.2020.106344|s2cid=219733047}}</ref> यह प्रभाव डेटा हानि, वित्तीय, सद्भावना की हानि और व्यर्थ प्रयास हो सकता है। गंभीरता का स्तर मानकीकृत नहीं है। प्रभाव उद्योग भर में भिन्न होते हैं। एक वीडियो गेम में क्रैश का प्रभाव वेब ब्राउज़र या रीयल टाइम मॉनिटरिंग सिस्टम में क्रैश की तुलना में बिल्कुल अलग होता है। उदाहरण के लिए, बग की गंभीरता का स्तर क्रैश या हैंग हो सकता है, कोई समाधान नहीं (जिसका अर्थ है कि ग्राहक किसी दिए गए कार्य को पूरा नहीं कर सकता है), समाधान है (जिसका अर्थ है कि उपयोगकर्ता अभी भी कार्य पूरा कर सकता है), दृश्य दोष (उदाहरण के लिए, छवि या विस्थापित बटन या प्रपत्र तत्व), या दस्तावेज़ त्रुटि। कुछ सॉफ्टवेयर प्रकाशक अधिक योग्य गंभीरता का उपयोग करते हैं जैसे कि महत्वपूर्ण, उच्च , निम्न, अवरोधक या तुच्छ।<ref>{{cite web|url=http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|title=5.3। एक बग का एनाटॉमी|work=bugzilla.org|url-status=live|archive-url=https://web.archive.org/web/20130523121753/http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|archive-date=May 23, 2013}}</ref> बग की गंभीरता को ठीक करने के लिए उसकी प्राथमिकता के लिए एक अलग श्रेणी हो सकती है, और दोनों को अलग-अलग परिमाणित और प्रबंधित किया जा सकता है। | गंभीरता सिस्टम संचालन पर बग के प्रभाव की तीव्रता है।<ref>{{Cite journal|last1=Soleimani Neysiani|first1=Behzad|last2=Babamir|first2=Seyed Morteza|last3=Aritsugi|first3=Masayoshi|date=2020-10-01|title=सॉफ़्टवेयर बग ट्राइएज सिस्टम में डुप्लिकेट बग रिपोर्ट डिटेक्शन के सत्यापन प्रदर्शन सुधार के लिए कुशल सुविधा निष्कर्षण मॉडल|url=https://linkinghub.elsevier.com/retrieve/pii/S0950584920301117|journal=Information and Software Technology|language=en|volume=126|pages=106344|doi=10.1016/j.infsof.2020.106344|s2cid=219733047}}</ref> यह प्रभाव डेटा हानि, वित्तीय, सद्भावना की हानि और व्यर्थ प्रयास हो सकता है। गंभीरता का स्तर मानकीकृत नहीं है। प्रभाव उद्योग भर में भिन्न होते हैं। एक वीडियो गेम में क्रैश का प्रभाव वेब ब्राउज़र या रीयल टाइम मॉनिटरिंग सिस्टम में क्रैश की तुलना में बिल्कुल अलग होता है। उदाहरण के लिए, बग की गंभीरता का स्तर क्रैश या हैंग हो सकता है, कोई समाधान नहीं (जिसका अर्थ है कि ग्राहक किसी दिए गए कार्य को पूरा नहीं कर सकता है), समाधान है (जिसका अर्थ है कि उपयोगकर्ता अभी भी कार्य पूरा कर सकता है), दृश्य दोष (उदाहरण के लिए, छवि या विस्थापित बटन या प्रपत्र तत्व), या दस्तावेज़ त्रुटि। कुछ सॉफ्टवेयर प्रकाशक अधिक योग्य गंभीरता का उपयोग करते हैं जैसे कि महत्वपूर्ण, उच्च , निम्न, अवरोधक या तुच्छ।<ref>{{cite web|url=http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|title=5.3। एक बग का एनाटॉमी|work=bugzilla.org|url-status=live|archive-url=https://web.archive.org/web/20130523121753/http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|archive-date=May 23, 2013}}</ref> बग की गंभीरता को ठीक करने के लिए उसकी प्राथमिकता के लिए एक अलग श्रेणी हो सकती है, और दोनों को अलग-अलग परिमाणित और प्रबंधित किया जा सकता है। | ||
| Line 122: | Line 120: | ||
== प्रकार == | == प्रकार == | ||
सॉफ्टवेयर | सॉफ्टवेयर डेवलोपमेन्ट परियोजनाओं में, किसी भी स्तर पर गलती या त्रुटि प्रस्तुत की जा सकती है। विनिर्देश, डिज़ाइन, कोडिंग, कॉन्फ़िगरेशन, डेटा प्रविष्टि या दस्तावेज़ीकरण के समय एक सॉफ़्टवेयर टीम द्वारा निरीक्षण या गलतियों से बग उत्पन्न होते हैं। उदाहरण के लिए, शब्दों की सूची को वर्णानुक्रमित करने के लिए एक अपेक्षाकृत सरल प्रोग्राम, डिज़ाइन इस बात पर विचार करने में विफल हो सकता है कि जब किसी शब्द में [[हैफ़ेन]] होता है तो क्या होना चाहिए। या जब अमूर्त डिजाइन को कोड में परिवर्तित करते हैं, तो कोडर अनजाने में एक-एक त्रुटि बना सकता है जो सूची में अंतिम शब्द को सॉर्ट करने में विफल हो सकता है। | ||
बग की अन्य श्रेणी को रन की स्थिति कहा जाता है जो उसी समय हो सकता है जब प्रोग्राम में कई घटक निष्पादित होते हैं। यदि घटक डेवलपर के अलग क्रम में बातचीत करते हैं, तो वे एक दूसरे के साथ हस्तक्षेप कर सकते हैं और कार्यक्रम को अपने कार्यों को पूरा करने से रोक सकते हैं। इन बगों का पता लगाना या अनुमान लगाना कठिन हो सकता है, क्योंकि वे किसी प्रोग्राम के प्रत्येक निष्पादन के समय नहीं हो सकते हैं। | बग की अन्य श्रेणी को रन की स्थिति कहा जाता है जो उसी समय हो सकता है जब प्रोग्राम में कई घटक निष्पादित होते हैं। यदि घटक डेवलपर के अलग क्रम में बातचीत करते हैं, तो वे एक दूसरे के साथ हस्तक्षेप कर सकते हैं और कार्यक्रम को अपने कार्यों को पूरा करने से रोक सकते हैं। इन बगों का पता लगाना या अनुमान लगाना कठिन हो सकता है, क्योंकि वे किसी प्रोग्राम के प्रत्येक निष्पादन के समय नहीं हो सकते हैं। | ||
| Line 129: | Line 127: | ||
=== अंकगणित === | === अंकगणित === | ||
संख्यात्मक मूल्यों पर संचालन में, समस्याएं उत्पन्न हो सकती हैं जिसके परिणामस्वरूप अप्रत्याशित आउटपुट, प्रक्रिया की धीमी गति या क्रैशिंग हो सकती है।<ref>{{cite web |last1=Di Franco |first1=Anthony |last2=Guo |first2=Hui |last3=Cindy |first3=Rubio-González |title=रीयल-वर्ल्ड न्यूमेरिकल बग विशेषताओं का एक व्यापक अध्ययन|url=https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-date=2022-10-09 |url-status=live}}</ref> ये डेटा स्टोरेज के गुणों के बारे में जागरूकता की कमी से हो सकते हैं जैसे [[गोलाई]], [[संख्यात्मक स्थिरता]] एल्गोरिदम, अंकगणित अतिप्रवाह और अंकगणितीय अंडरफ्लो के कारण अंकगणितीय सटीकता, या विभिन्न सॉफ्टवेयर कोडिंग | संख्यात्मक मूल्यों पर संचालन में, समस्याएं उत्पन्न हो सकती हैं जिसके परिणामस्वरूप अप्रत्याशित आउटपुट, प्रक्रिया की धीमी गति या क्रैशिंग हो सकती है।<ref>{{cite web |last1=Di Franco |first1=Anthony |last2=Guo |first2=Hui |last3=Cindy |first3=Rubio-González |title=रीयल-वर्ल्ड न्यूमेरिकल बग विशेषताओं का एक व्यापक अध्ययन|url=https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://web.cs.ucdavis.edu/~rubio/includes/ase17.pdf |archive-date=2022-10-09 |url-status=live}}</ref> ये डेटा स्टोरेज के गुणों के बारे में जागरूकता की कमी से हो सकते हैं जैसे [[गोलाई]], [[संख्यात्मक स्थिरता]] एल्गोरिदम, अंकगणित अतिप्रवाह और अंकगणितीय अंडरफ्लो के कारण अंकगणितीय सटीकता, या विभिन्न सॉफ्टवेयर कोडिंग लैंग्वेजओं द्वारा गणना इस बारे में जागरूकता की कमी से कैसे की जाती है। शून्य कंप्यूटर अंकगणित द्वारा विभाजन के रूप में जो कुछ लैंग्वेजओं में अपवाद फेंक सकता है, और अन्य में [[NaN]] या इन्फिनिटी कंप्यूटिंग जैसे विशेष मान लौटा सकता है। | ||
=== नियंत्रण प्रवाह === | === नियंत्रण प्रवाह === | ||
| Line 162: | Line 160: | ||
=== सिंटेक्स === | === सिंटेक्स === | ||
{{See also|वाक्य रचना त्रुटि}} | {{See also|वाक्य रचना त्रुटि}} | ||
* गलत लेक्सिकल_विश्लेषण टोकन का उपयोग, जैसे कि समानता के अतिरिक्त असाइनमेंट करना। उदाहरण के लिए, कुछ | * गलत लेक्सिकल_विश्लेषण टोकन का उपयोग, जैसे कि समानता के अतिरिक्त असाइनमेंट करना। उदाहरण के लिए, कुछ लैंग्वेजओं में <nowiki>x=5</nowiki> x का मान 5 पर सेट करेगा जबकि <nowiki>x==5</nowiki> जाँच करेगा कि x वर्तमान में 5 है या कोई अन्य संख्या। व्याख्या की गई लैंग्वेजएँ ऐसे कोड को विफल होने देती हैं। परीक्षण शुरू होने से पहले संकलित लैंग्वेजएँ ऐसी त्रुटियों को पकड़ सकती हैं। | ||
=== टीम वर्क === | === टीम वर्क === | ||
| Line 172: | Line 170: | ||
सॉफ़्टवेयर बग की मात्रा और प्रकार की क्षति स्वाभाविक रूप से सॉफ़्टवेयर गुणवत्ता के संबंध में निर्णय लेने, प्रक्रियाओं और नीति को प्रभावित कर सकती है। [[मानव अंतरिक्ष उड़ान]], उड्डयन, परमाणु ऊर्जा, [[स्वास्थ्य देखभाल]], सार्वजनिक परिवहन या [[मोटर वाहन सुरक्षा]] जैसे अनुप्रयोगों में, चूंकि सॉफ़्टवेयर की कमियों में मानव चोट या यहां तक कि मौत का कारण बनने की क्षमता होती है, ऐसे सॉफ़्टवेयर की तुलना में कहीं अधिक जांच और गुणवत्ता नियंत्रण होगा, उदाहरण के लिए, एक ऑनलाइन शॉपिंग वेबसाइट। बैंकिंग जैसे अनुप्रयोगों में, जहाँ सॉफ़्टवेयर की कमियों से बैंक या उसके ग्राहकों को गंभीर वित्तीय हानि होने की संभावना होती है, गुणवत्ता नियंत्रण भी एक फोटो एडिटिंग एप्लिकेशन की तुलना में अधिक महत्वपूर्ण है। | सॉफ़्टवेयर बग की मात्रा और प्रकार की क्षति स्वाभाविक रूप से सॉफ़्टवेयर गुणवत्ता के संबंध में निर्णय लेने, प्रक्रियाओं और नीति को प्रभावित कर सकती है। [[मानव अंतरिक्ष उड़ान]], उड्डयन, परमाणु ऊर्जा, [[स्वास्थ्य देखभाल]], सार्वजनिक परिवहन या [[मोटर वाहन सुरक्षा]] जैसे अनुप्रयोगों में, चूंकि सॉफ़्टवेयर की कमियों में मानव चोट या यहां तक कि मौत का कारण बनने की क्षमता होती है, ऐसे सॉफ़्टवेयर की तुलना में कहीं अधिक जांच और गुणवत्ता नियंत्रण होगा, उदाहरण के लिए, एक ऑनलाइन शॉपिंग वेबसाइट। बैंकिंग जैसे अनुप्रयोगों में, जहाँ सॉफ़्टवेयर की कमियों से बैंक या उसके ग्राहकों को गंभीर वित्तीय हानि होने की संभावना होती है, गुणवत्ता नियंत्रण भी एक फोटो एडिटिंग एप्लिकेशन की तुलना में अधिक महत्वपूर्ण है। | ||
वॉर्म्स से होने वाली क्षति के अतिरिक्त, उनकी कुछ लागत उन्हें ठीक करने में किए गए प्रयास के कारण होती है। 1978 में, लिएंट्ज़ एट अल। दिखाया गया है कि बग फिक्सिंग में परियोजनाओं का माध्य | वॉर्म्स से होने वाली क्षति के अतिरिक्त, उनकी कुछ लागत उन्हें ठीक करने में किए गए प्रयास के कारण होती है। 1978 में, लिएंट्ज़ एट अल। दिखाया गया है कि बग फिक्सिंग में परियोजनाओं का माध्य डेवलोपमेन्ट के प्रयास का 17 प्रतिशत निवेश करता है।<ref>{{Cite journal|title = एप्लिकेशन सॉफ़्टवेयर रखरखाव के लक्षण|journal = Communications of the ACM |date = 1978 |pages = 466–471|volume = 21|doi = 10.1145/359511.359522|first1 = B. P.|last1 = Lientz |first2 = E. B.|last2 = Swanson |first3 = G. E.|last3 = Tompkins|issue = 6 |s2cid = 14950091 }}</ref> 2020 में [[GitHub|गिट हब (GitHub)]] रिपॉजिटरी पर शोध में दिखाया गया है कि माध्य 20% है।<ref>{{cite arXiv |last1=Amit |first1=Idan |last2=Feitelson |first2=Dror G.|date=2020 |title=सुधारात्मक प्रतिबद्धता संभाव्यता कोड गुणवत्ता मीट्रिक|class=cs.SE |eprint=2007.10912}}</ref> | ||
{{anchors|residual defects|Deployment failures}} | {{anchors|residual defects|Deployment failures}} | ||
| Line 178: | Line 176: | ||
1994 में, नासा के [[गोडार्ड अंतरिक्ष उड़ान केंद्र]] ने त्रुटियों की औसत संख्या 4.5 प्रति 1000 लाइन कोड (कोड की सोर्स लाइन) से घटाकर 1 प्रति 1000 SLOC करने में अपना योगदान दिया।<ref name="NASA1994">{{Cite report |title=सॉफ्टवेयर इंजीनियरिंग प्रयोगशाला का अवलोकन|date=1994-12-01 |url=https://ntrs.nasa.gov/api/citations/19950022293/downloads/19950022293.pdf |access-date=2022-11-22 |url-status=live |publisher=[[Goddard Space Flight Center]], NASA |location=Maryland, USA |at=pp41–42 Figure 18; pp43–44 Figure 21 |language=en |id=CR-189410; SEL-94-005|archive-url=https://web.archive.org/web/20221122105623/https://ntrs.nasa.gov/api/citations/19950022293/downloads/19950022293.pdf |format=pdf |archive-date=2022-11-22}} (bibliography: [https://ntrs.nasa.gov/citations/19950022293 An overview of the Software Engineering Laboratory])</ref> | 1994 में, नासा के [[गोडार्ड अंतरिक्ष उड़ान केंद्र]] ने त्रुटियों की औसत संख्या 4.5 प्रति 1000 लाइन कोड (कोड की सोर्स लाइन) से घटाकर 1 प्रति 1000 SLOC करने में अपना योगदान दिया।<ref name="NASA1994">{{Cite report |title=सॉफ्टवेयर इंजीनियरिंग प्रयोगशाला का अवलोकन|date=1994-12-01 |url=https://ntrs.nasa.gov/api/citations/19950022293/downloads/19950022293.pdf |access-date=2022-11-22 |url-status=live |publisher=[[Goddard Space Flight Center]], NASA |location=Maryland, USA |at=pp41–42 Figure 18; pp43–44 Figure 21 |language=en |id=CR-189410; SEL-94-005|archive-url=https://web.archive.org/web/20221122105623/https://ntrs.nasa.gov/api/citations/19950022293/downloads/19950022293.pdf |format=pdf |archive-date=2022-11-22}} (bibliography: [https://ntrs.nasa.gov/citations/19950022293 An overview of the Software Engineering Laboratory])</ref> | ||
1990 में एक अन्य अध्ययन ने बताया कि असाधारण रूप से अच्छी सॉफ्टवेयर | 1990 में एक अन्य अध्ययन ने बताया कि असाधारण रूप से अच्छी सॉफ्टवेयर डेवलोपमेन्ट प्रक्रियाएँ 0.1 प्रति 1000 SLOC के रूप में परिनियोजन विफलता दर प्राप्त कर सकती हैं।<ref name="CobbMills1990">{{Cite journal |title=सांख्यिकीय गुणवत्ता नियंत्रण के तहत इंजीनियरिंग सॉफ्टवेयर|journal=[[IEEE Software]] |url=https://trace.tennessee.edu/utk_harlan/14/|via=University of Tenessee – Harlan D. Mills Collection |last=Cobb |first=Richard H. |issue=6 |volume=7 |last2=Mills |first2=Harlan D. |doi=10.1109/52.60601 |year=1990 |page=46 |language=en |issn=1937-4194 |author-link2=Harlan Mills}}</ref> यह आंकड़ा साहित्य में पुनरावृत्त है जैसे [[स्टीव मैककोनेल]] द्वारा [[कोड पूर्ण]],<ref name="McConnel1993">{{Cite book |title=कोड पूर्ण|last=McConnell |first=Steven C. |publisher=Microsoft Press |year=1993 |isbn=9781556154843 |location=Redmond, Washington, USA |pages=611 |language=en |url=https://archive.org/details/codecompleteprac0000mcco/page/611/mode/1up?q=%22space+shuttle%22|via=archive.org |quote=(कॉब एंड मिल्स 1990)|author-link=Steve McConnell |url-access=registration}}</ref> और नासा अध्ययन उड़ान सॉफ्टवेयर जटिलता पर।<ref name="NASA2009">{{Cite report |title=उड़ान सॉफ्टवेयर जटिलता पर नासा का अध्ययन|chapter=Appendix D – Software Complexity |date=2009-03-06 |url=https://www.nasa.gov/sites/default/files/418878main_FSWC_Final_Report.pdf |last=Holzmann |first=Gerard |author-link=Gerard J. Holzmann |editor-last=Dvorak |editor-first=Daniel L. |access-date=2022-11-22 |url-status=live |publisher=[[NASA]] |language=en |archive-url=https://web.archive.org/web/20220308105307mp_/https://www.nasa.gov/sites/default/files/418878main_FSWC_Final_Report.pdf |format=pdf |at=pdf frame 109/264. Appendix D p.2|archive-date=2022-03-08}} (under [https://www.nasa.gov/offices/oce/documents/FSWC_study.html NASA Office of the Chief Engineer Technical Excellence Initiative])</ref> कुछ परियोजनाओं में शून्य दोष भी पाए गए। [[आईबीएम व्हीलराइटर]] टाइपराइटर में [[फर्मवेयर]] जिसमें 63,000 एसएलओसी सम्मलित हैं, और 500,000 एसएलओसी के साथ [[अंतरिक्ष शटल]] सॉफ्टवेयर।<ref name="CobbMills1990" /> | ||
== प्रसिद्ध बग == | == प्रसिद्ध बग == | ||
{{Main|सॉफ़्टवेयर बग की सूची}} | {{Main|सॉफ़्टवेयर बग की सूची}} | ||