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

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

स्रोत

भाग 1 - संगठनात्मक और प्रबंधकीय। हमें स्वचालन की आवश्यकता क्यों थी। विकास और प्रबंधन प्रक्रिया का संगठन। उपयोग का संगठन

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

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

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

मैं दूसरी टीम की टीम और टीम लीडर हूं, जिसने स्केलिंग (मई 2018 में) के लिए प्रोटोटाइप ढांचे को अपनाया।

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

परिणाम

लगभग 1,500 परीक्षण परिदृश्य स्वचालित थे: प्रत्येक परीक्षण में, 200 से 2000 उपयोगकर्ता के संचालन के लिए।

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

सुविधाओं की एक विस्तृत श्रृंखला लागू की गई है:

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

यह सब क्यों जरूरी था?

शुरुआत में, सिस्टम का उद्देश्य काफी सरल और स्पष्ट था।

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

यह सब डेढ़ हजार परीक्षण परिदृश्यों में बदल जाता है, और यह केवल सर्वोच्च प्राथमिकता और केवल सकारात्मक है।

स्वचालन की प्रक्रिया में, विभिन्न बारीकियों का खुलासा किया गया था जिसमें विभिन्न समाधानों के उपयोग की आवश्यकता थी।

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

स्रोत

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

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

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

लक्ष्यों

एंड-टू-एंड टेस्टिंग के संचालन की श्रम लागत को कम करने और वॉल्यूम के संदर्भ में पूर्ण और कम होने वाली रजिस्टरों की गति को बढ़ाने के लिए यह आवश्यक था।

कार्य

विकास का मुख्य कार्य बहुत सरल रूप से तैयार किया गया था - अगले 6 महीनों में उच्चतम प्राथमिकता के 1000 परीक्षण परिदृश्यों को स्वचालित करने के लिए।

मूल परीक्षण क्रियाओं की अनुमानित संख्या 100 से 300 के बीच थी, जिसने हमें 10-20 लाइनों के साथ लगभग 200 हजार परीक्षण विधियां दीं, बिना सहायकों, डेटा प्रदाताओं और डेटा मॉडल के सामान्य और सहायक वर्गों को ध्यान में रखते हुए।

इस प्रकार, यह पता चला कि, समय की कमी (130 कार्य दिवस) को ध्यान में रखते हुए, प्रति दिन कम से कम 10 परीक्षण करना आवश्यक था और साथ ही सिस्टम में होने वाले परिवर्तनों को ध्यान में रखते हुए कार्यान्वित स्व-परीक्षणों की प्रासंगिकता सुनिश्चित करना (सिस्टम सक्रिय रूप से विकसित हो रहा है)।

विशेषज्ञ के अनुमानों के अनुसार, एक ऑटोटेस्ट को विकसित करने के लिए आवश्यक श्रम 4-8 घंटे था। इसलिए हमें कम से कम 5 लोगों की एक टीम मिली (वास्तव में, ऑटोटैस्ट्स के विकास के चरम पर, टीम में 10 से अधिक ऑटोमेशन इंजीनियर थे)।

जिन कार्यों को हल करने की आवश्यकता थी, वे भी समझ में आए।

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

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

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

असल में, सब कुछ संभव और आशावादी लग रहा था। इसके अलावा, हम एक निश्चित समय में पूरी तरह से कार्यों के साथ मुकाबला करते हैं।

निम्नलिखित AutoTests के विकास के व्यक्तिगत तकनीकी और प्रक्रिया पहलुओं का वर्णन करता है।

ऑटोटेस्ट्स का वर्णन। उपयोगकर्ता कहानियां और सुविधाएँ

स्रोत

ऑटोटेस्ट्स परीक्षण समूह द्वारा उनके उपयोग के संदर्भ में उपयोगकर्ता कहानियों के निम्नलिखित सेट को लागू करते हैं:

• मैनुअल परीक्षण स्वचालन;
• स्वचालित पूर्ण प्रतिगमन;
• CI \ CD श्रृंखला में असेंबली की गुणवत्ता नियंत्रण।

भाग 2 - तकनीकी में कार्यान्वयन विवरण और वास्तु संबंधी निर्णयों पर चर्चा की जाएगी । वास्तुकला और तकनीकी ढेर। कार्यान्वयन विवरण और तकनीकी आश्चर्य ।

स्वचालित और मैनुअल परीक्षण (उपयोगकर्ता कहानियां)

एक परीक्षक के रूप में, मैं लक्ष्य E2E परीक्षण करना चाहता हूं, जो मेरी सीधी भागीदारी (स्वचालित मोड में) के बिना किया जाएगा और मुझे दिए गए चरणों के संदर्भ में एक विस्तृत रिपोर्ट प्रदान करेगा, जिसमें दर्ज किए गए डेटा और प्राप्त परिणाम भी शामिल हैं, साथ ही साथ

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

स्वचालित पूर्ण प्रतिगमन

एक परीक्षण समूह के रूप में, मैं हर रात सभी परीक्षणों को स्वचालित मोड में एक विशिष्ट परीक्षण बेंच पर करना चाहता हूं, जिसमें "स्वचालित मैनुअल" की सभी विशेषताएं शामिल हैं।

CI \ CD श्रृंखला में असेंबली गुणवत्ता नियंत्रण

एक परीक्षण समूह के रूप में, मैं लक्ष्य कार्यात्मक परीक्षण चरण स्टैंड को अपडेट करने से पहले एक समर्पित प्रीक्यूए-स्टैंड पर सिस्टम के तैनात किए गए अपडेट का स्वत: परीक्षण करना चाहता हूं, जो बाद में कार्यात्मक परीक्षण के लिए उपयोग किए गए थे।

बुनियादी सुविधाओं को लागू किया

स्रोत

यहाँ AutoTests के मुख्य कार्यान्वित कार्यों का एक संक्षिप्त सेट है, जो महत्वपूर्ण या बस उपयोगी निकला है। कुछ दिलचस्प कार्यों के कार्यान्वयन का विवरण लेख के दूसरे भाग में होगा।

स्थानीय और दूरस्थ उपयोग

फ़ंक्शन ने ऑटोटेस्ट्स को चलाने के लिए दो विकल्पों की पेशकश की - स्थानीय और दूरस्थ।

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

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

फ़ंक्शन पर्यावरण चर MODE = REMOTE | LOCAL का उपयोग करके कार्यान्वित किया गया था, जिसके आधार पर या तो एक स्थानीय या दूरस्थ वेब ब्राउज़र को सेलेनॉइड क्लाउड में आरंभीकृत किया गया था।

फ़िल्टर द्वारा चलने वाले परीक्षणों की संरचना को सीमित करना

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

फ़िल्टरों का मूल्य नियमित एक्सप्रेशंस REGEXP1, ..., REGEXPN के सिद्धांत के अनुसार "OR" के सिद्धांत के अनुसार लागू किया गया है।

मैनुअल मोड में शुरू करने पर, परीक्षक को विशेष @ फ़िल्टर (स्ट्रिंग मान) एनोटेशन पर लागू होने वाले नियमित अभिव्यक्तियों की एक सूची के रूप में एक विशेष पर्यावरण चर सेट करने के लिए कहा गया था, जिसने परीक्षण कक्षाओं में सभी परीक्षण विधियों को एनोटेट किया था। प्रत्येक परीक्षण के लिए, यह एनोटेशन अद्वितीय है और अंडरस्कोर द्वारा अलग किए गए टैग के एक सेट के आधार पर बनाया गया है। हम निम्नलिखित न्यूनतम टेम्पलेट SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT} का उपयोग करते हैं, जहां DEFAULT टैग स्वचालित रात प्रतिगमन में शामिल परीक्षणों के लिए है।

फ़ंक्शन को org.junit.runners.BlockJUnit4ClassRunner वर्ग के एक कस्टम एक्सटेंशन के माध्यम से कार्यान्वित किया जाता है (विवरण इस लेख की निरंतरता के भाग 2-1 में दिया जाएगा)

सभी चरणों के परिणामों के साथ रिपोर्ट का दस्तावेजीकरण

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

उपयोग किए जाने वाले मुख्य कार्य हैं:

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

अपने बाद के सत्यापन और विश्लेषण के साथ / से ब्राउज़र में फ़ाइलों को डाउनलोड और अपलोड करें

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

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

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

इस फ़ंक्शन का कार्यान्वयन एक गैर-तुच्छ कार्य है, मुख्य रूप से मानक फ़ाइल हैंडलिंग क्षमताओं की कमी के कारण: फिलहाल, फ़ंक्शन क्रोम ब्राउज़र के लिए केवल "क्रोम: // डाउनलोड /" सेवा पृष्ठ के माध्यम से लागू किया गया है।

मैं आपको दूसरे भाग में कार्यान्वयन विवरण के बारे में विस्तार से बताऊंगा।

लेखा और कोणीय इंटरफ़ेस की अतुल्यकालिक प्रकृति का नियंत्रण। कोणीय और REST सेवाओं के बीच लंबित अनुरोध नियंत्रण

चूँकि हमारी टेस्टिंग का उद्देश्य एंगुलर पर आधारित था, इसलिए हमें फ्रंटेंड और टाइमआउट की अतुल्यकालिक प्रकृति के साथ "लड़ाई" करना सीखना था।

सामान्य तौर पर, org.openqa.selenium.support.ui.FluentWait के अतिरिक्त, हम एक विशेष रूप से डिज़ाइन की गई प्रतीक्षा पद्धति का उपयोग करते हैं जो जावास्क्रिप्ट के माध्यम से चेक-इन करता है कि फ्रंट-एंड REST सेवाओं के साथ "अपूर्ण" इंटरैक्शन के लिए, और इस डायनेमिक टाइमआउट के आधार पर, परीक्षणों का पालन करने के बारे में जानकारी मिलती है। फिर थोड़ी देर प्रतीक्षा करें।

कार्यक्षमता की दृष्टि से, हम स्थैतिक उम्मीदों की अस्वीकृति के कारण परीक्षणों को पूरा करने में लगने वाले समय को कम करने में सक्षम थे, जहां ऑपरेशन के पूरा होने का अलग-अलग निर्धारण करने का कोई तरीका नहीं है। इसके अलावा, इसने हमें प्रदर्शन समस्याओं के साथ "हैंगिंग" REST सेवाओं को परिभाषित करने की अनुमति दी। उदाहरण के लिए, उन्होंने एक REST सेवा पकड़ी जिसके लिए पृष्ठ पर प्रदर्शित रिकॉर्ड की संख्या 10,000 तत्वों पर सेट की गई थी।

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

ब्राउज़र लॉग कंट्रोल

ब्राउजर लॉग कंट्रोल फ़ंक्शन को ड्रॉप टेस्ट के लिए अतिरिक्त जानकारी प्राप्त करने के लिए SEERE स्तर के पृष्ठों पर त्रुटियों को नियंत्रित करने के लिए जोड़ा गया था, उदाहरण के लिए, "... संसाधन लोड करने में विफल: सर्वर ने 500 (आंतरिक सर्वर त्रुटि) की स्थिति के साथ जवाब दिया।"

ब्राउज़र में पृष्ठ प्रसंस्करण त्रुटियों की संरचना प्रत्येक परीक्षा परिणाम पर लागू होती है, और ईएलके में घटनाओं के रूप में अतिरिक्त रूप से अनलोड भी होती है।

परीक्षण की वीडियो रिकॉर्डिंग और परीक्षण के "गिरावट" के बिंदु पर पृष्ठ के स्नैपशॉट को हटा दें

गिराए गए परीक्षणों के निदान और पार्सिंग की सुविधा के लिए कार्य कार्यान्वित किए जाते हैं।

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

ईएलके के लिए घटनाओं को पास करना

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

विकास संगठन

स्रोत

विकास दल

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

इस प्रकार, 6 जावा डेवलपर्स (वास्तविकता में, ऑटोटेस्ट्स के विकास के चरम पर, टीम 10 ऑटोमेशन से अधिक हो गई) लेना आवश्यक था।

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

शुरुआती जूनियर्स पर रिलायंस को एक विशिष्ट करियर ऑफर, काम का एक स्पष्ट शेड्यूल और अलग-अलग कार्यात्मक डोमेन में आवेदन के विभाजन के रूप में क्षतिपूर्ति तंत्र की शुरुआत की आवश्यकता थी ( भाग 2 में इस पर अधिक - तकनीकी वास्तुकला और तकनीकी स्टैक। कार्यान्वयन विवरण और तकनीकी आश्चर्य )।

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

विकास की प्रक्रिया

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

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

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

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

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

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

कार्यान्वयन की जटिलता का मूल्यांकन "परीक्षण चरणों" में किया गया था, जो वास्तव में चरणों के सरल सारांश द्वारा स्वचालित परीक्षण परिदृश्य द्वारा निर्धारित किए गए थे। व्यवहार में, यह परीक्षण मामले में सभी पैराग्राफ का योग था।

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

विकास कार्यों की विशिष्टता

बैकलॉग में प्रारंभिक विकास कार्य कार्यात्मक परीक्षण समूह से परीक्षण विनिर्देशों (टेस्ट स्क्रिप्ट) के रूप में आए, जो ऑटोटेस्ट के लिए एक आंतरिक उपयोगकर्ता और हितधारक के रूप में कार्य करते थे।

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

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

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

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

रिपोजिटरी संगठन

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

परियोजना की शुरुआत में, हमने तय किया कि हम ऑटोटैस्ट के विभिन्न रिलीज का समर्थन नहीं करेंगे - यह आवश्यक नहीं था, इसलिए हमने अलग रिलीज शाखा नहीं बनाई।

विशेषताएं:

(+) छोटी टीमों के लिए कार्यों के निरंतर वितरण की सरल प्रक्रिया;
(+) आपको कार्यों को तैनात करने की अनुमति देता है क्योंकि वे कोड स्तर पर रिलीज की योजना की आवश्यकता के बिना विकसित किए जाते हैं;
(+) आपको रिलीज़ देरी की शुरुआत किए बिना वास्तविक विकास के साथ "पकड़ने" की अनुमति देता है;
(-)फ्रेमवर्क का केवल एक संस्करण समर्थित है (वर्तमान);
(-) AutoTests के पिछले संस्करणों में, केवल हॉटफ़िक्स बग समर्थित हैं।

परिणामस्वरूप, हम निम्नलिखित नियमों पर आए।

डेवलपर

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

गेटकीपर (टीम लीड द्वारा संचालित)

• Bamboo.
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

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