सेलेनियम 2.0 - वेबड्राइवर। छापें, समस्याओं और उपयोग के लिए युक्तियाँ

परिचय

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

संक्षेप में सेलेनियम के बारे में

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

मैंने लागू करने के लिए क्या प्रबंध किया था

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

भाग एक छापों

विभिन्न ब्राउज़रों में अलग व्यवहार

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

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

सेलेनियम 2.0 - कच्चा उत्पाद

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

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

सेलेनियम टेस्ट - डिपेंडेंट टेस्ट

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

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

सेलेनियम टेस्ट - धीमी टेस्ट

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

परिषद:
केवल वही परखें जो वास्तव में परखने की जरूरत है। एक ही कार्रवाई को लागू करने के लिए सभी संभव कार्य विकल्पों में से - सबसे तेज़ चुनें।

सेलेनियम आईडीई - कोई सहायक नहीं

सेलेनियम आईडीई फ़ायरफ़ॉक्स के लिए एक विशेष प्लग-इन है, जो स्क्रिप्ट के रूप में सभी प्रदर्शन किए गए उपयोगकर्ता कार्यों को रिकॉर्ड करने में सक्षम है। वहां आप विभिन्न भाषाओं में और दो प्रारूपों में संकलित लिपियों का निर्यात कर सकते हैं: सेलेनियम 1.0 (आरसी) और सेलेनियम 2.0 (वेबडेवर)।
ज्यादातर मामलों में, एक बेकार बात।

समस्याएं हैं:

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

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

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

भाग दो उभरते मुद्दों (जावा) के लिए व्यावहारिक समाधान

नीचे वर्णित समाधान सुंदर नहीं हैं, आदर्श हैं, वे अस्वीकृति का कारण बन सकते हैं, लेकिन वे काम कर रहे हैं। मेरे अनुभव में, वे समस्याओं को खत्म करते हैं। मुझे आशा है कि वे लाभान्वित होंगे और आपको खोए हुए घंटों और दिनों से बचाएंगे।

एक तत्व प्राप्त करना (खोज करना)

समस्या:
WebDriver एक WebElement इकाई को खोजने और पुनः प्राप्त करने के लिए एक तंत्र प्रदान करता है:

webDriver.findElement(By.id("elementId")); 

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

 webDriver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS); 

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

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

कोड उदाहरण:

 protected WebElement findElement(By elementLocatorToFind) { if(isSafari() || isChrome() || isIE()) { // for example, use simple Thread.sleep(1000) inside doDelayForMilliseconds(1000); } return webDriver.findElement(elementLocatorToFind); } 

आइटम प्राप्त करना (खोजें)

समस्या और समाधान एक तत्व को खोजने के समान है।

किसी तत्व के अस्तित्व की जाँच करें

यदि यह सत्यापित करना आवश्यक है कि तत्व गायब है, तो निर्माण का उपयोग करने की अनुशंसा की जाती है:

 findElements(elementLocatorToFind).isEmpty(); 

यहाँ JavaDocs से एक सिफारिश की गई है:

गैर-मौजूद तत्वों की तलाश के लिए findElement का उपयोग नहीं किया जाना चाहिए, findElements (By) का उपयोग करें और इसके बजाय शून्य लंबाई प्रतिक्रिया का जोर दें।

चित्र या फ़ाइल डाउनलोड करना

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

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

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

कोड उदाहरण:

  // just look at your cookie's content (eg using browser) and import these settings from it private static final String SESSION_COOKIE_NAME = "JSESSIONID"; private static final String DOMAIN = "domain.here.com"; private static final String COOKIE_PATH = "/cookie/path/here"; protected boolean isResourceAvailableByUrl(String resourceUrl) { HttpClient httpClient = new DefaultHttpClient(); HttpContext localContext = new BasicHttpContext(); BasicCookieStore cookieStore = new BasicCookieStore(); cookieStore.addCookie(getSessionCookie()); localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore); // resourceUrl - is url which leads to image HttpGet httpGet = new HttpGet(resourceUrl); try { HttpResponse httpResponse = httpClient.execute(httpGet, localContext); return httpResponse.getStatusLine().getStatusCode() == HttpStatus.SC_OK; } catch (IOException e) { return false; } } protected BasicClientCookie getSessionCookie() { Cookie originalCookie = webDriver.manage().getCookieNamed(SESSION_COOKIE_NAME); if (originalCookie == null) { return null; } String cookieName = originalCookie.getName(); String cookieValue = originalCookie.getValue(); BasicClientCookie resultCookie = new BasicClientCookie(cookieName, cookieValue); resultCookie.setDomain(DOMAIN); resultCookie.setExpiryDate(originalCookie.getExpiry()); resultCookie.setPath(COOKIE_PATH); return resultCookie; } 

क्लीयर इनपुट फ़ील्ड मान

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

समस्या:
कभी-कभी, आपको किसी प्रकार के इनपुट के क्षेत्र का मान साफ़ करने की आवश्यकता होती है। उदाहरण के लिए, आपको पुराने मान को नए के साथ बदलने की आवश्यकता है।
WebDriver इसके लिए एक विशेष विधि प्रदान करता है:

 webElement.clear(); 

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

समाधान:
कई बुनियादी तरीके हैं।
पहला तरीका "सभी का चयन करें" कार्रवाई का अनुकरण करना है और इसके तुरंत बाद एक नया मूल्य भेजना है:

 inputElement.sendKeys(Keys.chord(Keys.CONTROL, "a") + Keys.DELETE + newValue); 

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

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

कोड उदाहरण:

 protected void clearInput(WebElement webElement) { // isIE() - just checks is it IE or not - use your own implementation if (isIE() && "file".equals(webElement.getAttribute("type"))) { // workaround // if IE and input's type is file - do not try to clear it. // If you send: // - empty string - it will find file by empty path // - backspace char - it will process like a non-visible char // In both cases it will throw a bug. // // Just replace it with new value when it is need to. } else { // if you have no StringUtils in project, check value still empty yet while (!StringUtils.isEmpty(webElement.getAttribute("value"))) { // "\u0008" - is backspace char webElement.sendKeys("\u0008"); } } } 

सर्वर पर फ़ाइल अपलोड करें

समस्या:
आपको मानक HTML तत्वों का उपयोग करके फ़ाइल को सर्वर पर अपलोड करना होगा:

 <input name="uploadFile" type="file"> <input name="doUpload" value="Upload" type="button"/> 

समाधान:
मैं आपको इसे लेने और इसे एक अलग सार्वभौमिक विधि में डालने की सलाह देता हूं और हर बार आपको इस फॉर्म के माध्यम से कुछ अपलोड करने की आवश्यकता होती है।

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

कोड उदाहरण:

 protected void uploadFile(By uploadInput, By uploadButton, String filePath) { clearInput(uploadInput); findElement(uploadInput).sendKeys(filePath); findElement(uploadButton).click(); } 

आइफ्रेम के अंदर तत्वों के साथ क्रिया

समस्या:
यदि आवश्यक तत्व iframe के अंदर है, तो यह डिफ़ॉल्ट संदर्भ से सुलभ नहीं है। आप DOM मॉडल में इसका पता नहीं लगा सकते हैं और WebDriver NoSuchElementException को फेंक देगा।

समाधान:
इस तत्व के साथ बातचीत करने से पहले, आपको वेबड्राइवर को तत्व के iframe संदर्भ पर स्विच करना होगा। जैसा कि मैं इसे समझता हूं, यह इस तथ्य के कारण है कि इस पृष्ठ पर पृष्ठ संदर्भ और iframe संदर्भ दो भिन्न DOM मॉडल हैं।

कोड उदाहरण:

 webDriver.switchTo().frame(findElement(By.id("id_of_your_iframe"))); // do actions against inner web element, located in iframe webDriver.switchTo().defaultContent(); // continue to do actions in default content 

IE8। XPath मुद्दा

समस्या:
IE8, अपने अजीब विलक्षण तरीके से, कभी-कभी तत्व सूचक (By.id, By.xpath और अन्य) का गलत अर्थ निकालता है।
मेरे पास ऐसी परिस्थितियाँ थीं जब उन्होंने आवश्यक तत्व के शोधन को अनदेखा कर दिया जो कि उसकी वर्गीय विशेषता को दर्शाता है।
उदाहरण के लिए, IEDriver ने दो अलग-अलग तत्वों द्वारा पाया जाने वाले ऐसे तत्वों के बीच अंतर करने से इनकार कर दिया और दोनों विकल्पों के लिए उपयुक्त तत्व प्रदर्शित किए:

 findElement(By.xpath("//div[@id='elementContainer']/div[@class='someProcessInProgress']")); findElement(By.xpath("//div[@id='elementContainer']/div[@class='someProcessFinished']")); 

मैं समझ नहीं पा रहा था कि उन्हें किन परिस्थितियों में समस्या हो रही है।
तत्व की आईडी के प्रत्यक्ष संकेत के साथ एक बिल्कुल समान स्थिति उत्पन्न हुई। वेबड्राइवर का दावा है कि यह मौजूद नहीं है।

समाधान:
यदि IEDriver में एक तत्व खोजने में एक आभामंडलिक भ्रम है (लेकिन अन्य ड्राइवरों और ब्राउज़रों में नहीं) - XPath को बदलने का सबसे अच्छा तरीका है। एक्सपीथ के लचीलेपन के लिए धन्यवाद, हमेशा कई विकल्प होते हैं।

IE8। आइटम क्लिक करने योग्य नहीं है

समस्या:
IE8, अन्य ब्राउज़रों के विपरीत, हमेशा किसी तत्व को स्वतंत्र रूप से स्क्रॉल करने में सक्षम नहीं होता है यदि आप कंटेनर के दृश्य भाग (परत, तालिका, आदि) के बाहर स्थित किसी तत्व पर क्लिक करते हैं। नतीजतन, यह व्यवहार एक त्रुटि की ओर जाता है।

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

 new Actions(webDriver).moveToElement(elementToScrollTo).perform(); 

लेकिन यह IE8 के मामले में काम नहीं करेगा।

कोड उदाहरण:

 ((JavascriptExecutor) webDriver).executeScript("container.scrollLeft=1000;"); 

जहां कंटेनर स्क्रॉल करने के लिए तत्व की आईडी है। यानी हमारे मामले में, एक div या तालिका जिसके अंदर तत्व स्थित है। जैसा कि आप देख सकते हैं, यह स्क्रिप्ट क्षैतिज रूप से स्क्रॉल करेगी।

फ़ायरफ़ॉक्स मर सकता है

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

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

निष्कर्ष

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

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

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