Jaka jest różnica między css-selector i Xpath? co jest lepsze(w zależności od wydajności i testowania między przeglądarkami)?

Utrzymam niepopularną opinię na temat tagu selenium, że XPATH jest preferowany od CSS w dłuższej perspektywie.

Pozwól, że najpierw zajmę się "The elephant in the room" – xpath jest wolniejszy niż css.

Przy obecnej mocy procesora (Czytaj: wszystko, co wyprodukowano w ciągu ostatnich 5 lat), nawet na Browserstack/saucelabs VM, i rozwoju przeglądarek (czytaj: wszystkie popularne w ciągu ostatnich 5 lat), że nie jest to przypadek. Rozwijały się silniki przeglądarki, obsługa xpath jest jednorodny, czyli nie ma go w obrazku (mam nadzieję, że dla większości z nas). To porównanie w drugiej odpowiedzi jest cytowane wszędzie, ale jest bardzo kontekstowe-ilu działa - lub obchodzi-przeciwko IE8?

Jeśli istnieje różnica, jest toułamek milisekundy .

Jednak większość frameworków wyższego poziomu dodaje przynajmniej 1ms nad wywołaniem raw selenium (wrappery, manipulatory, przechowywanie stanu itp.); moja osobista broń z wyboru – robotframework-dodaje co najmniej 2ms, które z przyjemnością poświęcę za to, co zapewnia. Obieg sieciowy z AWS us-east-1 do koncentratora BrowserStack wynosi zwykle 11 milisekund.

Więc w przypadku zdalnych przeglądarek, jeśli istnieje różnica między XPath a css, jest ona przyćmiona przez Wszystko inne.

Nie ma zbyt wielu publicznych porównań (naprawdę widziałem cytowane), więc – tutaj jest szorstki pojedynczy przypadek, głupi i prosty. Cel – Strona docelowa browserstacka i przycisk "Zarejestruj się"; zrzut ekranu html:

Oto kod testowy (python):

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))

dla tych, którzy nie są zaznajomieni z Pythonem-otwiera stronę i znajduje element-najpierw z lokalizatorem css, a następnie z xpath; operacja find jest powtarzana 1000 razy. Wyjście jest całkowity czas w sekundach dla 1000 powtórzeń, a średni czas dla jednego znaleziska w milisekundach.

The lokalizatory są – dla xpath - "elementem div o tej dokładnej wartości klasy, gdzieś w DOM"; css jest podobny - "elementem div o tej klasie, gdzieś w DOM". Celowo wybrany, aby nie być przesadnie dostrojony; również selektor klas jest cytowany dla css jako "drugi najszybszy po id".

Oto wyjście:

Css łączny czas 1000 powtórzeń: 8.84 s, per find: 8.84 ms

XPath łączny czas dla 1000 powtórzeń: 8.52 s, per find: 8.52 ms

Oczywiście czasy per find są dość bliskie; różnica jest 0.32 milisekundy. Nie skacz – xpath jest szybszy-czasem jest, czasem jest css.

Spróbujmy z innym zestawem lokalizatorów, trochę bardziej skomplikowanym-atrybutem posiadającym podłańcuch (wspólne podejście przynajmniej dla ja, idąc za klasą elementu, gdy jego część nosi znaczenie funkcjonalne):

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

Dwa lokalizatory są ponownie semantycznie takie same – "znajdź element div mający w swojej klasie atrybut ten podłańcuch". Oto wyniki:

Css łączny czas 1000 powtórzeń: 8.60 s, per find: 8.60 ms

XPath całkowity czas dla 1000 powtórzeń: 8.75 s, per find: 8.75 ms

Różnica 0,15 ms.

Przy bardziej złożonym DOM, wyniki są takie same; nie mam żadnych publicznie dostępne adresy URL pod ręką, aby dać przykład, ale ponownie widziałem podobne wyniki dla XPath i css.

Jako ćwiczenie-ten sam test, co w linked blog {[29] } w komentarzach / inne odpowiedzi - strona testowa jest publiczna, podobnie jak kod testowy .

Robią kilka rzeczy w kodzie-klikają na kolumnę, aby ją sortować, następnie pobierają wartości i sprawdzają poprawność sortowania interfejsu. Wytnę-po prostu weź lokalizatory, po tym wszystkim to jest test root, prawda?

Ten sam kod jak wyżej, z tymi zmianami w:

Adres url jest teraz http://the-internet.herokuapp.com/tables; są 2 testy.

Lokalizatory dla pierwszego z nich - "Finding Elements By ID and Class" - to:

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

Wynik:

Css łączny czas 1000 powtórzeń: 8.24 s, per find: 8.24 ms

XPath całkowity czas dla 1000 powtórzeń: 8.45 s, per find: 8.45 ms

Różnica 0,2 milisekundy.

" Znajdowanie Elementów Przez Przejście": {]}

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

Wynik:

Css łączny czas 1000 powtórzeń: 9.29 s, per find: 9.29 ms

XPath łączny czas dla 1000 powtórzeń: 8.79 s, per find: 8.79 ms

Tym razem jest to 0,5 ms (w odwrotnej kolejności xpath okazał się tutaj "szybszy").

Więc, poza xpath i css, który z nich wybrać dla wydajności? Odpowiedź jest prosta-Wybierz lokalizowanie według id .

W skrócie, jeśli id elementu jest unikalne (jak to według specyfikacji), jego wartość odgrywa ważną rolę w wewnętrznej reprezentacji DOM przeglądarki, a więc jest zwykle najszybsza.

Z występem poza obrazem, dlaczego uważam, że xpath jest lepszy? Proste-wszechstronność i moc.

Xpath jest językiem stworzonym do pracy z dokumentami XML; jako taki pozwala na znacznie potężniejsze konstrukcje niż css.
Na przykład, nawigacja w każdym kierunku w drzewie-znajdź element, a następnie udać się do dziadka i szukać dziecka z niego o pewnych właściwościach. Pozwala na wbudowane warunki logiczne-cond1 I not (cond2 lub not (cond3 i cond4)); wbudowane selektory - "znajdź div o tych dzieciach z tymi atrybutami, a następnie Nawiguj zgodnie z nim". Umożliwia przeszukiwanie w oparciu o wartość węzła – jednak jest to przydatne szczególnie w źle zorganizowanych dokumentach (brak określonych atrybutów, takich jak dynamiczne identyfikatory i klas).

Krok w css jest zdecydowanie łatwiejszy – można zacząć pisać selektory w ciągu kilku minut; ale po kilku dniach użytkowania, moc i możliwości xpath szybko pokonuje css.
I czysto subiektywne – złożony css jest o wiele trudniejszy do odczytania niż złożone wyrażenie xpath.

Wreszcie, znowu bardzo subiektywny-który wybrać? IMHO, nie ma dobrego lub złego wyboru - są to różne rozwiązania tego samego problemu, a co więcej nadaje się do pracy należy wybrać. Będąc fanem xpath nie wstydzę się używać w moich projektach mieszanki obu-heck, czasami jest znacznie szybciej po prostu rzucić css jeden, jeśli Wiem, że będzie działać dobrze.