बग्स की जांच करना सीखना [बंद]


11

मुझे यकीन नहीं है कि इस कठिनाई को कैसे परिभाषित किया जाए। यह मुझे याद दिलाता है कि मुझे नौकरी मिलने से पहले संभावित कर्मचारियों के एक जोड़े ने परीक्षण किया था। वे कमरे में एक वस्तु उठाते हैं और फिर मुझे खुद से यह निर्धारित करने में मदद करने की अनुमति दी जाती है कि वह वस्तु क्या है (20 प्रश्नों की तरह)। मैं इस पर हास्यास्पद रूप से अच्छा था (नहीं, मुझे विनम्रता के लिए कभी भी उच्च अंक नहीं मिला), इसलिए मैंने मान लिया था कि मैं समस्याओं के निवारण के लिए वास्तव में अच्छा हूँ ...

लेकिन यहाँ मैं हाल ही में पता चला है। मैं उस स्थिति में वास्तव में अच्छा हूं क्योंकि कमरे में मौजूद हर चीज को देखना वास्तव में आसान है, इसलिए मैं अपनी समस्या को घटक भागों की कुछ अवधारणा के साथ संपर्क कर सकता हूं। संक्षेप में "मुझे पता है कि मैं क्या नहीं जानता"। लेकिन प्रोग्रामिंग के साथ मैं बहुत सारी स्थितियों में भाग लेता हूं जहां समस्या मेरे लिए पूरी तरह से अज्ञात है। मुझे पता है कि यह टूट गया है, लेकिन मुझे इसकी कोई अवधारणा नहीं है कि इसे कैसे तोड़ा जा सकता है। मैंने सभी निर्देशों का पालन किया है, मुझे तकनीक अच्छी तरह से पता है ...

अगर मैं ईमानदार हूं, तो मुझे लगता है कि मैं सिर्फ उन चीजों की कल्पना करने में कठिन समय बिता रहा हूं, जो गलत हो सकते हैं, इसलिए मैं उनका परीक्षण कर सकता हूं और उम्मीद है कि एक समाधान मिल जाएगा।

मैं उस कौशल को कैसे विकसित करूं? मेरी मदद करने के लिए मुझे क्या करने की आवश्यकता है, जाहिरा तौर पर, सीमित कल्पना उन तरीकों के साथ आती है जो मेरी परियोजना संभवतः टूट सकती हैं? क्या अभ्यास (शायद पहेलियाँ?) हैं जो मुझे इस पर बेहतर बना सकते हैं? मुझे पता है कि शायद सबसे बड़ा इलाज सिर्फ अनुभव है ... लेकिन अगर मैं कर सकता हूं तो मैं इस प्रक्रिया में तेजी लाने में मदद करने की उम्मीद कर रहा हूं। एक समय में कुछ घंटों के लिए मेरे कंप्यूटर स्क्रीन को घूरना भी मज़ेदार नहीं है ...


3
कल्पना कीजिए कि आपको कैसे लगता है कि यह काम कर सकता है, और जांच के रास्ते खोजने के लिए आउटपुट से इनपुट पर पीछे की ओर काम कर सकता है
स्टीवन ए। लोव

1
मैं वहां एक लिंक टॉस करूंगा - एक प्रोग्रामर कैसे बनें - सूचीबद्ध पहला कौशल "लर्न टू डिबग" है।

1
मैं "आउट ऑफ द बॉक्स" सोच के बारे में कुछ टॉस करना चाहता था। कीड़े के संबंध में, मैं अक्सर सोचता हूं कि पहली बात यह है कि केवल सभी इंटरेक्टिंग सिस्टम को सूचीबद्ध करना है, फिर मान लें कि इसका कोई भी हिस्सा गलती पर तब तक साबित हो सकता है जब तक कि अन्यथा साबित न हो। तब आपकी नौकरी आसान हो जाती है: मान लें कि घटक विफल हो रहा है, और एक ऐसा तरीका खोजें जो पहले भी हो सकता है अगर यह अतार्किक लगता है ("आउटपुट दूषित हो रहा है", आदि)। फिर साबित करें कि आपका घटक विफल नहीं हो रहा है, सबसे तत्काल इंटरैक्शन के साथ शुरू हो रहा है। तथ्य के बाद यह कल्पना की तरह लग सकता है लेकिन अक्सर यह केवल निराशावादी दृष्टिकोण से शुरू होता है।
J Trana

कोड की प्रत्येक पंक्ति के तहत एक printfया printlnजो भी आप उपयोग करते हैं वह 100% सुनिश्चित करें कि सब कुछ काम करता है कि आप इसे कैसे काम करना चाहते हैं। उसके बाद अपना कंसोल एप्लिकेशन चलाएं App > out.txtजिसमें विशाल फ़ाइल को देखने वाला कठिन भाग आता है .. कभी-कभी मेरी लॉग फाइलें कुछ मिलियन लाइनों से अधिक होती हैं और इसमें कुछ समय लग सकता है। बेशक सही तरीका डिबगर और ब्रेकप्वाइंट का उपयोग करना होगा लेकिन कभी-कभी ऐसा करना संभव नहीं होता है।
5

1
पढ़ें Pirsig के ज़ेन और मोटरसाइकिल रखरखाव की कला amazon.com/Zen-Art-Motorcycle-Maintenance-Inquiry/dp/0060589469
जेफरी केम्प

जवाबों:


11

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

स्पष्ट रूप से व्यापार के उपकरण, लॉग फाइलें, डिबगर आदि ऐसी धारणाओं को उजागर करने और वास्तविक प्रणाली के साथ अपने विश्व मॉडल को फिर से संरेखित करने में सहायक हैं। लेकिन जब तक आप महत्वपूर्ण धारणा पर सवाल उठाने के लिए तैयार नहीं होते हैं, उदाहरण के लिए "यह बुरा इनपुट नहीं हो सकता है क्योंकि हमारे पास व्यापक इनपुट जाँच है", आप अपना पूरा समय सिस्टम के गलत हिस्सों की जाँच करने में बिताएंगे, या बस यह नहीं जान पाएंगे कि और कहाँ देखना है। पहली जगह में।


3
मैं इसे किलियन कहने से नफरत करता हूं, लेकिन मुझे लगता है कि आपने सिर पर कील ठोक दी है। मैंने अपने "ज्ञान" पर बहुत गर्व किया है जो मैंने अपने समय पर हासिल किए गए सिस्टम के "ज्ञान" के लिए किया है और मुझे लगता है कि मैं गलत होने के विचार के लिए मानसिक रूप से प्रतिरोधी हूं। जैसा कि मैंने उल्लेख किया है, मैंने विनम्रता पर कभी उच्च स्कोर नहीं किया। मेरी खुद की मान्यताओं को चुनौती देने की आपकी सलाह के बाद वास्तव में मुझे अपने ही कोड में सामना कर रहे कुछ मुद्दों पर कुछ ठोस प्रगति करने की अनुमति मिली। इसलिए, धन्यवाद, मैं आगे बढ़ने को ध्यान में रखूंगा।
जे कैर

2
@JayCarr: " मानसिक रूप से गलत होने के विचार के लिए प्रतिरोधी " - क्या होगा यदि आप गलतियों को गलती के बजाय सीखने के स्रोत के रूप में देखने की कोशिश करते हैं? जब तक आप वहां नहीं रुकेंगे, तब तक गलत होने के साथ कुछ भी गलत नहीं है।
JensG

14

मेरी मदद करने के लिए मुझे क्या करने की आवश्यकता है, जाहिरा तौर पर, सीमित कल्पना उन तरीकों के साथ आती है जो मेरी परियोजना संभवतः टूट सकती हैं?

ज्यादातर मामलों में, मैं बिल्कुल कुछ नहीं कहूँगा। आपको उन चीजों का सपना नहीं देखना चाहिए जो प्रोग्राम को तोड़ने का कारण बन सकते हैं। आपको व्यवस्थित रूप से यह निर्धारित करना चाहिए कि इसके टूटने का कारण क्या है

आपको जानकारी के निम्नलिखित टुकड़ों के साथ डिबगिंग प्रक्रिया में जाना चाहिए:

  • जो कदम उठाए गए थे और जो बग पैदा करने के लिए दर्ज किए गए थे;
  • उन चरणों और सूचनाओं को देखते हुए कार्यक्रम क्या होना चाहिए;
  • कार्यक्रम क्या है जब उन कदमों और आदानों दिया कर।

यदि कोई त्रुटि संदेश है, तो उसके बारे में सभी जानकारी प्राप्त करें। यदि त्रुटि संदेश स्वयं स्पष्ट नहीं है, और आपको यह नहीं पता है कि व्यवहार में इसका क्या मतलब है (कुछ त्रुटि संदेश हमेशा विशेष रूप से उपयोगी नहीं होते हैं), तो इसके बारे में जानकारी प्राप्त करने के लिए Google, या StackOverflow, या किसी अन्य ऑनलाइन संसाधन का उपयोग करें। ।

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

यदि आपके कोड द्वारा फेंके गए अपवाद (और वहाँ होना चाहिए) के साथ प्रदान किए गए स्टैकट्रैक हैं, तो उल्लिखित कोड की पंक्तियों को देखें। लाइन ही वह नहीं हो सकती है जो वास्तव में समस्या पैदा कर रही है। यदि आपको जावा कोड के एक टुकड़े में NullPointerException मिलती है, तो स्टैकट्रेस आपको बताएगा कि आपने ऐसी किसी चीज़ का उपयोग करने की कोशिश की थी, जब आप इसे नहीं होने की उम्मीद कर रहे थे। यह समस्या का कारण बनने वाली रेखा के लिए आपको इंगित नहीं करता है, लेकिन यह आम तौर पर आपको यह बताता है कि चर का वह मान नहीं है जिसकी आप उससे अपेक्षा करते हैं, इसलिए आप उस चर को निर्धारित करने के लिए उस चर के किसी भी संदर्भ / असाइनमेंट को देख सकते हैं। सेट नहीं किया जा रहा है या मान गलत तरीके से सेट किया जा रहा है।

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

अभी भी कोई सुराग नहीं है कि समस्या क्या है? किसी से मदद मांगो । एक सहकर्मी, एक मित्र, एक ऑनलाइन समुदाय। उन सभी को दिखाएं जो आपने अभी-अभी किए हैं। उन्हें त्रुटि संदेश दिखाएं, स्टैकट्रैक्स, समझाएं कि प्रोग्राम सामान्य शब्दों में क्या करता है (यदि वे पहले से नहीं जानते हैं), इस विशेष उदाहरण में क्या करना चाहिए (उदाहरण 4 मान वापस करना), यह वास्तव में क्या कर रहा है (जैसे 5 मान लौटाते हुए)। यदि आपने इसे डीबगर में कोड की कुछ पंक्तियों तक सीमित कर दिया है, तो कहें "मुझे पता है कि समस्या कोड में इन पंक्तियों के कारण होती है, यह X का मान सेट कर रहा है जब इसे Y होना चाहिए, लेकिन मैं नहीं देख सकता ऐसा क्यों हो रहा है ”।

अपनी स्क्रीन पर कुछ घंटे घूर कर बिताना निश्चित रूप से मज़ेदार नहीं है, लेकिन ऐसा कोई कारण नहीं है जो आपको करना चाहिए। अगर आपके कोड में कोई समस्या है, तो आपको कोड के माध्यम से पढ़ना या कदम रखना होगा।


इस उत्तर को जज करने में थोड़ी जल्दी हो सकती है, जब मैं इसे पढ़ता था तो थोड़ा निराश हो जाता था। ध्वनि की सलाह। हत्यारों की टिप्पणियों से मुझे लगता है कि मेरी समस्या के दिल में बस और अधिक बात हुई। यही कारण है कि इसके बजाय चयनित उत्तर नहीं है।
Jay Carr

4

कुछ हद तक, यह एक आपराधिक मामले की जांच करने या मन की पहेली के समान है।

सबसे पहले, आपको पीड़ित मिला। मामले में थोड़ी देर खुदाई करने के बाद, आपने कुछ संदिग्धों की पहचान की और आपने एक कार्य परिकल्पना भी विकसित की कि कैसे पीड़ित व्यक्ति की हत्या हो सकती है। आप जांच करना जारी रखते हैं, अधिक उपयोगी जानकारी की तलाश में, आप समस्या के वास्तविक स्रोत के निकट और निकट हो जाते हैं।

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

और कभी-कभी आपको एहसास होता है, कि अपराधी को हाजिर करने के लिए आवश्यक सभी तथ्य और संकेत आधे घंटे पहले ही आपके सामने इंतजार कर रहे थे। यद्यपि, यह सबसे दिलचस्प भागों में से एक है, क्योंकि यदि आप अपने कार्यों और गलतियों की समीक्षा करते हैं, तो आप सीख सकते हैं और बेहतर हो सकते हैं । अपने आप से सवाल पूछें जैसे:

  • मैं समय की इस बर्बादी से कैसे बच सकता था?
  • मैंने पहली जगह में क्या देखा, और क्यों?
  • मैंने क्या और किन गलत धारणाओं पर भरोसा किया?

यह आपकी क्षमताओं को प्रशिक्षित करेगा। यह आपकी आंत की वृत्ति को भी विकसित करेगा , इसलिए समय के साथ आप उन सभी छोटी-छोटी चीजों को स्वचालित रूप से नोटिस करना सीख जाते हैं जो बहुत आसानी से अनदेखी हो जाती हैं, जिससे आप सही उत्तर की ओर अग्रसर होते हैं। अंत में, यह सब जानबूझकर अभ्यास के बारे में है

पिछले कम से कम हमेशा याद रखें कि शरलॉक होम्स ने हमें क्या सिखाया है: जब आपने असंभव को खत्म कर दिया है, तो जो कुछ भी है, हालांकि, असंभव है, सच्चाई होनी चाहिए।


3

मेरी मदद करने के लिए मुझे क्या करने की आवश्यकता है, जाहिरा तौर पर, सीमित कल्पना उन तरीकों के साथ आती है जो मेरी परियोजना संभवतः टूट सकती हैं?

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

यह आपको उन चीजों के प्रकार का एक अच्छा अवलोकन देगा जो आपके उत्पाद में गलत हैं। यदि आप आमतौर पर सभी प्रकार के सॉफ़्टवेयर में गलत तरीके से रुचि रखते हैं, विशेष रूप से सुरक्षा-प्रभाव दोषों पर जोर देने के साथ, मेरा सुझाव है कि आप CWE सूची पढ़ें: http://cwe.mitre.org/data/index.html


2

इसलिए एक विशिष्ट दोष को पुन: उत्पन्न करने और ठीक करने की कोशिश करने के बजाय, मेरा मानना ​​है कि आप नए परीक्षणों के बारे में सोचने के बारे में पूछ रहे हैं, जिसका उपयोग आप उत्पाद की जांच करने के लिए कर सकते हैं, यह देखने के लिए कि क्या उत्पाद उदाहरण के लिए उन परिस्थितियों में काम करता है: क्या होता है अगर मैं विशेष वर्णों में प्रवेश करता हूं साइन अप पेज का पासवर्ड, या क्या होगा अगर मैं प्रोग्राम को डेटाबेस में लिखते समय जबरदस्ती बंद कर दूं। इन मामलों को वास्तव में सोचना मुश्किल है।

पिछले 10 वर्षों में सॉफ्टवेयर विकास (एजाइल / एक्सपी / टीडीडी आदि) केवल स्पष्ट आवश्यकताओं को पूरा करने और फिर सुविधा समाप्त घोषित करने, और कुछ को तोड़ने के लिए हर संभव तरीका नहीं ढूंढने के मूल्य पर आ गया है (यदि आप संभव हैं तो अपवाद हैं) नासा के लिए काम करना या सफेद टोपी की सुरक्षा करना लेकिन फिर भी उपयोगकर्ता की कहानी के मानदंड में ऐसी चीजों को बाहर करने के लिए एक मामला होना चाहिए)।

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

कुछ लोग इन परीक्षणों के लिए आवश्यकताओं की स्पष्ट घोषणा होने की वकालत करते हैं, जिन्हें कोड यानी टेस्ट फर्स्ट (या टेस्ट ड्रिवेन डेवलपमेंट) से पहले लिखा जाना चाहिए।

हालाँकि मैं इस बात की सराहना करता हूं कि आप इस तरह से आवाज नहीं करते हैं जैसे आप एक नई परियोजना पर विचार कर रहे हैं जहां आप शुरू करने से पहले अपने खुद के विकास के सर्वोत्तम अभ्यास निर्धारित कर सकते हैं और इसके बजाय सॉफ्टवेयर लिखे जाने के बाद आ रहे हैं और 'इसे परखने' के लिए कहा जा रहा है। यह वास्तव में अधिक चुनौतीपूर्ण है लेकिन समान सिद्धांत लागू होते हैं, आप केवल एक बार इसका परीक्षण कर सकते हैं जब आप जानते हैं कि यह क्या करना चाहिए था। यदि आपके पास काम करने के लिए विकास टीम द्वारा मिलने वाली आवश्यकताओं की एक व्यापक सूची नहीं है, तो सवाल पूछना सबसे अच्छा तरीका है। आपकी टीम के आधार पर, यह नाजुक रूप से किए जाने की आवश्यकता हो सकती है क्योंकि सॉफ्टवेयर सिस्टम बनाने से पहले जिन लोगों ने अपनी आवश्यकताओं को स्पष्ट रूप से सूचीबद्ध नहीं किया था, उन्हें यह याद दिलाना पसंद नहीं है कि वे क्या चूक गए थे, लेकिन इस कार्य को अच्छी तरह से करना आवश्यक है।

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


बिल्कुल नहीं जिस सवाल का मैं जवाब देने के लिए देख रहा था, लेकिन उत्कृष्ट कमेंटरी किसी से कम नहीं है। मैं आपको वोट कर रहा हूं, यह बहुत उपयोगी टिप्पणी है।
जे कैर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.