Was ist der Unterschied zwischen cssSelector & Xpath und was ist besser in Bezug auf Leistung für cross-browser-testing?
Arbeite ich mit der Selenium WebDriver 2.25.0 auf mehrsprachigen web-Anwendung & vor allem die Seite testen von Inhalten (Für unterschiedliche Sprachen, wie Arabisch, Englisch, Russisch & so weiter).
Für meine Anwendung was ist besser nach Leistung & stellen Sie sicher, dass es sein sollte die Unterstützung für alle Browser (d.h. IE 7,8,9, FF, Chrome etc).
Vielen Dank im Voraus für Ihre wertvollen Anregungen.
Du musst angemeldet sein, um einen Kommentar abzugeben.
CSS-Selektoren führen viel besser als Xpath-und es ist gut dokumentiert, die in Selen-community. Hier sind einige Gründe,
Allerdings gibt es einige Situationen, in denen müssen Sie xpath verwenden, zum Beispiel die Suche nach einem übergeordneten element oder die Suche element durch seinen text (ich würde nicht empfehlen, das später).
Lesen Sie den blog von Simon hier . Er empfiehlt auch CSS über Xpath.
Wenn Sie Inhalte testen, dann verwenden Sie keine Auswahlen, die abhängig vom Inhalt der Elemente. Das wird ein Wartungs-Albtraum für jedes Gebietsschema. Versuchen im Gespräch mit den Entwicklern und verwenden Techniken, die Sie verwendet, um zu externalisieren, den text in der Anwendung, wie Wörterbücher oder resource bundles etc. Hier ist mein blog erklärt, dass es im detail.
Bearbeiten 1
Dank @parishodak, hier ist die link das die zahlen beweisen, dass die CSS-performance ist besser
Werde ich halten Sie die ungeliebten auf, SO Selen tag Meinung, dass XPath ist vorzuziehen CSS auf längere Sicht.
Dieser lange Beitrag hat zwei Teile: - die erste, die ich werde einen back-of-the-Serviette Nachweis der performance-Unterschied zwischen den beiden ist 0.1-0.3 Millisekunden (ja, das ist 100 microSekunden), und dann werde ich teilen Sie meine Meinung, warum XPath ist mächtiger.
Performance-Unterschied
Wir zuerst angehen "der Elefant im Raum" – xpath ist langsamer als css.
Mit der aktuellen cpu-Leistung (lies: alles, was x86 produziert seit 2013), auch auf browserstack/saucelabs/aws VMs, und die Entwicklung der Browser (read: alle populären, in den letzten 5 Jahren) das ist kaum der Fall. Die browser-engines entwickelt haben, die Unterstützung von xpath ist es, einheitliche, SPRICH ist aus dem Bild (hoffentlich für die meisten von uns). Dieser Vergleich in der anderen Antwort zitiert, die alle über den Ort, aber es ist sehr kontextuell – wie viele laufen – oder care-about – automation-gegen IE8?
Wenn es einen Unterschied gibt, ist es in einer Bruchteil einer Millisekunde.
Noch, die meisten höher-level-frameworks fügen Sie mindestens 1ms overhead über die raw-Selen rufen sowieso (Wrapper, Handler, Zustand, Lagerung usw.); meine persönliche Waffe der Wahl – RobotFramework – fügt mindestens 2ms, die ich mehr als glücklich bin, Opfer zu bringen für was es bietet. Ein Netz hin-und Rückfahrkarte von einem AWS-us-east-1 zu BrowserStack hub ist in der Regel 11 Millisekunden.
Also mit remote-Browser, ob es einen Unterschied zwischen xpath und css, es ist überschattet alles, was sonst in Größenordnungen.
Die Messungen
Gibt es nicht viele öffentliche Vergleiche (habe ich wirklich gesehen, nur die zitiert eine), so – hier ist eine grobe Einzel-Fall, dummy und einfaches.
Es wird, suchen Sie ein element, indem Sie die zwei Strategien, die X-mal, und vergleichen Sie die Durchschnittliche Zeit für die.
Ziel – BrowserStack ist "Startseite", und seine "Anmelden" - Taste, einen screenshot von der html-wie das schreiben dieses post:
Hier ist der test-code (python):
Für diejenigen, die nicht vertraut sind mit Python – es öffnet sich die Seite, und sucht das element – zuerst mit der css-locator, um dann mit xpath; die Suche-Funktion wiederholt sich 1000 mal. Die Ausgabe ist die Summe der Zeit in Sekunden, für die 1000 Wiederholungen, und die Durchschnittliche Zeit für einen finden in Millisekunden.
Den Locator-Punkten liegen:
Bewusst entschieden, nicht über-tuned; auch, wird der class-Selektor wird zitiert für die css als "die zweitbeste nach der id".
Umwelt – Chrom-v66.0.3359.139, chromedriver v2.38, cpu: ULV Core M-5Y10 in der Regel läuft bei 1,5 GHz (ja, ein "word-processing" ein, nicht einmal eine regelmäßige i7 beast).
Hier ist die Ausgabe:
Offensichtlich die pro finden, die timings sind ziemlich nahe; der Unterschied ist 0.32 Millisekunden. Springen Sie nicht "den xpath-schneller" – manchmal ist es, manchmal ist es css.
Lassen Sie uns versuchen, mit einem anderen Satz von Locator, eine kleine-etwas komplizierter – ein Attribut, mit einer substring (gemeinsames Konzept, zumindest für mich, zu gehen, nachdem ein element der Klasse, wenn ein Teil davon trägt der funktionellen Bedeutung):
Die beiden Locator-Punkte werden wieder semantisch die gleiche – "finden Sie ein div-element mit in seiner Klasse-Attribut dieses substring".
Hier sind die Ergebnisse:
Diff 0.15 ms.
Als übung - der gleiche test wie in der verlinkten blog in die Kommentare/andere Antwort - die test Seite ist öffentlich, und so ist die testen von code.
Sind Sie dabei ein paar Dinge in der code - Klick auf eine Spalte zu Sortieren, klicken Sie dann, um die Werte und die Prüfung der UI-sort korrekt.
Ich werde schneiden Sie es - Holen Sie sich den Locator, nachdem alle - das ist der root-test, richtig?
Den gleichen code wie oben, mit folgenden änderungen:
Die url ist jetzt
http://the-internet.herokuapp.com/tables
; es gibt 2 tests.Den Locator für die erste - "suchen von Elementen nach ID und Klasse" - das sind:
Und hier ist das Ergebnis:
Diff 0.2 Millisekunden.
Den "Suchen Von Elementen Durch Das Durchlaufen":
Das Ergebnis:
Dieser Zeit ist es 0.5 ms (in umgekehrter, xpath stellte sich heraus, "schneller" hier).
Also 5 Jahre später (besserer Browser-engines) und sich nur auf die Locator-Punkte-performance (keine Aktionen wie Sortieren in der Benutzeroberfläche, etc), das gleiche testbed - es gibt praktisch keinen Unterschied zwischen CSS und XPath.
So, aus xpath und css, die von den zwei zu wählen, für die Leistung? Die Antwort ist einfach – wählen Sie Auffinden von id.
Lange Geschichte kurz, wenn Sie die id eines Elements eindeutig ist (wie es sein sollte laut specs), dessen Wert spielt eine wichtige Rolle in der browser-interne Darstellung des DOM, und damit ist in der Regel die schnellsten.
Doch, eindeutige und Konstante (z.B. nicht auto-generiert) - ids sind nicht immer verfügbar, und das bringt uns zu "warum XPath-wenn es CSS?"
Der XPath-Vorteil
Mit der Leistung aus dem Bild heraus, warum ich denke, dass xpath ist besser? Einfache Vielseitigkeit und power.
Xpath ist eine Sprache entwickelt, die für die Arbeit mit XML-Dokumenten; als solche, es ermöglicht eine wesentlich mächtigere Konstrukte als css.
Zum Beispiel, die navigation in jede Richtung, in die Baum – finden Sie ein element, dann gehen Sie zu Ihren Großeltern und suchen für ein Kind mit bestimmten Eigenschaften.
Es ermöglicht die eingebetteten booleschen Bedingungen –
cond1 and not(cond2 or not(cond3 and cond4))
; embedded – Selektoren - "Suche ein div, dass diese Kinder, die mit diesen Attributen, und navigieren Sie dann entsprechend zu".XPath ermöglicht die Suche basiert auf einem Knoten den Wert (text) – jedoch missbilligt diese Praxis ist, es kommt in praktisch, vor allem in schlecht strukturierten Dokumenten (keine bestimmte Attribute, auf Schritt, wie dynamische ids und Klassen - suchen Sie das element, indem Sie seine text-Inhalte).
Wird der Schrittmotor in css ist auf jeden Fall einfacher – man kann anfangen zu schreiben Selektoren in einer Angelegenheit von Minuten, aber nach ein paar Tagen der Nutzung, der macht und Möglichkeiten von xpath hat schnell überwindet css.
Und rein subjektiv – eine komplexe css ist viel schwerer zu Lesen als eine komplexe xpath-Ausdruck.
Outro 😉
Schließlich, wieder sehr subjektiv - was man zu wählen?
IMHO gibt es keine richtige oder falsche Entscheidung - Sie sind verschiedene Lösungen für das gleiche problem, und was ist besser geeignet für den job sollte abgeholt werden.
Als "fan" der XPath-ich bin nicht schüchtern, um meine Projekte, die eine Mischung aus beiden - was solls, manchmal ist es viel schneller, um nur werfen eine CSS ein, wenn ich weiß, es wird funktionieren just fine.
[]
nach//
zum Beispiel),. Aber nach dem ersten Tag zu lernen und es zu benutzen, so ziemlich jeder kreuzt, der Wendepunkt der Lernkurve 🙂 (css Schritt ist admitably einfacher, IMHO).Die Debatte zwischen cssSelector vs XPath bleiben würde, als einer der am meisten subjektive Debatte in der Selen Gemeinschaft. Was wir bereits wissen, so weit kann wie folgt zusammengefasst werden:
Dave Haeffner durchgeführt test auf eine Seite mit zwei HTML-Tabellen, eine Tabelle geschrieben wird, ohne hilfreiche Attribute (ID und Klasse), und der andere mit Ihnen. Ich habe analysiert, die Prüfverfahren und das Ergebnis dieses Experiments in details in die Diskussion Warum sollte ich jemals verwenden cssSelector Selektoren im Gegensatz zu XPath für die automatisierte Prüfung?. Während dieses experiment zeigte, dass jeder Locator-Strategie ist einigermaßen gleichwertigen Browsern, es nicht ausreichend zu malen, das ganze Bild für uns. Dave Haeffner in der anderen Diskussion Css Vs. X-Pfad, Unter dem Mikroskop erwähnt, in einer end-to-end-test es gab eine Menge andere Variablen mit im Spiel Sauce startup, Browser starten, und Latenz zu und von der zu testenden Anwendung. Der unglückliche zum mitnehmen aus, dass experiment könnte sein, dass ein Treiber ist möglicherweise schneller als die anderen (z.B. IE vs Firefox), wenn in der Tat, das war nicht der Fall. Um einen echten Geschmack von dem, was der performance-Unterschied ist zwischen cssSelector und XPath, die wir brauchten, um tiefer zu Graben. Wir wussten, dass durch die Ausführung alles aus einer lokalen Maschine, während mit einem performance-benchmarking-Dienstprogramm. Zudem konzentrierten wir uns auf eine bestimmte Selen-Aktion, anstatt den gesamten test run, und führen Sie die Dinge unzählige Male. Ich habe analysiert, die spezifischen Prüfverfahren und das Ergebnis dieses Experiments in details in die Diskussion cssSelector vs XPath für Selen. Aber die tests waren immer noch fehlt ein Aspekt, dh mehr browser-Abdeckung (z.B. Internet Explorer 9 und 10) und die Prüfung gegen eine größere und tiefere Seite.
Dave Haeffner in einer anderen Diskussion Css Vs. X-Pfad, Unter dem Mikroskop (Teil 2) erwähnt, um sicherzustellen, dass die erforderlichen Auflagen sind in der bestmöglichen Weise, die wir berücksichtigen müssen ein Beispiel, das demonstriert eine große und Tiefe Seite.
Test-SetUp
Demonstrieren dieses detaillierte Beispiel einen virtuellen Computer mit Windows XP setup und Ruby (1.9.3) installiert wurde. Alle verfügbaren Browser und deren äquivalente browser Treiber für Selen wurde auch installiert. Für das benchmarking, Ruby ' s standard-lib
benchmark
verwendet wurde.Test-Code
Ergebnisse
In Tabellarischer Form:
In Diagramm-Form:
Analyse der Ergebnisse
Zusammenfassung
Trivia
Führen Sie die bench-marking auf eigene, mit diese Bibliothek wo Dave Haeffner umwickelt, bis der gesamte code.