La primera parte está aquí .
Imagina la situación. Te enfrentas a la tarea de desarrollar una nueva funcionalidad. Tienes desarrollos de tus predecesores. Suponiendo que no tienes obligaciones morales, ¿qué harías?
Muy a menudo, todos los logros antiguos se olvidan y todo comienza de nuevo. A nadie le gusta profundizar en el código de otra persona, y si tiene tiempo, ¿por qué no comenzar a crear su propio sistema? Este es un enfoque típico, y es en gran medida correcto. Pero en nuestro proyecto hicimos mal. Establecimos las bases para un futuro sistema de prueba automatizado basado en pruebas unitarias en utPLSQL de nuestros predecesores, y luego nos pusimos a trabajar en varias direcciones paralelas.
- Restaurar antiguas pruebas unitarias. La recuperación se refiere a adaptar las pruebas al estado existente del sistema de lealtad y adaptar las pruebas a los estándares utPLSQL.
- La solución al problema con la comprensión, y qué exactamente, qué métodos y procesos, estamos cubiertos por las pruebas automáticas. Debe tener en cuenta esta información o sacar conclusiones basadas en el propio código de autotest. Por lo tanto, decidimos crear un catálogo. Asignamos un código mnemotécnico único a cada prueba automática, formamos una descripción y arreglamos la configuración (por ejemplo, en qué condiciones debería comenzar o qué debería suceder si la prueba comienza a fallar). Esencialmente, completamos los metadatos sobre las pruebas automáticas y colocamos estos metadatos en las tablas de esquema estándar utPLSQL.
- Definir una estrategia de expansión, es decir selección de funcionalidad para ser verificada por autotest. Decidimos prestar atención a tres cosas: nuevas mejoras del sistema, incidentes de producción y procesos clave del sistema. Por lo tanto, estamos desarrollando en paralelo con el lanzamiento, proporcionando su mayor calidad, expandiendo simultáneamente el volumen de regresión y asegurando la confiabilidad del sistema en lugares críticos. El primer obstáculo fue el proceso de distribución de descuentos y bonificaciones en un cheque.
- Naturalmente, comenzamos a desarrollar nuevas pruebas automáticas. Una de las primeras tareas de lanzamiento fue evaluar el rendimiento de muestras predefinidas del sistema de fidelización. En nuestro proyecto, hay un bloque de consultas sql rígidamente fijas que seleccionan clientes según las condiciones. Por ejemplo, obtenga una lista de todos los clientes cuya última compra fue en una ciudad en particular, o una lista de clientes cuyo monto promedio de compra está por encima de cierto valor. Después de escribir las pruebas automáticas, verificamos las muestras predefinidas, arreglamos los parámetros de rendimiento de referencia y, además, tuvimos pruebas de carga.
- El trabajo con autotest debe ser conveniente . Muy a menudo, se realizan dos acciones: ejecutar pruebas automáticas y crear datos de prueba. Entonces en nuestro sistema aparecieron dos módulos auxiliares: el módulo de lanzamiento y el módulo de generación de datos.
El iniciador se presenta como un procedimiento universal único con un parámetro de texto de entrada. Como parámetro, puede pasar el código mnemónico de la prueba automática, el nombre del paquete, el nombre de la prueba, la configuración de la prueba automática o una palabra clave reservada. El procedimiento selecciona y ejecuta todas las pruebas automáticas que satisfacen las condiciones.
El módulo de generación de datos se presenta en forma de un paquete en el que para cada objeto del sistema bajo prueba (tabla en la base de datos), se crea un procedimiento especial que inserta datos allí. En este procedimiento, los valores predeterminados se completan tanto como sea posible, lo que garantiza la creación de objetos con el clic de un dedo. Y para facilitar su uso, se crearon plantillas para los datos generados. Por ejemplo, cree un cliente de cierta edad con un teléfono de prueba y una compra perfecta. - Las pruebas automáticas deben ejecutarse y ejecutarse en un momento aceptable para su sistema. Por lo tanto, se organizó un lanzamiento nocturno diario, cuyos resultados generan un informe sobre los resultados y lo envían a todo el equipo de desarrollo por correo corporativo. Después de restaurar las antiguas pruebas automáticas y crear otras nuevas, el tiempo total de funcionamiento fue de 30 minutos. Tal desempeño fue adecuado para todos, ya que el lanzamiento tuvo lugar después de las horas.
Pero tuve que trabajar para optimizar la velocidad del trabajo. La actualización del sistema de fidelización en producción se realiza de noche. Como parte de uno de los lanzamientos, tuve que hacer cambios urgentes por la noche. La media hora de espera de los resultados de las pruebas automáticas a las tres de la mañana no hizo feliz a la persona responsable de la liberación (¡saludos sinceros a Alexei Vasyukov!), Y a la mañana siguiente se dijeron muchas palabras amables hacia nuestro sistema. Pero según los resultados, se estableció un estándar de trabajo de 5 minutos.
Para acelerar el rendimiento, utilizamos dos métodos: las pruebas automáticas comenzaron a ejecutarse en tres subprocesos paralelos, lo cual es muy conveniente debido a la arquitectura de nuestro sistema de fidelización. Y abandonamos el enfoque cuando la prueba automática no crea datos de prueba por sí misma, sino que trata de encontrar algo adecuado en el sistema. Después de hacer los cambios, el tiempo total de operación se redujo a 3-4 minutos. - El proyecto con pruebas automáticas debería poder implementarse en varios stands. Al comienzo del viaje, hubo intentos de escribir sus propios archivos por lotes, pero quedó claro que una instalación automática autoescrita era un completo horror, y recurrimos a soluciones industriales. Debido al hecho de que el proyecto tiene mucho código directo (en primer lugar, almacenamos el código para las pruebas automáticas) y muy pocos datos (los datos principales son metadatos sobre las pruebas automáticas), resultó ser muy simple introducir Liquibase en el proyecto.
Es una biblioteca de código abierto independiente de la base de datos para rastrear, administrar y aplicar cambios en el esquema de la base de datos. Gestionado a través de la línea de comandos o marcos como Apache Maven. El principio de funcionamiento de Liquibase es bastante simple. Tenemos un proyecto organizado de cierta manera, que consiste en cambios o scripts que deben implementarse en el servidor de destino, y archivos de control que determinan en qué secuencia y con qué parámetros deben instalarse estos cambios.
En el nivel DBMS, se crea una tabla especial en la que Liquibase almacena el registro de ejecución. Cada cambio tiene un hash calculado, que se compara cada vez entre el proyecto y el estado en la base de datos. Gracias a Liquibase, podemos transferir fácilmente los cambios de nuestro sistema a cualquier circuito. Las pruebas automáticas ahora se ejecutan en bucles de prueba y lanzamiento, así como en contenedores (bucles personales de desarrolladores).
Entonces, hablemos de los resultados de aplicar nuestro sistema de pruebas unitarias.
- Por supuesto, antes que nada, estamos convencidos de que comenzamos a desarrollar un mejor software. Las pruebas automáticas se ejecutan diariamente y encuentran docenas de errores cada año. Además, algunos de estos errores están relacionados indirectamente con la funcionalidad que realmente queríamos cambiar. Existen grandes dudas de que estos errores se encontraron mediante pruebas manuales.
- El equipo ganó confianza en que la funcionalidad específica funciona correctamente ... En primer lugar, se refiere a nuestros procesos críticos. Por ejemplo, en los últimos seis meses, no hemos tenido problemas con la distribución de descuentos y bonificaciones en el cheque, a pesar de los cambios en los lanzamientos, aunque en los períodos anteriores se produjeron errores en algunos intervalos
- Pudimos reducir el número de iteraciones de prueba. Debido al hecho de que las pruebas automáticas se escriben para una nueva funcionalidad, los analizadores y los probadores a tiempo parcial obtienen un código de mayor calidad, porque Ya ha sido verificado.
- Los desarrolladores utilizan parte de los desarrollos de las pruebas automatizadas. Por ejemplo, los datos de prueba en contenedores se crean utilizando el módulo de generación de objetos.
- Es importante que hayamos desarrollado la "adopción" de un sistema de pruebas automatizadas por parte de los desarrolladores. Hay un entendimiento de que esto es importante y útil. Y desde mi propia experiencia puedo decir que esto está lejos de ser el caso. Las pruebas automáticas deben escribirse, deben mantenerse y desarrollarse, los resultados deben analizarse y, a menudo, estos costos de tiempo simplemente no valen la pena. Es mucho más fácil ir a la producción y lidiar con los problemas allí. En nuestro lugar, los desarrolladores se alinean y solicitan cubrir su funcionalidad con pruebas automáticas.
Que sigue
Hablemos de los planes de desarrollo para el proyecto de pruebas automatizadas.
Por supuesto, si bien el sistema de lealtad de Sportmaster sigue vivo y continúa desarrollándose, también es posible desarrollar autocomprobaciones casi sin fin. Por lo tanto, la dirección principal del desarrollo es la expansión del área de cobertura.
A medida que aumenta el número de autotests, el tiempo total de su trabajo crecerá de manera constante y nuevamente tendremos que volver al tema de la productividad. Lo más probable es que la solución sea aumentar el número de hilos paralelos.
Pero estos son caminos de desarrollo obvios. Si hablamos de algo más no trivial, destacamos lo siguiente:
- Actualmente, las pruebas automáticas se gestionan a nivel DBMS, es decir, necesita conocimientos de PL / SQL para trabajar con éxito. Si es necesario, controle el sistema (por ejemplo, iniciando o creando metadatos), puede hacer algún tipo de panel de administración usando Jenkins o algo similar.
- Todos aman los indicadores cuantitativos y cualitativos. Para las pruebas automatizadas, dicha métrica universal es la Cobertura de código o las métricas de cobertura de código. Con este indicador, podemos determinar qué porcentaje del código de nuestro sistema de prueba está cubierto por las pruebas automáticas. A partir de la versión 12.2, Oracle proporciona la capacidad de calcular esta métrica y sugiere utilizar el paquete estándar DBMS_PLSQL_CODE_COVERAGE.
Nuestro sistema de prueba automática tiene poco más de un año, y quizás ahora sea el momento de evaluar la cobertura. En mi proyecto anterior (un proyecto que no es de Sportmaster) sucedió. Un año después de trabajar en las pruebas automáticas, la gerencia estableció una meta para evaluar qué porcentaje del código cubrimos. Con una cobertura de más del 1%, la administración estaría contenta. Nosotros, los desarrolladores, esperábamos un resultado de aproximadamente el 10%. Código de cobertura atornillado, medido, recibido 20%. Para celebrar, fuimos por un premio, pero cómo lo hicimos y dónde fuimos más tarde es una historia completamente diferente. - Las pruebas automáticas pueden verificar los servicios web expuestos. Oracle le permite hacer esto, y ya no encontraremos una serie de problemas.
- Y, por supuesto, nuestro sistema de prueba automatizado puede aplicarse en otro proyecto. Nuestra solución es universal y solo requiere el uso de Oracle. Escuché que en otros proyectos de Sportmaster hay un interés en las pruebas automáticas y, tal vez, iremos a ellos.
Conclusiones
Resumamos En el proyecto, el sistema de fidelización en Sportmaster logramos implementar un sistema de prueba automatizado. Su base es la solución utPLSQL de Stephen Feuerstein. Alrededor de utPLSQL se encuentra el código de autotest y los módulos auxiliares autoescritos: módulo de lanzamiento, módulo de generación de datos y otros. Las pruebas automáticas se realizan a diario y, lo más importante, funcionan y aportan beneficios. Estamos convencidos de que hemos comenzado a lanzar software de mayor calidad. Al mismo tiempo, la solución resultante es universal y puede aplicarse libremente en cualquier proyecto donde sea necesario organizar pruebas automatizadas en Oracle DBMS.
PD Este artículo no es muy específico: hay mucho texto y casi no hay ejemplos técnicos. Si el tema es globalmente interesante, entonces estamos listos para continuarlo y regresar con una continuación, donde le diremos qué ha cambiado en los últimos seis meses y le daremos ejemplos de código.
Escriba comentarios si hay puntos en los que vale la pena centrarse en el futuro, o preguntas que requieren divulgación.