सॉफ्टवेयर बग
सॉफ़्टवेयर बग कंप्यूटर सॉफ्टवेयर के डिज़ाइन, डेवलोपमेन्ट या संचालन में एक त्रुटि, दोष या दोष (तकनीक) है जिसके कारण यह गलत या अप्रत्याशित परिणाम उत्पन्न करता है, या अनपेक्षित विधि से व्यवहार करता है। बग को खोजने और सुधारने की प्रक्रिया को डिबगिंग कहा जाता है और अधिकांशतः बग को इंगित करने के लिए औपचारिक तकनीकों या उपकरणों का उपयोग किया जाता है। 1950 के दशक के बाद से कुछ कंप्यूटर सिस्टम संचालन के समय विभिन्न कंप्यूटर बगों को रोकने, पहचानने या स्वत। ठीक करने के लिए डिज़ाइन किए गए हैं।
सॉफ़्टवेयर में बग उपयोगकर्ताओं की आवश्यकता को समझने और निकालने में की गई गलतियों और त्रुटियों से उत्पन्न हो सकते हैं, प्रोग्राम के सॉफ़्टवेयर डिजाइन की योजना बना सकते हैं, इसके सोर्स कोड लिख सकते हैं, और ऑपरेटिंग सिस्टम या लाइब्रेरी (कम्प्यूटिंग) जैसे मनुष्यों, हार्डवेयर और प्रोग्राम के साथ बातचीत से उत्पन्न हो सकते हैं। कई या गंभीर बग वाले प्रोग्राम को अधिकांशतः बग के रूप में वर्णित किया जाता है। बग उन त्रुटियों को ट्रिगर कर सकते हैं जिनके तरंग प्रभाव हो सकते हैं। बग के प्रभाव सूक्ष्म हो सकते हैं, जैसे अनपेक्षित पाठ स्वरूपण, अधिक स्पष्ट प्रभावों के माध्यम से जैसे प्रोग्राम को क्रैश (कंप्यूटिंग), कंप्यूटर को फ्रीज (कंप्यूटिंग) करना, या हार्डवेयर को नुकसान पहुंचाना। अन्य बग सुरक्षा बग के रूप में अर्हता प्राप्त करते हैं और उदाहरण के लिए, विशेषाधिकार वृद्धि के लिए पहुँच नियंत्रण (एक्सेस कंट्रोल) को बायपास करने के लिए ब्लैक कैप हैकिंग को सक्षम कर सकते हैं।[1]
कुछ सॉफ़्टवेयर बग्स को आपदाओं से जोड़ा गया है। 1980 के दशक में थेरेक-25 विकिरण उपचार मशीन को नियंत्रित करने वाले कोड में वॉर्म्स सीधे मरीजों की मौत के लिए जिम्मेदार थे। 1996 में, ऑन-बोर्ड मार्गदर्शन कंप्यूटर प्रोग्राम में बग के कारण यूरोपीय अंतरिक्ष एजेंसी के US$1 बिलियन प्रोटोटाइप एरियन उड़ान V88 लॉन्च के एक मिनट से भी कम समय बाद।[2] 1994 में, 1994 स्कॉटलैंड आरएएफ चिनूक दुर्घटना दुर्घटना, 29 की मौत; शुरुआत में इसे पायलट त्रुटि के लिए दोषी ठहराया गया था, लेकिन बाद में माना गया कि यह एफएडीईसी (FADEC) इंजन-कंट्रोल कंप्यूटर में एक सॉफ्टवेयर बग के कारण हुआ है।[3] बग सॉफ्टवेयर ने 21वीं सदी के आरंभिक ब्रिटिश डाकघर घोटाला का कारण बना, ब्रिटिश कानूनी इतिहास में न्याय का सबसे व्यापक गर्भपात।[4]
2002 में, अमेरिकी वाणिज्य विभाग के राष्ट्रीय मानक और प्रौद्योगिकी संस्थान द्वारा शुरू किए गए अध्ययन ने निष्कर्ष निकाला कि सॉफ्टवेयर बग, या त्रुटियां, इतनी प्रचलित और इतनी हानिकारक हैं कि वे अमेरिकी अर्थव्यवस्था को अनुमानित रूप से सकल घरेलू उत्पाद के लिए $59 बिलियन वार्षिक, या लगभग 0.6 प्रतिशत खर्च करते हैं।[5]
इतिहास
मध्य अंग्रेजी शब्द wikt।bugge#Noun शब्दों के लिए आधार है wikt।bugbear#Noun और wikt।bug-a-boo#Noun एक राक्षस के लिए प्रयुक्त शब्दों के रूप में।[6]
दोषों का वर्णन करने के लिए बग शब्द 1870 के दशक से इंजीनियरिंग शब्दजाल का एक भाग रहा है[7] और इलेक्ट्रॉनिक्स और कंप्यूटरों की भविष्यवाणी करता है; यह मूल रूप से यांत्रिक खराबी का वर्णन करने के लिए हार्डवेयर इंजीनियरिंग में उपयोग किया गया हो सकता है। उदाहरण के लिए, थॉमस एडीसन ने 1878 में एक सहयोगी को लिखे पत्र में लिखा था।[8]
बाफल बॉल, पहला मैकेनिकल पिनबॉल गेम, 1931 में वॉर्म्स से मुक्त होने के रूप में विज्ञापित किया गया था।[9] द्वितीय विश्व युद्ध के समय सैन्य गियर के साथ समस्याओं को बग (या ग्लिट्स) कहा जाता था।[10] 1942 में प्रकाशित एक पुस्तक में, लुईस डिकिंसन रिच ने एक संचालित बर्फ काटने वाली मशीन के बारे में बात करते हुए कहा, बर्फ काटने को तब तक के लिए निलंबित कर दिया गया था जब तक कि निर्माता को अपने प्रिय से वॉर्म्स निकालने के लिए नहीं लाया जा सकता था।[11] कहानी का एक विशिष्ट संस्करण है।
जब बग पाया गया तो हूपर सम्मलित नहीं था, लेकिन यह उसकी पसंदीदा कहानियों में से एक बन गई।[12] लॉग बुक में तारीख 9 सितंबर, 1947 थी।[13][14][15] जिन ऑपरेटरों ने इसे पाया, उनमें विलियम बिल बर्क, बाद में नेवल सरफेस वारफेयर सेंटर डहलग्रेन डिवीजन, डहलग्रेन, वर्जीनिया, सम्मलित थे।[16] इंजीनियरिंग की शब्दावली से परिचित थे और मनोरंजक विधि से कीट को इस संकेतन के साथ रखा कि बग का पहला वास्तविक स्थिति पाया जा रही है। संलग्न कीट के साथ पूर्ण यह लॉग बुक, अमेरिकी इतिहास के स्मिथसोनियन राष्ट्रीय संग्रहालय के संग्रह का भाग है।[14]
संबंधित शब्द डिबग भी कंप्यूटिंग में इसके उपयोग से पहले का प्रतीत होता है। ऑक्सफोर्ड इंग्लिश डिक्शनरी'शब्द की व्युत्पत्ति में विमान इंजन के संदर्भ में 1945 से एक प्रमाणन सम्मलित है।[17]
यह ऐसी अवधारणा है कि सॉफ्टवेयर में त्रुटियां हो सकती हैं, विश्लेषणात्मक इंजन पर एडा बायरन के नोट्स से मिलती हैं। एडा लवलेस के 1843 नोट्स एनालिटिकल इंजन पर, जिसमें वह चार्ल्स बैबेज के एनालिटिकल इंजन के गलत होने के लिए प्रोग्राम कार्ड की संभावना की बात करती हैं।
विश्लेषणात्मक इंजन को आवश्यक ऑपरेटिव डेटा प्रस्तुत करने के लिए एक विश्लेषण प्रक्रिया समान रूप से निष्पादित की जानी चाहिए; और इसमें त्रुटि का संभावित स्रोत भी हो सकता है। यह माना जाता है कि वास्तविक तंत्र अपनी प्रक्रियाओं में त्रुटिहीन है, कार्ड इसे गलत आदेश दे सकते हैं।
सिस्टम रिपोर्ट में वायरस
मुक्त प्रौद्योगिकी संस्थान, समूह, न्यू अमेरिका द्वारा चलाया जाता है,[18] अगस्त 2016 में एक रिपोर्ट बग्स इन द सिस्टम जारी की जिसमें कहा गया था कि अमेरिकी नीति निर्माताओं को सॉफ्टवेयर बगों की पहचान करने और उन्हें दूर करने में शोधकर्ताओं की मदद करने के लिए सुधार करना चाहिए। रिपोर्ट में सॉफ्टवेयर भेद्यता खोज और प्रकटीकरण के क्षेत्र में सुधार की आवश्यकता पर प्रकाश डाला गया है।[19] रिपोर्ट के लेखकों में से एक ने कहा कि कांग्रेस ने साइबर सॉफ़्टवेयर भेद्यता को दूर करने के लिए पर्याप्त नहीं किया है, भले ही कांग्रेस ने साइबर सुरक्षा के बड़े विवाद का मुकाबला करने के लिए कई बिल पारित किए हैं।[19]
सरकारी शोधकर्ता, कंपनियाँ और साइबर सुरक्षा विशेषज्ञ वे लोग हैं जो साधारणतयः सॉफ़्टवेयर की कमियों का पता लगाते हैं। रिपोर्ट में कंप्यूटर अपराध और कॉपीराइट कानूनों में सुधार की मांग की गई है।[19]
कंप्यूटर फ्रॉड एंड एब्यूज एक्ट, डिजिटल मिलेनियम कॉपीराइट एक्ट और इलेक्ट्रॉनिक कम्युनिकेशंस प्राइवेसी एक्ट उन कार्रवाइयों के लिए अपराधीकरण और नागरिक दंड बनाते हैं, जो सुरक्षा शोधकर्ता नियमित रूप से वैध सुरक्षा अनुसंधान करते समय संलग्न करते हैं, रिपोर्ट में कहा गया है। 1970 के दशक के बाद से गैरी किल्डाल ने कुछ विनोदी ढंग से ब्लंडर शब्द का उपयोग करने का सुझाव दिया।[20][21] जो इसमें सम्मलित है।
टंकण त्रुटियाँ
बग साधारणतयः तब दिखाई देते हैं जब प्रोग्रामर एक तार्किक त्रुटि करता है। प्रोग्रामिंग शैली और रक्षात्मक प्रोग्रामिंग में विभिन्न नवाचारों को इन बगों की संभावना कम करने, या स्पॉट करने में आसान बनाने के लिए डिज़ाइन किया गया है। कुछ टाइपो, विशेष रूप से प्रतीकों या तार्किक/ऑपरेटर (गणित) के, प्रोग्राम को गलत विधि से संचालित करने की अनुमति देते हैं, जबकि अन्य जैसे लापता प्रतीक या गलत वर्तनी वाले नाम प्रोग्राम को संचालन से रोक सकते हैं। सोर्स कोड संकलित होने पर संकलित लैंग्वेजएँ कुछ टाइपो प्रकट कर सकती हैं।
डेवलोपमेन्ट के विधि
कई योजनाएँ प्रोग्रामर गतिविधि को प्रबंधित करने में सहायता करती हैं जिससे कि कम बग उत्पन्न हों। सॉफ्टवेयर इंजीनियरिंग (जो सॉफ़्टवेयर डिज़ाइन के मुद्दों को भी संबोधित करती है) दोषों को रोकने के लिए कई विधियों को लागू करती है। उदाहरण के लिए, औपचारिक कार्यक्रम विनिर्देश कार्यक्रमों के सटीक व्यवहार को बताते हैं जिससे कि डिज़ाइन बग को समाप्त किया जा सके। दुर्भाग्य से, औपचारिक विनिर्देश किसी भी चीज के लिए अव्यावहारिक हैं, लेकिन कम से कम कार्यक्रमों के लिए, दहनशील विस्फोट और गैर-नियतात्मक एल्गोरिदम की समस्याओं के कारण।
इकाई का परीक्षण में प्रत्येक फंक्शन (यूनिट) के लिए एक टेस्ट लिखना सम्मलित है जिसे प्रोग्राम को परफॉर्म करना है।
परीक्षण-संचालित डेवलोपमेन्ट में इकाई परीक्षण कोड से पहले लिखे जाते हैं और कोड को तब तक पूर्ण नहीं माना जाता जब तक कि सभी परीक्षण सफलतापूर्वक पूर्ण नहीं हो जाते।
अगिल सॉफ्टवेयर डेवलोपमेन्ट में अपेक्षाकृत छोटे बदलावों के साथ लगातार सॉफ्टवेयर रिलीज सम्मलित होते हैं। उपयोगकर्ता प्रतिक्रिया से दोष प्रकट होते हैं।
ओपन सोर्स डेवलपमेंट किसी को भी सोर्स कोड की जांच करने की अनुमति देता है। लिनस के नियम के रूप में एरिक एस. रेमंड द्वारा लोकप्रिय विचार के एक स्कूल का कहना है कि लोकप्रिय ओपन सोर्स सॉफ्टवेयर में अन्य सॉफ़्टवेयर की तुलना में कम या कोई बग नहीं होने की अधिक संभावना है, क्योंकि पर्याप्त नेत्रगोलक दिए जाने पर, सभी बग उथले हैं।[22] चूंकि, यह दावा विवादित रहा है। कंप्यूटर सुरक्षा विशेषज्ञ इलियास लेवी ने लिखा है कि जटिल, कम समझ में आने वाले और बिना दस्तावेज वाले सोर्स कोड में कमजोरियों को छिपाना आसान है, क्योंकि भले ही लोग कोड की समीक्षा कर रहे हों, इसका मतलब यह नहीं है कि वे योग्य हैं ऐसा करने के लिए।[23] ओपन-सोर्स सॉफ़्टवेयर बग का एक उदाहरण डेबियन 2008 ओपनएसएसएल भेद्यता थी।
प्रोग्रामिंग लैंग्वेज समर्थन
प्रोग्रामिंग लैंग्वेज में बग्स को रोकने में मदद करने के लिए फीचर्स सम्मलित हैं, जैसे स्टैटिक प्रकार प्रणाली, प्रतिबंधित नाम स्थान और मॉड्यूलर प्रोग्रामिंग है। उदाहरण के लिए, जब एक प्रोग्रामर लिखता है (स्यूडोकोड) LET REAL_VALUE PI = "THREE AND A BIT", चूंकि यह वाक्यात्मक रूप से सही हो सकता है, कोड एक प्रकार की जाँच में विफल रहता है। संकलित लैंग्वेजएँ प्रोग्राम को चलाए बिना इसे पकड़ लेती हैं। व्याख्या की गई लैंग्वेजएँ रनटाइम पर ऐसी त्रुटियों को पकड़ती हैं। कुछ लैंग्वेजएं धीमी गति से प्रदर्शन की कीमत पर जानबूझकर उन विशेषताओं को बाहर करती हैं जो आसानी से बग की ओर ले जाती हैं। सामान्य सिद्धांत यह है कि, थोड़ा तेज चलने वाले रहस्यमय कोड की तुलना में सरल, धीमा कोड लिखना लगभग हमेशा बेहतर होता है, विशेष रूप से यह देखते हुए कि रखरखाव लागत पर्याप्त है . उदाहरण के लिए, जावा (प्रोग्रामिंग लैंग्वेज) पॉइंटर (कंप्यूटर प्रोग्रामिंग) अंकगणित का समर्थन नहीं करता है; पास्कल (प्रोग्रामिंग लैंग्वेज) और स्क्रिप्टिंग लैंग्वेजओं जैसी कुछ लैंग्वेजओं के कार्यान्वयन में अधिकांशतः कम से कम डिबगिंग बिल्ड में सरणी की रनटाइम सीमा जांच होती है।
कोड विश्लेषण
स्टेटिक कोड विश्लेषण के लिए उपकरण संभावित समस्याओं का पता लगाने के लिए कंपाइलर की क्षमताओं से परे प्रोग्राम टेक्स्ट का निरीक्षण करके डेवलपर्स की मदद करते हैं। चूंकि साधारणतयः एक विनिर्देश दिए गए सभी प्रोग्रामिंग त्रुटियों को खोजने की समस्या हल करने योग्य नहीं है (देखें रुकने की समस्या), ये उपकरण इस तथ्य का फायदा उठाते हैं कि मानव प्रोग्रामर अधिकांशतः सॉफ़्टवेयर लिखते समय कुछ प्रकार की सरल गलतियाँ करते हैं।
इंस्ट्रूमेंटेशन
चल रहे सॉफ़्टवेयर के प्रदर्शन की निगरानी करने के लिए उपकरण, या तो विशेष रूप से टोंटी (इंजीनियरिंग) जैसी समस्याओं का पता लगाने के लिए या कार्य को सही करने के लिए आश्वासन देने के लिए, स्पष्ट रूप से कोड में एम्बेड किया जा सकता है (इस प्रकार इस कथन के रूप में सरल PRINT "I AM HERE"), या उपकरण के रूप में प्रदान किया गया। यह अधिकांशतः आश्चर्य की बात है कि अधिकांश समय कोड के एक टुकड़े द्वारा कहाँ लिया जाता है, और मान्यताओं को हटाने से कोड को फिर से लिखा जा सकता है।
परीक्षण
सॉफ़्टवेयर परीक्षक वे लोग होते हैं जिनका प्राथमिक कार्य बग ढूंढना या परीक्षण का समर्थन करने के लिए कोड लिखना होता है। कुछ परियोजनाओं पर, कार्यक्रम विकसित करने की तुलना में परीक्षण पर अधिक संसाधन खर्च किए जा सकते हैं।
परीक्षण के समय माप शेष संभावित बगों की संख्या का अनुमान प्रदान कर सकते हैं; यह अधिक विश्वसनीय हो जाता है क्योंकि किसी उत्पाद का परीक्षण और डेवलोपमेन्ट किया जाता है।[citation needed]
डिबगिंग
बग्स को ढूँढना और ठीक करना, या डिबगिंग, कंप्यूटर प्रोग्रामिंग का एक प्रमुख भाग है। एक शुरुआती कंप्यूटिंग अग्रणी मौरिस विल्क्स ने 1940 के दशक के अंत में अपने अहसास का वर्णन किया कि उनके जीवन का अधिकांश समय उनके अपने कार्यक्रमों में गलतियाँ खोजने में व्यतीत होगा।[24]
साधारणतयः, डिबगिंग का सबसे कठिन भाग बग ढूंढ रहा है। एक बार यह मिल जाने के बाद, इसे ठीक करना साधारणतयः अपेक्षाकृत आसान होता है। डिबगर्स के रूप में जाने जाने वाले प्रोग्राम प्रोग्रामर को कोड लाइन को लाइन से निष्पादित करके, चर मूल्यों को देखते हुए, और प्रोग्राम के व्यवहार को देखने के लिए अन्य सुविधाओं द्वारा बग का पता लगाने में मदद करते हैं। डिबगर के बिना, कोड जोड़ा जा सकता है जिससे कि प्रोग्राम निष्पादन का पता लगाने या मान दिखाने के लिए कंसोल या विंडो या लॉग फ़ाइल में संदेश या मान लिखे जा सकें।
चूंकि, डिबगर की सहायता से भी, बग्स का पता लगाना एक कला है। किसी प्रोग्राम के सेक्शन में बग के लिए यह असामान्य नहीं है कि वह पूरी तरह से अलग सेक्शन में फेल हो जाए, इस प्रकार इसे ट्रैक करना विशेष रूप से कठिन बना देता है (उदाहरण के लिए, ग्राफिक्स रेंडरिंग (कंप्यूटर ग्राफिक्स) रूटीन में एक त्रुटि जिसके कारण फ़ाइल इनपुट/आउटपुट रूटीन विफल हो जाता है), सिस्टम के स्पष्ट रूप से असंबंधित भाग में।
कभी-कभी, एक बग एक अकेला दोष नहीं होता है, लेकिन प्रोग्रामर की ओर से सोचने या योजना बनाने में त्रुटि का प्रतिनिधित्व करता है। ऐसी तार्किक त्रुटियों के लिए प्रोग्राम के एक भाग को ओवरहाल या फिर से लिखने की आवश्यकता होती है। कोड समीक्षा के एक भाग के रूप में, कोड के माध्यम से आगे बढ़ने और निष्पादन प्रक्रिया की कल्पना या लिप्यंतरण करने से अधिकांशतः बग को पुन। प्रस्तुत किए बिना त्रुटियां मिल सकती हैं।
अधिक विशिष्ट रूप से, बग का पता लगाने में पहला कदम इसे मज़बूती से पुन। प्रस्तुत करना है। एक बार जब बग पुनरुत्पादित हो जाता है, तो प्रोग्रामर उस बिंदु को खोजने के लिए त्रुटि को पुन। उत्पन्न करते समय डीबगर या अन्य टूल का उपयोग कर सकता है जिस पर प्रोग्राम भटक गया था।
इनपुट से कुछ बग का पता चलता है जो प्रोग्रामर के लिए फिर से बनाना मुश्किल हो सकता है। थेराक-25 विकिरण मशीन से होने वाली मौतों का एक कारण एक बग (विशेष रूप से, एक रन की स्थिति) था जो केवल तब हुआ जब मशीन ऑपरेटर ने बहुत तेजी से एक उपचार योजना में प्रवेश किया; ऐसा करने में सक्षम होने में अभ्यास के कई दिन लग गए, इसलिए बग परीक्षण में प्रकट नहीं हुआ या जब निर्माता ने इसे डुप्लिकेट करने का प्रयास किया। बग को खोजने में मदद करने के लिए जब भी सेटअप बढ़ाया जाता है, तो अन्य बग होने बंद हो सकते हैं, जैसे प्रोग्राम को डीबगर के साथ चलाना; इन्हें हाइसनबग्स कहा जाता है (हास्यास्पद रूप से अनिश्चितता सिद्धांत के नाम पर)।
1990 के दशक के बाद से, विशेष रूप से एरियन 5 फ्लाइट 501 आपदा के बाद, डिबगिंग के लिए स्वचालित सहायता में रुचि बढ़ी, जैसे अमूर्त व्याख्या द्वारा स्थिर कोड विश्लेषण।[25]
बग के कुछ वर्गों का कोड से कोई लेना-देना नहीं है। दोषपूर्ण दस्तावेज़ीकरण या हार्डवेयर सिस्टम उपयोग में समस्याएँ पैदा कर सकता है, भले ही को