⭐️ 🕳️ 📶 100 एप्लिकेशन लॉन्च होने के बजाय - एक ऑटोटेस्ट, या एक क्यूए इंजीनियर को जीवन के 20 साल कैसे बचाएं 👩🏾‍🌾 🥑 👍🏻

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

आरंभ करने के लिए, हम यह पता लगाएंगे कि हम इस प्रणाली के साथ क्या कर रहे हैं।

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

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

प्लेटफार्मों में से, हम एंड्रॉइड और आईओएस का उपयोग करते हैं - पार्क में केवल 12 डिवाइस। दो प्रोग्रामर सिस्टम डेवलपमेंट और सपोर्ट में शामिल हैं, और एक QA इंजीनियर टेस्ट लिख रहा है और उसका विश्लेषण कर रहा है।

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

आप परीक्षण कैसे बनाते हैं, विश्लेषण करते हैं और चलाते हैं

मान लीजिए हम एक साधारण परीक्षण लिखना चाहते हैं कि गेम सेटिंग्स विंडो में ध्वनि को चालू और बंद करने के लिए आइकन की जांच करेगा।

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

इस मामले में, 575 परीक्षण शुरू किए गए, जिनमें से 97% सफल रहे। सभी परीक्षणों को पूरा करने में हमें लगभग तीन घंटे लगे। तुलना के लिए, एक ही परीक्षण, यदि मैन्युअल रूप से किया जाता है, तो कम से कम 50 घंटे का निरंतर संचालन होगा।

तो उन 3% परीक्षणों का क्या हुआ जो विफल रहे?

हम एक विशिष्ट परीक्षण खोलते हैं और एक संदेश देखते हैं जो स्क्रीनशॉट से मेल खाते समय एक त्रुटि हुई।

फिर हम स्क्रीनशॉट खोलते हैं, जो उस समय डिवाइस पर था, और हम देखते हैं कि जो ज़ोन मूल के अनुरूप नहीं हैं, वे लाल पिक्सेल के साथ चिह्नित हैं। तुलना के लिए, हम उसे देते हैं।

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

यह अच्छा लग रहा है। यह सब क्यों जरूरी है?

कुछ समय पहले, वार रोबोट प्रोजेक्ट पर, हमें एक छोटे से रीफैक्टरिंग की आवश्यकता थी। इसमें हथियारों की फायरिंग के लिए कोड के कुछ टुकड़ों को फिर से लिखना शामिल था - विशेष रूप से, मशीन गन।

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

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

हम किन उपकरणों का उपयोग करते हैं

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

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

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

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

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

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

अगले नवाचारों और संशोधनों के बाद, पूरे सिस्टम की वास्तुकला निम्नानुसार दिखाई देने लगी।

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

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

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

उपकरणों को चुनने के लिए टिप्स

अलग-अलग, मैं परीक्षण के लिए उपकरणों की पसंद पर ध्यान देना चाहता हूं।

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

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

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

परीक्षण रिपोर्टिंग

परीक्षणों के पूरा होने के बाद, हम एक एल्योर रिपोर्ट तैयार करते हैं, जिसमें हमारे परीक्षण के दौरान बनाई गई सभी कलाकृतियाँ शामिल हैं।

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

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

हम प्रक्रियाओं, बैटरी पावर, तापमान, और आम तौर पर उन सभी चीजों की एक सूची एकत्र करते हैं जो हम तक पहुंच सकते हैं।

अच्छे स्क्रीनशॉट और वीडियो क्या हैं

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

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

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

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

हमारा सिस्टम और क्या कर सकता है?

कुछ समय पहले, क्यूए परीक्षण विभाग से, हमें मैनुअल प्लेटेस्ट के दौरान मैट्रिक्स इकट्ठा करने के लिए एक उपकरण विकसित करने का अनुरोध मिला।

ये किसके लिये है?

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

हमारे द्वारा विकसित प्रणाली निम्नानुसार काम करती है। QA इंजीनियर ने डिवाइस पर War Robots लॉन्च किया, प्लेबेंच सत्र की रिकॉर्डिंग चालू की - गेमबेंच के हमारे एनालॉग - ने playtest खेला, फिर "playbench सत्र को समाप्त करें" पर क्लिक किया, उत्पन्न रिपोर्ट को रिपॉजिटरी में सहेजा गया था, जिसके बाद इस playtest के डेटा के साथ इंजीनियर अपने काम पर पहुंच सकता है। मशीनें और रिपोर्ट देखें: एफपीएस पर क्या गिरावट थी, मेमोरी की खपत, डिवाइस पर क्या हो रहा था।

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

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

और अन्य उपयोगी विशेषताएं

अंत में, मैं पिछले कुछ वर्षों में मिले कुछ दिलचस्प मामलों पर ध्यान देना चाहता हूं।

हाल ही में हमारे साथ सामने आए सबसे दिलचस्प मामलों में से एक बॉट्स के साथ झगड़े के दौरान बेंचमार्क हैं।

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

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

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

एक निष्कर्ष के बजाय

अंत में, मैं उन समस्याओं की ओर ध्यान आकर्षित करना चाहूंगा जिनके बारे में हमें पता है कि हम पहले स्थान पर हल करना चाहते हैं।

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

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

मैं देशी UI के साथ भी बातचीत करना चाहूंगा, लेकिन अभी तक हमारे पास ऐसा कोई अवसर नहीं है। हम जानते हैं कि यह कैसे करना है, लेकिन कार्यक्षमता के लिए अन्य अनुरोधों की उपस्थिति हमें इस तक पहुंचने की अनुमति नहीं देती है।

और व्यक्तिगत रूप से, मेरी इच्छा उद्योग में मौजूद मानकों का पालन करना है, लेकिन यह भविष्य की योजनाओं में भी है, शायद इस साल भी।

100 एप्लिकेशन लॉन्च होने के बजाय - एक ऑटोटेस्ट, या एक क्यूए इंजीनियर को जीवन के 20 साल कैसे बचाएं