Grabadora de cinta: una herramienta para grabar autotests

Buenas tardes, queridos lectores. Me llamo Victor Burov. Trabajo como desarrollador en ISPsystem y quiero compartir mi experiencia en la automatización de pruebas.

Sucedió que las pruebas manuales prevalecieron en nuestro país, y los evaluadores pasaron mucho tiempo realizando las mismas acciones. Una vez pensamos: ¿por qué no enseñar al panel a repetir las acciones del probador, porque, de hecho, todas se convierten en llamadas API específicas? Esto permitiría a las personas escribir pruebas incluso sin habilidades de programación.

Decidimos escribir un módulo para crear pruebas automáticas. Para que el probador pueda simplemente presionar el botón para crear una prueba, cumplir con las condiciones del caso de prueba, al final haga clic en "finalizar" - y eso es todo, ¡la prueba estaba lista! Una idea simple, pero darse cuenta de que no fue fácil. Porque queríamos que este módulo se adaptara al máximo para nuestros productos y aprovechara una interfaz unificada: para que el video grabado se viera como un caso de prueba listo para usar. Esto eliminaría por completo el trabajo manual de escribir pruebas. El sistema resultante se llamaba "grabadora de cinta".


Interfaz para ver condiciones de casos de prueba

Principio de funcionamiento

Todos los parámetros de solicitud (encabezados HTTP, variables de entorno, datos POST, si los hay) y la respuesta completa se escriben en el archivo xml. A cada registro se le asigna un número de serie. Todas las solicitudes se dividen en modificables y no modificables. Después de grabar la prueba, muchas de las consultas que no se modifican se cortan, ya que no afectan la ejecución de las pruebas y solo retrasan y confunden el proceso de ejecución (de ahí los números de secuencia que faltan en la captura de pantalla).

Durante la grabación, la grabadora le permite configurar la verificación de valores en los campos de los formularios y en las columnas de las listas con un solo clic. También le permite grabar pruebas negativas, recordando qué error devolvió el panel mientras grababa una prueba.

Durante la reproducción, las solicitudes se envían directamente a la API de la aplicación sin usar un navegador.

De hecho, una grabadora de cinta es un módulo que se integra en todos nuestros productos y le permite instalar procesadores sensibles a eventos. Escrito usando COREmanager.

Un ejemplo de grabación de una llamada realizada por una grabadora:

Mejoras (sobre las cuales no pensamos de antemano)

Esperando

Una persona puede "solo esperar", una computadora - no. Uno de los primeros problemas que la grabadora debía resolver era la escritura de vaters. Lo que la gente no inventó para esperar la finalización de la operación. Se implementó la expectativa de tareas en segundo plano y la capacidad de agregar una parada en el paso especificado durante un número específico de segundos.

Grabación y edición de pasos de prueba

Probablemente, todos recuerdan los tiempos de las máquinas de escribir: un error, y hay que reimprimir toda la página.



Para que el probador no tuviera que reescribir toda la prueba con una acción errónea, se agregó un mecanismo para volver a grabar la prueba desde cualquier paso después de guardarla. La capacidad de editar es útil cuando necesita adaptar la prueba a los cambios en el comportamiento de las funciones probadas.

Macros para variables

Durante las pruebas, los valores en los parámetros transmitidos y verificados cambiaron según el servidor en el que se ejecutaban. Un ejemplo de tales datos son las direcciones IP. Es imposible reconocerlos en la etapa de grabación de prueba, así que agregué un sistema macro. Esto nos permitió crear pruebas que no están tan rígidamente ligadas al medio ambiente. El inconveniente de la solución es que después de la grabación, las macros deben especificarse manualmente.

Otro problema que complica significativamente el trabajo con la grabadora es el uso de claves no nativas. No lo notamos de inmediato, ya que probamos la grabadora en ISPmanager, que utiliza identificadores nativos. Pero en algunos otros paneles, el registro se identifica mediante una identificación única. Por lo tanto, tuve que enseñarle a la grabadora no solo a obtener el identificador después de crear el registro u objeto (ya que el ID puede cambiar de principio a inicio), sino también a sustituirlo en todas las solicitudes posteriores.

Soporte de formato JUnit

Las pruebas generadas en cinta se ejecutan automáticamente en el entorno de integración continua de Jenkins. Después de completar las pruebas, se crea un archivo xml que contiene los datos en el formato JUnit. Para que el archivo se formara correctamente, se introdujo una restricción en el nombre de las pruebas. Por ejemplo, la prueba User.Create.xml cayó en testuite con el nombre User y, por lo tanto, tenía un caso de prueba llamado Create. En caso de error, se agregó un nodo de falla con una descripción completa del error.

Métricas

El número de funciones llamadas únicas se calcula durante el paso de las pruebas y la proporción se determina como un porcentaje del número total de funciones, excluyendo aquellas disponibles solo para uso interno. Por lo tanto, se mide la cobertura de prueba más simple. Además, las métricas muestran el tiempo total necesario para completar la prueba y el número de pruebas exitosas y fallidas.

Repositorio de prueba

El repositorio de pruebas, en primer lugar, resuelve el problema de transferir pruebas ya hechas a otros servidores. También resulta útil cuando varios probadores escriben pruebas. Se desarrolló e implementó un pequeño panel para almacenar las pruebas de Almacenamiento también sobre la base de nuestro COREmanager. La grabadora tiene un módulo para sincronizar las pruebas con el almacenamiento. Al escribir una nueva prueba o descargar pruebas desde el repositorio, automáticamente no estarán disponibles para cargar en el repositorio para que no haya confusión. Después de cambiar la prueba, el número de revisión aumenta para que solo las pruebas después de que los cambios se carguen en el repositorio.

Dificultades (bueno, sin ellas)

El uso de una grabadora de cinta mostró que no todas las funciones de la API siguieron nuestras recomendaciones internas. En particular, no todas las funciones devolvieron el identificador de registro después de su creación. Tuve que regresar, incluso a un código de trabajo, y adaptarlo a los requisitos.

El punto muerto es otro problema. El panel implica la realización de algunas acciones críticas en modo exclusivo. Y la grabadora, al ser parte del mismo panel, causando tales funciones, hizo que todo el sistema se congelara. Fue posible determinar esto solo con la ayuda de GDB (nadie recordaba esta característica). Desafortunadamente, hubo muletas, porque se decidió al ejecutar las pruebas de la grabadora para realizar estas funciones en modo de subprocesos múltiples. Teóricamente, fue posible diseñar una grabadora de cinta no con un módulo, sino con un panel separado. Pero no lo intentamos.

Desafortunadamente, la escritura y el olvido también fallaron. La interfaz de nuestros productos está cambiando y se está volviendo más complicada. Además, el número de componentes de la interfaz está creciendo activamente. Por lo tanto, la grabadora debe modificarse de vez en cuando, de modo que cuando aparezcan nuevos componentes, pueda analizar su estructura y procesar los resultados de las consultas.

Conclusión

La creación de una grabadora ha ayudado a mejorar la calidad de los productos probados. Ahorro de tiempo y recursos para capacitar a los evaluadores. En el camino, la grabadora nos permitió revisar nuestra API para verificar el cumplimiento de las recomendaciones internas y, por lo tanto, hacer que la API sea un poco más "lógica".