div - xpath list of elements

¿Cuál es la diferencia entre css-selector & Xpath? que es mejor(de acuerdo con el rendimiento y para las pruebas de navegador cruzado)?

Question

Estoy trabajando con Selenium WebDriver 2.25.0 en una aplicación web multilingüe y principalmente pruebo el contenido de la página (para diferentes idiomas como árabe, inglés, ruso, etc.).

Para mi aplicación, que es mejor según el rendimiento y asegúrese de que sea compatible con todos los navegadores (es decir, IE 7,8,9, FF, Chrome, etc.).

Gracias de antemano por sus valiosas sugerencias.

Answer 1

La principal ventaja de usar CSS en IE (generalmente en la mayoría de los navegadores) es que es un poco más rápido que xpath. Puede consultar este enlace para obtener una mejor imagen.

Answer 2

Los selectores de CSS funcionan mucho mejor que Xpath y está bien documentado en la comunidad de Selenium. Aquí hay algunas razones,

• Los motores Xpath son diferentes en cada navegador, por lo tanto, son inconsistentes
• IE no tiene un motor xpath nativo, por lo tanto, el selenio inyecta su propio motor xpath para la compatibilidad de su API. Por lo tanto, perdemos la ventaja de utilizar funciones nativas del navegador que WebDriver promueve inherentemente.
• Xpath tiende a volverse complejo y, por lo tanto, dificulta la lectura en mi opinión

Sin embargo, hay algunas situaciones en las que necesita usar xpath, por ejemplo, buscar un elemento padre o elemento de búsqueda por su texto (no lo recomendaría más adelante).

Puedes leer el blog de Simon here . También recomienda CSS sobre Xpath.

Si está probando contenido, no use selectores que dependan del contenido de los elementos. Eso será una pesadilla de mantenimiento para cada localidad. Intente hablar con los desarrolladores y use las técnicas que usaron para externalizar el texto en la aplicación, como diccionarios o paquetes de recursos, etc. Aquí está mi blog que lo explica en detalle.

editar 1

Gracias a @parishodak, aquí está el link que proporciona los números que demuestran que el rendimiento de CSS es mejor

Answer 3

Voy a tener la opinión poco popular de la etiqueta de selenio SO que XPATH es preferible a CSS en el largo plazo.

Déjame abordar "el elefante en la habitación" - xpath es más lento que css.

Con la potencia actual de la CPU (léase: cualquier cosa producida en los últimos 5 años), incluso en las VM de navegador / salsalabs, y el desarrollo de los navegadores (léase: todos los populares en los últimos 5 años), ese no es el caso. Los motores del navegador se han desarrollado, el soporte de xpath es uniforme, IE está fuera de la imagen (con suerte para la mayoría de nosotros). Esta comparación en la otra respuesta se está citando por todas partes, pero es muy contextual: ¿cuántos corren o se preocupan por IE8?

Si hay una diferencia, es en una fracción de milisegundo .

Sin embargo, la mayoría de los marcos de nivel superior agregan al menos 1 ms de sobrecarga a la llamada de selenio sin procesar de todos modos (envoltorios, manipuladores, almacenamiento de estado, etc.); mi arma personal preferida - robotframework - agrega al menos 2ms, que estoy más que feliz de sacrificar por lo que proporciona. Una red de ida y vuelta desde un AWS us-east-1 al concentrador BrowserStack generalmente es de 11 milisegundos .

Entonces, con los navegadores remotos si hay una diferencia entre xpath y css, se ve eclipsado por todo lo demás.

No hay tantas comparaciones públicas (realmente he visto el citado), entonces, aquí hay un caso único, ficticio y simple. El objetivo: la página de destino de BrowserStack y su botón de Registrarse; una captura de pantalla del html:

Aquí está el código de prueba (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))

Para aquellos que no están familiarizados con Python, abre la página y encuentra el elemento, primero con el localizador css y luego con xpath; la operación de búsqueda se repite 1,000 veces. El resultado es el tiempo total en segundos para las 1,000 repeticiones y el tiempo promedio para un hallazgo en milisegundos.

Los localizadores son - para xpath - "un elemento div que tiene este valor de clase exacto, en algún lugar del DOM"; el css es similar - "un elemento div con esta clase, en algún lugar del DOM". Deliberadamente elegido para no ser sobreajustado; también, el selector de clase se cita para el css como "el segundo más rápido después de un id".

El entorno: Chrome v66.0.3359.139, chromedriver v2.38, cpu: ULV Core M-5Y10, por lo general, funciona a 1.5 GHz (sí, uno de procesamiento de textos, ni siquiera una bestia regular i7).

Aquí está el resultado:

css tiempo total 1000 repeticiones: 8.84s, por búsqueda: 8.84ms

xpath tiempo total para 1000 repeticiones: 8.52s, por búsqueda: 8.52ms

Obviamente, los tiempos de búsqueda son bastante cercanos; la diferencia es 0.32 milisegundos . No saltar el xpath es más rápido, a veces lo es, a veces es css.

Probemos con otro conjunto de localizadores, un poco más complicado: un atributo que tiene una subcadena (enfoque común al menos para mí, yendo después de la clase de un elemento cuando una parte tiene un significado funcional):

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

Los dos localizadores son semánticamente los mismos: "encuentra un elemento div que tenga en su atributo de clase esta subcadena". Aquí están los resultados:

css tiempo total 1000 repeticiones: 8.60s, por búsqueda: 8.60ms

Tiempo total de xpath para 1000 repeticiones: 8.75s, por búsqueda: 8.75ms

Diferencia de 0.15ms.

Con DOM más complejo, los resultados son los mismos; No tengo ninguna URL disponible públicamente para dar un ejemplo, pero he visto resultados similares para xpath y css.

Como un ejercicio, la misma prueba que se realiza en el elementalselenium.com/tips/32-xpath-vs-css en los comentarios / otra respuesta, la página de prueba es pública, al igual que el código de prueba .

Están haciendo un par de cosas en el código, haciendo clic en una columna para ordenarla, luego obteniendo los valores y verificando que la ordenación de la interfaz de usuario sea correcta. Lo cortaré, solo obtengo los localizadores, después de todo, esta es la prueba de raíz, ¿no?

El mismo código que el anterior, con estos cambios en:

La URL ahora es http://the-internet.herokuapp.com/tables ; hay 2 pruebas

Los localizadores para el primero - "Encontrar elementos por ID y clase" - son:

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

El resultado:

css tiempo total 1000 repeticiones: 8.24s, por búsqueda: 8.24ms

Tiempo total de xpath para 1000 repeticiones: 8.45s, por búsqueda: 8.45ms

Diferencia de 0.2 milisegundos.

El "Encontrar elementos atravesando":

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

El resultado:

css tiempo total 1000 repeticiones: 9.29s, por búsqueda: 9.29ms

Tiempo total de xpath para 1000 repeticiones: 8.79s, por búsqueda: 8.79ms

Esta vez es 0.5 ms (en reversa, xpath resultó "más rápido" aquí).

Entonces, fuera de xpath y css, ¿cuál de los dos elegir para el rendimiento? La respuesta es simple: elige ubicar por ID .

Para resumir, si la identificación de un elemento es única (como se supone que debe ser de acuerdo con las especificaciones), su valor juega un papel importante en la representación interna del DOM en el navegador, y por lo tanto suele ser el más rápido.

Con el rendimiento fuera de escena, ¿por qué creo que xpath es mejor? Simple: versatilidad y potencia.

Xpath es un lenguaje desarrollado para trabajar con documentos XML; como tal, permite construcciones mucho más potentes que css.
Por ejemplo, navegación en todas las direcciones del árbol: encuentre un elemento, acceda a su abuelo y busque un hijo con ciertas propiedades. Permite condiciones booleanas incrustadas - cond1 y no (cond2 o no (cond3 y cond4)); selectores incorporados: "encuentra un div que tenga estos niños con estos atributos y luego navega de acuerdo con él". Permite realizar búsquedas basadas en el valor de un nodo. Sin embargo, no está bien visto en esta práctica, pero es útil especialmente en documentos mal estructurados (sin atributos definidos para avanzar, como los ID dinámicos y las clases).

El paso en CSS es definitivamente más fácil: uno puede comenzar a escribir selectores en cuestión de minutos; pero después de un par de días de uso, el poder y las posibilidades xpath superan rápidamente css.
Y puramente subjetivo: un css complejo es mucho más difícil de leer que una expresión compleja de xpath.

Finalmente, nuevamente muy subjetivo, ¿cuál elegir? En mi humilde opinión, no hay elección correcta o incorrecta: son soluciones diferentes para el mismo problema, y ​​lo que es más adecuado para el trabajo debe ser elegido. Siendo fanático de xpath, no soy tímido para usar en mis proyectos una combinación de ambos, diablos, a veces es mucho más rápido lanzar un CSS, si sé que hará el trabajo bien.