🈯️ 🚶🏿 🅱️ सेलेनियम पर ऑटोटेस्ट्स को जल्दी और कुशलता से लिखने के लिए एक उपकरण बनाना 🧒🏻 👨🏽‍🚒 👩🏼

मौलिक बिल्डिंग ब्लॉक स्वचालन - परीक्षण
रॉड जॉनसन

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

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

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

अवधारणा का

परीक्षण प्रक्रिया सूचना प्रणाली पर निर्भर करती है।

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

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

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

अवधारणाएँ जो मैंने अपने लिए निर्धारित की हैं:

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

मैंने शुरू में मना करने का फैसला किया:

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

मैं कंपनी में विकास के स्तर और कुछ विवरणों को पूरी तरह से स्पष्ट करने के लिए उपकरण बनाने की शर्तों के बारे में कुछ और बात करूँगा।

कुछ गोपनीय परिस्थितियों के कारण, मैं उस कंपनी का खुलासा नहीं करता जहाँ मैं काम करता हूँ।

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

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

विधानसभा विवरण

मंच को JDK 12 का उपयोग करके जावा में लिखा गया है

की इन्फ्रास्ट्रक्चर टूल्स - सेलेनियम वेब ड्राइवर, ओजेडीबीसी

काम करने के लिए आवेदन के लिए, फ़ायरफ़ॉक्स ब्राउज़र संस्करण 52 को पीसी पर स्थापित किया जाना चाहिए

एप्लिकेशन बिल्ड संरचना

आवेदन के साथ, 3 फ़ोल्डर और 2 फाइलें आवश्यक हैं:

• BuildKit फ़ोल्डर - में शामिल हैं:

jdk12, जिसके माध्यम से एप्लिकेशन लॉन्च किया गया है (JVM);
geckodriver.exe - फायरफॉक्स ब्राउज़र के साथ काम करने के लिए सेलेनियम वेब ड्राइवर के लिए;
SprintAutoTest.jar - सीधे आवेदन उदाहरण

• रिपोर्ट फ़ोल्डर - आवेदन परीक्षण के मामले को पूरा करने के बाद रिपोर्ट को इसे सहेजा जाता है। इसमें ErrorScreens फ़ोल्डर भी होना चाहिए, जहाँ एक त्रुटि के मामले में स्क्रीनशॉट सहेजा जाता है

• TestSuite फ़ोल्डर - वेब पैकेज, जावास्क्रिप्ट, परीक्षण मामलों का एक सेट (इस फ़ोल्डर को भरने पर विस्तार से चर्चा की जाएगी)

• config.properties फ़ाइल - एक Oracle डेटाबेस से जुड़ने के लिए एक विन्यास और WebDriverWait के लिए स्पष्ट अपेक्षाओं के मूल्यों को समाहित करता है।

• starter.bat - एप्लिकेशन लॉन्च करने के लिए फ़ाइल (यदि आप TestCase नाम अंत में एक पैरामीटर के रूप में दर्ज करते हैं तो मैन्युअल रूप से TestCase को निर्दिष्ट किए बिना एप्लिकेशन को स्वचालित रूप से लॉन्च करना संभव है)।

आवेदन का संक्षिप्त विवरण

एप्लिकेशन को पैरामीटर (नाम TestCase) के साथ या इसके बिना लॉन्च किया जा सकता है - इस मामले में, आपको कंसोल में परीक्षण मामले का नाम दर्ज करना होगा।

एक पैरामीटर के बिना चलने के लिए एक बैट फ़ाइल की सामान्य सामग्री का एक उदाहरण: "AutoTest लांचर"% cd% \ BuildKit \ jdk-12 \ bin \ java.exe -Xmx768M -jar --enable- पूर्वावलोकन% cd% \ BuildKit \ SprintAutoTest.jar शुरू करें

एप्लिकेशन के सामान्य लॉन्च पर, यह "\ TestSuite \ TestCase" निर्देशिका (सबफ़ोल्डर्स की सामग्री को देखे बिना) में स्थित xml फ़ाइलों को देखता है। इस स्थिति में, संरचना के सही होने के लिए xml फ़ाइलों की प्राथमिक मान्यता होती है (अर्थात, xml मार्कअप के दृष्टिकोण से सभी टैग सही हैं), और "testCaseName" टैग में दिए गए नामों को इंगित किया गया है, जिसके बाद उपयोगकर्ता को उपलब्ध परीक्षण के लिए संभावित नामों में से एक दर्ज करने के लिए प्रेरित किया जाता है। मामलों। एक गलत प्रविष्टि के मामले में, सिस्टम आपको फिर से नाम दर्ज करने के लिए कहेगा।

TestCase नाम प्राप्त होने के बाद, आंतरिक मॉडल बनाया गया है, जो TestCase (परीक्षण स्क्रिप्ट) का एक गुच्छा है - जाव ऑब्जेक्ट्स के रूप में वेबपैकेज (तत्वों का भंडारण)। मॉडल के निर्माण के बाद, TestCase (प्रोग्राम का निष्पादन योग्य ऑब्जेक्ट) सीधे बनाया गया है। TestCase के निर्माण चरण में, द्वितीयक सत्यापन भी होता है - यह जाँच की जाती है कि TestCase में सभी निर्दिष्ट रूप संबद्ध WebPackage में हैं और कार्रवाई में निर्दिष्ट सभी तत्व WebPackage में निर्दिष्ट पृष्ठों के भीतर हैं। (टेस्टकेस और वेबपेज की संरचना नीचे विस्तार से वर्णित है)

TestCase निर्मित होने के बाद, स्क्रिप्ट सीधे चलती है

स्क्रिप्ट ऑपरेशन एल्गोरिथ्म (मुख्य तर्क)

TestCase एक्शन संस्थाओं का एक संग्रह है, जो बदले में ईवेंट संस्थाओं का एक संग्रह है।

testcase
-> सूची {क्रिया}
-> सूची {घटना}

जब TestCase शुरू होता है, तो कार्रवाई क्रमिक रूप से शुरू होती है (प्रत्येक क्रिया तार्किक परिणाम देती है)

जब क्रिया प्रारंभ होती है, तो ईवेंट क्रमिक रूप से प्रारंभ होता है (प्रत्येक ईवेंट एक तार्किक परिणाम देता है)

प्रत्येक ईवेंट का परिणाम सहेजा जाता है।

तदनुसार, परीक्षण या तो पूरा हो गया है जब सभी क्रियाएं सफलतापूर्वक पूरी हो गई थीं, या यदि कार्रवाई झूठी थी।

* क्रैश मैकेनिज्म

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

आवेदन के अंत में, एक रिपोर्ट तैयार की जाती है, जिसे "\ रिपोर्ट" निर्देशिका में सहेजा जाता है। त्रुटि के मामले में, एक स्क्रीनशॉट लिया जाता है, जिसे "\ Report \ ErrorScreens" में सहेजा जाता है।

टेस्टसुइट भरना

तो, परीक्षण का वर्णन। जैसा कि पहले ही उल्लेख किया गया है, चलाने के लिए आवश्यक मुख्य पैरामीटर को चलाने के लिए परीक्षण का नाम है। यह नाम "/ TestSuite / TestCase" निर्देशिका में xml फ़ाइल में संग्रहीत है। सभी परीक्षण स्क्रिप्ट इस निर्देशिका में संग्रहीत की जाती हैं। उनकी कोई भी संख्या हो सकती है। परीक्षण मामले का नाम फ़ाइल के नाम से नहीं, बल्कि फ़ाइल के अंदर "testCaseName" टैग से लिया गया है।

TestCase सेट करता है कि वास्तव में क्या किया जाएगा - अर्थात कार्रवाई। निर्देशिका में "/ TestSuite / WebPackage" xml फ़ाइलों में सभी लोकेटर संग्रहीत किए जाते हैं। यानी सभी सर्वश्रेष्ठ परंपराओं में - क्रियाओं को अलग-अलग संग्रहीत किया जाता है, वेब प्रपत्र लोकेटर अलग से।

TestCase भी WebPackage नाम को "webPackageName" टैग में संग्रहीत करता है।

कुल तस्वीर पहले से ही है। चलाने के लिए, आपके पास 2 xml फ़ाइलें होनी चाहिए: TestCase और WebPackage। वे एक गुच्छा बनाते हैं। WebPackage स्वतंत्र है - पहचानकर्ता "WebPackageName" टैग में नाम है। तदनुसार, यहां पहला नियम है - टेस्टकेस और वेबपैकेज नाम अद्वितीय होने चाहिए। यानी एक बार फिर - वास्तव में, हमारा परीक्षण TestCase और WepPackage फ़ाइलों का एक समूह है, जो WebPackage नाम से जुड़े हैं, जो TestCase में निर्दिष्ट है। व्यवहार में, मैं एक प्रणाली को स्वचालित करता हूं और मैं अपने सभी परीक्षण मामलों को एक वेबपेज पर भेजता हूं जिसमें मेरे पास सभी रूपों के विवरणों का ढेर होता है।

तार्किक अपघटन की अगली परत पृष्ठ ऑब्जेक्ट जैसे पैटर्न पर आधारित होती है।

पृष्ठ वस्तु

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

तर्क और कार्यान्वयन का पृथक्करण

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

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

अगला, मैं वेबपैकेज और टेस्टकैसे की संरचना का विस्तार नहीं करने की कोशिश करूंगा। उनके लिए, मैंने WebPackage के लिए DTD स्कीमा और TestCase के लिए XSD 1.1 बनाया।

! महत्वपूर्ण

डीटीडी और एक्सएसडी योजनाओं को बनाए रखने से, त्वरित परीक्षण लेखन की अवधारणा को लागू किया जाता है।

WebPackage और TestCase को सीधे लिखते समय, आपको xml संपादक का उपयोग वास्तविक समय में DTD और XSD सत्यापन कार्यों के साथ ऑटो-टैग के निर्माण के साथ करना होगा, जिससे ऑटो टेस्ट लिखने की प्रक्रिया काफी हद तक स्वचालित हो जाएगी (सभी आवश्यक टैग स्वचालित रूप से प्रतिस्थापित हो जाएंगे, ड्रॉप-डाउन सूची विशेषता मानों के लिए प्रदर्शित होगी। संभावित मान, घटना के प्रकार के अनुसार संबंधित टैग उत्पन्न किए जाएंगे) ।

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

WebPackage

WebPackaege - एक xml फ़ाइल जो वेब रूपों के तत्वों का वर्णन करती है, जो "\ TestSuite \ WebPackage" निर्देशिका में स्थित है। (आपकी जितनी चाहें उतनी फाइलें हो सकती हैं। फाइलों का नाम कुछ भी हो सकता है - केवल सामग्री मायने रखती है)।

DTD (दस्तावेज़ की शुरुआत में सम्मिलित):

<!DOCTYPE webPackage [ <!ELEMENT webPackage (webPackageName, forms)> <!ELEMENT webPackageName (#PCDATA)> <!ELEMENT forms (form+)> <!ELEMENT form (formName, elements+)> <!ELEMENT formName (#PCDATA)> <!ELEMENT elements (element+)> <!ELEMENT element (name, locator)> <!ATTLIST element type (0|1|2|3|4|5|6|7) #REQUIRED> <!ATTLIST element alwaysVisible (0|1) #IMPLIED> <!ELEMENT name (#PCDATA)> <!ELEMENT locator (#PCDATA)> <!ATTLIST locator type (1|2) #IMPLIED> ]>

सामान्य तौर पर, यह लगभग दिखता है

 <webPackage> <webPackageName>_</webPackageName> <forms> <form> <formName>______</formName> <elements> <element type="2" alwaysVisible="1"> <name>_</name> <locator type="2">.//div/form/div/div/form/table/tbody/tr/td[text()=""]/following-sibling::td/input</locator> </element> <element type="2"> <name>__</name> <locator>.//div/form/div/div/form/table/tbody/tr/td[text()=""]/following-sibling::td/input</locator> </element> ....... </elements> </form> ....... </forms> </webPackage>

जैसा कि पहले ही उल्लेख किया गया है, ताकि तत्व ढेर में न हों - वेब रूपों के अनुसार सब कुछ विघटित हो गया है

कुंजी इकाई है

 <element>

तत्व टैग में 2 विशेषताएँ हैं:

टाइप
alwaysVisible

प्रकार की विशेषता आवश्यक है और तत्व के प्रकार को निर्दिष्ट करता है। प्लेटफॉर्म में, बाइट प्रकार सेट करें

फिलहाल, विशेष रूप से मंच में खुद के लिए मैंने निम्नलिखित प्रकारों को लागू किया है:

• 0 - एक कार्यात्मक अर्थ नहीं है, आमतौर पर किसी प्रकार का शिलालेख
• 1 - बटन (बटन)
• 2 - इनपुट क्षेत्र
• 3 - चेकबॉक्स (चेकबॉक्स)
• 4 - ड्रॉप-डाउन सूची (चयन) - वास्तव में लागू नहीं किया गया, लेकिन इसके लिए एक जगह छोड़ दी गई
• 5 - srm ड्रॉप-डाउन सूची के लिए: नाम लिखें, मान प्रकट होने के लिए प्रतीक्षा करें - विशिष्ट xpath टेम्पलेट के अनुसार चयन करें - विशेष रूप से मेरे सिस्टम के लिए प्रकार
• 6 - srm select - खोज, आदि जैसे विशिष्ट कार्यों पर उपयोग किया जाता है। - मेरे सिस्टम के लिए विशेष रूप से टाइप करें

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

संभावित मूल्य:

0 - डिफ़ॉल्ट रूप से (या यदि विशेषता सेट नहीं है) - तत्व पृष्ठ पर नहीं हो सकता है (मान्य न करें)
1 - तत्व हमेशा पृष्ठ पर मौजूद होता है

एक वैकल्पिक वैकल्पिक प्रकार विशेषता लोकेटर टैग के साथ कार्यान्वित की जाती है

संभावित मूल्य:

1 - आईडी द्वारा एक तत्व के लिए खोज (क्रमशः, लोकेटर में केवल आईडी निर्दिष्ट करें)
2 - डिफ़ॉल्ट रूप से (या यदि विशेषता सेट नहीं है) - xpath पर खोजें - यह केवल xpath पर खोज का उपयोग करने के लिए अनुशंसित है, यह विधि बाकी के लगभग सभी लाभों को जोड़ती है और सार्वभौमिक है

testcase

TestCase - xml फ़ाइल जो सीधे परीक्षण स्क्रिप्ट का वर्णन करती है, "\ TestSuite \ TestCase" निर्देशिका में स्थित है (आपकी जितनी चाहें उतनी फाइलें हो सकती हैं। फाइलों का नाम कुछ भी हो सकता है - केवल सामग्री मायने रखती है)।

XSD सर्किट:

 <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.1"> <xs:element name="testCase"> <xs:complexType> <xs:sequence> <xs:element name="testCaseName" type="xs:string"/> <xs:element name="webPackageName" type="xs:string"/> <xs:element name="actions" type="actionsType"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="actionsType"> <xs:sequence> <xs:element name="action" type="actionType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="actionType"> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="orderNumber" type="xs:positiveInteger"/> <xs:element name="runConfiguration" type="runConfigurationType"/> </xs:sequence> </xs:complexType> <xs:complexType name="runConfigurationType"> <xs:sequence> <xs:element name="formName" type="xs:string"/> <xs:element name="repeatsOnError" type="xs:positiveInteger" minOccurs="0"/> <xs:element name="events" type="eventsType"/> <xs:element name="exceptionBlock" type="eventsType" minOccurs="0"/> </xs:sequence> <xs:attribute name="openValidation" use="required"> <xs:simpleType> <xs:restriction base="xs:byte"> <xs:enumeration value="1"/> <xs:enumeration value="0"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="closeValidation" use="required"> <xs:simpleType> <xs:restriction base="xs:byte"> <xs:enumeration value="1"/> <xs:enumeration value="0"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="eventBaseType"> <xs:sequence> <xs:element name="orderNumber" type="xs:positiveInteger"/> </xs:sequence> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="goToURL"/> <xs:enumeration value="checkElementsVisibility"/> <xs:enumeration value="checkElementsInVisibility"/> <xs:enumeration value="fillingFields"/> <xs:enumeration value="clickElement"/> <xs:enumeration value="dbUpdate"/> <xs:enumeration value="wait"/> <xs:enumeration value="scrollDown"/> <xs:enumeration value="userInput"/> <xs:enumeration value="checkInputValues"/> <xs:enumeration value="checkQueryResultWithUtilityValue"/> <xs:enumeration value="checkFieldsPresenceByQueryResult"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="invertResult" use="optional" default="0"> <xs:simpleType> <xs:restriction base="xs:byte"> <xs:enumeration value="1"/> <xs:enumeration value="0"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="hasExceptionBlock" use="optional" default="0"> <xs:simpleType> <xs:restriction base="xs:byte"> <xs:enumeration value="1"/> <xs:enumeration value="0"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="eventsType"> <xs:sequence> <xs:element name="event" type="eventBaseType" maxOccurs="unbounded"> <xs:alternative test="@type='goToURL'" type="eventGoToURL"/> <xs:alternative test="@type='checkElementsVisibility'" type="eventCheckElementsVisibility"/> <xs:alternative test="@type='checkElementsInVisibility'" type="eventCheckElementsVisibility"/> <xs:alternative test="@type='fillingFields'" type="eventFillingFields"/> <xs:alternative test="@type='checkInputValues'" type="eventFillingFields"/> <xs:alternative test="@type='clickElement'" type="eventClickElement"/> <xs:alternative test="@TYPE='dbUpdate'" type="eventRequest"/> <xs:alternative test="@type='wait'" type="utilityValueInteger"/> <xs:alternative test="@type='scrollDown'" type="eventClickElement"/> <xs:alternative test="@type='userInput'" type="eventClickElement"/> <xs:alternative test="@type='checkQueryResultWithUtilityValue'" type="eventRequestWithValue"/> <xs:alternative test="@type='checkFieldsPresenceByQueryResult'" type="eventRequestWithValue"/> </xs:element> </xs:sequence> </xs:complexType> <!--   EVENTS --> <xs:complexType name="eventGoToURL"> <xs:complexContent> <xs:extension base="eventBaseType"> <xs:sequence> <xs:element name="url" type="xs:anyURI"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="eventCheckElementsVisibility"> <xs:complexContent> <xs:extension base="eventBaseType"> <xs:sequence> <xs:element name="fields" type="fieldType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="eventFillingFields"> <xs:complexContent> <xs:extension base="eventBaseType"> <xs:sequence> <xs:element name="fields" type="fieldTypeWithValue"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="eventClickElement"> <xs:complexContent> <xs:extension base="eventBaseType"> <xs:sequence> <xs:element name="elementName" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="eventRequest"> <xs:complexContent> <xs:extension base="eventBaseType"> <xs:sequence> <xs:element name="dbRequest" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="utilityValueInteger"> <xs:complexContent> <xs:extension base="eventBaseType"> <xs:sequence> <xs:element name="utilityValue" type="xs:positiveInteger"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="eventRequestWithValue"> <xs:complexContent> <xs:extension base="eventBaseType"> <xs:sequence> <xs:element name="dbRequest" type="xs:string"/> <xs:element name="utilityValue" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!--   EVENTS --> <xs:complexType name="fieldType"> <xs:sequence> <xs:element name="field" maxOccurs="unbounded"> <xs:complexType> <xs:choice> <xs:element name="element" type="xs:string"/> <xs:element name="xpath" type="xs:string"/> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="fieldTypeWithValue"> <xs:sequence> <xs:element name="field" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="element" type="xs:string"/> <xs:element name="value" type="valueType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="valueType"> <xs:complexContent> <xs:extension base="xs:anyType"> <xs:attribute name="type" use="optional" default="1"> <xs:simpleType> <xs:restriction base="xs:byte"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema>

सामान्य दृश्य:

 <!DOCTYPE testCase SYSTEM "./TestSuite/TestCase/entities.dtd" []> <testCase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="testShema.xsd"> <testCaseName>__testCase</testCaseName> <webPackageName>_webPackage__webPackageName</webPackageName> <actions> <action> <name>          </name> <orderNumber>10</orderNumber> <runConfiguration openValidation="1" closeValidation="1"> <formName>______</formName> <events> <event type="goToURL"> <orderNumber>10</orderNumber> <url>&srmURL;</url> </event> ....... </events> </runConfiguration> </action> ....... </actions> </testCase>

इस पंक्ति में आप देख सकते हैं कि xsd स्कीम को कैसे तेज किया जाए ताकि XML एडिटर इसे देख सके:

 <testCase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="testShema.xsd">

TestCase में, मैं DTD संस्थाओं का भी उपयोग करता हूं जो एक ही निर्देशिका में अलग से संग्रहीत की जाती हैं - एक्सटेंशन .dtd के साथ एक फ़ाइल। इसमें, मैं लगभग सभी डेटा - स्थिरांक को संग्रहीत करता हूं। मैंने इस तरह से तर्क का निर्माण किया कि एक नया परीक्षण शुरू करने के लिए, और पूरे परीक्षण के दौरान, नई अनूठी इकाइयाँ बनाई गईं, एक नया अंतरिक्ष यान पंजीकृत किया गया, इस फाइल में 1 अंक को बदलने के लिए पर्याप्त था।

इसकी संरचना बहुत सरल है - मैं एक उदाहरण दूंगा:

 <?xml version="1.0" encoding="UTF-8"?> <!ENTITY mainNumber '040'> <!ENTITY mail '@mail.ru'> <!ENTITY srmURL 'https://srm-test.ru'>

ऐसे स्थिरांक को टैग मूल्य में निम्नानुसार डाला जाता है:

 <url>&srmURL;</url>

- संयुक्त किया जा सकता है।

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

testcase

testCase - सबसे मूल टैग शामिल हैं:

testCaseName - हमारे परीक्षण मामले का नाम, इस पैरामीटर को एप्लिकेशन इनपुट में पास किया जाता है
webPackageName - WebPackage का नाम, जो WebPackageName में निर्दिष्ट है (WebPackage पर ऊपर पैरा देखें)
क्रिया - एक्शन एंटिटी कंटेनर

कार्य

शामिल हैं:

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

runConfiguration

शामिल हैं:

OpenValidation विशेषता - वैकल्पिक, डिफ़ॉल्ट "0" है
- 0 - प्रारंभिक फॉर्म सत्यापन का संचालन न करें
- 1 - प्रारंभिक प्रपत्र सत्यापन
विशेषता निकटता - वैकल्पिक, डिफ़ॉल्ट "0" है
- 0 - अंतिम रूप सत्यापन का संचालन न करें
- 1 - अंतिम रूप सत्यापन
formName - प्रपत्र का नाम जिसके भीतर क्रियाएँ की जाएंगी - WebPackage से फ़ॉर्मनाम मान
repeatsOnError - वैकल्पिक, इंगित करता है कि विफलता के मामले में कितने दोहराए जाने चाहिए
घटनाओं - घटना इकाई कंटेनर
अपवादब्लॉक - वैकल्पिक - एक त्रुटि के मामले में निष्पादित होने वाली घटना संस्थाओं का एक कंटेनर

घटना

न्यूनतम संरचनात्मक इकाई - यह इकाई दर्शाती है कि क्या कार्य किए जाते हैं

प्रत्येक ईवेंट विशेष है, इसमें अद्वितीय टैग और विशेषताएँ हो सकती हैं।

आधार प्रकार में शामिल हैं:

प्रकार विशेषता - तत्व के प्रकार को इंगित करता है
hasExceptionBlock विशेषता एक वैकल्पिक विशेषता है, डिफ़ॉल्ट रूप से "0" विफलता तंत्र को लागू करने के लिए आवश्यक है - विशेषता इंगित करती है कि हम इस घटना पर एक त्रुटि की उम्मीद कर सकते हैं
- 0 - कोई त्रुटि की उम्मीद नहीं है
- 1 - कार्रवाई पर एक संभावित त्रुटि की उम्मीद है
विशेषता invertResult - वैकल्पिक विशेषता, "0" के लिए चूक - विशेषता इंगित करती है कि घटना के परिणाम को बदलना आवश्यक है
- 0 - घटना के परिणाम को छोड़ दें
- 1 - घटना के परिणाम को विपरीत में बदलें

*! अपेक्षित त्रुटि का वर्णन करने के लिए एक तंत्र

मैं आपको एक तुच्छ उदाहरण देता हूं कि मैंने इसे पहली बार कहां इस्तेमाल किया और इसे काम करने के लिए क्या करना चाहिए।

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

मेरे संदर्भ से उदाहरण।

यहां बताया गया है कि मैंने इस कार्यक्रम को कैसे पंजीकृत किया:

 <event type="checkElementsInVisibility" hasExceptionBlock="1"> <orderNumber>57</orderNumber> <fields> <field> <element>___</element> </field> </fields> </event>

और यहाँ अपवाद घटनाओं के बाद

  <exceptionBlock> <event type="clickElement"> <orderNumber>10</orderNumber> <elementName>_____</elementName> </event> </exceptionBlock>

और हाँ, एक पृष्ठ पर कार्रवाई कई कार्यों में विघटित हो सकती है।

+ जो विन्यास में 2 मापदंडों को देखा: defaultTimeOutsForWebDriverWait, lowTimeOutsForWebDriverWait। इसलिए वे हैं। क्योंकि मेरे पास एक सिंगलटन में पूरा वेब ड्राइवर है, और मैं हर बार एक नया WebDriverWait नहीं बनाना चाहता था, तो मेरे पास 1 उपवास है और यह एक त्रुटि के मामले में है (अच्छी तरह से, या यदि आपने सिर्फ hasExceptionBit = "1" रखा है, तो यह कम समय के साथ बेवकूफ होगा। स्पष्ट प्रतीक्षा) - ठीक है, आपको सहमत होना चाहिए, यह सुनिश्चित करने के लिए एक मिनट प्रतीक्षा करें कि संदेश कमल आईल फूट नहीं आया है, साथ ही हर बार एक नया वेबड्राइवर बनाएं। खैर, यह स्थिति जिस तरफ छड़ी नहीं करती है उसे एक बैसाखी की आवश्यकता होती है - मैंने ऐसा करने का फैसला किया।

घटना प्रकार

यहां मैं अपनी घटनाओं का एक न्यूनतम सेट दूंगा, जैसे स्काउट सेट, जिसके साथ मैं अपने सिस्टम पर लगभग सब कुछ परीक्षण कर सकता हूं।

और अब यह समझने के लिए कोड के लिए चिकनी है कि एक घटना क्या है और यह कैसे बनाया गया है। कोड अनिवार्य रूप से रूपरेखा को लागू करता है। मेरे पास 2 कक्षाएं हैं - DataBaseWrapper और SeleniumWrapper। इन वर्गों में, बुनियादी ढांचे के घटकों के साथ बातचीत का वर्णन किया गया है, और मंच की विशेषताएं भी परिलक्षित होती हैं। मैं इंटरफ़ेस दूंगा जो सेलेनियमवॉपर को लागू करता है

 package logic.selenium; import models.ElementWithStringValue; import models.webpackage.Element; import org.openqa.selenium.WebElement; public interface SeleniumService { void initialization(boolean webDriverWait); void nacigateTo(String url); void refreshPage(); boolean checkElementNotPresent(Element element); WebElement findSingleVisibleElement(Element element); WebElement findSingleElementInDOM(Element element); void enterSingleValuesToWebField(ElementWithStringValue element); void click(Element element); String getInputValue(Element element); Object jsReturnsValue(String jsFunction); //Actions actions void doubleClick(Element element); void moveMouseToElement(Element element); void pressKey(CharSequence charSequence); void getScreenShot(String storage); }

यह सेलेनियम और ओवरले प्लेटफ़ॉर्म चिप्स की सभी विशेषताओं का वर्णन करता है - ठीक है, वास्तव में मुख्य चिप "एंटरसेलवैल्यूसटॉउवेफिल्ड" विधि है। याद रखें कि हम WebPackage में तत्व के प्रकार को निर्दिष्ट करते हैं। इसलिए, खेतों में भरने पर इस प्रकार की प्रतिक्रिया कैसे करें, यहां लिखा गया है। हम 1 बार लिखते हैं और भूल जाते हैं। उपरोक्त विधि को पहली बार में अपने लिए सही किया जाना चाहिए। उदाहरण के लिए, प्रकार 5 और 6, वर्तमान में लागू हैं, केवल मेरे सिस्टम के लिए उपयुक्त हैं। और यदि आपके पास फ़िल्टर के रूप में ऐसी कोई चीज़ है और आपको बहुत अधिक फ़िल्टर करने की आवश्यकता है, और यह विशिष्ट (आपके वेब एप्लिकेशन में) है, लेकिन इसका उपयोग करने के लिए आपको सबसे पहले माउस को फ़ील्ड में ले जाना होगा, कुछ फ़ील्ड्स के प्रकट होने की प्रतीक्षा करें, कुछ पर स्विच करें, प्रतीक्षा करें वहाँ कुछ है, तो वहाँ जाओ और दर्ज करें ... Stupidly कार्रवाई के तंत्र को 1 बार निर्धारित करें, स्विच संरचना में इस सभी को एक अद्वितीय प्रकार दें - आगे परेशान न करें - सभी समान एप्लिकेशन फ़िल्टर के लिए एक बहुरूपी विधि प्राप्त करें।

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

तो, एक स्काउट सेट।

goToURL - आमतौर पर पहली कार्रवाई - निर्दिष्ट लिंक पर क्लिक करें

एक उदाहरण:

 <event type="goToURL"> <orderNumber>10</orderNumber> <url>testURL</url> </event>

fillFields - निर्दिष्ट तत्वों को भरना

विशेष टैग:

फ़ील्ड - इकाई कंटेनर फ़ील्ड
- फ़ील्ड - में तत्व टैग है
  - तत्व - वेबपैक से तत्व के नाम को इंगित करता है
  - मूल्य - क्या मान इंगित करने के लिए, एक वैकल्पिक प्रकार विशेषता है (यदि तत्व एक चेकबॉक्स है, तो एक मान इंगित किया गया है: "चेक" या "अनचेक")

प्रकार विशेषता - इंगित करता है कि मूल्य कैसे लिया जाए, वैकल्पिक, डिफ़ॉल्ट मान "1" है
- 1 - निर्दिष्ट मूल्य लिया जाता है
- 2 - इस मामले में, "\ TestSuite \ JS" निर्देशिका से निर्दिष्ट JS फ़ंक्शन निष्पादित होता है! महत्वपूर्ण - txt फ़ाइल का नाम ".txt" के बिना इंगित किया गया है, (और अब तक मुझे केवल इस रूप में js फ़ंक्शंस के लिए एप्लिकेशन मिले हैं - मैं एक यादृच्छिक सराय उत्पन्न करने के लिए एक जगह पर इसका उपयोग करता हूं, लेकिन संभावित अनुप्रयोगों का स्पेक्ट्रम व्यापक है)
- 3 - इस मामले में, डेटाबेस में क्वेरी को मूल्य के रूप में दर्शाया गया है, और प्रोग्राम इस क्वेरी के पहले परिणाम को प्रतिस्थापित करता है

एक उदाहरण:

 <event type="fillingFields"> <orderNumber>10</orderNumber> <fields> <field> <element>test</element> <value>test</value> </field> </fields> </event>

checkElementsVisibility - जांचता है कि निर्दिष्ट तत्व फॉर्म पर मौजूद हैं (अर्थात्, दिखाई देते हैं, और केवल DOM में नहीं)। फ़ील्ड विशेषता में, WebPackage या सीधे xpath से एक तत्व निर्दिष्ट किया जा सकता है

एक उदाहरण:

 <event type="checkElementsVisibility"> <orderNumber>10</orderNumber> <fields> <field> <element>test</element> </field> <field> <xpath>test</xpath> </field> </fields> </event>

checkElementsInVisibility - CheckElementsVisibility के समान है, लेकिन इसके विपरीत

clickElement - निर्दिष्ट तत्व पर क्लिक करें

एक उदाहरण:

 <event type="clickElement"> <orderNumber>10</orderNumber> <elementName>test</elementName> </event>

checkInputValues - दर्ज किए गए मानों की जांच करें

एक उदाहरण:

 <event type="checkInputValues"> <orderNumber>10</orderNumber> <fields> <field> <element>test</element> <value>test</value> </field> </fields> </event>

dbUpdate - डेटाबेस में एक अपडेट करते हैं ( dbUpdate प्रकार की 1 घटना के लिए ओक्सीजन अजीब तरह से प्रतिक्रिया करता है - मुझे नहीं पता कि इसके साथ क्या करना है और मुझे समझ नहीं आ रहा है कि क्यों )

एक उदाहरण:

 <event type="dbUpdate"> <orderNumber>10</orderNumber> <dbRequest>update - </dbRequest> </event>

CheckQueryResultWithUtilityValue - डेटाबेस से मूल्य के साथ उपयोगकर्ता द्वारा दर्ज मूल्य की जांच करें

एक उदाहरण:

 <event type="checkQueryResultWithUtilityValue"> <orderNumber>10</orderNumber> <dbRequest>select ...</dbRequest> <utilityValue>test</utilityValue> </event>

checkFieldsPresenceByQueryResult - पैटर्न के आधार पर xpath द्वारा तत्वों की उपस्थिति के लिए जाँच करें। यदि वांछित पैटर्न निर्दिष्ट नहीं है, तो खोज पैटर्न के अनुसार घटित होगी ।//* [पाठ () [(सामान्य-स्थान (।), "$")]]], जहां "$" के बजाय डेटाबेस से एक मूल्य होगा। अपने स्वयं के पैटर्न का वर्णन करते समय, आपको उस स्थान पर "$" का संकेत करना चाहिए जहां आप डेटाबेस से मूल्य डालना चाहते हैं। मेरे सिस्टम में तथाकथित ग्रिड हैं जिनमें ऐसे मूल्य हैं जो आमतौर पर किसी तरह के दृष्टिकोण से बनते हैं। इस तरह की ग्रिड का परीक्षण करने के लिए यह घटना

एक उदाहरण:

 <event type="checkFieldsPresenceByQueryResult"> <orderNumber>10</orderNumber> <dbRequest>test</dbRequest> <utilityValue></utilityValue> </event>

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

एक उदाहरण:

 <event type="wait"> <orderNumber>10</orderNumber> <utilityValue>1000</utilityValue> </event>

स्क्रॉलडाउन - निर्दिष्ट तत्व से नीचे स्क्रॉल करें। यह इस तरह से किया जाता है: यह निर्दिष्ट तत्व पर क्लिक करता है और "PgDn" कुंजी दबाता है। मेरे मामलों में जहां मुझे नीचे स्क्रॉल करना पड़ा, यह ठीक काम करता है:

एक उदाहरण:

 <event type="scrollDown"> <orderNumber>10</orderNumber> <elementName>test</elementName> </event>

userInput - निर्दिष्ट तत्व में एक मान दर्ज करें। मेरे स्वचालन में एकमात्र अर्धचालक यंत्र, केवल कैप्चा के लिए उपयोग किया जाता है। मूल्य में प्रवेश करने का तत्व इंगित किया गया है। मान पॉप-अप संवाद बॉक्स में दर्ज किया गया है।

एक उदाहरण:

 <event type="userInput"> <orderNumber>10</orderNumber> <elementName>capch_input</elementName> </event>

कोड के बारे में

इसलिए, मैंने अंकल बॉब के क्लीन आर्किटेक्चर के सिद्धांतों के अनुसार मंच बनाने की कोशिश की।

संकुल:

आवेदन - आरंभीकरण और लॉन्च + कॉन्फ़िगर और रिपोर्ट (रिपोर्ट वर्ग के लिए मुझे डांट नहीं है - यह वही है जो इसे जितनी जल्दी हो सके, उतनी तेजी से संभव बनाता है)

लॉजिक - सेलेनियम और डीबी के प्रमुख तर्क + सेवाएं। घटनाएँ हैं।

मॉडल - XML में POJO और सभी सहायक वस्तु वर्ग

बर्तन - सेलेनियम और डीबी के लिए सिंगलटन

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

ठीक है, सब कुछ शुरू करने के लिए, जेडीके से पहले आपको ओजडबेक ड्रायवर डाउनलोड करने और "स्प्रिंटऑटोस्टेस्ट \ src \ lib" निर्देशिका में dzharnik छोड़ने की आवश्यकता होगी। मैं इसे प्रदान नहीं करता, क्योंकि अभी वहां ओरेकल पर सब कुछ गंभीर है - डाउनलोड करने के लिए पंजीकरण करना आवश्यक है, लेकिन मुझे यकीन है कि हर कोई किसी न किसी तरह से सामना करेगा (अच्छी तरह से, सुनिश्चित करें कि सभी फ़ोल्डर बनाए गए हैं, अन्यथा रिपोर्ट सहेजी नहीं जाएगी)

सारांश

इसलिए, हमारे पास एक परीक्षण लांचर है, जिसके लिए परीक्षण लिखना वास्तव में तेज़ है। कार्य सप्ताह के दौरान, मैं 1.5 घंटे के मैनुअल काम को स्वचालित करने में सक्षम था, जिसे 5-6 मिनट में रोबोट द्वारा निष्पादित किया जाता है। ये समाप्‍त परीक्षण मामले की लगभग 3700 लाइनें और 830 वर्णित तत्व (4800 से अधिक लाइनें) हैं। संख्या किसी न किसी तरह है, और इसलिए इसे मापा नहीं जाता है, लेकिन जो लोग स्वचालन में लगे हुए हैं, उन्हें समझना चाहिए कि यह एक बहुत ही उच्च आंकड़ा है, खासकर रोबोट-अनफ्रीगेटेड सिस्टम के लिए। उसी समय, मैं सब कुछ परीक्षण करता हूं - व्यावसायिक तर्क, जिस तरह से मैं भरे हुए विशेषताओं की शुद्धता के लिए कुछ नकारात्मक परीक्षण करता हूं, और एक बोनस के रूप में मैं हर वेब फॉर्म की जांच करता हूं, जिसके बारे में मैं आलसी नहीं हूं, और सभी कार्यात्मक और महत्वपूर्ण तत्वों का वर्णन करता हूं, मुझे स्वतंत्र रूप से उनकी आवश्यकता है मुझे या नहीं (एक छोटा विषयांतर - मैं मुख्य रूप से केवल परीक्षण लिखते समय क्लोज़वीडिलेशन का उपयोग करता हूं।जब यह स्थिर होता है, और यह स्पष्ट है कि स्थानीय लोग अंतर नहीं करते हैं, तो मैं इसे सभी कार्यों के लिए बंद कर देता हूं, ताकि प्रक्रिया तेजी से हो)।

पहली नज़र में, ऐसा लगता है कि xml की बहुत सारी लाइनें हैं, लेकिन व्यवहार में वे अर्ध-स्वचालित रूप से उत्पन्न होती हैं, और एक त्रुटि केवल सीधे दर्ज किए गए मापदंडों में हो सकती है (क्योंकि वास्तव में हमारे पास सत्यापन के 2 स्तर हैं - पहला योजना का xml है, दूसरा टेस्टकेस की शुरुआत में निर्दिष्ट रूपों और तत्वों की उपस्थिति के लिए जाँच)।

Minuses की - परीक्षणों की कोई स्पष्ट सीमाएँ नहीं हैं। जैसे, वे गायब हैं और आप मुझे दोष दे सकते हैं कि यह सिर्फ एक स्थूल लांचर है, परीक्षण नहीं। मैं यह कहता हूं:

प्लेटफ़ॉर्म में, परीक्षण को अलग-अलग दृष्टिकोणों से कई स्तरों पर अमूर्त रूप से विभाजित किया जाता है:

+ — « » + — ( – .. -)
( action — event c + )
, , – -. , – . , . , – ,
पृष्ठ पर प्रत्येक क्रिया एक इकाई परीक्षण है (एकल परिणाम सही या गलत लौटाता है)

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

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

मैं क्या करना चाहूंगा, इसके बारे में सोचना चाहता हूं, लेकिन मेरे हाथ अभी तक नहीं आए हैं:

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

खैर, बस इतना ही। मैं एक संदर्भ github संलग्न करता हूं: स्रोत कोड ।

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

सेलेनियम पर ऑटोटेस्ट्स को जल्दी और कुशलता से लिखने के लिए एक उपकरण बनाना

अवधारणा का

विधानसभा विवरण

एप्लिकेशन बिल्ड संरचना

आवेदन का संक्षिप्त विवरण

स्क्रिप्ट ऑपरेशन एल्गोरिथ्म (मुख्य तर्क)

टेस्टसुइट भरना

! महत्वपूर्ण

WebPackage

testcase

घटना प्रकार

कोड के बारे में

सारांश

More articles: