ऑटो टेस्ट: स्काईेंग टीम से दस लाइफहाक्स

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

हमारे पास ऑटोटेस्ट की व्यवस्था कैसे है

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

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

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

टेन लाइफ हैक्स

1. ब्राउज़र उदाहरण की भूमिका को स्पष्ट रूप से निर्दिष्ट करें । विमबॉक्स परीक्षणों की विशिष्टता यह है कि अधिकांश मामलों में दो या इससे अधिक ब्राउज़र इंस्टेंसेस का उपयोग किया जाता है, क्योंकि पाठ में कम से कम दो पक्ष होते हैं - एक शिक्षक और एक छात्र। एक समस्या हुआ करती थी: एक ब्राउज़र उदाहरण को एक संख्या द्वारा इंगित किया गया था, यह समझा गया था कि हर कोई समझता था कि browser1 1 एक शिक्षक था, और browser2 और उससे आगे के छात्र थे। लेकिन यह हमेशा ऐसा नहीं होता है, ऐसा होता है कि छात्र का ब्राउज़र पहले था। इसके अलावा, ऐसे परीक्षण हैं जहां छात्र खुद अलग हैं - उदाहरण के लिए, हमें यह सुनिश्चित करने की आवश्यकता है कि आप गलती से किसी और के सबक में नहीं आ सकते हैं। यह स्पष्ट करने के लिए कि कौन सा उपयोगकर्ता किस ब्राउज़र का उदाहरण है, उन्होंने स्पष्ट रूप से इसके नाम में भूमिका का संकेत देना शुरू कर दिया: teacher.browser । wrongStudent.browser , student.browser , wrongStudent.browser , आदि। अधिक पठनीय परीक्षण स्क्रिप्ट मिली।

   
   

2. हम तीर फ़ंक्शन का उपयोग करते हैं: () => , function() नहीं function() । सबसे पहले, ऐसा रिकॉर्ड छोटा है। दूसरे, एक अधिक आधुनिक वाक्य रचना, हम पुरातन से दूर जाने की कोशिश करते हैं। तीसरा, एरो फ़ंक्शंस जावास्क्रिप्ट से this सूचक के साथ समस्याओं से बचते हैं। तीर फ़ंक्शन इसके शाब्दिक दायरे का निर्माण नहीं करता है, इसलिए इसके बाहर परिभाषित किसी चीज़ को संदर्भित करना संभव है। क्लासिक बैसाखी से छुटकारा पाएं = this ।

   
   

3. हम प्लसस के साथ संघनन के बजाय टेम्प्लेट स्ट्रिंग्स का उपयोग करते हैं: `छात्र $ {छात्रनाम}, और“ छात्र ”+ छात्रनाम नहीं । हम प्लसस के साथ संयोजन के बजाय पैटर्न स्ट्रिंग्स का उपयोग करने का प्रयास करते हैं।

   
   
   

   यह एक आधुनिक वाक्यविन्यास है, यह अधिक पठनीय है, स्ट्रिंग के अंदर आप दोनों प्रकार के उद्धरण चिह्नों (एकल और दोहरे) का उपयोग कर सकते हैं और उनमें से किसी से भी बच नहीं सकते।

   
   

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

   
   

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

   
   

6. हम यूएटी के साथ काम करने की सुविधा के लिए कई थ्रेड्स में समानांतर में यूएटी को निष्पादित करते हैं । तथ्य यह है कि हमारे साथ ऐसा परीक्षण एक घंटे में एक बार चलता है और 15 मिनट के लिए एक धागे में चलता है। यदि कोई फ़ाइल इसमें होती है, तो यह पुनरारंभ हो जाएगी और अंत में आधे घंटे के लिए काम करेगी। एक तैनाती के दौरान, यह एक समस्या हो सकती है क्योंकि कतार में देरी हो रही है। समानांतर का उपयोग करने का परिणाम यूएटी पर 2-3 मिनट है (या 6 एक पुनरारंभ के साथ)। कतार तेजी से चलती है, समस्या के बारे में जानकारी या जो फ़ाइल गलत निकली है वह तेजी से आती है।

   
   

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

   
   

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

   
   

9. हम पाए जाने वाले कीड़े को ठीक करते हैं । ऑटोटैस्ट्स का मुख्य कार्य बग ढूंढना नहीं है, लेकिन जल्दी से यह सुनिश्चित करने के लिए कि वे वहां नहीं हैं, इसलिए कुछ का शायद ही कभी पता लगाया जाता है। फिक्सेशन दो समस्याओं को हल करता है: सबसे पहले, हम उन आंकड़ों को देखते हैं जहां समस्याएं अक्सर बनी रहती हैं और कौन सी होती हैं, और दूसरी बात, हम इस भावना से छुटकारा पाते हैं कि हम कुछ गलत कर रहे हैं। जब परीक्षणों में कुछ नहीं मिलता है, तो सवाल उठता है: क्या हम सब कुछ सही कर रहे हैं, शायद हमारे परीक्षणों का कोई फायदा नहीं है? और फिर एक टैबलेट दिखा रहा है कि जब वे पकड़ने में सक्षम थे: प्रति वर्ष 60 से अधिक कीड़े। उसी समय, ठेस और परीक्षण सर्वर दोनों पर परीक्षण चलाने का अर्थ स्पष्ट हो गया। ठेस पर लगातार लॉन्च - हर घंटे - बुनियादी सुविधाओं की समस्याओं को पकड़ने में मदद करता है (एक बाहरी सेवा अनुपलब्ध है, हमारा सर्वर नीचे चला गया), मैन्युअल परीक्षण से पहले लॉन्च नए कोड द्वारा शुरू किए गए ब्रेकडाउन का पता लगाता है।

   
   

10. लागू डेटा-क्यूए-आईडी विशेषताएँ , उदाहरण के लिए, [data-qa-id="btn-login"] । उद्देश्य: अधिक स्थिर चयनकर्ता। हम विकास टीम से सहमत थे कि यदि आप कुछ तत्वों के कार्यान्वयन में बदलाव करते हैं, यदि वे data-qa-id विशेषता देखते हैं, तो वे समझते हैं कि यह ऑटोटेस्ट के लिए है, वे इसे नहीं बदलते हैं और वे इसे सही तरीके से स्थानांतरित करते हैं। इस विशेषता का एक तार्किक नाम है, जो अपने आप में यह बताने में सक्षम है कि तत्व किसके लिए जिम्मेदार है। इसके अलावा, हम तत्व के विशिष्ट कार्यान्वयन पर निर्भर नहीं हैं - जो उस पर साधारण आईडी लटकाता है, उस पर कौन सा वर्ग, टैग, अंतर, लिंक लटका हुआ है। यह शांत हो गया: चयनकर्ता कम बार टूटते हैं, कुछ मामलों में इस विशेषता के साथ अतिरिक्त जानकारी प्रदर्शित की जा सकती है। उदाहरण के लिए, आपको एक पाठ में एक कदम के नाम की आवश्यकता है। यदि आप XPath के माध्यम से चरण के नाम को देखते हैं, तो चयनकर्ता लंबे, बहु-स्तरीय और निम्न-पठनीय हो सकता है, और यदि आप कोणीय कोड में html-टेम्पलेट के साथ काम करते हैं, तो आप लंबे XPP को दरकिनार करते हुए एक छोटे नाम योग्य विशेषता में प्रदर्शित कर सकते हैं।

    
    

टिप्पणियों में अपने जीवन के हैक और विचार साझा करें!