दुखद परीक्षा के बारे में

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

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

सारांश:

• यूनिट-टेस्ट कोड कवरेज
• सेलेनियम
• स्वचालित परीक्षण
• प्रत्येक त्रुटि की विस्तृत घोषणा
• साप्ताहिक विश्लेषण और पाया कीड़े का मूल्यांकन
• Acunote के साथ सिंक करें

हम खोजते हैं और पाते हैं

बग की खोज करने के लिए, हम यूनिट-परीक्षण, सेलेनियम प्लग-इन फायरफ़ॉक्स, इंटरफ़ेस के मैनुअल परीक्षण का उपयोग करते हैं।

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

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

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

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

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

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

घोषित

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

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

तस्वीर क्लिक करने योग्य है।

प्राथमिकता क्षेत्र में भरने के लिए कई विकल्प हैं:

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

प्राथमिकता को Acunote में कार्य प्राथमिकताओं के साथ पूरी तरह से सिंक्रनाइज़ किया गया है।

ज्यादातर समय मैं इस तालिका और विकास विभाग के प्रमुख के साथ काम करता हूं। डेवलपर्स को नई प्रविष्टियों को जोड़ने और पुराने को संपादित करने के लिए कनेक्ट करने का प्रयास किया गया था, लेकिन प्रोग्रामर एक तालिका में काम करने में सहज नहीं हैं । यदि किसी टीम को कोई त्रुटि मिलती है, तो वह मुझे स्काइप में या ई-मेल से इसकी सूचना देता है।

परिणामस्वरूप, त्रुटि का जीवन चक्र कुछ इस तरह दिखता है:
1. एक बग पाया जाता है और तालिका में दर्ज किया जाता है;
2. यदि बग को P0 या P1 प्राथमिकता दी जाती है, तो यह अनियोजित कार्य के रूप में वर्तमान स्प्रिंट में जाता है;
3. प्रोग्रामर बग को ठीक करता है, जब मैं इसे बंद करता हूं तो मुझे इसके बारे में पता चलेगा;
4. मैं सुधार की जांच करता हूं - इस कदम को छोड़ नहीं दिया जा सकता है - और तालिका को अपडेट करें।

योजना बना रहे हैं

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

विश्लेषण

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

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

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

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

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

PS अंत तक लेख पढ़ने के लिए धन्यवाद। एक सवाल है? पूछो, जवाब देना दिलचस्प होगा!