Buenas tardes, queridos lectores.
Quiero hablar sobre la experiencia de construir un sistema de automatización de pruebas cuando no hay pruebas en absoluto en el proyecto, o su grado es mínimo.
Espero que el artículo sea útil para las pruebas automáticas para principiantes.
- En la primera parte, estamos a favor del enfoque general.
- En la segunda parte ( Parte 1 ) con ejemplos, haremos un proyecto de pruebas automáticas en JAVA + para enseñar cómo probar rápidamente la API.
- En la tercera parte, complementaremos el proyecto para las pruebas de IU, haremos pruebas paralelas.
¿Cuándo hacer autotests?
La respuesta corta es lo más pronto posible.
Un completo se revelará a continuación. En cualquier caso, cuando el proyecto funciona durante 3 años, y todo se verificó manualmente, la vida se vuelve muy monótona. Y una flota de 5000 escenarios para automatizar en uno o dos meses es problemática. Como regla general, en tales proyectos tendrá que comenzar a resolver los scripts nuevamente. Porque será más rápido. Y no el hecho de que lo viejo pueda automatizarse sin cambios significativos.
Por qué
Porque los autotets:
- Acumula escenarios para la regresión
- Imparcial
- Rápido
Escenarios acumulados
Cuanto mayor sea la flota de escenarios automatizados, más probabilidades hay de encontrar una regresión, especialmente si los datos cambian con cada ejecución.
Si la prueba automática pasó de manera estable y cayó en alguna rama, entonces cambiaron los requisitos, o un error, o la infraestructura falló.
Imparcialidad
Si se cambian los requisitos, la prueba automática debe ir a la modificación junto con la modificación de la funcionalidad principal. Es por eso que los evaluadores participan en la aprobación de TK.
Si una ejecución de prueba se vincula automáticamente a una tarea, nadie puede decir que no se ha probado. O viceversa, él puede. En general, definitivamente hay menos problemas.
Velocidad
Si cada prueba satisface las tediosas condiciones:
Precondición - Prueba - Postcondición
Tales pruebas son fáciles de automatizar.
Y luego es fácil paralelizar. Porque son independientes.
El número de subprocesos: cuántos servidores de prueba pueden soportar y para no molestar a otros.
El segundo punto es la velocidad misma. En modo manual, haga clic en la creación del producto, su búsqueda y compra en la tienda en línea es de 5 minutos. 4 navegadores Total 20 minutos. En solo un pequeño escenario.
La prueba automática en este escenario tarda 1,5 minutos. Pero en 8 navegadores. (Las últimas y penúltimas versiones de cada navegador).
Por donde empezar
Con scripts personalizados.
El valor de las pruebas atómicas cae todo el tiempo, especialmente en microservicios. En general, en un mundo ideal, esta es el área de responsabilidad del programador. Dichos errores deben detectarse en la etapa de prueba de la unidad.
El control de calidad debería funcionar a partir de la historia del usuario. Porque el programador generalmente no la conoce y no quiere saberlo.
En consecuencia, la prueba 1 lógica - 1 caso de usuario (escenario empresarial) está más cerca de la realidad.
Por supuesto, existen dificultades con la preparación de datos, por ejemplo, en el caso de una tienda en línea, el proceso de pago con tarjeta requiere la presencia de cosas en la cesta, y datos para un nuevo usuario o datos de autorización para uno existente.
Sí, a veces las condiciones previas toman más tiempo que una prueba, pero no es difícil reutilizar los scripts.
Qué scripts para automatizar
Menos susceptible a cambios a corto plazo. Para la automatización al menos algunos vivieron.
O más comúnmente utilizado. Tiene sentido ayudar a las pruebas manuales en la generación de datos de prueba. Por ejemplo, en el tablón de anuncios, tiene sentido automatizar la creación de anuncios, porque Además, cualquier escenario requiere un anuncio creado.
Que exactamente hacer
Usualmente en proyectos allí
- Backend
- Frontend
- Aplicaciones móviles
- Glándulas
Y los dos últimos puntos, generalmente viven por separado. Los teléfonos móviles se prueban en sus propios scripts, y pocos pueden abordar la depuración de hierro de acuerdo con JTAG sin preparación.
Por lo tanto, propongo tratar con el Backend y el Front.
Elige un escenario
Digamos que tenemos una tienda en línea.
Hay un panel de administración, hay un frente de cliente y administrador.
Hay una API que sirve todo esto.
¿Dónde comenzar la automatización?
Vamos a mirar
Hay clientes, hay empleados.
El cliente tiene el primer caso: ver y buscar el producto, agregarlo a la cesta y diseñar.
El empleado tiene el caso más común: agregar una tarjeta de producto.
¿Qué caso se automatizará primero? Y como?
Lo más importante para la tienda son las ventas.
Por lo tanto, el historial del cliente es más importante para las empresas. Por lo tanto, encontrar los productos, colocarlos en la cesta y completar el pago con cualquier método de pago es lo primero que debe hacer.
Por API Pero sin frente. Aquí puede discutir, pero lo más probable es que el diseño cambie 2-3 veces más, pero el backend es poco probable. Entonces, en la etapa 1, debe verificar la interfaz manualmente.
Luego, verifique la API que edita la tarjeta del producto y su frente.
Y volver al cliente. En esta etapa, ya habrá estadísticas sobre las acciones de usuario más frecuentes y las rutas de clientes más frecuentes. Sí, Yandex Metric y Webvisor también ayudan a los evaluadores.
No tiene sentido en la primera etapa verificar si la función de pago a la cuenta de la empresa a través del sistema de pago generado funciona si el 0.5% de los visitantes utilizan esta función. Por supuesto, puede hacerle una pregunta al gerente por qué se necesita esto aquí, pero no se trata de eso.
Supongamos que el 40% de las personas paga en el sitio con una tarjeta, el 30% en efectivo, el 20% en efectivo en la entrega y el 10% en todos los demás métodos.
¿Qué tipo de pago comprobaremos primero? Por supuesto el mapa.
Es decir, debemos entender claramente qué escenario es el más importante para el negocio en este momento. Y su calidad es ante todo.
Postcondiciones
Creamos todo, todo en las pruebas. Basura Sería necesario limpiar después de ti mismo. Es necesario prever de antemano en qué pruebas limpiaremos después de nosotros mismos y en cuáles, no.
Si los productos se pueden dejar en la tienda, y no pasará nada malo, entonces se deben devolver los derechos de administrador al usuario normal. Y luego puede caer la siguiente prueba relacionada con los derechos. O peor, vaya positivo, aunque debería haber caído.
Rarezas
Hay un enfoque extraño cuando automatizan scripts en los que los usuarios encuentran un error. Por lo general, estos son escenarios muy exóticos, y gastar un recurso en ellos no tiene sentido. Hubo una situación en la que se rompió la funcionalidad de actualizar los datos del banco de contraparte. La sincronización con el directorio BIC falló.
Es decir, el nuevo BIC no se actualizó. Pero el nuevo banco comenzó normalmente.
¿Tiene sentido automatizar este escenario? Si los contratistas cambian todos los días, tal vez. Y luego fue una falla en la planificación.
Si esto se hace 5-6 veces al año, ¿puede ser mejor hacer una tarea de mayor prioridad?
¿Qué pasará después?
En el próximo artículo, le diré cómo comenzar a probar rápidamente la API, incrustar estas pruebas en lanzamientos, hacer pruebas paralelas, cómo seleccionar datos para las pruebas y lo que nos dará.
Permíteme recordarte el efecto de un pesticida y cómo hacer que brille al mínimo.
Tecnologías: Java + maven + testng + allure + RestAssured + Pict.