क्लाउड में ककड़ी: उत्पाद तनाव परीक्षण के लिए बीडीडी लिपियों का उपयोग करना

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


हम ऐलिस प्लेटफॉर्म नामक एक उत्पाद बना रहे हैं और मैं अब आपको बताऊंगा कि उन्होंने लोड परीक्षण की समस्या को कैसे हल किया।



एलिस होटल के लिए जीरा है। हम उनकी इनसाइट्स से निपटने में उनकी मदद करने के लिए एक प्लेटफॉर्म बना रहे हैं। कंसीयज, फ्रंट डेस्क ऑपरेटर, क्लीनर - उन्हें भी टिकट की आवश्यकता होती है। उदाहरण के लिए: एक अतिथि कॉल> यह कहता है कि आपको कमरे को साफ करने की आवश्यकता है> कर्मचारी एक टिकट बनाता है> जो लोग साफ करते हैं, जानते हैं कि किस व्यक्ति को रखा गया है> निष्पादित करें> स्थिति बदलें।

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



सबसे महत्वपूर्ण बात: पिछले एक साल में हम 2 गुना बढ़ गए हैं, अब हमारे पास 50 लोगों के क्षेत्र में एक इंजीनियरिंग टीम है और हम 2019 में उपयोगकर्ता आधार को दोगुना करने की योजना बना रहे हैं। और यह मुख्य चुनौती है जो हमारा सामना करती है।

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

जैसा कि आप देख सकते हैं, अब तक हम रात में बहुत अच्छी तरह से नहीं सो रहे हैं। हम यह सुनिश्चित करने के लिए जानते हैं कि हमारा बुनियादी ढांचा गिर जाएगा। हम सच्चाई का सामना करते हैं और इसे समझते हैं। एक सवाल: कब? इस तरह हमने समझा कि लोड परीक्षण मोक्ष की कुंजी है। यही हमें ध्यान रखने की जरूरत है।



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

और हमें पता होना चाहिए कि यह सब झेल सकता है। पहले से जान लें, इससे पहले कि उपयोगकर्ता आते हैं और सब कुछ गिर जाएगा।

हम भी रिलीज करते हैं। हर हफ्ते। सोमवार को। बेशक, सभी रिलीज़ कार्यक्षमता, कहीं रखरखाव, कहीं बग फिक्स को विस्तारित नहीं करते हैं, लेकिन हमें यह समझना चाहिए कि उपयोगकर्ता इस पर ध्यान नहीं देंगे और उनका अनुभव खराब नहीं होगा।

लेकिन हम, अच्छे डेवलपर्स के रूप में, आलसी लोग हैं और काम करना पसंद नहीं करते हैं। इसलिए, उन्होंने समुदाय और Google से पूछा कि लोड परीक्षण के लिए क्या सेवाएँ / समाधान हैं। उनमें से बहुत से थे। कुछ साधारण चीजें हैं, जैसे कि अपाचे बेंच, जो बस एक साइट को url में सौ थ्रेड में मारती है। मशीन गन्स के साथ मधुमक्खियों का एक दुष्ट और अजीब संस्करण है, जहां सब कुछ समान है, लेकिन यह ऐसे उदाहरणों को शुरू करता है जो उड़ते हैं और आपके आवेदन डालते हैं। वहाँ JMeter है, वहाँ आप कुछ स्क्रिप्ट लिख सकते हैं, क्लाउड में चला सकते हैं।



सब कुछ ठीक लगता है, लेकिन, सोचने के बाद, हमने महसूस किया कि हमें वास्तव में काम करना है और पहले कई समस्याओं को हल करना है।



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

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

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



लोड पीढ़ी का मुद्दा तत्काल है, क्योंकि प्रत्येक उपकरण इसे उत्पन्न करने के लिए अपने तरीके से पूछता है। और यहां तक ​​कि जब आप यह सुनिश्चित करने में कामयाब रहे कि परिदृश्य पर्याप्त थे, तो सवाल उठता है: 2-4 गुना अधिक कैसे चलाएं? ऐसा लगता है: रन और सब कुछ ठीक है। लेकिन नहीं। इन अनुरोधों में सभी प्रकार की आईडी हैं - हम कुछ बनाते हैं, एक नई आईडी प्राप्त करते हैं, पुरानी आईडी को बदलते हैं और परीक्षण, जो संस्था को आईडी से लोड करता है, अपने क्षेत्र को दूसरे में बदलता है। और 10 परीक्षण जो एक ही इकाई को 10 बार लोड करते हैं, वे बहुत दिलचस्प नहीं हैं। क्योंकि 10 बार विभिन्न संस्थाओं को लोड करना और इस लोड को सही ढंग से मापना आवश्यक है।

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

चूंकि हम हर हफ्ते रिलीज करते हैं, स्वाभाविक रूप से, हमने कुछ परीक्षणों को स्वचालित किया - एकीकरण और कुछ और। इसके लिए हम ककड़ी का उपयोग करते हैं। यह व्यवहार चालित विकास के लिए एक BDD ढांचा है। यानी हम कुछ लिपियों से पूछते हैं जिनमें चरणों का समावेश है।



हमारे बुनियादी ढांचे ने हमें दो मोड में एकीकरण और कार्यात्मक परीक्षण चलाने की अनुमति दी: बस बैकएंड को किक करें, एपीआई को घुमाएं, या वास्तव में सेलेनियम के माध्यम से क्रोम चलाएं और इसे प्रबंधित करें।

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



तदनुसार, आपको इसे सभी को एक साथ रखने की आवश्यकता है। हमने पहले ही मुख्य परिदृश्यों को स्वचालित कर दिया है। हमारे परिदृश्य (क्योंकि यह BDD की तरह है) वास्तविक उपयोगकर्ताओं की नकल करते हैं और लोड वास्तविक उत्पादन के समान है। उसी समय, हम इसे स्केल कर सकते हैं। चूंकि यह रिलीज़ प्रक्रिया का हिस्सा है, इसलिए इसे हमेशा अद्यतित रखा जाता है।



अब चलो कोई भी उपकरण लेते हैं जो वर्तमान में बाजार पर है। वे एक ही आदिम पर काम करते हैं: http, http, http, JSON, JUnit पर एपीआई कॉल, बस। लेकिन जैसे ही हम ककड़ी पर अपने परीक्षणों को छड़ी करने की कोशिश करते हैं, वे ऐसा ही करते हैं, समान चीजों पर काम करते हैं, लेकिन कुछ भी काम नहीं करता है। हम सोचने लगे कि इस कार्य को कैसे किया जाए।

एक छोटा विषयांतर, क्योंकि BDD खेल के विकास में बहुत लोकप्रिय शब्द नहीं है, यह उद्यम समाधान के लिए अधिक है।



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



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



अब संक्षेप में स्लाइड्स पर एक ही बात। फ़ीचर फाइल्स को स्क्रिप्ट में बांटा गया है, स्टेप्स हैं और यह सब अंग्रेजी में लिखा गया है।



तब ककड़ी, जावा कोड, खेल में आता है, यह इन लिपियों को कोड के लिए मैप करता है जो वास्तव में निष्पादित होता है।



यह कोड हमारे एप्लिकेशन का उपयोग करता है।



और जो हमने चुना है उसके आधार पर: या तो सेलेनियम क्रोम के माध्यम से एलिस एप्लिकेशन पर जाता है।



या http एपीआई के माध्यम से एक ही बात।



और फिर (युरेन्क्स फॉर एल्योर रिपोर्ट्स के दोस्तों के लिए धन्यवाद) यह सब हमें खूबसूरती से दिखाया गया है - कितना समय लगा, क्या परीक्षण किए गए, किस कदम पर फ़्लिप किया गया और यहां तक ​​कि अगर कुछ गलत हुआ तो स्क्रीनशॉट भी लागू करें।



यहाँ एक संक्षिप्त सारांश है कि हमारे पास पहले से क्या था।



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



फिर, चूंकि हम बादल में हैं, 5-10-20 ककड़ी सूट चलाएं। लेकिन एक अति सूक्ष्म अंतर है: हमारे सभी कार्यात्मक परीक्षणों में से प्रत्येक रन एक रिपोर्ट उत्पन्न करता है। एक बार हमने 400 परीक्षण चलाए और 400 रिपोर्ट तैयार की गईं।

ओपन सोर्स के लिए यैंडेक्स के लोगों के लिए फिर से धन्यवाद, हमने प्रलेखन, स्रोत कोड पढ़ा और महसूस किया कि सभी 400 रिपोर्टों को एक में संयोजित करने के तरीके हैं। हमने डेटा को थोड़ा ठीक किया, हमारे कुछ एक्सटेंशन लिखे, और सब कुछ काम किया।



अब जेनकिन्स से, हम कहते हैं कि "हमें 200 उदाहरण दें।" हमारी निश्चित ऑर्केस्ट्रेशन स्क्रिप्ट अमेज़ॅन को जाती है, "400 कंटेनर लॉन्च करें"। उनमें से प्रत्येक में हमारे एकीकरण परीक्षण शामिल हैं, वे एक रिपोर्ट उत्पन्न करते हैं, रिपोर्ट एग्रीगेटर के माध्यम से एक टुकड़े में एकत्र की जाती है, जेनकिंस में रखी जाती है, नौकरी पर लागू होती है, यह सुपर काम करती है।

लेकिन।

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

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

ठीक है, चलो हमारे सिस्टम का मानवीकरण करें। उपयोगकर्ता इंटरफ़ेस ऐसा दिखता है:



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



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



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

चूंकि हमारे पास काफी परीक्षण थे, इसलिए हमने इस चीज के तहत प्रत्येक को फिर से लिखना शुरू नहीं किया। उन्होंने AspectJ को लिया, इसे हमारे कोड पर खींचा, कोड की 5 और पंक्तियों को जोड़ा, यह बहुत अच्छा काम करता है।

लघु डेमो।







यह एक टाइमलाइन है। ग्रीन टेस्ट अच्छे हैं, कहीं बुरे हैं। लुभाना हमें विवरण दिखाएगा कि वह कहाँ फ़्लिप करता है।

और यहाँ समयरेखा है, यह दिखाते हुए कि हमारे पास कई उदाहरण हैं। उन्होंने एक परीक्षण किया, कहीं कुछ गिर गया।



प्रणाली वास्तव में काम करती है - पिछले सप्ताह हमने लड़ाकू उत्पादन पर पहला परीक्षण किया।

अब अगले चरणों के बारे में, कैसे, हम मानते हैं, सुधार किया जा सकता है।



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

क्योंकि हमारे पास uskeys के आधार पर सभी परिदृश्य हैं, हम रिसेप्शन पर एक व्यक्ति और 10 क्लीनर को चलाकर नकल कर सकते हैं। फिर 20 या 30 सफाईकर्मी। लेकिन लोगों के सामने अभी भी वही है। यानी हम व्यवहार प्रतिमानों द्वारा एक वास्तविक भार उत्पन्न कर सकते हैं, एक यथार्थवादी भार के बहुत करीब।

साथ ही बहु-क्षेत्रीय परीक्षण। पूरे विश्व में हमारे सिस्टम का उपयोग किया जाता है (हालांकि सब कुछ अमेरिका में होस्ट किया जाता है) और इसलिए हम रूस और अमेरिका दोनों से एक लोड उत्पन्न कर सकते हैं यह देखने के लिए कि उनमें से कौन सा तेजी से धीमा करना शुरू कर देता है।

श्रोताओं से सवाल

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

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

- और आपके पास एक स्थिति नहीं थी कि एक बदलाव के बाद सभी परीक्षण लाल हो जाते हैं।

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

हालांकि एक बार, जब हमने गलती से कुछ तोड़ दिया, तो यह हमारे साथ हुआ। केवल 40% हरा रह गया, हालांकि इससे पहले यह 99% था। वह एक छोटा सा बदलाव था। हमने एक चरण (कोड की लाइन) को ठीक किया और सब कुछ फिर से हरा हो गया।

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

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

- लेकिन ये अलग-अलग दृष्टिकोण हैं? या हम विशेष रूप से सर्वर के साथ या खिड़की के साथ काम करते हैं। आप एक साथ कई सर्वरों के अनुरोधों का अनुकरण कर सकते हैं।

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

- लेकिन बहुत सी चीजें इस बात पर निर्भर करेंगी कि इंटरनेट किस तरह का यूजर है, कैसा माहौल है। लेकिन विशेष रूप से, एप्लिकेशन का संचालन पहले से ही और आपके पक्ष पर निर्भर करेगा। , : - ?

— , - . , , , . , , . YouTube , . , . , .

— . - Selenium Grid ? - .

— Cucumber': JAR, JAR Docker image Fargate' , image . flood.io grid Selenium , .

— ? , Chrome, . Internet Explorer 4 ( - ), ? - Android -.

— , enterprise. enterprise , requirements. — , , web view. Android web view , .

— , , Load-? ?

— .



Environment . . , Load, . 4- , , aliceapp.com. Load- , . , 504, , MySQL ElasticSearch.

— ( ), , ? .

— Load- , . यानी .

— , ?

— , . , , , .

— , , .. html API?

— Selenium DOM- : , , key down , — . .

— ? , ?

— . , . QC, , QC. Smoke- -. « -, ». — , , , .

Pixonic DevGAMM Talks

• Consul stateful- ( , DevOps BIT.GAMES);
• CICD: ( , Pixonic);
• - Quake Champions ( , backend- Saber Interactive);
• - - Tacticool ( , Lead Software Engineer PanzerDog);
• ECS, C# Job System SRP ( , Field Engineer Unity);
• KISS ( , Lead Game Programmer 1C Game Studios);
• ( , Deputy Technical Officer Pixonic).