CssSelector और Xpath में क्या अंतर है और जो क्रॉस ब्राउज़र परीक्षण के लिए प्रदर्शन के संबंध में बेहतर है?

Question 1

मैं बहुभाषी वेब एप्लिकेशन पर सेलेनियम वेबड्राइवर 2.25.0 के साथ काम कर रहा हूं और मुख्य रूप से पृष्ठ सामग्री (अरबी, अंग्रेजी, रूसी और इसी तरह की विभिन्न भाषाओं के लिए) का परीक्षण कर रहा हूं।

मेरे आवेदन के लिए जो प्रदर्शन के अनुसार बेहतर है और सुनिश्चित करें कि यह सभी ब्राउज़रों (यानी IE 7,8,9, FF, क्रोम आदि) के लिए समर्थन होना चाहिए।

आपके बहुमूल्य सुझावों के लिए अग्रिम धन्यवाद।

Question 2

CSS चयनकर्ता Xpath से बेहतर प्रदर्शन करते हैं और यह सेलेनियम समुदाय में अच्छी तरह से प्रलेखित है। यहाँ कुछ कारण हैं,

Xpath इंजन प्रत्येक ब्राउज़र में भिन्न होते हैं, इसलिए उन्हें असंगत बनाते हैं
IE में एक देशी xpath इंजन नहीं है, इसलिए सेलेनियम अपने API की संगतता के लिए अपना स्वयं का xpath इंजन इंजेक्ट करता है। इसलिए हम मूल ब्राउज़र सुविधाओं का उपयोग करने का लाभ खो देते हैं जो वेबड्राइवर स्वाभाविक रूप से बढ़ावा देता है।
Xpath जटिल हो जाते हैं और इसलिए मेरी राय में पढ़ना मुश्किल है

हालाँकि ऐसी कुछ परिस्थितियाँ हैं, जहाँ, आपको xpath का उपयोग करने की आवश्यकता है, उदाहरण के लिए, मूल तत्व की खोज या इसके पाठ द्वारा खोज तत्व (मैं बाद की सिफारिश नहीं करूँगा)।

आप यहाँ साइमन से ब्लॉग पढ़ सकते हैं । वह Xpath पर CSS की सिफारिश भी करता है।

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

संपादित करें 1

@Parishodak के लिए धन्यवाद, यहां वह लिंक दिया गया है जो यह साबित करता है कि सीएसएस प्रदर्शन बेहतर है

Question 3

मैं एसओ सेलेनियम टैग राय पर अलोकप्रिय रखने जा रहा हूं कि XPath लंबे समय में सीएसएस के लिए बेहतर है।

इस लंबे पोस्ट के दो खंड हैं - पहले मैं बैक-ऑफ-द-नैपकिन प्रूफ दूंगा, दोनों के बीच प्रदर्शन अंतर 0.1-0.3 मिलीसेकंड है (हाँ; यह 100 माइक्रो सेकंड है) , और फिर मैं अपनी राय साझा करूँगा क्यों XPath अधिक शक्तिशाली है।

प्रदर्शन अंतर

चलो पहले "कमरे में हाथी" से निपटते हैं - जो xpath सीएसएस की तुलना में धीमा है।

वर्तमान सीपीयू पावर (2013 से उत्पादित कुछ भी x86) के साथ , यहां तक कि ब्राउज़रस्टैक / सॉसेलब / एम्स वीएम और ब्राउज़र के विकास पर भी (पढ़ें: पिछले 5 वर्षों में सभी लोकप्रिय हैं) शायद ही ऐसा हो। ब्राउज़र के इंजन विकसित हो गए हैं, xpath का समर्थन एक समान है, IE तस्वीर से बाहर है (हम में से अधिकांश के लिए उम्मीद है) । अन्य उत्तर में इस तुलना का सभी जगह उल्लेख किया जा रहा है, लेकिन यह बहुत ही प्रासंगिक है - कितने चल रहे हैं - या IE8 के खिलाफ स्वचालन के बारे में परवाह है?

यदि अंतर है, तो यह एक मिलीसेकंड के एक अंश में है ।

फिर भी, अधिकांश उच्च-स्तरीय ढांचे कच्चे सेलेनियम कॉल पर ओवरहेड के कम से कम 1ms को जोड़ते हैं (रैपर, हैंडलर, स्टेट स्टोरिंग आदि); पसंद का मेरा व्यक्तिगत हथियार - रोबॉटफ़्रेमवर्क - कम से कम 2ms जोड़ता है, जो मुझे प्रदान करने के लिए बलिदान करने से अधिक खुश है। AWS us-East-1 से BrowserStack के हब तक एक नेटवर्क राउंडट्रिप आमतौर पर 11 मिलीसेकंड है ।

इसलिए दूरस्थ ब्राउज़रों के साथ अगर xpath और css के बीच अंतर होता है, तो इसे परिमाण के क्रम में, बाकी सब चीज़ों के साथ बदल दिया जाता है।

माप

ऐसा नहीं है कि कई सार्वजनिक तुलनाएं (मैंने वास्तव में केवल एक का उल्लेख किया है) , इसलिए - यहां एक मोटा एकल-मामला, डमी और सरल है।
यह दो रणनीतियों X बार एक तत्व का पता लगाएगा, और उसके लिए औसत समय की तुलना करेगा।

लक्ष्य - ब्राउज़रस्टैक का लैंडिंग पृष्ठ, और इसका "साइन अप" बटन; इस पोस्ट को लिखने के रूप में HTML का स्क्रीनशॉट:

यहाँ परीक्षण कोड (अजगर) है:

from selenium import webdriver
import timeit


if __name__ == '__main__':

    xpath_locator = '//div[@class="button-section col-xs-12 row"]'
    css_locator = 'div.button-section.col-xs-12.row'

    repetitions = 1000

    driver = webdriver.Chrome()
    driver.get('https://www.browserstack.com/')

    css_time = timeit.timeit("driver.find_element_by_css_selector(css_locator)", 
                             number=repetitions, globals=globals())
    xpath_time = timeit.timeit('driver.find_element_by_xpath(xpath_locator)', 
                             number=repetitions, globals=globals())

    driver.quit()

    print("css total time {} repeats: {:.2f}s, per find: {:.2f}ms".
          format(repetitions, css_time, (css_time/repetitions)*1000))
    print("xpath total time for {} repeats: {:.2f}s, per find: {:.2f}ms".
          format(repetitions, xpath_time, (xpath_time/repetitions)*1000))

उन लोगों के लिए जो पायथन से परिचित नहीं हैं - यह पृष्ठ खोलता है, और तत्व पाता है - पहले सीएसएस लोकेटर के साथ, फिर xath के साथ; खोज ऑपरेशन को 1,000 बार दोहराया गया है। आउटपुट 1,000 पुनरावृत्ति के लिए सेकंड में कुल समय है, और मिलीसेकंड में एक के लिए औसत समय है।

लोकेटर हैं:

xpath के लिए - "एक दिव्य तत्व जिसमें यह सटीक वर्ग मान है, कहीं डोम में";
सीएसएस समान है - "इस वर्ग के साथ एक दिव्य तत्व, डोम में कहीं"।

जानबूझकर ओवर-ट्यून नहीं चुना गया; वर्ग चयनकर्ता को सीएसएस के लिए "एक आईडी के बाद दूसरा सबसे तेज़" के रूप में उद्धृत किया गया है।

पर्यावरण - क्रोम v66.0.3359.139, क्रोमेड्रिवर v2.38, सीपीयू: ULV Core M-5Y10 आमतौर पर 1.5GHz पर चल रहा है (हाँ, एक "वर्ड-प्रोसेसिंग" एक, नियमित रूप से i7 जानवर भी नहीं) ।

यहाँ उत्पादन है:

css total time 1000 repeats: 8.84s, per find: 8.84ms

xpath total time for 1000 repeats: 8.52s, per find: 8.52ms

जाहिर है प्रति खोज समय बहुत करीब हैं; अंतर 0.32 मिलीसेकंड है । कूद मत "xpath तेज है" - कभी-कभी यह है, कभी-कभी यह सीएसएस है।

आइए स्थानीय लोगों के एक और सेट के साथ प्रयास करें, एक छोटा सा और अधिक जटिल - एक विशेषता जिसमें एक विकल्प है (कम से कम मेरे लिए सामान्य दृष्टिकोण, तत्व के वर्ग के बाद जा रहा है जब इसका एक हिस्सा कार्यात्मक अर्थ धारण करता है) :

xpath_locator = '//div[contains(@class, "button-section")]'
css_locator = 'div[class~=button-section]'

दो लोकेटर फिर से एक ही हैं - "अपनी कक्षा में इस तत्व को प्रतिस्थापित करने वाले एक दिव्य तत्व को खोजें"।
यहाँ परिणाम हैं:

css total time 1000 repeats: 8.60s, per find: 8.60ms

xpath total time for 1000 repeats: 8.75s, per find: 8.75ms

0.15ms की कठिनाई ।

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

वे कोड में कुछ चीजें कर रहे हैं - इसके द्वारा सॉर्ट करने के लिए एक कॉलम पर क्लिक करना, फिर मान प्राप्त करना और यूआई सॉर्ट की जांच करना सही है।
मैं इसे काट दूंगा - बस लोकेटर मिल जाएंगे, आखिर - यह रूट टेस्ट है, है ना?

इन परिवर्तनों के साथ ऊपर जैसा ही कोड:

Url अब है http://the-internet.herokuapp.com/tables; 2 परीक्षण हैं।
पहले एक के लिए लोकेटर - "आईडी और क्लास द्वारा तत्वों का पता लगाना" -

css_locator = '#table2 tbody .dues'
xpath_locator = "//table[@id='table2']//tr/td[contains(@class,'dues')]"

और यहाँ परिणाम है:

css total time 1000 repeats: 8.24s, per find: 8.24ms

xpath total time for 1000 repeats: 8.45s, per find: 8.45ms

की Diff 0.2 मिलीसेकंड।

"ट्रेसिंग द्वारा तत्व ढूँढना":

css_locator = '#table1 tbody tr td:nth-of-type(4)'
xpath_locator = "//table[@id='table1']//tr/td[4]"

परिणाम:

css total time 1000 repeats: 9.29s, per find: 9.29ms

xpath total time for 1000 repeats: 8.79s, per find: 8.79ms

इस बार यह 0.5 एमएस है (रिवर्स में, xpath यहां "तेज" निकला)।

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

तो, xpath और css में से, दोनों में से किसको प्रदर्शन के लिए चुनना है? उत्तर सरल है - आईडी द्वारा पता लगाना चुनें ।

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

फिर भी, अद्वितीय और निरंतर (उदाहरण के लिए ऑटो-जेनरेट नहीं) आईडी हमेशा उपलब्ध नहीं होती हैं, जो हमें "सीएसएस के लिए सीएसएस क्यों है?"

XPath लाभ

चित्र के प्रदर्शन से, मुझे लगता है कि xpath बेहतर क्यों है? सरल - बहुमुखी प्रतिभा, और शक्ति।

Xpath XML दस्तावेजों के साथ काम करने के लिए विकसित भाषा है; जैसे, यह सीएसएस की तुलना में बहुत अधिक शक्तिशाली निर्माणों की अनुमति देता है।
उदाहरण के लिए, पेड़ में हर दिशा में नेविगेशन - एक तत्व ढूंढें, फिर उसके दादा-दादी के पास जाएं और इसके कुछ गुणों वाले बच्चे की खोज करें।
यह एम्बेडेड बूलियन स्थितियों की अनुमति देता है - cond1 and not(cond2 or not(cond3 and cond4)); एम्बेडेड चयनकर्ता - "इन विशेषताओं वाले इन बच्चों वाले एक डिव को खोजें, और फिर उसके अनुसार नेविगेट करें"।
XPath एक नोड के मूल्य (इसके पाठ) के आधार पर खोज करने की अनुमति देता है - हालांकि इस अभ्यास पर आधारित है, यह विशेष रूप से बुरी तरह से संरचित दस्तावेजों में काम में आता है (गतिशील आईडी और कक्षाओं की तरह कोई निश्चित गुण नहीं है - इस पाठ द्वारा तत्व का पता लगाएं सामग्री) ।

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

आउटरो;)

अंत में, फिर से बहुत व्यक्तिपरक - जो एक को चुना?

आईएमओ, कोई सही या गलत विकल्प नहीं है - वे एक ही समस्या के अलग-अलग समाधान हैं, और जो कुछ भी नौकरी के लिए अधिक उपयुक्त है, उसे चुनना चाहिए।

XPath का "प्रशंसक" होने के नाते मुझे अपनी परियोजनाओं में दोनों के मिश्रण का उपयोग करने में शर्म नहीं है - बिल्ली, कभी-कभी यह सिर्फ एक सीएसएस एक को फेंकने के लिए बहुत तेज़ होता है, अगर मुझे पता है कि यह काम ठीक कर देगा।

Question 4

CssSelector बनाम XPath के बीच बहस सेलेनियम समुदाय में सबसे व्यक्तिपरक बहस में से एक के रूप में रहेगी । अब तक जो हम पहले से ही जानते हैं उसे संक्षेप में प्रस्तुत किया जा सकता है:

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

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

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

परीक्षण व्यवस्था

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

टेस्ट कोड

require_relative 'base'
require 'benchmark'

class LargeDOM < Base

  LOCATORS = {
    nested_sibling_traversal: {
      css: "div#siblings > div:nth-of-type(1) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3)",
      xpath: "//div[@id='siblings']/div[1]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]"
    },
    nested_sibling_traversal_by_class: {
      css: "div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1",
      xpath: "//div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]"
    },
    table_header_id_and_class: {
      css: "table#large-table thead .column-50",
      xpath: "//table[@id='large-table']//thead//*[@class='column-50']"
    },
    table_header_id_class_and_direct_desc: {
      css: "table#large-table > thead .column-50",
      xpath: "//table[@id='large-table']/thead//*[@class='column-50']"
    },
    table_header_traversing: {
      css: "table#large-table thead tr th:nth-of-type(50)",
      xpath: "//table[@id='large-table']//thead//tr//th[50]"
    },
    table_header_traversing_and_direct_desc: {
      css: "table#large-table > thead > tr > th:nth-of-type(50)",
      xpath: "//table[@id='large-table']/thead/tr/th[50]"
    },
    table_cell_id_and_class: {
      css: "table#large-table tbody .column-50",
      xpath: "//table[@id='large-table']//tbody//*[@class='column-50']"
    },
    table_cell_id_class_and_direct_desc: {
      css: "table#large-table > tbody .column-50",
      xpath: "//table[@id='large-table']/tbody//*[@class='column-50']"
    },
    table_cell_traversing: {
      css: "table#large-table tbody tr td:nth-of-type(50)",
      xpath: "//table[@id='large-table']//tbody//tr//td[50]"
    },
    table_cell_traversing_and_direct_desc: {
      css: "table#large-table > tbody > tr > td:nth-of-type(50)",
      xpath: "//table[@id='large-table']/tbody/tr/td[50]"
    }
  }

  attr_reader :driver

  def initialize(driver)
    @driver = driver
    visit '/large'
    is_displayed?(id: 'siblings')
    super
  end

  # The benchmarking approach was borrowed from
  # http://rubylearning.com/blog/2013/06/19/how-do-i-benchmark-ruby-code/
  def benchmark
    Benchmark.bmbm(27) do |bm|
      LOCATORS.each do |example, data|
    data.each do |strategy, locator|
      bm.report(example.to_s + " using " + strategy.to_s) do
        begin
          ENV['iterations'].to_i.times do |count|
         find(strategy => locator)
          end
        rescue Selenium::WebDriver::Error::NoSuchElementError => error
          puts "( 0.0 )"
        end
      end
    end
      end
    end
  end

end

परिणाम

नोट : आउटपुट सेकंड में है, और परिणाम 100 निष्पादन के कुल रन समय के लिए हैं।

तालिका प्रपत्र में:

चार्ट फॉर्म में:

क्रोम :

फ़ायरफ़ॉक्स :

इंटरनेट एक्सप्लोरर 8 :

इंटरनेट एक्सप्लोरर 9 :

इंटरनेट एक्सप्लोरर 10 :

ओपेरा :

परिणामों का विश्लेषण

क्रोम और फ़ायरफ़ॉक्स स्पष्ट रूप से तेज cssSelector प्रदर्शन के लिए तैयार हैं।
Internet Explorer 8 cssSelector का एक हड़पने वाला बैग है जो काम नहीं करेगा, नियंत्रण से बाहर XPath ट्रैवर्सल जो ~ 65 सेकंड लेता है, और 38 सेकंड टेबल ट्रैवर्सल जिसमें कोई cssSelector परिणाम नहीं है, उसके खिलाफ तुलना करें।
IE 9 और 10 में, XPath समग्र रूप से तेज है। सफारी में, यह एक अप टॉस, साथ धीमी ट्रेवर्सल रन के एक जोड़े के अलावा है XPath । और लगभग सभी ब्राउज़रों में, नेस्टेड भाई ट्रेवर्सल और तालिका सेल ट्रेवर्सल के साथ किया XPath एक महंगी आपरेशन कर रहे हैं।
ये आश्चर्य की बात नहीं होनी चाहिए क्योंकि स्थानीय लोग भंगुर और अक्षम हैं और हमें उनसे बचने की आवश्यकता है।

सारांश

कुल मिलाकर दो परिस्थितियाँ हैं जहाँ XPath cssSelector की तुलना में धीमा है । लेकिन वे आसानी से परिहार्य हैं।
प्रदर्शन का अंतर इसके पक्ष में थोड़ा है सीएसएस-चयनकर्ताओं गैर-IE ब्राउज़रों के लिए और इसके पक्ष में थोड़ा xpath IE ब्राउज़रों के लिए।

सामान्य ज्ञान

आप इस पुस्तकालय का उपयोग करके बेंच-मार्किंग स्वयं कर सकते हैं, जहां डेव हैफनर ने सभी कोड को लपेटा है।