इस लेख के साथ, हम एक बड़ी सूचना प्रणाली (बाद में सिस्टम के रूप में संदर्भित) के ऑटो-प्रोसेस (बाद में इसे ऑटोटैस्ट्स के रूप में संदर्भित) की ऑटो-प्रोसेस परियोजनाओं में से एक में कैसे प्रकाशित करते हैं, इस पर प्रकाशनों की एक श्रृंखला जारी रखते हैं।

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

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

स्रोत

वास्तुकला और प्रौद्योगिकी ढेर

प्रणाली की सामान्य संरचना और उसका वातावरण - उच्च स्तरीय डिजाइन

परियोजना में उपयोग की जाने वाली मुख्य प्रौद्योगिकियां और पुस्तकालय:

• JavaSE8 & maven & JUnit - विकास स्टैक;
• सेलेनियम - एक वेब ब्राउज़र के कार्यों को स्वचालित करने के लिए एक पुस्तकालय;
• सेलेनाइड - सेलेनियम के लिए एक ऐड-ऑन, जिसमें एक सुरुचिपूर्ण एपीआई है जो ब्राउज़र और पेज तत्वों के साथ बातचीत को बहुत सरल करता है;
• सेलेनॉइड और जीजीआर - सेलेनियम ग्रिड के कार्यान्वयन और ब्राउज़रों के लिए सीआई सर्वर + पूर्व-कॉन्फ़िगर कंटेनरों पर परीक्षण चलाने के लिए एक लोड बैलेंसर;
• Yandex Allure - CI सर्वर पर रिपोर्ट के लिए।

ऑटोटेस्ट्स और सेलेनॉइड बुनियादी ढांचे के घटकों का एक सामान्य चित्र नीचे दिए गए आरेखों में दिखाया गया है, जिसमें व्याख्यात्मक टिप्पणियां शामिल हैं:

ऑटोटेस्ट्स की रूपरेखा
उपयोगकर्ता इंटरफ़ेस प्रतिगमन के स्वचालन के लिए आवेदन।
सोर्स कोड में दिया गया। JUnit4 का उपयोग करता है

run.properties
ऑटोटेस्ट चलाने के लिए कॉन्फ़िगरेशन फ़ाइल। प्रयुक्त स्टैंड के सशर्त नाम और निष्पादन के प्रकार को परिभाषित करता है - स्थानीय या बाहरी कंटेनरों और अन्य चर के माध्यम से।

लुभाना प्लगइन
एक विशेष निष्पादन योग्य फ़ाइल जो एक बांस सर्वर पर स्थापित होती है।
एक बांस सर्वर के माध्यम से सुलभ एक परीक्षण HTML रिपोर्ट बनाता है।

टेस्ट रिपोर्ट
बांस सर्वर के माध्यम से परीक्षण HTML रिपोर्ट उपलब्ध है।
यह एक अलग टैब में योजना के परिणामों में बांस सर्वर पर संग्रहीत होता है।

बांस
स्वत: और मैनुअल मोड दोनों में एकीकरण परीक्षण की शुरूआत प्रदान करता है।
Allure प्रारूप में स्टोर परीक्षण रिपोर्ट।

GGR-सर्वर
सेलेनॉइड-सर्वरों का सर्वर-बैलेंसर।
सेलेनियम सर्वर के कई उदाहरणों के लिए ऑटोटेस्ट्स (रिमोटवेबड्राइवर) से अनुरोधों का संतुलन प्रदान करता है।

डाक में काम करनेवाला मज़दूर
सेलरॉइड सर्वर कंटेनर और ब्राउज़र को चलाने के लिए डॉकर सर्वर।

Selenoid-सर्वर
रिमोट टेस्टिंग सर्वर
"हेडलेस" ब्राउज़र का उपयोग करके विशेष डॉकटर कंटेनरों में परीक्षणों की शुरूआत प्रदान करता है।
समांतर सूत्र की निर्दिष्ट संख्या के अनुसार समानांतर मोड में परीक्षण करता है।

Selenoid-ui
सेलेनॉइड सर्वर के लिए सर्वर उपयोगकर्ता इंटरफ़ेस।
VNC के माध्यम से परीक्षण प्रगति की निगरानी की अनुमति देता है।

Selenoid-webdriver
रिमोट परीक्षणों को निष्पादित करने के लिए एक हेडलेस ब्राउज़र के साथ एक विशेष कंटेनर।
सेलेनॉइड रिपॉजिटरी से प्रदान किया गया।

GitLab
ऑटोटेस्ट्स एप्लिकेशन के स्रोत कोड को संग्रहीत करता है।

कार्य योजना

निम्न आरेख उच्च स्तर के डिज़ाइन स्तर पर ऑटोटेस्ट सेवा की सामान्य योजना को दर्शाता है।

स्थापना और परिनियोजन

ऑटोटेस्ट्स चार सर्वरों पर आधारित हैं, जिनमें से एक निष्पादन सर्वर है, और अन्य तीन कंटेनर में हेडलेस ब्राउजर लॉन्च करते हैं। ऑटोटेस्ट्स की वर्तमान शक्ति 60 एक साथ धाराएं प्रदान करती है और यदि आवश्यक हो तो इसका विस्तार किया जा सकता है।

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

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

कोड संरचना और संगठन

कोड की संरचना और संगठन के लिए आगे बढ़ने से पहले, मैं एक बार फिर उन नीतियों और प्रतिबंधों की सूची बनाऊंगा जो अंततः वास्तुकला के विकास की दिशा निर्धारित करते हैं:

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

पूर्वगामी के आधार पर, मुख्य वास्तु चालक निम्नलिखित हैं:

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

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

सामान्य कोड संरचना और प्रमुख विशिष्ट समाधानों का विवरण नीचे दिया गया है।

सामान्य कोड संरचना और विकास पैटर्न

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

• परीक्षण स्तर
• परीक्षण परिदृश्य स्तर
• वेबपेज स्तर
• वेब तत्व का स्तर
• परीक्षण रूपरेखा (आरेख में डिमिंग द्वारा दिखाया गया है)।

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

इसके अतिरिक्त, एक "स्तरित" संरचना कोड के पैकेज में संकुल में तय की गई थी (नीचे आरेख देखें)।

इस तरह की योजना ने डेवलपर्स के बीच सभी सबसिस्टम (जिनमें से योजना में काफी अधिक थे) को विभाजित करना संभव बना दिया और परिणामस्वरूप, मर्ज संघर्षों की व्यावहारिक रूप से गायब संख्या के साथ स्वतंत्र रूप से विकसित करना संभव बना दिया।

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

टेस्ट स्तर

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

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

परीक्षण वर्ग परीक्षा परिदृश्य के निष्पादन को व्यवस्थित करने के लिए जिम्मेदार है:

1. परीक्षण व्यवसाय डेटा (परीक्षण दृश्य) का आरंभीकरण,
2. चरण 2 से उन्हें प्रारंभिक परीक्षण डेटा के हस्तांतरण के साथ आवश्यक परिदृश्य के अनुसार व्यक्तिगत परीक्षण स्क्रिप्ट (क्रिया) की क्रमिक कॉल।

इसके अलावा, चरण 2 में बिना किसी शाखा या निर्णय बिंदु के एक रैखिक अनुक्रम होना चाहिए। वर्ग कार्यान्वयन टेम्पलेट नीचे दिखाया गया है।

टेस्ट केस स्तर

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

टेस्ट केस क्लास का मुख्य उद्देश्य:

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

परीक्षण केस क्लास को "कार्यात्मक इंटरफ़ेस" के रूप में आयोजित किया जाता है:

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

यह वर्ग संगठन आपको इसकी अनुमति देता है:

• स्व-दस्तावेजी रिपोर्ट प्रदान करें। प्रत्येक विधि परीक्षण विनिर्देश में एक विशिष्ट बिंदु से मेल खाती है और एल्योर एनोटेशन @ स्टेप द्वारा एनोटेट किया गया है;
• अलग-अलग परीक्षणों में परीक्षण स्क्रिप्ट कक्षाओं का पुन: उपयोग करें, क्योंकि परीक्षण स्क्रिप्ट 1) एक परीक्षण दृश्य नहीं बनाता है और 2) उपयोगकर्ता के लॉगिन पर निर्भर नहीं करता है (परीक्षण वर्ग स्तर पर लॉगिन-पुनः संचालन चालू है) 3), परीक्षण अन्य वर्गों पर निर्भर नहीं करता है -stsenariev।

वेबपेज स्तर

वेब पेज स्तर सेलेनियम में परीक्षण के लिए एक क्लासिक पेज पैटर्न है। पृष्ठ श्रेणी में विशिष्ट वेब तत्वों की परिभाषाएँ और परीक्षण मामले के चरणों के संदर्भ में कुछ समूह क्रियाओं के प्रदर्शन के लिए सार्वजनिक विधियों का एक सेट है।

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

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

वेब तत्व का स्तर

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

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

परीक्षण की रूपरेखा

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

ढांचे में निम्नलिखित कार्यात्मक ब्लॉक शामिल हैं:

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

परीक्षण वातावरण का प्रारंभ। नियम

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

ऑटोटेस्ट ढांचे के लिए आधार कक्षाओं के कार्यान्वयन का विवरण लेख के अगले भाग में दिखाया जाएगा: भाग 2-1 देखें। सभी परीक्षणों और JUnit ChainRule के लिए बेस क्लास कार्यान्वयन।

लुभाना रिपोर्ट के माध्यम से दस्तावेजीकरण परिणाम।

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

परीक्षण रिपोर्ट को दस्तावेज करने के लिए, निम्नलिखित कार्यक्षमता का उपयोग किया जाता है:

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

रिपोर्ट को चिह्नित करने के लिए निम्नलिखित एल्योर और जूनिट एनोटेशन का उपयोग किया जाता है।

• परीक्षण वर्ग स्तर पर:
  
  o @ फ़ीचर - परीक्षण करने के लिए कार्यात्मक सबसिस्टम का नाम;
  ओ @ स्टोरी - एक विशिष्ट परीक्षण मामले का नाम;
  o @ स्वामी - परीक्षण में अंतिम परिवर्तन करने वाले डेवलपर का नाम;
  o @ TmsLink - प्रयुक्त "परीक्षण प्रबंधन प्रणाली" में परीक्षण विवरण के लिए लिंक।
• परीक्षण वर्ग के परीक्षण विधि स्तर (@ टेस्ट) पर:
  
  o @ DisplayName - परीक्षण स्क्रिप्ट का पूरा नाम। यह @ स्टोरी से अलग है, यह आपको उसी स्क्रिप्ट को साझा करने की अनुमति देता है, जो केवल परीक्षण दृश्य की संरचना में भिन्न होती है;
• परीक्षण परिदृश्य के विशिष्ट चरणों के अनुरूप विधियों के स्तर पर:
  
  ओ @ स्टेप - टेस्ट स्टेप का सार्थक नाम जो कि हो रहा है के व्यावसायिक सार को दर्शाता है।

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

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

संभवत: अलग से क्या किया जा सकता है? स्प्रिंग फ्रेमवर्क का उपयोग करें

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

• परीक्षण दृश्य का आरंभीकरण;
• वेब पेजों और तत्वों का आरंभ।

एकमात्र विशेषता प्रोटोटाइप स्तर के "डिफ़ॉल्ट" गुंजाइश संदर्भ का उपयोग करने की आवश्यकता है।

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

वेब पेजों और तत्वों का प्रारंभ। वेब पेज क्लासेस और वेब एलिमेंट्स का इंजेक्शन सेलेनाइड वेब एलिमेंट्स के आलसी आलसी इनिशियलाइज़ेशन के आधार पर काम करता है।

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

मुझे तुरंत यह कहना होगा कि मैंने इसे बहुत सावधानी से परीक्षण नहीं किया, वास्तव में मैंने खुद को लॉगिन के "पृष्ठों" और इस सिद्धांत पर उपयोगकर्ता की "जानकारी" पृष्ठ के परीक्षण कार्यान्वयन तक सीमित कर दिया।

पूर्वव्यापी। आश्चर्य

यहाँ मैंने इस परियोजना के विकास के दौरान उठने वाले अप्रत्याशित आश्चर्य का वर्णन किया, साथ ही "नहीं" होने पर क्या किया जा सकता है, इसके बारे में कुछ विचार।

सेलेनियम के अनुकूल फ्रंट-एंड मार्कअप (कोणीय)

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

दुर्भाग्य से, यह समस्या आम तौर पर असम्भव थी। हमने इसे संगठनात्मक उपायों के साथ दरकिनार किया: 1) रिलीज के लिए एक नए उम्मीदवार का परीक्षण करने की शुरुआत में, ऑटोटेस्ट के सभी डेवलपर्स वेब तत्व लोकेटरों के मूल्यों को संपादित करने के संदर्भ में त्वरित उन्मूलन और शोधन पर ध्यान केंद्रित करते हैं; 2) अंत में, हम रिश्तेदार XPath का उपयोग करने के लिए आए थे, जो, अफसोस, प्रदर्शन में सुधार नहीं करता है।

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

"डाउनलोड" फ़ाइल के लिए गुम फ़ाइल नाम

परीक्षण के तहत सिस्टम से फ़ाइलें "अपलोड" करने के लिए, हम निम्नलिखित समाधान का उपयोग करते हैं:

• "स्थानीय" लॉन्च मोड के लिए (सीधे काम करने वाले पीसी पर लॉन्च) - जब "स्थानीय" ब्राउज़र को आरंभीकृत किया जाता है, तो अस्थायी स्थानीय फ़ोल्डर का नाम इसे पैरामीटर के रूप में पास किया जाता है। अगला, फ़ाइल को बाद के विश्लेषण के लिए स्थानीय फ़ोल्डर से सीधे पढ़ा जाता है;
• "रिमोट" मोड के लिए (बांस के माध्यम से) फ़ाइल को सोलनॉइड सर्वर की सुविधा के माध्यम से ब्राउज़र के साथ कंटेनर से "ले" लिया गया था: selenoid-host.example.com:4444/download/आईडीSESSION_ID►-ariosFILE_NAME}

विवरण प्रलेखन में वर्णित हैं ।

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

परीक्षण डेटाबेस clogging

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

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

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

उच्च परीक्षण अवधि

एक साथ निष्पादित परीक्षणों की संख्या में वृद्धि के दौरान हमें बहुत अप्रत्याशित रूप से इस समस्या का सामना करना पड़ा। मुझे लगता है कि हमने अभी इसके बारे में नहीं सोचा था। परीक्षणों का एक पूरा सेट पूरा करने में लगने वाला समय (~ 1000 पूर्ण परीक्षण) 6 घंटे के महत्वपूर्ण निशान के करीब पहुंचने लगा।

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

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

बड़ी संख्या में परीक्षणों के एक साथ निष्पादन के साथ "तूफान" शुरू करना

कार्य परीक्षणों की अकथनीय बड़े पैमाने पर दुर्घटनाएं 60 ब्राउज़रों में 60 युगपत परीक्षण धाराओं को स्केल करने के बाद अगला आश्चर्य था।

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


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

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

हमने बैलेंसर में लॉगिन स्क्रिप्ट विधि को लपेटकर पहली समस्या को हल किया, जिसने अधिकतम संख्या में लॉगिन संचालन को एक निरंतर तक सीमित कर दिया।

@Step(":    ")     public void apply(User user) {     try {         LoadCounter.get(); //   .              try {                 applyLogin(user); //          } catch (Throwable t) {             throw t; //                   } finally {             LoadCounter.release(); //            }         } catch (LoadCounterException e) { //                  throw new StandRuntimeException("Can not get loadcounter for Login action.", e);     }     } 

रैंडम टेस्ट रन ऑप्शन को चालू करके दूसरी समस्या हल की गई, जो कि जूनट मावेन प्लगइन के पास है।

    <plugin>               <groupId>org.apache.maven.plugins</groupId>                <artifactId>maven-surefire-plugin</artifactId>         <version>….</version>            <configuration>                <!-- Defines the order the tests will be run in. Supported values are "alphabetical",                     "reversealphabetical", "random","hourly", "failedfirst", "balanced" and "filesystem". -->                <runOrder>random</runOrder>                … 

यह ध्यान दिया जाना चाहिए कि ये समस्याएं इस तथ्य से संबंधित थीं कि हमारे पास सीमित संसाधनों के कारण परीक्षण बेंच के प्रदर्शन को बढ़ाने का अवसर नहीं था, और यह भी कि क्योंकि ये संसाधन अधिकांश समय निष्क्रिय रहेंगे।

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

बांस सर्वर और उसके भंडारण पर उच्च भार

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

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

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

जारी रखा जाए

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

यह लेख प्रोजेक्ट मैनेजर और कोटलैस्क उत्पाद के मालिक के सहयोग से लिखा गया था।

भाग 1. संगठनात्मक और प्रबंधकीय। हमें स्वचालन की आवश्यकता क्यों थी। विकास और प्रबंधन प्रक्रिया का संगठन। उपयोग का संगठन
भाग 2. तकनीकी। वास्तुकला और तकनीकी ढेर। कार्यान्वयन विवरण और तकनीकी आश्चर्य
भाग 2-1। सभी परीक्षणों और JUnit ChainRule के लिए बेस क्लास कार्यान्वयन
भाग 2-2। एक कंटेनर से एक फाइल को अपलोड करने की प्रक्रिया का कार्यान्वयन एक ब्राउज़र के साथ एक परीक्षण ढांचे के लिए। ब्राउज़र द्वारा डाउनलोड की गई फ़ाइल का नाम खोजें