He desarrollado un marco de prueba basado en Selenium WebDriver para un cliente, para probar una aplicación web y puedo compartir las lecciones aprendidas.
El marco y las pruebas se escribieron en Java, pero en su mayoría deberían aplicarse los mismos principios. Usaré el pseudo código a continuación para ilustrar mis puntos.
Uso del patrón de objetos de página (o vista)
La base de los objetos de la página es separar entre el código de prueba y las definiciones de cómo acceder al elemento (es decir, los selectores de elementos).
Esos no deberían limitarse a las páginas web reales, sino a cualquier vista o parte de la vista en la aplicación web. Por ejemplo: la página de inicio de sesión en sí, una barra de navegación que aparece en varias páginas, un control de selección de fecha.
Tome cada componente de vista de esa manera y ajuste el acceso al elemento.
- Permitir composición y herencia de
Por ejemplo:clase BlogPost extiende BlogPage TagList postTags Buscar en el cuadro de búsqueda ShareDialog clickShareButton: .... - Tenga objetos de vista parametrizados para componentes reutilizables, que en cada vista de contenedor pueden tener diferentes configuraciones y selectores:
DropDownMenu (itemsList, parentDivSelector) - Registre las interacciones simuladas del usuario en los componentes, para comprender el escenario del script ejecutado y dónde fallaron las pruebas.
(Más información sobre los próximos informes …)Botón de clase (nombre, selector) hacer clic: testContext.log ("Botón {nombre} hecho clic") Elemento (selector) .click ()
Un contexto de prueba para registrar datos adicionales en
Esas no son pruebas unitarias, sino escenarios de usuario complejos. Las pruebas deberían poder guardar datos adicionales en él. Entonces debería poder mostrarlo en los informes (a continuación) bajo la prueba correcta. Algunos ejemplos de tipo de información se utilizan para guardar en el contexto de la prueba en ejecución:
- ¿Cuánto cuesta alojar un sitio web creado?
- ¿Cuáles son las ventajas y desventajas de usar un RDBMS para una aplicación web sobre archivos planos?
- ¿Cuántas etiquetas H1 debo usar para cada página?
- ¿Debo asumir el trabajo de desarrollo web que no he hecho antes?
- ¿Cómo podemos agregar controles deslizantes y diferentes secciones en la página de inicio usando WordPress sin aprender WordPress desde cero?
- Capturas de pantalla en llamadas explícitas para guardarlas
- capturas de pantalla implícitas al final o en errores
- Mensajes de registro, en diferentes niveles (información, seguimientos, etc.)
- Información con sello de tiempo para todo lo anterior
- Probar metadatos del entorno: navegador, sistema operativo, etc.
Informes de pruebas de automatización web
Como se indicó, el tipo de información necesaria para comprender qué salió mal con los escenarios de prueba, se necesita un informe diferente al de un informe de prueba de unidad simple. Debe informar los datos que ha registrado en el contexto de texto en un escenario como la moda.
Por ejemplo:
Prueba de inicio de sesión
Navegador: Chrome 30 en Windows
00:00 Iniciando nueva sesión del navegador
00:00 Apertura de la página de inicio
00:01 Haga clic en inicio de sesión
00:05 Navegación a la página de inicio de sesión completada
00:05 ingresó “amitay” en el cuadro de texto del nombre de usuario
00:06 ingrese “secreto” en la contraseña.
00:06 [captura de pantalla]
00:08 clic en el botón enviar
00:10 Navegación a la página dashoard completada.
00:11 *** Error: la URL esperada es …
00:12 [captura de pantalla]
Capacidades adicionales de corredores de prueba
Es posible que su marco de prueba (ya sea su propia implementación o la que está aprovechando) deba admitir capacidades adicionales:
- Ejecución de pruebas paralelas (la automatización web con selenio puede ser lenta …)
- Pruebas dependientes (ejecute testC si y cuando testB y testC se completen
- Prueba parametrizada (por ejemplo, para ejecutar las mismas pruebas en diferentes WebDrivers (es decir, diferentes navegadores)
- Crear una nueva sesión de navegador y continuar una desde una prueba completa.
Configuración
Las pruebas pueden ejecutarse en diferentes configuraciones: servidor de integración continua, desarrollo, pruebas nocturnas, pruebas por confirmación.
Alguna configuración que pueda necesitar:
- Configuración de creación de instancia de controlador web
- Autenticación de terceros (como los laboratorios de salsa)
- Qué pruebas ejecutar
- Qué pruebas ejecutar en qué navegadores
- Tiempos de espera
Algunas otras sugerencias
- Considere el uso de un “Controlador web remoto como servicio” de terceros, como browserstack o saucelabs.
La principal ventaja es salvar el enorme dolor que supone mantener un entorno estable de múltiples navegadores.
Una ventaja adicional son las características adicionales que agregan (como videos grabados, registro de selenio). - Escribe algunas pruebas mientras escribes el marco. Los problemas que encontrará le enseñarán mucho sobre cuáles son las necesidades reales.
- No escriba escenarios de prueba demasiado complejos. La prueba de controladores web en el mundo real puede ser bastante frágil, y las pruebas demasiado complejas pueden dar lugar a muchos falsos negativos, cuando es la prueba que falló.
- Considere cuándo es mejor escribir pruebas unitarias de JavaScript en lugar de pruebas de automatización del navegador. Tienden a ser mucho más robustos.
- Un consejo para los desarrolladores de Java: dale una oportunidad a testNG. Lo encontré muy poderoso y extensible, y es un gran arnés de prueba para más que pruebas unitarias.
Esto terminó bastante largo, más una publicación que una respuesta. Si lo ha leído hasta aquí, ¡podría ser el momento de escribir algunas pruebas de selenio! ¡Buena suerte!
