ब्राउज़र गेम अल्फा-टेस्टर के लिए सुविधाजनक बग रिपोर्ट का संगठन

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



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

क्या शर्तें हैं?

• ब्राउज़र परियोजना, रणनीति;
• टेक्नोलॉजीज - फ्लैश + पीएचपी;
• आंतरिक बग ट्रैकर Redmine है।

क्या आवश्यक है

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

खिलाड़ी कैसा दिखता है?

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


चित्र 1

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


Fig.2

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

डेवलपर कैसा दिखता है?

हम थोड़ा कार्यान्वयन पर चर्चा करेंगे, लेकिन एक ही समय में ध्यान दें कि डेवलपर को अंतिम प्रक्रिया कैसे प्रस्तुत की जाती है।
तो:

• क्लाइंट सर्वर से पूरी तरह से जुड़ा हुआ है, अर्थात लगभग 2400 स्थानों पर जाँच की जाती है कि सर्वर क्या डेटा भेजता है, इसकी शुद्धता। यदि कुछ कहीं सुसंगत नहीं है, तो यह एक त्रुटि उत्पन्न करता है। इस स्थिति का एक सरल उदाहरण: एक इकाई को काम पर रखने के बाद, 1000 सोना रहना चाहिए, और 1001 बचे;
• त्रुटि में एक अद्वितीय टोकन होता है जिसमें त्रुटि कोड और त्रुटि स्थान का हैश शामिल होता है। उदाहरण: सर्वर विधि की प्रतिक्रिया की वैधता के लिए जाँच, यह 100500 विधियों की जाँच कर सकता है, यदि यह सत्यापित नहीं है, तो यह एक त्रुटि कोड है, और इसे एक हैश सौंपा गया है, जो उस डेटा सेट के लिए अद्वितीय है जिस पर त्रुटि हुई है, इसलिए प्रत्येक त्रुटि खेल के एक विशेष स्थान में इसका अपना विशिष्ट मार्कर है;
• यदि क्लाइंट कोई त्रुटि उत्पन्न करता है, या यदि परीक्षक गेम में केवल एक विजुअल कैंट देखता है, तो वह F12 दबाता है, और ऐसा आकृति चित्र 1 में दिखाई देता है।
• जब "भेजें" को इस रूप में दबाया जाता है, तो क्लाइंट एक संग्रह बनाता है जिसमें शामिल होता है: एक स्क्रीनशॉट (यदि खिलाड़ी से "भित्तिचित्र" - उनके साथ), परीक्षक की टिप्पणियों के साथ एक फ़ाइल, एक त्रुटि लॉग (यदि कोई था), एक त्रुटि कोड ( यदि वहाँ था), vorning लॉग (जो एक त्रुटि हो सकती है)
• फिर यह संग्रह रिपॉजिटरी में है, जहां इसे सर्वर पर अनपैक किया गया है और एक विस्तृत और सुविधाजनक त्रुटि रिपोर्ट के रूप में http लिंक के माध्यम से उपयोगकर्ता को दिखाया गया है, जिसे चित्र 2 में देखा जा सकता है।
• और अंत में, सबसे सुविधाजनक: इस प्रणाली का सर्वर Redmine में एक कार्य बनाता है, त्रुटि मार्कर द्वारा दोहराए जाने वाले कार्यों को ट्रैक करता है, और इसे परियोजना प्रबंधक को सौंपता है, निर्माता और अग्रणी डेवलपर्स को सर्वर और क्लाइंट को पर्यवेक्षकों के रूप में रखता है।
• खिलाड़ी की रिपोर्ट का लिंक कार्य से जुड़ा है।

यह पता चलता है कि रीडमाइन में कार्य कुछ इस प्रकार है:


3 चित्र

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

क्या यह पर्याप्त है?

... जिज्ञासु पाठक पूछेगा। उपयोगकर्ता त्रुटि संग्रह के सुविधाजनक संगठन के लिए - हाँ। हम विश्वास से अधिक हैं कि समय के साथ, सिस्टम बन्स, चिप्स के साथ बढ़ेगा, और कार्यात्मक रूप से विस्तार करेगा। यदि आप प्रोजेक्ट टीम को बढ़ाते हैं, तो आपको संभवतः चयन मानदंड लागू करना होगा, जैसा कि ऊपर वर्णित है।

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

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

निष्कर्ष

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