Get best of the week

Pruebas de automatización de aplicaciones web llave en mano, sin registro y SMS.

A menudo sucede que una aplicación web consta de una gran cantidad de formularios de reestructuración dinámica con diferentes textos y controles. Probar una aplicación de este tipo se convierte en una pesadilla.

Debe hacer clic en 100500 páginas y verificar todas las funciones ... Y antes de la próxima versión, verifique lo mismo nuevamente ... Y nuevamente ... Y mañana nuevamente. En algún momento, la verificación comienza a tomar más tiempo que el desarrollo de una nueva funcionalidad. "¿Qué pasa con las pruebas e2e?" - usted pregunta. Pero, en primer lugar, todavía necesitan ser escritos. Y en segundo lugar, antes de comenzar a escribirlos, debe escribir casos de prueba. Muchos casos de prueba.

Si mientras lee estas líneas su frente está cubierta de transpiración, no se preocupe. En este artículo compartiré con ustedes la idea de cómo nosotros en Tinkoff automatizamos la prueba de una de las aplicaciones web sin escribir un solo caso de prueba y prueba e2e.




Escribir automáticamente casos de prueba


Dio la casualidad de que probar nuestra aplicación web está principalmente relacionado con las comprobaciones de la interfaz. Debe verificar que el botón esté presente en la pantalla, se muestren el título y el texto deseados, y cuando ingrese un valor no válido en la entrada , aparecerá un mensaje de error.

En consecuencia, al escribir un caso de prueba, debe registrar todas las acciones:

  • "Presioné el botón"
  • "Ingresó el valor de XXX"
  • "Seleccionó el valor AAA en la lista desplegable"

y cheques:

  • "El texto apareció: XXX"
  • "Aparece un mensaje de error: AAAA"
  • "El encabezado apareció: ZZZ"

Después de analizar toda la funcionalidad de nuestra aplicación web, identificamos cerca de 30 acciones y controles únicos. Quedó claro que este proceso puede ser automatizado. Para hacer esto, solo necesita rastrear todas las acciones del probador en la página y la reacción del sitio a estas acciones.

Comencemos por interceptar eventos. Para realizar un seguimiento de la interacción con controles como botones, botones de opción y casillas de verificación, debe suscribirse al evento de clic. Cada marco tiene sus propios métodos para esto. Por ejemplo, fromEvent en Angular y document.addEventListener en JavaScript y React. Para los controles de entrada, como el calendario o la entrada, solo cambiará el tipo de evento al que desea suscribirse: en lugar de hacer clic, se hará foco.

fromEvent(this.elementRef.nativeElement, 'click')
.subscribe(tagName => {
 	if (tagName === 'BUTTON') {
   		this.testCaseService.addAction(`   "${action.name}"`);
 	} else if (tagName === 'INPUT-CALENDAR') {
   		this.testCaseService
     			.addAction(`  "${action.name}" "${action.value}"`);
 	}
});

Y finalmente, lo más importante es verificar. La forma en que el sitio debe comportarse en respuesta a las acciones del probador.

¿Qué suele comprobar el probador? Por ejemplo, ingresó un valor no válido en la entrada , el sitio respondió con un mensaje de error. O, digamos que hicimos clic en un botón y en respuesta apareció una nueva pantalla, el título cambió, apareció un nuevo texto y se reconstruyeron los controles. Todos estos cambios están relacionados con el cambio en el árbol DOM. Hay muchas opciones para rastrearlos. Puede, por ejemplo, usar MutationObserver en React y JavaScript o ngAfterViewInit en Angular (poniendo una directiva sobre los elementos de formulario de interés en el sitio).

ngAfterViewInit() {
    const tagName = this.nativeElement.nodeName;
	const text = this.nativeElement.textContent;
    if (['SPAN', 'P'].includes(tagName)) {
 	 	 this.testCaseService.addContent(`** ** "${text}"\n`);
     } else if (tagName === 'H1') {
 	  	this.testCaseService.addContent(`** ** "${text}"\n`);
     } …	
}

El código dependerá mucho del diseño. Echemos un vistazo al marcado. Estos botones están tomados del traductor de Google.


<div class="tlid-input-button input-button header-button tlid-input-button-text text-icon" role="tab" tabindex="-1">
  	<div class="text"></div>
</div>
<div class="tlid-input-button input-button header-button tlid-input-button-docs documents-icon" role="tab" tabindex="-1">
 	 <div class="text"></div>
</div>

A pesar del hecho de que los botones no están representados como etiquetas de botón , al mirar el marcado, puede seleccionar todos los botones en la página usando la clase css "input-button", y puede obtener nombres de botones de la clase css "text" anidada.

La mitad del trabajo estaba hecho, solo queda anotar todo lo que rastreamos en un caso de prueba.

Incluimos la intercepción de todas las acciones en el sitio para una combinación de teclas específica y solo en el circuito de prueba. Paramos la intercepción de todos los eventos en el sitio mediante una combinación de teclas determinada. Esto le permite iniciar y detener la grabación automática del caso de prueba desde cualquier lugar.

Escribir automáticamente pruebas e2e


Si observa el caso de prueba generado automáticamente, estos son esencialmente scripts de usuario reducidos a la misma forma. Por lo tanto, se pueden convertir en pruebas e2e. Incluso puede escribir inmediatamente pruebas e2e después de interceptar todas las acciones y comprobaciones, evitando los casos de prueba.

Ahora hay una gran cantidad de marcos diferentes con notación de pepinillo basada en scripts de comportamiento: SpecFlow, xBehave.net., Cucumber.js, CodeceptJS, etc.

Para obtener características del caso de prueba, debe agregar la palabra clave When antes de las acciones y antes todos los cheques Entonces y E.

Obtenga la prueba e2e generada automáticamente:

Feature:   2-
  Background:
 	When  "" ""

  Scenario:
 	When    " - "
 	Then    "  "
 	And   " - "
 	When    "  " ""
 	When    "" "  "
 	When    ""

Para ejecutar la ejecución de prueba, las características generadas son pocas: debe escribir un controlador para todas las acciones y comprobaciones.

Hay buenas noticias: no necesita escribir un controlador para cada función. Como dije, a pesar de la gran cantidad de formas diferentes en el sitio, solo obtuvimos 30 acciones y comprobaciones únicas, lo que significa que habrá exactamente la misma cantidad de métodos en el procesador común para todas las pruebas e2e. El código será ligeramente diferente, dependiendo del marco elegido con notación y diseño de pepinillo en el sitio. Pero escribir el controlador en sí no lleva mucho tiempo.

When('   {string}', async function (button: string) {
	const xpath = "//button";
	const btn = await getItemByText(xpath, button);
	await waitAndClick(btn);
});
When('  {string} {string}', async function (label: string, text: string) {
	const xpath = "//*[contains(text(),'" + label + "')]/ancestor::outline";
	await inputSendKeys(currentBrowser().element(by.xpath(xpath)), text);
});

Ahora, comprobando la siguiente tarea, se escribe automáticamente un caso de prueba para el probador y se ejecuta la prueba e2e generada automáticamente.

En resumen, necesitas:

  1. Suscríbase a eventos de interacción con controles y la reacción del sitio a estas acciones (a través del seguimiento de la reconstrucción del árbol DOM).
  2. Convierta datos del párrafo 1 a pruebas e2e.
  3. Escriba un controlador general para ejecutar pruebas e2e.

Este enfoque te ayudará a alejarte de la rutina. Puede automatizar la escritura de casos de prueba y pruebas e2e para verificaciones simples relacionadas con la interfaz. Hemos ido aún más lejos y verificamos automáticamente también el registro en la base de datos y el envío a servicios de terceros.

Hablé sobre esto, así como sobre versiones, la pila de tecnología e incluso sobre los problemas en la primera etapa de implementación y su solución en la conferencia Heisenbug-2019 en Moscú .

En este artículo, traté de transmitir la idea principal sin entrar en detalles.

Conclusión


Ahora nos lleva 2 minutos en promedio escribir un caso de prueba y una prueba e2e; esto es 60 veces más rápido que los cálculos iniciales, cuando queríamos escribir casos de prueba y pruebas e2e manualmente.

No cambiamos los procesos en el equipo. Ya no era necesario asignar la capacidad de prueba para escribir casos de prueba y llevarla al equipo de automatización.

Nos hemos alejado completamente de la noción de regresión. Si antes, con un sprint de dos semanas, la regresión nos tomó más de 3 días, ahora la regresión lleva tiempo para ejecutar todas las pruebas e2e, y esto es solo 2 horas.

Al escribir manualmente pruebas e2e, es muy difícil ir en paralelo con las pruebas. Ahora, las pruebas e2e se escriben automáticamente durante la prueba de la tarea, y el probador no necesita verificar la misma funcionalidad dos veces.

Como resultado, nuestro equipo, sin cambiar la composición, comenzó a trabajar de manera mucho más eficiente.

More articles:


All Articles