यूआई परीक्षण: विभिन्न प्रस्तावों पर सिस्टम की जाँच

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

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



हम एक प्रणाली बनाते हैं और उसे बनाए रखते हैं जिसमें 7 हजार सक्रिय उपयोगकर्ता हैं। अक्सर वे इन ब्राउज़रों का उपयोग करते हैं:



और निम्न स्क्रीन रिज़ॉल्यूशन:



हर बार एक नया संस्करण जारी करने के बाद, आपको इसे इन ब्राउज़रों और अनुमतियों में प्रदर्शन के लिए जांचना होगा।

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


पासवर्ड रिकवरी फॉर्म


वह पृष्ठ जिस पर पुनर्निर्देशन आवेदन के सफल प्रस्तुतिकरण के बाद होता है

इस तंत्र का सरलीकृत रूप में परीक्षण इस तरह दिखता है:



कोड के रूप में एक ही स्क्रिप्ट:

it('    ', async function(): Promise<boolean | void> { await browser.get(browser.baseUrl); await element(by.name('EmailOrLogin')).sendKeys(userLogin); await element(by.buttonText('')).click(); const screenshot = await browser.takeScreenshot(); const canonicalScreenshotPath = <   >; await compareScreenshot(screenshot, canonicalScreenshotPath); }); 

जैसा कि आप देख सकते हैं, परीक्षण कोड काफी सरल दिखता है, यह शाब्दिक रूप से दोहराता है कि ब्लॉक आरेख पर क्या दिखाया गया था।

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

चयनित टूलबॉक्स

क्रोम के साथ शुरू किया

परीक्षण स्वचालन के लिए, हमने एंगुलर अनुप्रयोगों के परीक्षण के लिए एक e2e फ्रेमवर्क, प्रोट्रैक्टर को चुना। हमारा आवेदन सिर्फ कोणीय पर है। प्रोट्रेक्टर के साथ, हमने दो प्रकार के परीक्षण किए:

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

उदाहरण के लिए, यदि आप ऊपर वर्णित उदाहरण को पार्स करना जारी रखते हैं।


अमान्य लिंक संदेश के साथ स्क्रीनशॉट


संदर्भ और वर्तमान स्क्रीनशॉट में अंतर (बटन का लेआउट) बकाइन में प्रकाश डाला गया है

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

FF और विभिन्न अनुमतियाँ जोड़ें

समय के साथ, मौजूदा UI परीक्षण प्रणाली के लिए हमारी आवश्यकताएं बढ़ी हैं:

• न केवल क्रोम में, बल्कि FF में भी परीक्षण चलाएं,
• आचरण स्क्रीनशॉट परीक्षण एक संकल्प पर नहीं, बल्कि सबसे लोकप्रिय लोगों पर,
• समानांतर में परीक्षण चलाते हैं।

तो, चलिए क्रोम और एफएफ दोनों के समानांतर हमारे परीक्षण चलाते हैं।

ऐसा करने के लिए, Protractor'a क्षमताओं के विन्यास में, इसे इस से बदलें:

 multiCapabilities: [ { shardTestFiles: true, maxInstances: 2, browserName: 'chrome' }, { shardTestFiles: true, maxInstances: 2, browserName: 'firefox' } ] 

यहां सब कुछ स्पष्ट है, जिसके लिए प्रत्येक सेटिंग जिम्मेदार है। केवल ध्यान देने योग्य है
shardTestFiles: true
/** * If this is set to be true, specs will be shared by file (ie all files to be run by this set of capabilities will run in parallel). * Default is false. */

इस ध्वज के साथ हम उन सभी ब्राउज़रों में सभी स्पेक्स के समानांतर लॉन्च प्रदान करते हैं जो मल्टीकैपिबिलिटी में निर्दिष्ट हैं।

चश्मा पैरामीटर शब्द स्पेक्स के नीचे छिपा हुआ है, जो यह निर्धारित करता है कि परीक्षण के साथ फ़ाइलों के लिए कौन सा टेम्पलेट खोजना है।

 exports.config = { ... specs: ['./e2e/**/*.spec.ts'], ... } 

सभी परीक्षणों को कई कल्पना-फाइलों में विभाजित करने का सिद्धांत काफी तार्किक लगता है। concurrency उन पर काम करती है (उदाहरण के लिए, एप्लिकेशन की प्रत्येक सुविधा के लिए एक विशेष फ़ाइल बनाएं)।

इसके अलावा, प्रोट्रैक्टर में सुइट्स को उजागर करने की क्षमता है।

 exports.config = { ... suites: { suite01: './e2e/**/suite01.*.spec.ts', suite02: './e2e/**/suite02.spec.ts', suite03: './e2e/**/suite03.spec.ts' }, ... } 

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

विभिन्न प्रस्तावों पर आवेदन के परीक्षण के लिए, हम निम्नलिखित तरीके से गए। प्रयोगात्मक अनुमति के रूप में, सबसे लोकप्रिय में से एक का चयन किया गया था: 1920x1080, 1366x768, 1440x10900, 768x1024। जब आप प्रत्येक परीक्षण चलाते हैं, तो शुरू में सभी आवश्यक क्रियाएं की जाती थीं, और फिर स्क्रीनशॉट चेक की एक श्रृंखला की जाती है।

हम IE और पूर्ण आकार के स्क्रीनशॉट कनेक्ट करते हैं

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

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



हम दो समाधानों पर बसे: ज़लेनियम और सेलेनियम-ग्रिड । हम इस बात का वर्णन छोड़ देते हैं कि उनमें से कौन सा एक समेटे हुए है, और दोनों में से जो कुछ भी मिला / नहीं मिला उसके बारे में बताएं।

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


1920x6000 के स्क्रीन साइज वाले दो ब्राउज़र

सेलेनियम-ग्रिड: IE में परीक्षण बहुत आसानी से शुरू हुए।
Minuses की: किसी भी आकार की ब्राउज़र विंडो के आकार को सेट करने का कोई तरीका नहीं है।

कुल: ज़लेनियम + सेलेनियम-ग्रिड
हम ज़लेनियम + सेलेनियम-ग्रिड के एक समूह पर बसे: ज़लेनियम के माध्यम से क्रोम और एफएफ में परीक्षण चलाने का निर्णय लिया गया, और आईई में आवेदन के न्यूनतम प्रदर्शन की जांच करने के लिए सेलेनियम-ग्रिड के माध्यम से।

प्रक्रिया में मिलने के लिए क्या दिलचस्प था

1. एक तत्व लोकेटर के रूप में formControlName का उपयोग करना

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

 exports.config = { ... onPrepare() { require('ts-node').register({ project: 'e2e/tsconfig.e2e.json' }); jasmine.getEnv().addReporter(new specReporter({ spec: { displayStacktrace: true } })); addFormControlNameLocator(protractor); } ... } function addFormControlNameLocator(protractor) { protractor.by.addLocator('formControlName', function(value, optParentElement) { var using = optParentElement || document; return using.querySelectorAll('[formControlName="' + value + '"]'); }); } 

2. विश्व और स्थानीय रूप से स्थापित वेबड्राइवर-मैनेजर के काम में अंतर प्रोट्रैक्टर में

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

प्रोजेक्ट फ़ोल्डर में जाने और वेबड्राइवर-मैनेजर अपडेट को निष्पादित करने के बाद, Chrome, FF, IE के लिए ड्राइवर डाउनलोड किए जाते हैं। उसके बाद, परीक्षण शुरू करते समय, उन्होंने त्रुटि पकड़ी:

No update-config.json found. Run 'webdriver-manager update' to download binaries.

हमें एहसास हुआ कि अगर हम nd स्क्रिप्ट में वेबड्राइवर-मैनेजर अपडेट पैक करते हैं तो त्रुटि गायब हो जाती है:

 { ... scripts:{ “webdriver-update”: “webdriver-manager update” } ... } 

और npm run webdriver-update माध्यम से npm run webdriver-update , दोनों ड्राइवर स्रोत और उपर्युक्त npm run webdriver-update config.json प्रोजेक्ट फ़ोल्डर में मिलते हैं।

3. डॉकटर-कंपोज़ के जरिए ज़लेनियम चलाना

Zalenium प्रलेखन docker docker run कमांड और docker-compose फ़ाइल के उदाहरणों के साथ है। जादू से सब कुछ लगभग दूर हो जाता है। एकमात्र समस्या जिसका हमें सामना करना पड़ा, जब डॉकटर-कम्पोज़ फ़ाइल के माध्यम से शुरू हुआ
/var/run/docker.sock is not a valid windows path । समाधान यहाँ है ।

4. प्रोटेक्टर द्वारा तत्वों की दृश्यता

हमारे प्रयोगों के दौरान, एक पल में हमें पृष्ठ पर कुछ मेनू को छेदने के कार्य का सामना करना पड़ा, अर्थात। मेनू के प्रत्येक पृष्ठ पर जाएं और स्क्रीनशॉट लें।



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

हमने पर्याप्त स्क्रीन चौड़ाई सेट करके समस्या को हल किया ताकि मेनू इसके अगले तत्व पर क्लिक करने से पहले दिखाई दे।

5. आईई (सेलेनियम-ग्रिड) में संकल्प परिवर्तन

जैसा कि आपको याद है, क्रोम और एफएफ में हमने स्क्रीन रिज़ॉल्यूशन में बदलाव को ठीक किया। जब IE में यह आया, तो हमने बस त्रुटि पकड़ी: Failed: java.io.IOException: Server returned HTTP response code: 405 for URL: http://localhost:21800/session/8d14426d-6483-4bbf-90b3-2a3ed46ebe9b/window/size ।

लंबे डिबग के बाद, यह पता लगाना संभव था कि त्रुटि उसी समय उड़ जाती है जब कोड निष्पादित करने का प्रयास कर रहा होता है: browser.driver.manage().window().setSize(x, y) । यदि आप browser.driver.manage().window().setPosition(x, y) को निष्पादित करने का प्रयास करते हैं। यह हमें इस तथ्य की ओर ले जाता है कि जब IE में परीक्षण चलाए जाते हैं तो स्क्रीन रिज़ॉल्यूशन को नियंत्रित करना असंभव है। समस्या का हल बैसाखी है जिसके साथ आपको अपना कोड ओवरले करना होगा ताकि जब IE चल रहा हो तो रिज़ॉल्यूशन की स्थिति को न बदलें।

6. ज़लेनियम और वेबसॉकेट

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

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

 location / { proxy_pass some_url; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection “upgrade”; } 

9. सेलेनियम-ग्रिड का शुभारंभ

सेलेनियम-ग्रिड चलाने के लिए हमें चाहिए:

• सेलेनियम-सर्वर ,
• IE ड्राइवर, जो वेबड्राइवर-प्रबंधक अपडेट --ie32 के माध्यम से प्राप्त करना आसान है।

सर्वर लॉन्च:

java -jar selenium-server-standalone.jar -role hub -hubConfig selenium-server-config.json

 selenium-server-config.json { "host": "127.0.0.1", "maxSessions": 5, "port": 4445, "cleanupCycle": 5000, "timeout": 300000, "newSessionWaitTimeout": -1, "servlets": [], "prioritizer": null, "capabilityMatcher": "org.openqa.grid.internal.utils.DefaultCapabilityMatcher", "throwOnCapabilityNotPresent": true, "nodePolling": 180000, "platform": "WINDOWS" } 

IE चालक को लॉन्च करना:

java -Dwebdriver.ie.driver=< > -jar selenium-server-standalone.jar -role node -nodeConfig .\\ie-driver-config.json

 ie-driver-config.json { "capabilities": [ { "browserName": "internet explorer", "maxInstances": 1, "platform": "WINDOWS", "webdriver.ie.driver": "C:/Program Files (x86)/Internet Explorer/iexplore.exe" } ], "cleanUpCycle": 2000, "timeout": 30000, "port": -1, "role": "node", "hub": "http://127.0.0.1:4445/grid/register/", "register": true, "maxSessions": 5 } 

सर्वर शुरू करते समय और ड्राइवर के हब URL'e में समान पोर्ट के उपयोग पर ध्यान दें। प्रोटेक्टर विन्यास में सेलेनियमएड्रेस के रूप में हम http://127.0.0.1:4445/wd/hub उपयोग करते हैं।

निष्कर्ष

इसलिए हमने अपना कार्य हल किया और हर बार एक नया संस्करण जारी करने के बाद, हम इसे इन ब्राउज़रों और प्रस्तावों में प्रदर्शन के लिए जाँच सकते हैं।

वर्कफ़्लो में परीक्षण कैसे बनाएँ

यह समझना महत्वपूर्ण है कि परीक्षण चलाने और उन्हें लिखने के लिए पूरे बुनियादी ढाँचे को उठाना ही पर्याप्त नहीं है। आपको यह सोचने की ज़रूरत है कि आप अपने दैनिक जीवन में उनका उपयोग कैसे करेंगे।

हमने CI में UI परीक्षण लागू नहीं किया, क्योंकि वे लंबे समय तक निष्पादित होते हैं ताकि वे प्रत्येक निर्माण के लिए अपने निष्पादन की प्रतीक्षा कर सकें।

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

अंत में, हम जोर देना चाहते हैं:

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

हमारा मानना ​​है कि आसानी से किए जाने पर UI परीक्षण स्वचालित है। तो टिप्पणियों में अपने अवलोकन और सफल टूल हमारे साथ साझा करें।

हमसे उपयोगी लिंक:

• प्रोट्रैक्टर: ए न्यू होप - माइकल गियामबालो, क्रेग निशिना
• ज़लेनियम बनाम सेलेनॉइड
• डॉकर में सेलेनियम गर्ड में प्रोटेक्टर टेस्ट केस