Tipos de Pruebas y Herramientas
La plataforma contempla los siguientes tipos de pruebas. Para cada una de ellas se utiliza la herramienta más adecuada.
Pruebas unitarias
Son las de más bajo nivel. El objetivo de las pruebas unitarias es asegurar el correcto funcionamiento de métodos y funciones individuales de las clases, componentes o módulos de la plataforma. Todas estas pruebas están automatizadas y se ejecutan cada vez que el proyecto se compila.
En el caso de Onesait Platform se están usando las siguientes tecnologías para implementar las pruebas unitarias:
- Se usa JUnit, Spring Test y Mockito para implementar las pruebas
Para la ejecución automática de las pruebas se utiliza Jenkins, que a su vez utiliza la configuración del proyecto realizada con Maven.
Pruebas de integración
Las pruebas de integración verifican que los distintos módulos o servicios utilizados por la aplicación funcionan correctamente en conjunto. Por ejemplo, aseguran la interacción con la base de datos y comprueban que los microservicios funcionan bien en conjunto y según lo esperado. Estos tipos de pruebas son más costosos de ejecutar, ya que requieren que varias partes de la aplicación estén desplegadas.
La ejecución de estas pruebas está automatizada asegurando que se ejecutan al menos una vez al día. Para ello se realizan los siguientes pasos:
- Se utiliza Jenkins para arrancar una instancia efímera de la plataforma usando contenedores Docker.
- Los tests de integración están implementados con JUnit, Spring Test y Mockito.
- La ejecución automática de los tests se realiza con Jenkins, que usa la configuración realizada con Maven.
Pruebas funcionales
Las pruebas funcionales se centran en los requerimientos de negocio de la aplicación, verifican las salidas de una acción sin chequear los estados intermedios. Así pues, se comprueba que el usuario de la aplicación obtiene las respuestas correctas al realizar acciones sobre la plataforma.
A veces, se confunden las pruebas de integración con las funcionales, ya que ambas requieren que varios componentes interactúen entre sí. La diferencia es que una prueba de integración puede simplemente verificar que puedes hacer consultas en la base de datos, mientras que una prueba funcional esperaría obtener un valor específico desde la base de datos, según dicten los requisitos del producto.
En nuestro caso:
- Utilizamos Katalon Studio para crear los scripts automatizados de la plataforma a través del Control Panel.
- Lanzamos estos scripts desde Jenkins.
Dentro de estas pruebas podemos hablar de las pruebas integrales, que replican el comportamiento de un usuario con el software en un entorno de aplicación completo. Además, verifican que diversos flujos de usuario funcionen según lo previsto, y pueden ser tan sencillos como cargar una página web o iniciar sesión, o mucho más complejos, como la verificación de notificaciones de correo electrónico, pagos en línea, etc. y las pruebas de aceptación, que son pruebas formales ejecutadas para verificar si un sistema satisface los requisitos empresariales.
Pruebas de rendimiento
Las pruebas de rendimiento verifican los comportamientos del sistema cuando está bajo una carga significativa. Estas pruebas no son funcionales y pueden tener diversas formas para comprender la confiabilidad, la estabilidad y la disponibilidad de la plataforma. Por ejemplo, puede estar observando los tiempos de respuesta cuando se ejecuta una gran cantidad de solicitudes, o viendo cómo se comporta el sistema con una cantidad significativa de datos.
En nuestro caso:
- Utilizamos JMeter para crear los scripts automatizados que estresen la plataforma.
- Los datos de los Tests los almacenamos en un Elasticsearch y los explotamos desde Kibana:
- Lanzamos estos scripts desde Jenkins.
Pruebas de humo
Las pruebas de humo son pruebas básicas que sirven para comprobar la funcionalidad básica de la aplicación. Están concebidas para ejecutarse rápido, y su objetivo es ofrecerte la seguridad de que las principales funciones de tu sistema funcionan según lo previsto.
Las pruebas de humo son útiles justo después al realizar una nueva compilación para decidir si puede o no realizar pruebas más costosas, o justo después de una versión para asegurarse de que la aplicación se ejecute correctamente en el entorno recientemente implementado.