Pregunta

Ok, tal vez me esté perdiendo algo, pero realmente no veo el punto de Selenium. ¿Para qué sirve abrir el navegador con un código, hacer clic en los botones con un código y verificar el texto con un código? Leí el sitio web y veo cómo, en teoría, sería bueno probar automáticamente las aplicaciones web, pero al final, no toma más tiempo escribir todo este código en lugar de solo hacer clic y verificar visualmente que las cosas funcionen. ?

No lo entiendo ...

¿Fue útil?

Solución

Le permite escribir pruebas funcionales en su " unidad " marco de prueba (el problema es la denominación del último).

Cuando está probando su aplicación a través del navegador, generalmente está probando el sistema completamente integrado. Considere que ya tiene que probar sus cambios antes de realizarlos (pruebas de humo), no desea probarlos manualmente una y otra vez.

Algo realmente bueno, es que puede automatizar sus pruebas de humo, y el control de calidad puede aumentarlas. Bastante efectivo, ya que reduce la duplicación de esfuerzos y acerca a todo el equipo.

Salta como cualquier práctica que estés usando la primera vez que tiene una curva de aprendizaje, por lo que generalmente toma más tiempo las primeras veces. También le sugiero que consulte el patrón Page Object , que ayuda a mantener las pruebas. limpio.

Actualización 1: tenga en cuenta que las pruebas también ejecutarán javascript en las páginas, lo que ayuda a probar páginas altamente dinámicas. También tenga en cuenta que puede ejecutarlo con diferentes navegadores, por lo que puede revisar los problemas de los navegadores cruzados (al menos en el lado funcional, ya que aún necesita verificar lo visual).

También tenga en cuenta que a medida que se acumula la cantidad de páginas cubiertas por las pruebas, puede crear pruebas con ciclos completos de interacciones rápidamente. Usando el patrón de Objeto de página se ven así:

   LastPage aPage = somePage
      .SomeAction()
      .AnotherActionWithParams("somevalue")
      //... other actions
      .AnotherOneThatKeepsYouOnthePage(); 
  // add some asserts using methods that give you info
  // on LastPage (or that check the info is there).
  // you can of course break the statements to add additional 
  // asserts on the multi-steps story.

Es importante entender que vas de forma gradual al respecto. Si es un sistema ya construido, agrega pruebas para las características / cambios en los que está trabajando. Añadiendo más y más cobertura en el camino. En su lugar, ir al manual, por lo general oculta lo que no probó, por lo que si realizó un cambio que afecta a todas las páginas y verificará un subconjunto (si el tiempo no lo permite), sabrá cuáles realmente probó y QA puede trabajar. allí (con suerte agregando aún más pruebas).

Otros consejos

Esto es algo común que se dice acerca de las pruebas unitarias en general. " ¿Necesito escribir el doble de código para realizar pruebas? " Los mismos principios se aplican aquí. La recompensa es la capacidad de cambiar su código y saber que no está rompiendo nada.

Porque puedes repetir la prueba MISMO una y otra vez.

Si su aplicación tiene incluso más de 50 páginas y necesita realizar compilaciones frecuentes y probarlas con el número X de los principales navegadores, tiene mucho sentido.

Imagínese que tiene 50 páginas, todas con 10 enlaces cada una, y algunas con formularios de múltiples etapas que requieren que lea los formularios, ingresando aproximadamente 100 conjuntos diferentes de información para verificar que funcionan correctamente con todos los números de tarjetas de crédito , todas las direcciones en todos los países, etc.

Eso es virtualmente imposible de probar manualmente. Se vuelve tan propenso al error humano que no se puede garantizar que las pruebas se hayan realizado correctamente, sin importar lo que demostraron las pruebas sobre lo que se está probando.

Además, si sigue un modelo de desarrollo moderno, con muchos desarrolladores trabajando todos en el mismo sitio de manera desconectada y distribuida (algunos trabajan en el sitio desde su computadora portátil mientras están en un avión, por ejemplo), entonces los evaluadores humanos ni siquiera podrá acceder a él, y mucho menos tendrá la paciencia para volver a realizar pruebas cada vez que un solo desarrollador intente algo nuevo.

En cualquier tamaño de sitio web decente, las pruebas DEBEN ser automatizadas.

El punto es el mismo que para cualquier tipo de prueba automatizada: escribir el código puede llevar más tiempo que "simplemente hacer clic y verificar visualmente que las cosas funcionan", tal vez 10 o incluso 50 veces más.

Pero cualquier aplicación no trivial tendrá que ser probada más de 50 veces eventualmente, y las pruebas manuales son una tarea molesta que probablemente se omitirá o se hará de manera presuntuosa bajo presión, lo que hace que los errores queden sin descubrir hasta justo antes (o después) fechas límite importantes, que dan como resultado sesiones de codificación estresantes durante toda la noche o incluso pérdidas monetarias directas debido a sanciones contractuales.

Selenium (junto con herramientas similares, como Watir) le permite ejecutar pruebas contra la interfaz de usuario de su aplicación web en formas en que las computadoras funcionan bien: miles de veces durante la noche, o segundos después de cada registro de origen. (Tenga en cuenta que hay muchos otros elementos de prueba de UI en los que los humanos son mucho mejores, como darse cuenta de que algo extraño que no está directamente relacionado con la prueba está mal).

Hay otras formas de involucrar a toda la pila de su aplicación mirando el HTML generado en lugar de lanzar un navegador para renderizarlo, como Webrat y Mechanize . La mayoría de estos no tienen una forma de interactuar con las IU pesadas en JavaScript; El selenio tiene algo cubierto aquí.

Selenium grabará y volverá a ejecutar todos los clics y tipos de escritura que haga para probar su aplicación web. Una y otra vez.

Con el tiempo, los estudios de mí mismo me han demostrado que tiendo a hacer menos pruebas y comenzar a omitir algunas u olvidarlas.

En cambio, Selenium tomará cada prueba, la ejecutará, si no devuelve lo que esperaba, puede avisarle.

Hay un costo inicial de tiempo para registrar todas estas pruebas. Lo recomendaría como pruebas de unidad: si aún no lo tiene, comience a usarlo con las partes más complejas, delicadas o más actualizadas de su código.

Y si guarda esas pruebas como clases de JUnit, puede volver a ejecutarlas a su gusto, como parte de su compilación automatizada, o en la prueba de carga de un hombre pobre utilizando JMeter.

En un trabajo anterior, solíamos probar nuestra aplicación web. Si la aplicación web cambia su aspecto, no es necesario volver a escribir las pruebas. Todas las pruebas de tipo de grabación y reproducción deberían volver a realizarse.

¿Por qué necesitas selenio? Porque los testers son seres humanos. Se van a casa todos los días, no siempre pueden trabajar los fines de semana, se enferman, toman vacaciones públicas, se van de vacaciones de vez en cuando, se aburren haciendo tareas repetitivas y no siempre pueden confiar en que estén cerca cuando las necesite.

No estoy diciendo que debas deshacerte de los probadores, pero una herramienta automatizada de prueba de interfaz de usuario complementa a los probadores del sistema.

El punto es la capacidad de automatizar lo que era antes de una prueba manual y lenta. Sí, lleva tiempo escribir las pruebas, pero una vez escritas, se pueden ejecutar con la frecuencia que desee el equipo. Cada vez que se ejecutan, están verificando que el comportamiento de la aplicación web es consistente. Selenium no es un producto perfecto, pero es muy bueno para automatizar la interacción realista del usuario con un navegador.

Si no te gusta el enfoque de Selenium, puedes probar HtmlUnit , lo encuentro más útil y Fácil de integrar en las pruebas unitarias existentes.

Para aplicaciones con interfaces web ricas (como muchos proyectos GWT) Selenium / Windmill / WebDriver / etc es la manera de crear pruebas de aceptación. En el caso de GWT / GXT, el código de la interfaz de usuario final está en JavaScript, por lo que la creación de pruebas de aceptación utilizando casos de prueba normales de Junit está básicamente fuera de discusión. Con Selenium puede crear escenarios de prueba que coincidan con las acciones reales de los usuarios y los resultados esperados.

Según mi experiencia con Selenium, puede revelar errores en la lógica de la aplicación y la interfaz de usuario (en caso de que sus casos de prueba estén bien escritos). Tratar con las puntas frontales de AJAX requiere un esfuerzo adicional, pero aún es factible.

Lo uso para probar formularios de varias páginas, ya que esto elimina la carga de escribir lo mismo una y otra vez. Y tener la capacidad de verificar si ciertos elementos están presentes es genial. Nuevamente, usando el formulario como ejemplo, su prueba final de selenio podría verificar si algo como decir "Gracias Sr. Rogers por ordenar ..." aparece al final del proceso de pedido.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top