राम्रो बग रिपोर्टहरू कसरी लेख्ने: सिफारिसहरू

कल्पना गर्नुहोस् कि तपाईं एक विकासकर्ता हुनुहुन्छ, र एक परीक्षकले तपाईंलाई बग ल्याउँछ जुन रिग्रेसनको समयमा फेला परेको थियो। तपाईँ यो बग समाधान गर्न चाहनुहुन्छ, त्यसैले तपाईँले एउटा टिकट सिर्जना गर्न सोध्नुहुन्छ। तपाइँ पहिले नै कल्पना गर्दै हुनुहुन्छ कि तपाइँ यसलाई कसरी उठाउनुहुनेछ, यसमा पुल अनुरोधहरू लिङ्क गर्नुहोस्, र अनुमानहरू थप्नुहोस् ताकि उत्पादन प्रबन्धकसँग कुनै प्रश्नहरू छैनन्। केहि समय बित्छ, र नयाँ टिकट देखा पर्दछ, तर भित्र, त्यहाँ केवल एक जोडी लाइनहरू र स्क्रिनसटहरू छन्। सासको साथ, तपाइँ यो जानकारी प्रयोग गरेर बग पुन: उत्पादन गर्ने प्रयास गर्नुहुन्छ, तर त्यहाँ कुनै त्रुटि छैन। तपाइँ धेरै पटक प्रयास गर्नुहुन्छ, तर अन्त्यमा, तपाइँ परीक्षकलाई लेख्नुहुन्छ कि बग पुन: उत्पादन गर्न सकिँदैन, र स्पष्टीकरणको नयाँ चरण सुरु हुन्छ। तपाईं समय खर्च गर्दै हुनुहुन्छ जुन नयाँ कार्यहरूमा काम गर्न, अन्य बगहरू ठीक गर्न, वा प्रयोग गर्न सकिन्छ। एनिमे रिफ्याक्टर कोड हेर्न मेरो नाम हो; म एक हुँ, र म राम्रो बग रिपोर्ट बनाउँछ भनेर मेरो विचार साझा गर्ने प्रयास गर्नेछु। लामो परिचयको लागि माफ गर्नुहोस् - सुरु गरौं। Evgeny Domnin QA शीर्षक टिकट शीर्षकमा तीन प्रश्नहरूको जवाफ दिने प्रयास गर्नुहोस्: यो कहाँ हुन्छ? के हुन्छ? कुन परिस्थितिमा? एक अनुभवी विकासकर्ताले मुद्दा बुझ्नको लागि शीर्षकमा मात्र हेर्न आवश्यक छ। उदाहरणका लागि: लगइन पृष्ठ: गलत पासवर्ड प्रविष्ट गर्दा फिल्ड हाइलाइट गरिएको छैन वातावरण मैले प्रायः परीक्षकहरूले टिकटमा कुन वातावरणमा समस्या उत्पन्न भयो भनेर निर्दिष्ट गर्न बिर्सेको देखेको छु। यो विशेष गरी UI-सम्बन्धित टिकटहरूमा सान्दर्भिक छ, जहाँ वेबसाइट ठेगाना वा नेटवर्क अनुरोध देखिँदैन। सधैं यो निर्दिष्ट गर्नुहोस्। यदि टिकटमा छुट्टै फिल्ड छ भने, राम्रो, त्यहाँ राख्नुहोस्। यदि होइन भने, प्रजनन चरणहरूमा उल्लेख गर्नुहोस्, उदाहरणका लागि: व्यवस्थापक खाताको साथ स्टेजिङ वातावरणमा लग इन गर्नुहोस्। चरणहरूको कुरा गर्दै ... प्रजनन चरणहरू सबैभन्दा महत्त्वपूर्ण खण्डहरू मध्ये एक बग प्रजनन निर्देशनहरू हो। म फोकस गर्न दुई भागहरू हाइलाइट गर्नेछु: चरणहरूको ढाँचा (दृश्य) र सामग्री (डेटा भित्र)। दृश्य भाग संरचना कायम राख्नुहोस् बग रिपोर्टहरूको विभिन्न भिन्नताहरू छन्, तर शास्त्रीय रूपमा, तिनीहरूले निम्न खण्डहरू समावेश गर्नुपर्छ: चरणहरू अपेक्षित परिणाम वास्तविक परिणाम यो संरचना प्रयोग गर्नुहोस्, र यसलाई सधैं टाँस्नुहोस्। यो ती मामिलाहरू मध्ये एक हो जहाँ एकरूपताले मुद्दाको वर्णन गर्दा तपाईंको विचारहरू व्यवस्थित गर्न मद्दत गर्नेछ। नम्बर गरिएको सूची प्रयोग गर्नुहोस् अंकित सूची प्रयोग गरी चरणहरू तोड्नुहोस्। कहिलेकाहीँ, परीक्षकहरूले विस्तृत विवरणहरू लेख्छन्, तर पाठको निरन्तर ब्लकको रूपमा। यो नगर्नुहोस्। पाइलाहरू छुट्याएमा सबैलाई पढ्न धेरै सजिलो हुनेछ। सम्भव भएसम्म, व्याकरणीय त्रुटिहरू बिना लेख्नुहोस्। अब, यी चरणहरूको सामग्रीमा जाऔं। विवरणहरूमा सामान्य ज्ञान यदि बग पुन: उत्पादनको लागि महत्त्वपूर्ण छैन भने तपाईले प्रत्येक एकल कार्यलाई छुट्टै चरणमा विभाजन गर्न आवश्यक छैन - यो पढ्न र अभ्यासमा प्रयोग गर्न गाह्रो छ। एक चरणमा धेरै कार्यहरू समावेश गर्न नडराउनुहोस्। मेरो मतलब के हो? : खराब मा जानुहोस् test.com/login लगइन फिल्डमा क्लिक गर्नुहोस् लगइन प्रविष्ट गर्नुहोस् पासवर्ड फिल्डमा क्लिक गर्नुहोस् पासवर्ड प्रविष्ट गर्नुहोस् : राम्रो मा जानुहोस् र कुनै पनि खातामा लग इन गर्नुहोस् test.com/login हामी मानक प्रवाह पछ्याउँदा विकासकर्ताले स्वाभाविक रूपमा गर्ने कुराहरूमा चरणहरू तोडिरहेका छैनौं। जब मैले सुरु गरिरहेको थिएँ, मलाई लाग्थ्यो कि प्रत्येक एकल कार्यको आफ्नै कदम चाहिन्छ, तर यो आवश्यक छैन। अस्पष्टताबाट बच्नुहोस् सँधै प्रत्येक चरणमा जाँच गर्न विशेष अनुरोधको साथ चरणहरू पूरक गर्नुहोस्, र थिच्नको लागि निर्दिष्ट बटन लेख्नुहोस् (विशेष गरी यदि त्यहाँ एउटै नामका बटनहरू छन्)। परीक्षण डाटा समावेश गर्नुहोस् यदि त्रुटि तपाईंको खातासँग सम्बन्धित छ भने लगइन डाटा प्रदान गर्नुहोस्, र बग पुन: उत्पादन गर्न मद्दत गर्ने परीक्षण पेलोडहरू समावेश गर्न नहिचकिचाउनुहोस्। आफ्नो कदम पुन: समीक्षा गर्नुहोस् कहिलेकाहीँ, तपाईंले बगको सामना गरेपछि तुरुन्तै चरणहरू लेख्नुहुन्छ, तर तपाईंले पूर्ण बुझ्नको लागि एक चरण छुटेको वा बग पछि पुन: उत्पादन गर्न सकिँदैन भन्ने बाहिर आउन सक्छ। त्यस अवस्थामा, थप सटीक चरणहरू फेला पार्न आवश्यक हुन सक्छ। अपेक्षित नतिजा एउटा छुट्टै खण्ड अपेक्षित नतिजा हो, जहाँ हामीले चरणहरू पछ्याउँदा अपेक्षित नतिजा (अचम्मको रूपमा) वर्णन गर्छौं। यो खण्ड अवस्थित हुनैपर्छ भन्ने बाहेक यहाँ धेरै विशेष सिफारिसहरू छैनन् — विकासकर्ताले कार्यक्षमताले कस्तो व्यवहार ल्याउनुपर्छ भनेर बुझ्न आवश्यक छ। "सबै कुरा राम्रोसँग काम गर्नुपर्छ" जस्ता वाक्यांशहरूले यसलाई काट्दैनन् - विशिष्ट व्यवहार लेख्नुहोस्। वास्तविक परिणाम यहाँ, हामीले चरणहरू पछ्याउँदा वास्तवमा के भयो भनेर लेख्छौं। विशिष्टता यहाँ पनि महत्त्वपूर्ण छ। "सबै बिग्रियो" मात्र नलेख्नुहोस् (यद्यपि यो सम्भवतः के भयो)। सबै बिग्रिएको देखाउने संकेतकहरू वर्णन गर्नुहोस्। उदाहरणका लागि: GET /accounts अनुरोधमा 500 त्रुटि फर्काइन्छ , र UI अवरुद्ध गरिएको छ। प्रयोगकर्ता पृष्ठबाट बाहिर निस्कन वा तत्वहरूमा क्लिक गर्न सक्दैन। पृष्ठ पुन:ताजा गर्नाले अनुरोध पुन: ट्रिगर गर्दछ र उही त्रुटिमा जान्छ। अन्य शब्दहरूमा, वास्तविक प्रभाव र यसले प्रयोगकर्ताको प्रवाहलाई कसरी प्रभाव पार्छ भनेर वर्णन गर्नुहोस्। अतिरिक्त फाइलहरू यो एक अलग खण्ड उल्लेख गर्न लायक छ। यो जहाँ तपाइँ बग वर्णन गर्ने अतिरिक्त जानकारी संलग्न गर्नुहुन्छ। म केहि विकासकर्ताहरूलाई चिन्छु जो प्रजनन चरणहरू पढ्ने प्रशंसकहरू छैनन् र वास्तविक परिणाम र थप सामग्रीहरूमा जान्छन् जसले यसलाई व्याख्या गर्दछ। त्रुटिको स्क्रिनसटहरू सय पटक सुन्नु भन्दा एक पटक हेर्नु राम्रो हो। के भइरहेको छ र कहाँ भइरहेको छ भनी देखाउने यो उत्कृष्ट तरिका हो। सधैँ स्क्रिनसट संलग्न गर्ने प्रयास गर्नुहोस्। अनुरोध गर्नुहोस् यदि त्यहाँ त्रुटि भएको ठाउँमा अनुरोध छ भने, यसलाई सधैं टिकटमा समावेश गर्नुपर्छ। यद्यपि, अनुरोधहरूले धेरै फरक प्यारामिटरहरू समावेश गर्दछ। म निम्न समावेश गर्न महत्त्वपूर्ण रूपमा हाइलाइट गर्छु: - अनुरोध आफैं, जुन तपाइँ ब्राउजरको नेटवर्क खण्डबाट प्राप्त गर्न सक्नुहुन्छ जहाँ परीक्षण भइरहेको छ। त्रुटि URL - , , , , आदि। त्यहाँ धेरै विधिहरू छन्, जस्तै त्यहाँ एउटै URL सँग अनुरोधहरू छन् तर फरक विधिहरू छन्। टिकटमा निर्दिष्ट गर्न नबिर्सनुहोस्। विधि GET POST TRACE OPTION - अर्को महत्त्वपूर्ण बिन्दु। तपाईंले सायद यो बिर्सनुहुने छैन, तर सर्भरबाट कुन कोड फर्काइएको थियो भनेर नोट गर्न नबिर्सनुहोस्। त्रुटि कोड - यो हामीले सर्भरमा हाम्रो अनुरोधमा पठाएको डाटा हो। यो हरेक अनुरोधमा उपस्थित हुँदैन (जस्तै, HEAD वा GET सँग यो छैन), तर यो त्रुटिको कारण हुन सक्छ। पेलोड - सर्भरको प्रतिक्रिया। कहिलेकाहीँ, यसले पूर्ण त्रुटि समावेश गर्दछ, यो कहाँ भयो भनेर देखाउँदै पनि, जबकि अन्य पटक यो त्रुटिको प्रकारको लागि ब्याकइन्डमा सेट अप गरिएको पूर्वनिर्धारित प्लेसहोल्डर हो। यसलाई समावेश गर्न निश्चित गर्नुहोस् - यसले विकासकर्ताको धेरै समय बचत गर्नेछ। प्रतिक्रिया कन्सोल लगहरू कहिलेकाहीँ, त्रुटिहरू कन्सोलमा भेटिन्छन्, र यी टिकटमा थप्न सकिन्छ। सायद तपाईंले पहिले नै यो गरिरहनुभएको छ, तर म यो नोट गर्नेछु कि पाठको ठूलो ब्लक सधैं फाइलको रूपमा बचत गर्न सकिन्छ र टिकटमा थप्न सकिन्छ। यसले लग र टिकट दुवैको पठनीयता सुधार गर्दछ। .log यो सबै राम्रो र राम्रो छ, तर ... यो सबै राम्रो र राम्रो छ, तर हामी सबै कुरा यति राम्रो देखिने समय कहाँ पाउने? समयसीमा गइरहेको छ, प्रबन्धक रिसाउँदै छन्, उत्पादनमा अवरोधक छ, र मलाई बसेर सबै कुरा लेख्न भनिएको छ? म विकासकर्तालाई सिधै सन्देश पठाउनेछु, र त्यो हो। यो एउटा तार्किक तर्क हो जुन उठ्न सक्छ। म एक परीक्षकको उत्तम संसारको बारेमा कुनै भ्रम राख्दिन, जहाँ परीक्षणको लागि पर्याप्त समय छुट्याइएको छ, सबै कुरा प्रक्रियाद्वारा जान्छ, र पूर्ण र उच्च-गुणस्तरको कागजातहरू राखिएको छ। म बुझ्छु—अक्सर, यो समयको सङ्कट, जलिरहेको... राम्रो, आँखा, र सबै कुरा समयमै पूरा गर्ने दौड हो। साना त्रुटिहरू थुप्रिन्छन्, सन्दर्भ स्विचिङको कारणले बढी समय लाग्छ, र खराब अभ्यासहरूको नेतृत्व गर्दछ। यदि हामीले बिस्तारै सुधारहरू कार्यान्वयन गर्न थाल्छौं र तिनीहरूले कसरी काम गर्छन् भनेर अनुगमन गर्न थाल्यौं भने, हामी सबै सहभागीहरूका लागि थप स्थिर, मानकीकृत, र भविष्यवाणी गर्न सकिने प्रक्रिया सिर्जना गर्न सक्षम हुनेछौं। परियोजना प्रबन्धकले उत्पादनमा के भइरहेको छ भनेर बुझ्नेछन् अपडेटको लागि सबैलाई तान्नु पर्दैन, विकासकर्ताले प्रजनन अवस्थाहरूमा स्पष्टीकरणको लागि परीक्षकलाई सोध्नु पर्दैन र तिनीहरूलाई परीक्षणबाट टाढा लैजानेछैन, र सरोकारवालाहरूले बदलेमा, उत्पादनको प्रगतिको स्पष्ट दृष्टिकोण छ। यो लेख शुरुवात गर्नेहरूका लागि बढी उद्देश्य हो जसले परीक्षणमा आफ्नो मार्ग सुरु गरिसकेका छन्। मलाई विश्वास छ कि साना कदमहरूले ठूला नतिजाहरू निम्त्याउँछ, र यस लेखमा दिइएका सिफारिसहरूले उच्च-गुणस्तरको बग रिपोर्टहरू ल्याउनेछन्। यदि तपाइँसँग कुनै प्रश्नहरू, सुझावहरू, असहमतिहरू, वा गुनासोहरू छन् भने, तिनीहरूलाई टिप्पणीहरूमा छोड्न नहिचकिचाउनुहोस् - म तपाईंको राय सुन्न इच्छुक छु!

राम्रो बग रिपोर्टहरू कसरी लेख्ने: सिफारिसहरू

About Author

टिप्पणीहरू

ह्याङ्ग ट्यागहरू

यो लेख मा प्रस्तुत गरिएको थियो

Related Stories

The HackerNoon Newsletter: Futures of Ethereum II - Censorship Resistance (2/16/2025)

The HackerNoon Newsletter: So.. How Does One REALLY Determine AI Is Conscious? (2/8/2025)

The HackerNoon Newsletter: Climb the Ranks: 3 Actionable Tips to Become a Top Writer (2/12/2025)

Transcripts Don't Lie: HackerNoon's New YouTube Feature Keeps Readers on the Same Page

The HackerNoon Newsletter: Futures of Ethereum II - Censorship Resistance (2/16/2025)

The HackerNoon Newsletter: So.. How Does One REALLY Determine AI Is Conscious? (2/8/2025)

The HackerNoon Newsletter: Climb the Ranks: 3 Actionable Tips to Become a Top Writer (2/12/2025)

Transcripts Don't Lie: HackerNoon's New YouTube Feature Keeps Readers on the Same Page

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps