Hola Habr!
Mi nombre es Maxim Ponomarenko y soy desarrollador en Sportmaster. Tengo 10 años de experiencia en el campo de TI. Comenzó su carrera en pruebas manuales, luego pasó al desarrollo de bases de datos. Durante los últimos 4 años, acumulando conocimiento adquirido en pruebas y desarrollo, me he dedicado a la automatización de pruebas a nivel DBMS.
He sido parte del equipo de Sportmaster durante poco más de un año y estoy involucrado en el desarrollo de pruebas automatizadas en uno de los principales proyectos. En abril, los chicos de Sportmaster Lab y yo hablamos en una conferencia en Krasnodar, mi informe se llamaba "Pruebas de unidad en el DBMS", y ahora quiero compartirlo con ustedes. Habrá mucho texto, así que decidí dividir el informe en dos publicaciones. En el primero hablaremos sobre las pruebas automáticas y las pruebas en general, y en el segundo me detendré en nuestro sistema de prueba de la unidad y los resultados de su aplicación.
Al principio, una pequeña teoría aburrida. ¿Qué es la prueba automática? Esta es una prueba que realiza el software, y en las TI modernas se usa cada vez más en el desarrollo de software. Esto se debe al hecho de que las empresas están creciendo, sus sistemas de información están creciendo y, en consecuencia, la cantidad de funcionalidad que necesita ser probada está creciendo. La realización de pruebas manuales es cada vez más costosa.
Trabajé para una gran empresa, cuyos lanzamientos salen cada dos meses. Al mismo tiempo, se pasó todo un mes en una docena de evaluadores para verificar la funcionalidad con sus manos. Gracias a la introducción de la automatización por parte de un pequeño equipo de desarrolladores, pudimos reducir el tiempo de prueba a 2 semanas en un año y medio. No solo aumentamos la velocidad de las pruebas, sino que también aumentamos su calidad. Las pruebas automatizadas se ejecutan regularmente y siempre completan todo el curso de las pruebas inherentes a ellas, es decir, excluimos el factor humano.
La TI moderna se caracteriza por el hecho de que se puede requerir al desarrollador no solo que escriba el código del producto, sino que escriba pruebas unitarias que verifiquen este código.
Pero, ¿qué pasa si su sistema se basa principalmente en la lógica del servidor? No hay una solución única y mejores prácticas en el mercado. Como regla general, las empresas resuelven este problema creando su propio sistema de prueba auto-escrito. Tal sistema de prueba automatizado auto-escrito patentado fue creado en nuestro proyecto, y hablaré de ello en mi informe.
Prueba de lealtad
Primero, hablemos de un proyecto en el que implementamos un sistema de prueba automatizado. Nuestro proyecto es el sistema de fidelización de Sportmaster (por cierto, ya escribimos sobre esto en
esta publicación ).
Si su empresa es lo suficientemente grande, su sistema de fidelización tendrá tres propiedades estándar:
- Su sistema estará muy cargado.
- Su sistema contendrá procesos informáticos complejos.
- Su sistema se desarrollará activamente.
Vamos en orden. Sportmaster tiene una gran cantidad de tiendas que venden activamente. Naturalmente, el sistema de fidelización es un sistema altamente cargado. Y dado que el proyecto se usa activamente, debemos proporcionar los más altos estándares de calidad, porque cualquier error en el software es mucho dinero, reputación y otras pérdidas.
Al mismo tiempo, más de cien promociones diferentes funcionan en Sportmaster. Las acciones son muy diferentes: hay productos básicos, están programados para el día de la semana, están vinculados a una tienda en particular, hay acciones en el monto del cheque, hay una cantidad de productos. En general, no débil. Los clientes tienen bonos, hay códigos promocionales que se utilizan al comprar. Todo esto lleva al hecho de que el cálculo de cualquier orden es una tarea muy poco trivial.
El algoritmo que implementa el procesamiento de pedidos es realmente terrible y complicado. Y cualquier cambio en este algoritmo es algo bastante arriesgado. Parecía que había los cambios menores más externos que podrían conducir a efectos bastante impredecibles. Pero son precisamente los procesos computacionales tan complejos, más que la implementación de la funcionalidad crítica, el mejor candidato para la automatización. Revisar docenas de casos del mismo tipo con las manos lleva mucho tiempo. Y dado que el punto de entrada al proceso no cambia, una vez que lo describe, puede sellar rápidamente las pruebas automáticas y asegurarse de la funcionalidad.
Dado que nuestro sistema se usa activamente, la empresa querrá algo nuevo de usted, actualizado y orientado al cliente. En nuestro sistema de fidelización, los lanzamientos se lanzan cada dos meses. Entonces, cada dos meses necesitamos llevar a cabo una regresión completa de todo el sistema. Al mismo tiempo, por supuesto, como en cualquier TI moderna, el desarrollo no viene inmediatamente del desarrollador a la producción. Se origina en el circuito del desarrollador, luego pasa secuencialmente el banco de pruebas, el lanzamiento, la aceptación y solo entonces está en producción. Al menos en los circuitos de prueba y liberación, necesitamos realizar una regresión completa de todo el sistema.
Las propiedades descritas son estándar para casi cualquier sistema de fidelización. Hablemos de las características de nuestro proyecto.
Tecnológicamente, el 90% de la lógica de nuestro sistema de fidelización se basa en el servidor y se implementa en Oracle. Hay un cliente expuesto en Delphi, que realiza la función de un administrador de AWP. Hay servicios web expuestos para aplicaciones externas (como un sitio web). Por lo tanto, es muy lógico que si implementamos un sistema de prueba automatizado, lo haremos en Oracle.
El sistema de lealtad en Sportmaster existe desde hace más de 7 años y fue creado por desarrolladores individuales ... El número promedio de desarrolladores en nuestro proyecto durante estos 7 años fue de 3-4 personas. Pero durante el año pasado, nuestro equipo ha crecido significativamente y ahora 10 personas están trabajando en el proyecto. Es decir, las personas que no están familiarizadas con las tareas, procesos y arquitectura típicos llegan al proyecto. Y existe un mayor riesgo de omitir errores.
El proyecto se caracteriza por la ausencia de evaluadores dedicados como unidades de personal. Las pruebas, por supuesto, lo son, pero los analistas participan en las pruebas, además de sus otras responsabilidades principales: comunicarse con clientes comerciales, usuarios, resolver los requisitos del sistema, etc. etc ... A pesar de que las pruebas se llevan a cabo de manera muy cualitativa (esto es especialmente apropiado de mencionar, ya que uno de los analistas puede llamar la atención de este informe), nadie canceló la efectividad de la especialización y la concentración en una cosa.
Dado todo lo anterior, para mejorar la calidad del producto emitido y reducir el tiempo de desarrollo, la idea de automatizar las pruebas en el proyecto parece muy lógica. Y en diferentes etapas de la existencia del sistema de lealtad, los desarrolladores individuales hicieron esfuerzos para cubrir su código con pruebas unitarias. En general, fue un proceso bastante dispares donde todos usaron su arquitectura y métodos. Las pruebas unitarias eran comunes para los resultados finales: las pruebas se desarrollaron, se utilizaron durante algún tiempo, se apilaron en un almacenamiento de archivos versionado, pero en algún momento dejaron de iniciarse y se olvidaron. Esto se debió principalmente al hecho de que las pruebas se vincularon más a un artista específico que a un proyecto.
UtPLSQL viene al rescate
¿Sabes algo de Stephen Feuerstein?
Este es un tipo inteligente que dedicó gran parte de su carrera a trabajar con Oracle y con PL / SQL, escribió una gran cantidad de trabajos sobre este tema. Un libro suyo muy conocido se llama: “Oracle PL / SQL. Para profesionales ". Es Steven quien posee el desarrollo de la solución utPLSQL, o, tal como es, el marco de pruebas de unidad para Oracle PL / SQL. La solución utPLSQL se creó en 2016, pero continúan trabajando activamente en ella y lanzan nuevas versiones. En el momento del informe, la última versión está fechada el 24 de marzo de 2019.
Que es esto Este es un proyecto de código abierto separado. Pesa un par de megabytes, teniendo en cuenta ejemplos y documentación. Físicamente, es un esquema separado en la base de datos ORACLE con un conjunto de paquetes y tablas para organizar pruebas unitarias. La instalación lleva unos segundos. Una característica distintiva de utPLSQL es su facilidad de uso.
A nivel mundial, utPLSQL es un mecanismo para ejecutar pruebas unitarias, donde una prueba unitaria se refiere a procedimientos por lotes regulares de Oracle, cuya organización sigue ciertas reglas. Además del lanzamiento, utPLSQL almacena un registro de todas sus ejecuciones de prueba, y también hay un sistema de informes interno.
Veamos un ejemplo de cómo se ve el código de prueba de unidad implementado por esta técnica.
Entonces, la pantalla muestra el código para la especificación estándar de un paquete con pruebas unitarias. ¿Cuáles son los requisitos requeridos? El paquete debe tener el prefijo utp_. Todos los procedimientos con pruebas deben tener exactamente el mismo prefijo. El paquete debe contener dos procedimientos estándar: "utp_setup" y "utp_teardown". El primer procedimiento se llama reiniciando cada prueba unitaria, el segundo, después de comenzar.
"Utp_setup", como regla, prepara nuestro sistema para ejecutar una prueba unitaria, por ejemplo, crea datos de prueba. "Utp_teardown": por el contrario, todo vuelve a su configuración original y restablece los resultados de inicio.
Aquí hay un ejemplo de la prueba unitaria más simple, que verifica la normalización del número de teléfono ingresado del cliente al aspecto estándar de nuestro sistema de lealtad. No hay normas obligatorias para escribir procedimientos con pruebas unitarias. Como regla general, se llama a un método del sistema bajo prueba y el resultado devuelto por este método se compara con el de referencia. Es importante que la comparación del resultado de referencia y el resultado se realice a través de métodos estándar utPLSQL.
Una prueba unitaria puede tener cualquier número de verificaciones. Como puede ver en el ejemplo, hacemos cuatro llamadas consecutivas del método probado para normalizar el número de teléfono y después de cada llamada evaluamos el resultado. Al desarrollar una prueba unitaria, se debe tener en cuenta que hay comprobaciones que no afectan el sistema de ninguna manera, y después de algunas, es necesario volver al estado inicial del sistema.
Por ejemplo, en la prueba de unidad presentada, simplemente formateamos el número de teléfono de entrada, lo que no afecta el sistema de lealtad.
Y si escribimos pruebas unitarias utilizando el método de creación de un nuevo cliente, luego de cada verificación se creará un nuevo cliente en el sistema, lo que puede afectar el lanzamiento posterior de la prueba.
Así es como se ejecutan las pruebas unitarias. Hay dos posibles opciones de inicio: iniciar todas las pruebas unitarias desde un paquete específico o comenzar una prueba unitaria específica en un paquete específico.
Aquí hay un ejemplo de un sistema de informes internos. Según los resultados de la prueba unitaria, utPLSQL crea un pequeño informe. En él vemos el resultado de cada prueba específica y el resultado general de la prueba unitaria.
6 reglas de autotests
Antes de comenzar a crear un nuevo sistema para pruebas automatizadas de un sistema de lealtad, junto con la administración, determinamos los principios que nuestras futuras pruebas automáticas deben cumplir.
- Las pruebas automáticas deben ser efectivas y beneficiosas. Tenemos desarrolladores maravillosos, sobre los cuales debo decir, porque uno de ellos probablemente verá este informe y escribirán un código maravilloso. Pero incluso su maravilloso código no es perfecto y está contenido, contiene y contendrá errores. Se requieren pruebas automáticas para encontrar estos errores. Si esto no es así, o bien escribimos autoevaluaciones deficientes o llegamos a un área muerta, que, en principio, no se está finalizando. En ambos casos, estamos haciendo algo mal, y nuestro enfoque simplemente no tiene sentido.
- Se deben usar pruebas automáticas. No tiene sentido gastar mucho tiempo y esfuerzo escribiendo un producto de software, sumar su repositorio y olvidarlo. Las pruebas deben ejecutarse y ejecutarse tan regularmente como sea posible.
- Las pruebas automáticas deberían funcionar de manera estable. Independientemente de la hora del día, la plataforma de lanzamiento u otras configuraciones del sistema, ejecutar las pruebas debería conducir al mismo resultado. Como regla, esto está garantizado por el hecho de que las pruebas automáticas funcionan con datos de prueba especiales con configuraciones fijas del sistema.
- Las pruebas automáticas deben funcionar a una velocidad aceptable para su proyecto. Este tiempo se determina individualmente para cada sistema. Alguien puede permitirse el lujo de trabajar todo el día, y alguien encaja en los segundos. Qué estándares de velocidad hemos logrado en nuestro proyecto, lo contaré un poco más tarde.
- El desarrollo de las pruebas automáticas debe ser flexible. No es deseable negarse a probar cualquier funcionalidad simplemente porque aún no lo hemos hecho o por otras convicciones. utPLSQL no impone restricciones de desarrollo, y Oracle, en principio, le permite implementar una variedad de cosas. La mayoría de las tareas tienen una solución, la única pregunta es tiempo y esfuerzo.
- Implementabilidad. Tenemos varios puestos donde necesita ejecutar pruebas. En cada uno de los stands, se puede actualizar un volcado de datos en cualquier momento. Es necesario llevar a cabo un proyecto con pruebas automáticas de tal manera que pueda llevar a cabo su instalación total o parcial sin dolor.
Y en la segunda publicación en un par de días, les contaré lo que hemos hecho y qué resultados se han logrado.