उन बगों के साथ क्या करना है जो फिर से नहीं करते हैं?

Question

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

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

इस तरह के परिदृश्य में आप क्या करते हैं?

Comments

"कॉम्पैक्ट फ्रेमवर्क और कोई लाइन नंबर नहीं हैं" हुह? यह कौनसी भाषा है?

— TheLQ

@ TheLQ - C # (विजुअल स्टूडियो 2008) अफसोस की बात है कि कॉम्पैक्ट फ्रेमवर्क में इसके किसी भी स्टैक के निशान पर लाइन नंबर नहीं हैं। (अधिक जानकारी के लिए इस सवाल को देखें stackoverflow.com/questions/3507545/…

— Vaccano

कार्यक्रम पर उपयोगी स्टैक निशान उत्पन्न करने के लिए समय बिताने वाली पहली चीज़ है।

Pics, या ऐसा नहीं हुआ। : पी

— कैमरून मैकफारलैंड

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

— टिम पोस्ट

Answer 1

बिना संदर्भ के बग बग नहीं है, यह एक अस्थायी है। समस्या आपका कोड हो सकता है, यह एक तृतीय पक्ष पुस्तकालय हो सकता है, यह हार्डवेयर हो सकता है, या यह सौर विकिरण हो सकता है, जिसके कारण यह एक एकल बिट के लिए स्वयं पर फ्लिप कर सकता है। यदि आप इसे कम से कम कुछ नियमितता के साथ पुन: उत्पन्न नहीं कर सकते हैं (भले ही "यह हर 10 या 20 बार मैं एक्स" करने के बाद एक बार होता है), तो यह आपके परीक्षक से बेहतर नहीं है कि आपको बताए "कुछ कहीं गलत हुआ - इसे ठीक करें" ।

आपको अपने परीक्षक को यह समझाना पड़ सकता है कि उसका काम सिर्फ इनपुट उत्पन्न करना नहीं है, जब तक कि कुछ टूट न जाए। यदि ऐसा होता, तो आप उसे यादृच्छिक संख्या जनरेटर से बदल सकते थे। उनकी नौकरी का एक हिस्सा बग्स की पहचान करना है, जो उन्हें उत्पादन करने के तरीके की पहचान करने के लिए मजबूर करता है।

Answer 2

अंततः अगर न तो डेवलपर और न ही परीक्षक बग को पुन: उत्पन्न कर सकता है तो इसे बंद कर दिया जाना चाहिए लेकिन इस तरह के रूप में चिह्नित किया जाना चाहिए।

हालाँकि, आपको उस बिंदु पर पहुंचने में कितना समय लगता है यह बहस का विषय है।

कुछ लोग तर्क देंगे कि यदि यह तुरंत प्रजनन योग्य नहीं है तो इसे तुरंत बंद कर देना चाहिए।

मैं आमतौर पर समस्या के प्रवर्तक से अधिक जानकारी प्राप्त करने का प्रयास करता हूं। मूल रिपोर्ट में वे कुछ भूल सकते हैं। आवश्यक चरणों के बारे में बातचीत करने से अक्सर लापता जानकारी का पता चल सकता है।

एक अंतिम विचार - "नो-रिप्रो" के रूप में बंद होने का मतलब निश्चित नहीं है। यदि कोई वास्तविक समस्या है, तो यह जल्दी या बाद में खुद को प्रकट करेगा और सभी जानकारी होने पर आपकी मदद करेगा जब आप समस्या को फिर से दोहरा सकते हैं।

Answer 3

कुछ और सुझाव:

1. अपने उत्पाद कोड में लॉगिंग (और न केवल एक keylogger:}) जोड़ें। "नो रिप्रो" बग फूल सकते हैं, लेकिन वे स्मृति या राज्य भ्रष्टाचार हो सकते हैं जो केवल एक गैरकानूनी तरीके से उपयोग किए जाने वाले गंदे सिस्टम पर होते हैं (जैसे कि ग्राहक कंप्यूटर)। लॉगिंग या ट्रेसिंग जानकारी आपको यह पता लगाने में मदद कर सकती है कि जब परीक्षक ने फ्लूक पाया तो क्या गलत हो सकता है।

2. डेटाबेस (या बग ट्रैकिंग के लिए जो भी आप उपयोग करते हैं) के बाकी "नो रिप्रो" बग को स्कैन करें। अक्सर, flukes उत्पाद के एक क्षेत्र में एक साथ टकराते हैं। यदि ऐसा लगता है कि एक घटक गलती पर है, तो कोड संभव flakiness के लिए घटक की समीक्षा करें, उस घटक में अतिरिक्त लॉगिंग जोड़ें - या दोनों।

3. आधा या एक घंटा ले और अपने परीक्षक परीक्षण देखें। उनके दृष्टिकोण से आपको पता चल सकता है कि क्या गलत हुआ (उदाहरण के लिए "दिलचस्प - मुझे नहीं पता था कि आप उस तरह से उस संवाद को प्राप्त कर सकते हैं")। आप यह भी पा सकते हैं कि वे अनायास ही एक संवाद या विन्यास कदम को छोड़ देते हैं। यह उनके सिर में थोड़ा निवेश करने के लिए समय के लायक है।

Answer 4

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

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

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

Answer 5

बग के दो प्रकार हैं जो प्रजनन योग्य नहीं हैं:

1) जिन्हें एक परीक्षक (या उपयोगकर्ता) ने एक बार देखा है, लेकिन या तो पुन: पेश करने का प्रयास नहीं किया गया है या नहीं किया गया है।

इन स्थितियों में आपको चाहिए:

• बहुत संक्षेप में उन कार्यों के मूल पाठ्यक्रम की जांच करें जो यह सुनिश्चित करने के लिए दोष दर्शाते हैं कि यह प्रतिलिपि प्रस्तुत करने योग्य नहीं है।

• परीक्षक / उपयोगकर्ता से बात करें कि क्या कोई अन्य जानकारी है जो मदद कर सकती है।

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

• यदि आपके पास अभी भी जाने के लिए पर्याप्त नहीं है, तो आपको उपयोगकर्ता / परीक्षक को यह समझाने की आवश्यकता है कि आपके पास पर्याप्त जानकारी नहीं है। उन्हें विनम्रता से बताएं कि पर्याप्त जानकारी क्या होगी और इसकी आवश्यकता क्यों है।

2) जहां वे मज़बूती से पुन: पेश नहीं किए जा सकते हैं, हालांकि यह साबित करने के लिए पर्याप्त सबूत (बार-बार होने वाली घटनाओं के संदर्भ में) है कि दोष मौजूद है, तो मैं देख रहा हूं कि ये डेवलपर मुद्दे हैं और डेवलपर - परीक्षक द्वारा समर्थित / उपयोगकर्ता - जांच की जरूरत है।

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

Answer 6

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

मैं दूसरों से सहमत हूँ कि बेहतर लॉगिंग पर काम करना प्राथमिकता है। इस बीच, अगर आपको संदेह है कि परीक्षक कौशल / आत्मविश्वास की कमी एक मुद्दा हो सकती है, तो मुझे वास्तव में डैनी फ़ॉइट से बग अलगाव पर यह लेख पसंद है - आप उसे उस पर शुरुआत के लिए इंगित कर सकते हैं।

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

Answer 7

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

यदि इसे उस बिंदु से पुन: प्रस्तुत नहीं किया गया है, तो इसे बंद कर दिया गया है, लेकिन इसे फिर से सामना करने पर फिर से खोल दिया जा सकता है।

Answer 8

इस परीक्षक के कार्य केंद्र पर एक keylogger छड़ी!

Comments

यदि आप वास्तव में भाग्यशाली हैं, तो कीबोर्ड लॉगर कुछ साइड-इफेक्ट पैदा कर सकता है जो बग को उस मशीन पर पुन: पेश करना असंभव बनाता है। कभी एक स्थिति है जहाँ printfकोड में अतिरिक्त डालने से बग गायब हो गया? :)

— स्कॉट व्हिटलॉक

एक वीडियो कैमरा की उपस्थिति एक बग का कारण होगा?

— जॉब

वीडियो कैमरा - नहीं, लेकिन जिंग या हाइपरकैम 2 - निश्चित रूप से हाँ;)

— चतुर्भुजपटटी 22'13

Answer 9

ठीक है, पहला काम एक प्रतिलिपि प्रस्तुत करने योग्य परीक्षण प्रणाली है। आपके परीक्षक में एक अच्छी तरह से परिभाषित प्रक्रिया होनी चाहिए - यदि संभव हो तो स्वचालित।

ये तीन शर्तें हैं:

• वही बाइनरी
• वही कदम
• एक ही मशीन

यदि बग उपर्युक्त 3 शर्तों के साथ छिटपुट रूप से प्रकट होता है, तो आगे अलग करना शुरू करें। सिस्टम स्टैक और उसके कॉन्फ़िगरेशन के प्रत्येक स्तर पर विचार करें।

स्मृति प्रबंधन त्रुटियों का पता लगाने का एक तरीका कई ओएस पर कई संकलक के साथ प्रोग्राम को चलाना है। Valgrind भी मदद कर सकता है।

हालांकि, आमतौर पर समानांतर सिस्टम गैर-रिप्रो बग को प्रेरित करने के लिए उत्तरदायी होते हैं। बफर साइज़ और प्रोसेसिंग स्पीड, एसिंक्र ओयो, डेटाबेस लॉक, वैरिएबल मेमोरी इंटरलेइंग्स जैसी चीजें; वे सभी मुद्दे उत्पन्न कर सकते हैं। और कितना आगे और कितने पर।

Answer 10

सबसे पहले, आपके पास एक कठोर परीक्षण प्रक्रिया होनी चाहिए (लेकिन मैं आपको समझता हूं, मेरी कंपनी में आपने जो वर्णित किया है वह अक्सर होता है)।

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