सॉफ्टवेयर बग: Difference between revisions

सॉफ़्टवेयर बग [[कंप्यूटर सॉफ्टवेयर]] के डिज़ाइन, विकास या संचालन में एक त्रुटि, दोष या दोष (तकनीक) है जिसके कारण यह गलत या अप्रत्याशित परिणाम उत्पन्न करता है, या अनपेक्षित तरीके से व्यवहार करता है। बग को खोजने और सुधारने की प्रक्रिया को [[डिबगिंग]] कहा जाता है और अक्सर बग को इंगित करने के लिए औपचारिक तकनीकों या उपकरणों का उपयोग किया जाता है। 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 name=huggins>{{cite web |author=James S. Huggins |url=http://www.jamesshuggins.com/h/tek1/first_computer_bug.htm |archive-url=https://web.archive.org/web/20000816023000/http://www.jamesshuggins.com/h/tek1/first_computer_bug.htm |url-status=dead |archive-date=August 16, 2000 |title=पहला कंप्यूटर बग|publisher=Jamesshuggins.com |access-date=September 24, 2012  }}</ref> लॉग बुक में तारीख 9 सितंबर, 1947 थी।<ref>"[http://catb.org/jargon/html/B/bug.html Bug] {{webarchive|url=https://web.archive.org/web/20170323213836/http://www.catb.org/jargon/html/B/bug.html |date=March 23, 2017 }}", ''The Jargon File'', ver. 4.4.7. Retrieved June 3, 2010.</ref><ref name="si-bug">"[http://americanhistory.si.edu/collections/search/object/nmah_334663 Log Book With Computer Bug] {{webarchive|url=https://web.archive.org/web/20170323220950/http://americanhistory.si.edu/collections/search/object/nmah_334663 |date=March 23, 2017 }}", National Museum of American History, Smithsonian Institution.</ref><ref>"[https://web.archive.org/web/20000119173039/http://history.navy.mil/photos/images/h96000/h96566kc.htm The First "Computer Bug]", Naval Historical Center. But note the [[Harvard Mark II]] computer was not complete until the summer of 1947.</ref> जिन ऑपरेटरों ने इसे पाया, उनमें विलियम बिल बर्क, बाद में [[नेवल सरफेस वारफेयर सेंटर डहलग्रेन डिवीजन]], डहलग्रेन, वर्जीनिया, शामिल थे।<ref>IEEE Annals of the History of Computing, Vol 22 Issue 1, 2000</ref> इंजीनियरिंग की शब्दावली से परिचित थे और मनोरंजक तरीके से कीट को इस संकेतन के साथ रखा कि बग का पहला वास्तविक मामला पाया जा रहा है। संलग्न कीट के साथ पूर्ण यह लॉग बुक, अमेरिकी इतिहास के स्मिथसोनियन राष्ट्रीय संग्रहालय के संग्रह का हिस्सा है।<ref name="si-bug" />

संबंधित शब्द [[डिबग]] भी कंप्यूटिंग में इसके उपयोग से पहले का प्रतीत होता है: [[ऑक्सफोर्ड इंग्लिश डिक्शनरी]]{{'}}शब्द की व्युत्पत्ति में विमान इंजन के संदर्भ में 1945 से एक प्रमाणन शामिल है।<ref>''Journal of the Royal Aeronautical Society''. 49, 183/2, 1945 "It ranged ... through the stage of type test and flight test and 'debugging' ..."</ref>

सरकारी शोधकर्ता, कंपनियाँ और साइबर सुरक्षा विशेषज्ञ वे लोग हैं जो आमतौर पर सॉफ़्टवेयर की खामियों का पता लगाते हैं। रिपोर्ट में कंप्यूटर अपराध और कॉपीराइट कानूनों में सुधार की मांग की गई है।<ref name=":0" />

जबकि सॉफ़्टवेयर त्रुटियों का वर्णन करने के लिए बग शब्द का उपयोग आम है, कई लोगों ने सुझाव दिया है कि इसे छोड़ दिया जाना चाहिए। एक तर्क यह है कि बग शब्द इस अर्थ से अलग है कि एक इंसान समस्या का कारण बना, और इसके बजाय इसका अर्थ है कि दोष अपने आप उत्पन्न हुआ, जिसके कारण दोष जैसे शब्दों के पक्ष में बग शब्द को सीमित करने के लिए धक्का दिया गया। सफलता।<ref>{{cite web|url=http://www.sei.cmu.edu/library/abstracts/news-at-sei/wattsmar99.cfm|title=एसईआई 1999 आर्काइव पर समाचार|work=cmu.edu|url-status=live|archive-url=https://web.archive.org/web/20130526044359/http://www.sei.cmu.edu/library/abstracts/news-at-sei/wattsmar99.cfm|archive-date=May 26, 2013}}</ref> 1970 के दशक के बाद से [[गैरी किल्डाल]] ने कुछ विनोदी ढंग से ब्लंडर शब्द का उपयोग करने का सुझाव दिया।<ref name="Shustek_2016">{{cite web |url=http://www.computerhistory.org/atchm/in-his-own-words-gary-kildall/ |title=इन हिज ओन वर्ड्स: गैरी किल्डाल|author-first=Len |author-last=Shustek |date=August 2, 2016 |work=Remarkable People |publisher=[[Computer History Museum]] |url-status=live |archive-url=https://web.archive.org/web/20161217072842/http://www.computerhistory.org/atchm/in-his-own-words-gary-kildall/ |archive-date=December 17, 2016  }}</रेफरी><ref name="Kildall_1993">{{cite document |orig-year=1993 |date=August 2, 2016 |title=कंप्यूटर कनेक्शन: पर्सनल कंप्यूटर उद्योग के विकास में लोग, स्थान और घटनाएँ|author-first=Gary Arlen |author-last=Kildall |author-link=Gary Kildall |editor-first1=Scott |editor-last1=Kildall |editor-link=Scott Kildall |editor-first2=Kristin |editor-last2=Kildall |publisher=Kildall Family |type=Manuscript, part 1 |pages=14–15 |url=http://www.computerhistory.org/atchm/computer-history-museum-license-agreement-for-the-kildall-manuscript/ |access-date=November 17, 2016 |url-status=live |archive-url=https://web.archive.org/web/20161117231531/http://www.computerhistory.org/atchm/computer-history-museum-license-agreement-for-the-kildall-manuscript/ |archive-date=November 17, 2016  }}</रेफरी>

[[File:Software bug displayed on two screens at La Croix de Berny station in France - 2021-10-28.jpg|thumb|फ़्रांस के [[ला क्रोक्स डे बर्नी स्टेशन]] पर दो स्क्रीन पर प्रदर्शित सॉफ़्टवेयर बग के परिणामस्वरूप त्रुटि।]]सॉफ़्टवेयर उद्योग ने बगों की संख्या कम करने के लिए बहुत प्रयास किए हैं।<ref>{{cite book | last = Huizinga | first = Dorota | author2 = Kolawa, Adam | title = स्वचालित दोष निवारण: सॉफ्टवेयर प्रबंधन में सर्वोत्तम अभ्यास| url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page = 426 | isbn = 978-0-470-04212-0 | url-status = live | archive-url = https://web.archive.org/web/20120425232401/http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | archive-date = April 25, 2012 | df = mdy-all }}</ref><ref>{{cite book | last = McDonald | first = Marc | author2 = Musson, Robert | author3 = Smith, Ross | title = दोष निवारण के लिए व्यावहारिक मार्गदर्शिका| url = https://archive.org/details/practicalguideto00/page/480 | year = 2007 | publisher = Microsoft Press | page = [https://archive.org/details/practicalguideto00/page/480 480] | isbn = 978-0-7356-2253-1 | df = mdy-all | url-access = registration }}</ref> इसमे शामिल है:

बग आमतौर पर तब दिखाई देते हैं जब प्रोग्रामर एक तार्किक त्रुटि करता है। [[प्रोग्रामिंग शैली]] और [[रक्षात्मक प्रोग्रामिंग]] में विभिन्न नवाचारों को इन बगों की संभावना कम करने, या स्पॉट करने में आसान बनाने के लिए डिज़ाइन किया गया है। कुछ टाइपो, विशेष रूप से प्रतीकों या तार्किक/[[ऑपरेटर (गणित)]] के, प्रोग्राम को गलत तरीके से संचालित करने की अनुमति देते हैं, जबकि अन्य जैसे लापता प्रतीक या गलत वर्तनी वाले नाम प्रोग्राम को संचालन से रोक सकते हैं। स्रोत कोड संकलित होने पर संकलित भाषाएँ कुछ टाइपो प्रकट कर सकती हैं।

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

[[इकाई का परीक्षण]] में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना शामिल है जिसे प्रोग्राम को परफॉर्म करना है।

[[चुस्त सॉफ्टवेयर विकास]] में अपेक्षाकृत छोटे बदलावों के साथ लगातार सॉफ्टवेयर रिलीज शामिल होते हैं। उपयोगकर्ता प्रतिक्रिया से दोष प्रकट होते हैं।

ओपन सोर्स डेवलपमेंट किसी को भी सोर्स कोड की जांच करने की अनुमति देता है। लिनस के नियम के रूप में एरिक एस. रेमंड द्वारा लोकप्रिय विचार के एक स्कूल का कहना है कि लोकप्रिय [[खुला स्रोत सॉफ्टवेयर]] में अन्य सॉफ़्टवेयर की तुलना में कम या कोई बग नहीं होने की अधिक संभावना है, क्योंकि पर्याप्त नेत्रगोलक दिए जाने पर, सभी बग उथले हैं।<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>, हालांकि यह वाक्यात्मक रूप से सही हो सकता है, कोड एक प्रकार की जाँच में विफल रहता है। संकलित भाषाएँ प्रोग्राम को चलाए बिना इसे पकड़ लेती हैं। व्याख्या की गई भाषाएँ रनटाइम पर ऐसी त्रुटियों को पकड़ती हैं। कुछ भाषाएं धीमी गति से प्रदर्शन की कीमत पर जानबूझकर उन विशेषताओं को बाहर करती हैं जो आसानी से बग की ओर ले जाती हैं: सामान्य सिद्धांत यह है कि, थोड़ा तेज चलने वाले रहस्यमय कोड की तुलना में सरल, धीमा कोड लिखना लगभग हमेशा बेहतर होता है, विशेष रूप से यह देखते हुए कि रखरखाव लागत पर्याप्त है . उदाहरण के लिए, [[जावा (प्रोग्रामिंग भाषा)]] पॉइंटर (कंप्यूटर प्रोग्रामिंग) अंकगणित का समर्थन नहीं करता है; [[पास्कल (प्रोग्रामिंग भाषा)]] और स्क्रिप्टिंग भाषाओं जैसी कुछ भाषाओं के कार्यान्वयन में अक्सर कम से कम डिबगिंग बिल्ड में सरणी की रनटाइम सीमा जांच होती है।

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

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

[[File:Classpath bugs.png|thumb|350px|सामान्य बग इतिहास ([[जीएनयू क्लासपाथ]] प्रोजेक्ट डेटा)। उपयोगकर्ता द्वारा सबमिट किया गया एक नया बग अपुष्ट है। एक बार जब इसे एक डेवलपर द्वारा पुन: प्रस्तुत किया जाता है, तो यह एक पुष्टि की गई बग है। पुष्टि किए गए बग बाद में तय किए गए हैं। अन्य श्रेणियों से संबंधित बग (पुनरुत्पादन योग्य नहीं, तय नहीं किया जाएगा, आदि) आमतौर पर अल्पमत में होते हैं]]

आम तौर पर, डिबगिंग का सबसे कठिन हिस्सा बग ढूंढ रहा है। एक बार यह मिल जाने के बाद, इसे ठीक करना आमतौर पर अपेक्षाकृत आसान होता है। [[डिबगर]]्स के रूप में जाने जाने वाले प्रोग्राम प्रोग्रामर को कोड लाइन को लाइन से निष्पादित करके, चर मूल्यों को देखते हुए, और प्रोग्राम के व्यवहार को देखने के लिए अन्य सुविधाओं द्वारा बग का पता लगाने में मदद करते हैं। डिबगर के बिना, कोड जोड़ा जा सकता है ताकि प्रोग्राम निष्पादन का पता लगाने या मान दिखाने के लिए कंसोल या विंडो या लॉग फ़ाइल में संदेश या मान लिखे जा सकें।

हालाँकि, डिबगर की सहायता से भी, बग्स का पता लगाना एक कला है। किसी प्रोग्राम के एक सेक्शन में बग के लिए यह असामान्य नहीं है कि वह पूरी तरह से अलग सेक्शन में फेल हो जाए,{{citation needed|date=November 2012}} इस प्रकार इसे ट्रैक करना विशेष रूप से कठिन बना देता है (उदाहरण के लिए, ग्राफिक्स रेंडरिंग (कंप्यूटर ग्राफिक्स) रूटीन में एक त्रुटि जिसके कारण फ़ाइल इनपुट/आउटपुट | I/O रूटीन विफल हो जाता है), सिस्टम के एक स्पष्ट रूप से असंबंधित हिस्से में।

कभी-कभी, एक बग एक अकेला दोष नहीं होता है, लेकिन प्रोग्रामर की ओर से सोचने या योजना बनाने में त्रुटि का प्रतिनिधित्व करता है। ऐसी तार्किक त्रुटियों के लिए प्रोग्राम के एक हिस्से को ओवरहाल या फिर से लिखने की आवश्यकता होती है। कोड समीक्षा के एक भाग के रूप में, कोड के माध्यम से आगे बढ़ने और निष्पादन प्रक्रिया की कल्पना या लिप्यंतरण करने से अक्सर बग को पुन: पेश किए बिना त्रुटियां मिल सकती हैं।