How Guru’s Engineers Use Cypress for Better Burn Testing
बर्न परीक्षण को संभालने का बेहतर तरीका चाहिए? हमारे दो फ्रंट एंड इंजीनियरों ने साइप्रस का उपयोग करके QA को संभालने के तरीके में सुधार करने का एक तरीका पाया है।
हम गुरु में ज्ञान साझा करने के लिए समर्पित हैं, और जब हम कुछ नया और सहायक खोजते हैं, तो हम चाहते हैं कि दुनिया को पता चले! हमारी इंजीनियरिंग टीम अपने परीक्षण और गुणवत्ता आश्वासन प्रक्रिया में साइप्रस का उपयोग करती है। उन्होंने बेहतर बर्न परीक्षण चलाने के लिए एक नया तरीका खोजा है, और वे इसे अन्य इंजीनियरों और परीक्षणकर्ताओं के साथ साझा करना चाहते हैं।
पिछले वर्ष में, हम अपने परीक्षण कवरेज को बढ़ाने पर ध्यान केंद्रित कर रहे हैं — विशेष रूप से, एंड-टू-एंड परीक्षण जो यह सुनिश्चित करता है कि हमारे उत्पाद प्रवाह के विभिन्न हिस्से सही तरीके से कार्य करते हैं जब हम कोड अपडेट करते हैं। इस प्रकार के परीक्षण के लिए, हम एक उपकरण का उपयोग करते हैं जिसे साइप्रस कहा जाता है, जो हमारी वेब ऐप और गूगल क्रोम एक्सटेंशन के साथ उपयोगकर्ता व्यवहार का अनुकरण करता है। यह परीक्षण सूट हर पुल अनुरोध पर चलता है ताकि यह सुनिश्चित हो सके कि नया कोड हमारे UI में चीजों को तोड़ नहीं रहा है। हम यह भी चाहते हैं कि यदि हमारी साइप्रस सूट हमारे प्रोडक्शन शाखा में विफल होती है तो रिलीज़ बाहर जाने से रोका जाए।
पारंपरिक परीक्षण में हम क्या खोजते हैं
एक समस्या जिसका हम सामना कर चुके हैं, वह है कि हमारे कुछ परीक्षण फेल हो जाते हैं, लेकिन UI या कोड से जुड़े कारणों के लिए नहीं। तो, साइप्रस हमें इन मामलों में कैसे मदद करता है? हम साइप्रस को एक उपयोगकर्ता के रूप में कार्य करने देते हैं जिसका व्यवहार हम परिभाषित कर सकते हैं। कुछ ऐसे कई चर हैं जो साइप्रस को विफलता बताने के लिए प्रेरित कर सकते हैं, लेकिन एक उपयोगकर्ता के दृष्टिकोण से, कुछ भी गलत प्रतीत नहीं होता है।
उदाहरण के लिए, एक परीक्षण हो सकता है जो कहता है, “वेब ऐप के इस भाग पर जाएं > एक नया गुरु कार्ड जोड़ें > उम्मीद करें कि निर्माण के बाद की स्थिति दिखाई दे।” यदि एक कार्ड बनाने की लोडिंग स्थिति थोड़ी देर के लिए रुकी रहती है और साइप्रस निर्माण के बाद की स्थिति के लिए देखना शुरू कर देता है, तो यह परीक्षण विफल हो सकता है (हालांकि, आमतौर पर, यह परीक्षण पास होगा)। यदि यह एक पुल अनुरोध पर एक बार पास होता है, तो हम उस कोड को मर्ज करने में सक्षम होते हैं जो कभी-कभी फ्लेक कर सकता है। लेकिन हम नहीं जान पाएंगे कि क्या ऐसा होता है; पास किया गया परीक्षण इस बात की गारंटी नहीं है कि कोड सही है।
इस प्रकार की स्थिति हमारे परीक्षण कवरेज की विश्वसनीयता को कम कर देती है। नतीजतन, जब हमारी तैनाती पाइपलाइन में परीक्षण विफलता आती है, तो हमें सत्यापित करना होता है कि क्या यह UI का मुद्दा है — या परीक्षण का। इसे ठीक करने के लिए हमने इस बारे में सोचना शुरू किया कि हम यह कैसे पता लगा सकते हैं कि कोई परीक्षण फ्लेक कर सकता है इससे पहले कि यह हमारी उत्पादन कोड शाखा में जाए।
बर्न परीक्षण कैसे मदद करता है
बर्न परीक्षण में प्रवेश करें। बर्न परीक्षण एक प्रक्रिया है जिसका उपयोग कुछ चीजों का परीक्षण करने के लिए किया जाता है जो अधिक कठिन या चरम परिस्थितियों के तहत किया जाता है। इसे कभी-कभी तनाव परीक्षण या लोड परीक्षण भी कहा जाता है, यह विधि या विशेष क्षेत्र पर निर्भर करता है जो परीक्षण किया जा रहा है।
गुरु में, हम बर्न परीक्षण का उपयोग अपने साइप्रस सूट का एक हिस्सा के रूप में करते हैं जो किसी भी नए या संशोधित परीक्षण के लिए जोड़े गए हैं। इन परीक्षणों को मर्ज करने से पहले, हम उन्हें कई बार लगातार चलाते हैं और सभी को अगले चरण पर जाने के लिए पास होना चाहिए हमारे सर्कलसीआई बिल्ड पाइपलाइन में।
यह कदम उस समय होता है जब हम पूरी साइप्रस परीक्षण सूट चलाते हैं। इस आदेश का लाभ यह है कि यदि हमारा बर्न परीक्षण चरण एक विफलता उत्पन्न करता है, तो हम पूरे चेक को पहले विफलता के रूप में चिह्नित कर सकते हैं। बाकी सूट को छोड़ने से हमें समय बचाने और नए परीक्षणों को सुनिश्चित करने में लगने वाले चक्रों की संख्या को कम करने में मदद मिलती है कि वे उतने विश्वसनीय और दोष-प्रतिरोधी हों जितना हमें होना चाहिए।
हम जिन फ़ाइलों की तलाश कर रहे हैं, उन्हें खोजने के लिए, हम वर्तमान शाखा पर git diff का उपयोग करते हैं और पैरोमीटर के रूप में उस आउटपुट को एक टूल को प्रदान करते हैं जिसे cypress-repeat कहते हैं जो हमें उन परीक्षणों को किसी भी निर्दिष्ट समय में चलाने की अनुमति देता है, प्रभावी रूप से बर्न परीक्षण को हमारे एंड-टू-एंड परीक्षण सूट में एक कदम के रूप में जोड़ता है।
परिणाम
हमारी परीक्षण योजनाओं में इस बदलाव ने कुछ काफी अच्छे सकारात्मक परिणाम दिए हैं। हमारे लिए, बर्न परीक्षण जोड़ना भरोसेमंद परीक्षणों को खोजने में लगने वाले समय को 30 मिनट तक कम कर सकता है। यह नए कार्यक्षमता जोड़ने के लिए टर्नअराउंड समय को भी बेहतर बनाता है। चूंकि अब नए परीक्षण पहले चलाए जाते हैं, वे हमारे बाकी निर्माण प्रक्रिया में जारी रखने से पहले स्थिरता की पुष्टि करने की अनुमति देते हैं।
कुल मिलाकर, हमारे परीक्षण प्रक्रियाओं को और अधिक कुशल और मजबूत बनाने पर निरंतर ध्यान देना पूरे इंजीनियरिंग टीम के नई विशेषताओं को तेजी से शिप करने के विश्वास को बढ़ाता है। हम बग को तेजी से ठीक कर रहे हैं और हमारे सभी कोडबेस में काम करना आसान बना रहे हैं। हम उम्मीद करते हैं कि यह पोस्ट अन्य साइप्रस उपयोगकर्ताओं को बेहतर परीक्षण बनाने और पूरे टीमों को अधिक कुशलता से निर्माण करने में मदद करेगी।
हम गुरु में ज्ञान साझा करने के लिए समर्पित हैं, और जब हम कुछ नया और सहायक खोजते हैं, तो हम चाहते हैं कि दुनिया को पता चले! हमारी इंजीनियरिंग टीम अपने परीक्षण और गुणवत्ता आश्वासन प्रक्रिया में साइप्रस का उपयोग करती है। उन्होंने बेहतर बर्न परीक्षण चलाने के लिए एक नया तरीका खोजा है, और वे इसे अन्य इंजीनियरों और परीक्षणकर्ताओं के साथ साझा करना चाहते हैं।
पिछले वर्ष में, हम अपने परीक्षण कवरेज को बढ़ाने पर ध्यान केंद्रित कर रहे हैं — विशेष रूप से, एंड-टू-एंड परीक्षण जो यह सुनिश्चित करता है कि हमारे उत्पाद प्रवाह के विभिन्न हिस्से सही तरीके से कार्य करते हैं जब हम कोड अपडेट करते हैं। इस प्रकार के परीक्षण के लिए, हम एक उपकरण का उपयोग करते हैं जिसे साइप्रस कहा जाता है, जो हमारी वेब ऐप और गूगल क्रोम एक्सटेंशन के साथ उपयोगकर्ता व्यवहार का अनुकरण करता है। यह परीक्षण सूट हर पुल अनुरोध पर चलता है ताकि यह सुनिश्चित हो सके कि नया कोड हमारे UI में चीजों को तोड़ नहीं रहा है। हम यह भी चाहते हैं कि यदि हमारी साइप्रस सूट हमारे प्रोडक्शन शाखा में विफल होती है तो रिलीज़ बाहर जाने से रोका जाए।
पारंपरिक परीक्षण में हम क्या खोजते हैं
एक समस्या जिसका हम सामना कर चुके हैं, वह है कि हमारे कुछ परीक्षण फेल हो जाते हैं, लेकिन UI या कोड से जुड़े कारणों के लिए नहीं। तो, साइप्रस हमें इन मामलों में कैसे मदद करता है? हम साइप्रस को एक उपयोगकर्ता के रूप में कार्य करने देते हैं जिसका व्यवहार हम परिभाषित कर सकते हैं। कुछ ऐसे कई चर हैं जो साइप्रस को विफलता बताने के लिए प्रेरित कर सकते हैं, लेकिन एक उपयोगकर्ता के दृष्टिकोण से, कुछ भी गलत प्रतीत नहीं होता है।
उदाहरण के लिए, एक परीक्षण हो सकता है जो कहता है, “वेब ऐप के इस भाग पर जाएं > एक नया गुरु कार्ड जोड़ें > उम्मीद करें कि निर्माण के बाद की स्थिति दिखाई दे।” यदि एक कार्ड बनाने की लोडिंग स्थिति थोड़ी देर के लिए रुकी रहती है और साइप्रस निर्माण के बाद की स्थिति के लिए देखना शुरू कर देता है, तो यह परीक्षण विफल हो सकता है (हालांकि, आमतौर पर, यह परीक्षण पास होगा)। यदि यह एक पुल अनुरोध पर एक बार पास होता है, तो हम उस कोड को मर्ज करने में सक्षम होते हैं जो कभी-कभी फ्लेक कर सकता है। लेकिन हम नहीं जान पाएंगे कि क्या ऐसा होता है; पास किया गया परीक्षण इस बात की गारंटी नहीं है कि कोड सही है।
इस प्रकार की स्थिति हमारे परीक्षण कवरेज की विश्वसनीयता को कम कर देती है। नतीजतन, जब हमारी तैनाती पाइपलाइन में परीक्षण विफलता आती है, तो हमें सत्यापित करना होता है कि क्या यह UI का मुद्दा है — या परीक्षण का। इसे ठीक करने के लिए हमने इस बारे में सोचना शुरू किया कि हम यह कैसे पता लगा सकते हैं कि कोई परीक्षण फ्लेक कर सकता है इससे पहले कि यह हमारी उत्पादन कोड शाखा में जाए।
बर्न परीक्षण कैसे मदद करता है
बर्न परीक्षण में प्रवेश करें। बर्न परीक्षण एक प्रक्रिया है जिसका उपयोग कुछ चीजों का परीक्षण करने के लिए किया जाता है जो अधिक कठिन या चरम परिस्थितियों के तहत किया जाता है। इसे कभी-कभी तनाव परीक्षण या लोड परीक्षण भी कहा जाता है, यह विधि या विशेष क्षेत्र पर निर्भर करता है जो परीक्षण किया जा रहा है।
गुरु में, हम बर्न परीक्षण का उपयोग अपने साइप्रस सूट का एक हिस्सा के रूप में करते हैं जो किसी भी नए या संशोधित परीक्षण के लिए जोड़े गए हैं। इन परीक्षणों को मर्ज करने से पहले, हम उन्हें कई बार लगातार चलाते हैं और सभी को अगले चरण पर जाने के लिए पास होना चाहिए हमारे सर्कलसीआई बिल्ड पाइपलाइन में।
यह कदम उस समय होता है जब हम पूरी साइप्रस परीक्षण सूट चलाते हैं। इस आदेश का लाभ यह है कि यदि हमारा बर्न परीक्षण चरण एक विफलता उत्पन्न करता है, तो हम पूरे चेक को पहले विफलता के रूप में चिह्नित कर सकते हैं। बाकी सूट को छोड़ने से हमें समय बचाने और नए परीक्षणों को सुनिश्चित करने में लगने वाले चक्रों की संख्या को कम करने में मदद मिलती है कि वे उतने विश्वसनीय और दोष-प्रतिरोधी हों जितना हमें होना चाहिए।
हम जिन फ़ाइलों की तलाश कर रहे हैं, उन्हें खोजने के लिए, हम वर्तमान शाखा पर git diff का उपयोग करते हैं और पैरोमीटर के रूप में उस आउटपुट को एक टूल को प्रदान करते हैं जिसे cypress-repeat कहते हैं जो हमें उन परीक्षणों को किसी भी निर्दिष्ट समय में चलाने की अनुमति देता है, प्रभावी रूप से बर्न परीक्षण को हमारे एंड-टू-एंड परीक्षण सूट में एक कदम के रूप में जोड़ता है।
परिणाम
हमारी परीक्षण योजनाओं में इस बदलाव ने कुछ काफी अच्छे सकारात्मक परिणाम दिए हैं। हमारे लिए, बर्न परीक्षण जोड़ना भरोसेमंद परीक्षणों को खोजने में लगने वाले समय को 30 मिनट तक कम कर सकता है। यह नए कार्यक्षमता जोड़ने के लिए टर्नअराउंड समय को भी बेहतर बनाता है। चूंकि अब नए परीक्षण पहले चलाए जाते हैं, वे हमारे बाकी निर्माण प्रक्रिया में जारी रखने से पहले स्थिरता की पुष्टि करने की अनुमति देते हैं।
कुल मिलाकर, हमारे परीक्षण प्रक्रियाओं को और अधिक कुशल और मजबूत बनाने पर निरंतर ध्यान देना पूरे इंजीनियरिंग टीम के नई विशेषताओं को तेजी से शिप करने के विश्वास को बढ़ाता है। हम बग को तेजी से ठीक कर रहे हैं और हमारे सभी कोडबेस में काम करना आसान बना रहे हैं। हम उम्मीद करते हैं कि यह पोस्ट अन्य साइप्रस उपयोगकर्ताओं को बेहतर परीक्षण बनाने और पूरे टीमों को अधिक कुशलता से निर्माण करने में मदद करेगी।
गुरु प्लेटफॉर्म की शक्ति का अनुभव स्वयं करें - हमारे इंटरैक्टिव प्रोडक्ट टूर को लें
