cssSelector vs XPath für Selen

Question

Nach meinem Verständnis, CSS-Selektor durchläuft das DOM. Da CSS-Dateien keine Informationen über die Elementposition haben, ist cssSelector schneller als XPath (theoretisch).

Theoretisch:

cssSelector weniger Zeit nehmen, dann XPath als XPath müssen durch HTML-DOM zu durchqueren. XPath können wir Elemente rückwärts oder vorwärts in der DOM-Hierarchie suchen, während CSS nur in einer Vorwärtsrichtung arbeitet.

Aber wenn cssSelector auch durch HTML DOM durchlaufen dann wie cssSelector schneller machen.

Mit anderen Worten, wie cssSelector tatsächlich funktioniert intern und Grund, warum es immer vorzuziehen/empfohlen von jedermann zu verwenden, dann XPath

Bitte auch cssSelector über XPath mit anderem Vorteil teilen.

Und umgekehrt, in welchem ​​Bereich XPath sind besser als cssSelector

Answer 1

Ich habe viele Artikel gelesen, und ich habe einige wie this und this mit Daten, die zeigen, dass die CSS-Selektoren sind schneller und ich gesehen Ich habe ein wenig getestet und bin zu demselben Schluss gekommen. Ich habe im Dezember 2016 mit Dave Haeffner, dem Autor von elementsalselenium.com, gesprochen und ihn über die Perf-Zahlen auf seiner Seite befragt (in dem Beitrag, den ich oben verlinkt habe), da sie ziemlich alt waren. Er linked me a presentation (siehe Seite 18-23), wo er die Tests aktualisiert und CSS-Selektoren sind noch schneller, aber XPath holt in einigen Konfigurationen auf.

So können wir Beweise sehen, dass es wahr ist, aber ich habe nie jemanden gesehen, der über die technischen Details von warum spricht. Wenn ich raten würde, wäre es, weil viel Arbeit in die verschiedenen Browser investiert wurde, um die Geschwindigkeit des Seitenrenderings zu optimieren. Durch die schnelle Verwendung von CSS-Selektoren wird die Seite schneller gerendert, und da die Browsertreiber die Fähigkeit des Browsers zum Auffinden von Elementen nutzen, gewinnen CSS-Selektoren im Allgemeinen. Ich habe gelesen, dass einige Browser ihre XPath-Locator-Geschwindigkeit verbessert haben, aber ich denke, dass sie hinter CSS-Selektoren immer zurückbleiben wird, da sie viel weniger häufig als CSS-Selektoren ist.

Sowohl CSS-Selektoren als auch XPath müssen durch das DOM laufen, so dass es keinen wirklichen Unterschied gibt, außer der Geschwindigkeit des Motors, der das Traversieren durchführt. Die CSS-Selektor-Engine ist zu diesem Zeitpunkt wahrscheinlich eine fein abgestimmte Maschine gegenüber der XPath-Engine, da CSS-Selektoren weit verbreitet sind.

Meine allgemeine Locator-Strategie ist ID zuerst, CSS-Selektor für alles andere. Wenn nichts anderes funktioniert, verwende ich XPath. Es wird von Ort zu Ort variieren, aber nach meiner Erfahrung sind IDs vielleicht ~ 10% meiner Locators. CSS-Selektoren sind wahrscheinlich ~ 80% und die letzten 10% sind XPath. Ich verwende XPath im Allgemeinen, wenn ich ein Element nach dem enthaltenen Text und sehr selten nach DOM-Traversal suchen muss. Ein Beispiel für meine XPath-Verwendung könnte sein, dass ich ein Element in einer TABLE relativ zu einer Zeilenbezeichnung finden muss, z. der Preis von Käse in einer Tischreihe, wo die erste Zelle "Käse" enthält und die dritte Zelle den Preis enthält.

Ich denke, dass XPath viel auf Websites wie SO und vielen Blogs wegen seines einfachen Zugriffs gesehen wird. Alles, was ich tun muss, ist mit der rechten Maustaste auf ein Element in den Devtools und Copy XPath. Das Problem ist oft ein schlechter, spröder XPath. Ein handgefertigter XPath ist besser, aber es braucht Zeit und Erfahrung, um einen guten XPath- oder CSS-Selektor zu erstellen. Zeit, die viele nicht einbringen wollen. Ein schlecht gestalteter CSS-Selektor oder XPath wird auch die Dinge langsamer machen. Es gibt viele Möglichkeiten, ein Element zu finden, einige sind viel effizienter als andere ... es hängt von der Effizienz des Locators ab und wie Sie ihn verwenden.Ein schlecht gestalteter CSS-Selektor wird nicht automatisch schneller als ein wohlgeformter XPath.