Y de nuevo en nuestra cinta "Tester Calendar" . Este mes, Marina Tretyakova, un probador del proyecto Kontur . Entregas , hablará sobre la optimización de las pruebas. Marina analizará problemas específicos y cómo resolverlos, y también le aconsejará cómo optimizar sus pruebas y reducir el tiempo de prueba.

En primer lugar, dividamos todas las pruebas por el grado de automatización para examinar cada tipo con más detalle.

Según el grado de automatización, las pruebas se dividen en:

1. Domar
2. Automatizado.
3. Automático (sin intervención humana, por el momento, más bien un mito que una realidad).

El enfoque para optimizar las pruebas depende directamente del grado de automatización.

Optimizaciones aplicables a todo tipo de pruebas.

Las pruebas incluyen los pasos de:

• preparación del sistema de prueba
• preparación de datos de entrada
• prueba (manual o automáticamente, lo consideraremos a continuación),
• recogida y análisis de resultados.

Se cree que la regresión manual toma más tiempo de los probadores. Sin embargo, en la mayoría de los casos esto no es así. Como mínimo, no debe decir esto hasta que se haya medido y comprobado el problema.

Considere soluciones a problemas comunes. Muchos consejos pueden parecerle extremadamente obvios, pero como lo demuestra la experiencia de conferencias y discursos de colegas de otras compañías, estos consejos siguen siendo relevantes y han demostrado su aplicabilidad y utilidad.

Los problemas:

1. Preparación larga del sistema de prueba.

Preguntas que es importante hacer antes de implementar optimizaciones:

• Mucho tiempo con respecto a qué?
• ¿Quién participa en esta capacitación (probadores, programadores ...)?
• ¿Cuántas veces puedes preparar un sistema de prueba durante un día de trabajo? ¿Este número se ajusta a las necesidades de prueba?
• ¿Cuál es la etapa más larga de preparación y por qué?

Para encontrar la causa de este problema, es importante hacer la pregunta correcta.
Considere los siguientes ejemplos:

Compilación larga de todos los módulos del sistema.
La pregunta correcta es : ¿todos los módulos necesitan compilación?
Solución : compilar no todos los módulos del sistema, sino solo aquellos que se vieron afectados en la tarea y que participarán en el lanzamiento.

El largo proceso manual de actualizar todo el sistema para diferentes "máquinas virtuales" en el banco de pruebas
La pregunta correcta es : ¿en qué punto de la actualización se requiere la participación humana y en qué punto?
Solución : automatice el proceso de cálculo, use herramientas especiales de despliegue y servicio o mecanismos de liberación depurados para "combate", pero úselos solo para el despliegue en una prueba.

El largo proceso de "derramar" el código fuente en "máquinas virtuales" en un banco de pruebas para su posterior compilación y transmisión
Posible problema : conectividad de red.
La pregunta correcta es : ¿con respecto a qué (recopilar en la máquina local, recopilar en la red local)?
Solución : el banco de pruebas y el lugar donde se ubican las fuentes deben estar en la misma red para minimizar la interacción de la red.

Encontré este problema en mi trabajo cuando decidí cambiar el sitio de prueba en Ekaterimburgo a Moscú. Y en el proceso de tratar de "diseñar" el sitio, notamos rápidamente que la actualización del stand comenzó a tomar no 15 minutos, sino casi 15 minutos. La razón fue que el código fuente con una gran cantidad de archivos pequeños estaba en Ekaterimburgo, y el stand estaba en Moscú. El proceso de cálculo "se basó" en la transferencia de red de archivos pequeños para su posterior compilación y "cálculo" en el stand. Como resultado, el código también "se fue" para Moscú :)

2. Larga recolección y análisis de resultados.

Preguntas que es importante hacer antes de implementar optimizaciones:

• Mucho tiempo con respecto a qué?
• ¿Cuáles son las etapas del proceso de recopilación y análisis de resultados? ¿Qué etapa es la más larga y por qué?
• ¿Quién analiza los resultados?
• ¿Quién decide sobre la liberación y sobre qué base? ¿Cuánto tiempo lleva tomar una decisión?

Por ejemplo :
Los resultados de las pruebas se emiten de acuerdo con la plantilla, el registro de acuerdo con la plantilla lleva la mayor parte del tiempo durante la prueba.

Solución (¡gracias, Cap!) : Negarse a completar los resultados de la plantilla o crear una plantilla más fácil de completar. Será necesario llegar a un acuerdo con el equipo y averiguar de aquellos que leen estos resultados (¿y los leen?). ¿Existe realmente la necesidad de tal plantilla (el riesgo es escribir los resultados de las pruebas "en la tabla").

Optimizaciones aplicables a pruebas manuales

Estas pruebas se pueden dividir en dos grandes clases:

1. realizado regularmente, por ejemplo, antes del lanzamiento (considere las pruebas de regresión),
2. rara vez y solo para probar nuevas funcionalidades.

Si la regresión es a menudo y manual, entonces tiene sentido pensar en la automatización y la recuperación de la automatización, pero en este artículo no consideraremos el ROI de la automatización.

Para las pruebas manuales (no la regresión), no se debe hablar sobre la automatización de pruebas, sino sobre el soporte de pruebas instrumentales (como Alexei Barantsev aconsejó en la capacitación que realizamos en nuestra empresa). En este caso, las pruebas automáticas actuarán como una herramienta. En este contexto, la lógica y la visión de las pruebas automáticas en general cambiarán.

Para las pruebas manuales, en primer lugar, debe buscar tareas de rutina (tareas, ¡no pruebas!), Y ya optimizarlas (utilizando automatización o redistribuyendo recursos humanos).

Por ejemplo, la rutina para las pruebas es preparar datos de prueba. Hay diferentes formas de llevar a cabo esta preparación:

1. manualmente a través de la interfaz de usuario,
2. manualmente a través de la API,
3. ejecutando pruebas automáticas, los datos serán un efecto secundario de estas pruebas,
4. Automatizado a través de scripts / utilidades / herramientas personalizadas a través de API o UI.

Si nunca pensó en cuánto tiempo le lleva preparar manualmente los datos de la prueba, ¿tal vez es hora de medirlos? Y resulta que es mucho más eficiente usar al menos el segundo, y preferiblemente los enfoques tercero y cuarto.

Optimizaciones aplicables a pruebas automatizadas

El problema de preparar los datos de prueba aquí es más agudo que con las pruebas manuales. La preparación de los datos de la prueba debe ser:

1. rápido
2. Resistente a los cambios de diseño / diseño,
3. resistente a posibles pruebas paralelas,
4. Resistente a los cambios en la arquitectura interna del sistema.

Es deseable que la preparación de los datos no requiera habilidades y tiempo adicionales en la implementación de la solución.

Los datos de prueba se pueden preparar automáticamente:

1. a través de la interfaz de usuario,
2. a través de API o solicitudes HTTP,
3. a través de consultas de bases de datos.

Considere los pros y los contras de estos enfoques con más detalle en la tabla:

La preparación de datos de prueba a través de solicitudes API o HTTP para una combinación de ventajas y desventajas es la más óptima.

Existen varias optimizaciones más comunes que se aplican a las pruebas automatizadas:

Prueba de paralelismo

Si uno de los problemas de las pruebas es precisamente el momento de su aprobación, si bien hay recursos computacionales, puede realizarlos en paralelo y ejecutarlos en uno de los tres modos paralelos:

1. Paralelismo en una computadora, paralelismo en hilos de procesador.
2. Paralelismo en diferentes computadoras.
3. La combinación del primer y segundo método, es decir, si hay varias máquinas informáticas, las pruebas pasan en paralelo a lo largo de los flujos en cada una y en paralelo entre todas las máquinas.

Eliminar pruebas antiguas

Si las pruebas están escritas, pasan, pero en realidad no verifican nada (por ejemplo, solía haber lógica de negocios, ahora no existe y las pruebas esencialmente no verifican nada), entonces esas pruebas deben eliminarse sin piedad, porque de hecho no tienen ningún significado , quitando tiempo innecesario de la carrera. También vale la pena eliminar las pruebas, el resultado de pasar que no afecta la decisión sobre la posibilidad de liberación.

Uso de técnicas de diseño de prueba para optimizar conjuntos de casos de prueba

Para pruebas manuales, para optimizar conjuntos de casos de prueba, es necesario aplicar varias técnicas de diseño de prueba. Para las pruebas automáticas, también se deben utilizar métodos de división en clases de equivalencia, análisis por pares, análisis de límites y muchas otras técnicas para optimizar el conjunto de pruebas automáticas.

Transferencia de pruebas y verificaciones existentes a otro nivel

Por ejemplo, hay una prueba de navegador que abre la barra de búsqueda, ingresa "manzana", "manzanas", "manzana", "manzanas" (y así sucesivamente), y parece que al completar la búsqueda, recibió una notificación sobre la compra de manzanas en la tienda (prueba mira el hecho de mostrar la notificación y no más). Por lo tanto, una prueba de interfaz de usuario larga no verifica esencialmente la interfaz de usuario, verifica la lógica de que una prueba de unidad puede probar, por lo que esta prueba debe eliminarse y en su lugar debe escribirse una prueba de unidad.

Correcta descomposición de las pruebas en los niveles de "modular - integración - sistema"

Daré un ejemplo. Hay un escenario manual: seleccione el producto en la tienda en línea, colóquelo en la cesta y proceda al pago. Qué se puede hacer (y estará mal): cree exactamente una prueba que busque el producto, agréguelo a la cesta y proceda al diseño.

En este caso, será correcto dividir primero la prueba en tres escenarios secundarios: seleccionar un producto, agregar un producto a la cesta y realizar un pedido. Dividiremos cada escenario en más controles atómicos.
Por ejemplo: "abrir una tienda - mostrar diferentes categorías de productos para la selección" - una prueba; "Seleccionar una categoría de diferentes categorías de productos" es otra prueba. Examinamos cada prueba con más detalle y determinamos qué nivel de pruebas se necesitan para ello, el ejemplo anterior puede indicar qué tipo de pruebas es mejor diseñar inmediatamente como pruebas unitarias.

Un esquema de conexión popular de los sistemas probados y de prueba para pruebas automatizadas de aplicaciones web:

Para optimizar las pruebas automatizadas de una aplicación web, es aconsejable considerar la optimización de cada interacción en el esquema descrito.

Para simplificar, considere optimizar algunas interacciones:

1) Interacción "casos de prueba - navegador - base de datos"
Usar la API no solo para preparar los datos para la prueba, sino también para tomar una serie de pasos en la prueba.

Por ejemplo, si el objetivo es verificar la interfaz de usuario al final de una larga cadena de acciones, entonces no es necesario realizar todas las acciones a través de la interfaz de usuario. Después de todo, si algo se rompió en el medio de la cadena en la interfaz de usuario, la prueba nunca llegará al final y al objetivo. El probador adivinará, y si arreglan este eslabón roto en la cadena, ¿entonces todo lo que funciona después? Si en este caso, a lo largo de la cadena, además de la última acción, se usa una API, entonces con un desglose de la interfaz de usuario de cualquier enlace, el probador sabrá si el sistema funcionará según lo previsto si los desarrolladores arreglan el enlace roto.

2) Interacción "casos de prueba - SeleniumWebDriver - navegador".

• Cerrar pestañas adicionales al finalizar la prueba, en lugar de cerrar el navegador.
  En mi proyecto, esta optimización ayudó a ahorrar 10 minutos en la ejecución de pruebas de IU (en lugar de 1 h 10 min, las pruebas comenzaron a pasar en 1 h). Esta optimización está conectada con la lógica de SeleniumWebDriver, que se utiliza en el proyecto: tiene una preparación muy larga para abrir un navegador, pero el cierre de pestañas ocurre casi al instante.
• Optimización de la caché de aplicaciones del sistema bajo prueba, para que las pruebas pasen más rápido.
• Usar navegadores sin cabeza para que no haya costo en la representación de elementos de la página web.

En conclusión

Para cualquier optimización, debe identificar claramente por sí mismo los problemas actuales en el proceso de prueba, ampliar los puntos en los que se encuentran, presentar las posibles opciones (¡mejor varias!) Para resolverlos. Después de eso, es necesario expresarlos en un equipo, "vender" sus ideas y sugerencias para una solución, y solo después de la aprobación universal distribuir los esfuerzos y resolver las tareas. Una evaluación preliminar de "Antes" y una evaluación de "Después" ayudarán a considerar todas las ganancias de la optimización de los procesos.

Y una vez más, me gustaría repetir: ¡no busque pruebas de rutina, busque tareas de rutina y las automatice!

Lista de artículos del calendario:
Prueba un enfoque diferente
Prueba de par razonable
Comentarios: cómo sucede
Optimizar pruebas
Leer un libro
Pruebas analíticas
El probador debe atrapar el error, leer a Caner y organizar el movimiento.
Servicio de carga
Métricas del servicio de control de calidad
Prueba de seguridad
Conozca a su cliente
Tomar registro