Pruebas de regresión funcional con SOAtest como parte de un proceso de integración continua

La integración continua fusiona las copias de trabajo de todos los desarrolladores en una línea principal compartida. Este proceso hace que el desarrollo de software sea más accesible, más rápido y menos riesgoso para los desarrolladores. Lea este artículo para comprender cómo configurar SOAtest para ejecutar pruebas de regresión funcional como parte de CI.

¿Qué son las pruebas de regresión funcional?

Una regresión se define como "una tendencia o cambio hacia un estado inferior o menos que perfecto", que es lo que todos intentamos evitar al desarrollar software. Las pruebas de regresión descubren defectos que se introducen en nuestro software al añadir nuevas funciones, corregir errores o modificar la aplicación.

La prueba de regresión es un método común que la mayoría de los procesos de desarrollo de software utilizan para verificar la funcionalidad del software después de realizar modificaciones en él. Estas pruebas determinan si las nuevas modificaciones afectan la funcionalidad actual del software. Por supuesto, se necesitan nuevas pruebas para la nueva funcionalidad. Las pruebas de regresión aseguran que lo que ya se probó sigue siendo funcional.

Las pruebas de regresión juegan un papel vital en la integración continua (CI) en el desarrollo de software al garantizar que el código recién integrado no rompa la funcionalidad existente ni introduzca regresiones. Estas pruebas brindan la retroalimentación rápida esencial en CI al detectar defectos en el código recién integrado para que puedan identificarse y resolverse rápidamente antes de que afecten la estabilidad del software.

Pruebas de regresión funcional frente a pruebas funcionales

Pruebas de regresión Incluye pruebas funcionales. En la práctica, la mayoría de las pruebas funcionales se convierten con el tiempo en pruebas de regresión. La principal diferencia radica en el momento y el objetivo de estas pruebas.

Prueba funcional Se realiza típicamente durante el desarrollo, cuando se desarrollan, implementan y prueban nuevas funciones. Se centra en funciones, características o casos de uso específicos del software para verificar su comportamiento según lo esperado. Puede implicar diversas técnicas de prueba, como pruebas unitarias, pruebas de API, pruebas de IU, entre otras.

Las pruebas de regresión, por otro lado, se realizan durante el desarrollo como parte de la canalización de CI y/o después de hitos de desarrollo importantes, como al final de un sprint o un ciclo de lanzamiento. Las pruebas de regresión se automatizan tanto como sea posible para que puedan ser repetibles y eficientes, e incluyen pruebas tanto funcionales como no funcionales. Más sobre eso a continuación.

Herramientas de prueba de regresión funcional

Las pruebas de regresión se benefician significativamente de la automatización y, por lo tanto, las herramientas diseñadas para respaldar la práctica también admiten la automatización de todos los tipos de pruebas. Estas herramientas ayudan a automatizar la ejecución de casos de prueba que verifican la funcionalidad del software, recopilan y analizan resultados e informan sobre cualquier problema de regresión. Aquí hay algunas clases de herramientas de automatización de software de uso común para las pruebas de regresión funcional.

• Pruebas de interfaz de usuario. Estas herramientas automatizan la prueba de interfaces de usuario basado en un paradigma de grabación y reproducción. Los evaluadores registran casos de uso o flujos de trabajo de usuarios y las herramientas reproducen las mismas acciones en la interfaz de usuario. Selenium, por ejemplo, es una popular herramienta de automatización de código abierto ampliamente utilizada para probar aplicaciones web. Admite múltiples lenguajes de programación y proporciona un marco para automatizar las interacciones del navegador.
• Pruebas de API. Automatización de pruebas a nivel de API requiere casos de prueba y arneses para ejecutarlos que interactúan directamente con las API de la aplicación subyacente. Las pruebas a este nivel tienen ventajas sobre las pruebas manuales y automatizadas de la interfaz de usuario porque son más resistentes a los cambios de la interfaz de usuario y prueban la lógica empresarial de manera más directa.
• Examen de la unidad. Prueba unitaria se realiza en el componente de software más bajo, que suele ser un método en C++ o Java o una función en C. Las pruebas unitarias funcionan probando individualmente las funciones y/o procedimientos del código en un archivo fuente para seguridad, protección y solidez. A medida que se ejecutan las pruebas unitarias, los valores de salida de las funciones se recopilan y se inspeccionan para verificar que sean correctos, y los informes se pueden almacenar con fines de auditoría o cumplimiento. Muchos equipos de desarrollo también miden la cobertura del código para exponer el código que no se ha probado. Saber que cada unidad individual de código ha sido probada y es sólida elimina el riesgo y ayuda a garantizar la entrega de una aplicación de calidad.
• Gestión de datos de prueba. Se deben proporcionar datos de prueba apropiados a las aplicaciones bajo prueba durante el proceso de prueba para que los casos de prueba puedan validar la funcionalidad de la aplicación, incluidas las rutas de usuario comunes o críticas y los casos de esquina. Cuando se utilizan datos de prueba realistas, también ayuda a replicar las condiciones de error y los defectos. Gestión de datos de prueba (TDM) proporciona una manera de crear y administrar conjuntos de datos seguros y apropiados que su empresa puede usar en varios equipos para validar la funcionalidad y el rendimiento de una aplicación.
• Informes y análisis Después de ejecutar las pruebas de regresión, los resultados se analizan para proporcionar tanto estado y hallazgos procesables que se pueden ver en la web, en el escritorio o en informes HTML estáticos. Idealmente, los análisis se presentan en paneles personalizables y fáciles de usar que se componen de widgets altamente flexibles que muestran claramente los riesgos dentro de su base de código y brindan una vista completa del estado y la calidad del proyecto.

Estos tipos de herramientas mencionados son un subconjunto de las muchas herramientas diferentes que pueden ser necesarias para validar completamente una aplicación. Es fundamental que estas herramientas funcionen juntas a la perfección para facilitar la canalización de CI/CD.

Logre velocidad mientras protege su aplicación contra regresiones

CI es una práctica bien entendida y bien adoptada y un primer paso necesario para mejorar significativamente la velocidad de entrega de aplicaciones. Permite a los desarrolladores enviar sus cambios directamente a una rama maestra del código fuente. Un solo desarrollador puede impulsar potencialmente muchos cambios a la rama maestra a lo largo de un solo día. Para asegurarse de que la rama principal sea impecable, se pueda construir y tenga calidad de producción, es fundamental contar con casos de prueba apropiados para cada cambio, ya que sirve como la copia dorada del código fuente de la aplicación.

Profundicemos en cómo configurar Parasoft SOAtest para ejecutar pruebas funcionales y pruebas de regresión como parte de un proceso de integración continua. Repasaremos los pasos para configurar Parasoft SOAtest con Jenkins, una popular plataforma de automatización que utiliza la aplicación de demostración de código abierto Parabank y la implementaremos con Docker para simplificar las cosas.

¿Cómo funcionará esto?

El siguiente diagrama muestra el flujo de trabajo descrito en este artículo. Siga los pasos de izquierda a derecha.

1. Un desarrollador o un probador verificará sus casos de prueba en un repositorio de control de código fuente. En este ejemplo usaremos GitHub.
2. Jenkins revisará el repositorio de GitHub, que contiene el proyecto SOAtest llamado "parabanco"que contiene nuestros casos de prueba funcionales. Jenkins también extraerá una imagen de Docker llamada parasoft/parabanco de DockerHub. Esta imagen no solo contiene Parabank, sino también el servidor de aplicaciones y las dependencias necesarias para ejecutar la aplicación.
3. Jenkins creará una imagen de Parabank (llamada "contenedor") y configurará la aplicación bajo prueba (AUT) según las características específicas del entorno de prueba.
4. Luego, Jenkins activará Parasoft SOAtest para ejecutar pruebas funcionales extraídas de GitHub para que podamos validar nuestra aplicación Parabank e implementar las correcciones de errores necesarias.

Es cierto que esto no está del todo en el espíritu de una verdadera integración continua, ya que estamos comenzando con una imagen de Docker preconstruida. Pero esto nos ahorra la molestia de construir Parabank con Maven e instalar y configurar Tomcat/Java.

El siguiente diagrama muestra un diagrama más realista del mundo real de CI. Tan pronto como un desarrollador verifica el código fuente en GitHub, queremos ejecutar las pruebas de regresión necesarias y cualquier nuevo caso de prueba funcional para verificar que la aplicación aún esté en buen estado, incluso después de los cambios del desarrollador.

Un cambio de código fuente en GitHub activa automáticamente una compilación en Jenkins, y Jenkins inicia una etapa de compilación de Maven, que ejecuta cualquier análisis de código estático y JUnit prueba y compila nuestra aplicación. Si todas las pruebas unitarias pasan, la aplicación empaquetada, parabank.war, se implementa en un servidor de aplicaciones, en este caso, Tomcat, como parte de la etapa de implementación. SOAtest luego inicia la etapa de prueba y ejecuta pruebas de regresión y pruebas funcionales.

Solo después de que las pruebas unitarias y los casos de prueba de caja negra pasan durante la ejecución de SOAtest, los cambios originales del desarrollador se consideran correctos.

Repasemos los requisitos previos y los pasos para configurar el proceso en el primer diagrama.

Configuración de SOAtest y Jenkins

Requisitos previos

• Una máquina capaz de ejecutar Docker. Este tutorial utiliza Windows, por lo que algunos de los comandos de este artículo pueden tener una sintaxis diferente. Esta máquina debe estar conectada a Internet.
• Cree un archivo localsettings.properties en algún lugar de su máquina. Copia el contenido de este archivo de muestra en ello. Si tiene una licencia de nodo bloqueado, agréguela a la línea 5. Si usa un servidor de licencias, establezca la línea 6 en verdadero y agregue el nombre de host del servidor de licencias en la línea 3. Necesitaremos la ruta a este archivo más adelante.
• Jenkins 2.387.1 o posterior instalado en la misma máquina.
• Parasoft SOAtest 2022.1 o posterior instalado y en la RUTA para invocar soatestcli desde cualquier directorio.
• Docker instalado y en la RUTA de la misma máquina.
• Git instalado.

pasos

1. Inicie sesión en Jenkins en su navegador web. Jenkins normalmente se implementa en una URL como http:// :8080/jenkins.

2. Vamos a comenzar instalando algunos complementos de Jenkins. Seleccione Administrar Jenkins a la izquierda y luego Administrar complementos en el nuevo menú que aparece.

3. En la pestaña Disponible, seleccione e instale el complemento Parasoft Findings.
4. Seleccione Instalar sin reiniciar y luego, en la página Instalación, marque la casilla Reiniciar Jenkins cuando se complete la instalación y no se estén ejecutando trabajos.
5. Regrese al menú principal de Jenkins desde el paso 1. A la izquierda, seleccione Nuevo elemento.

6. Proporcione el nombre Parabank Deploy and Test y seleccione Proyecto Freestyle y luego Aceptar.

7. En el menú de configuración que aparece, desplácese hacia abajo hasta Administración de código fuente y seleccione Git. Agregue esta URL al campo URL del repositorio: https://github.com/sdebrosse/soatest-automation-example.git. Todos los demás campos se pueden dejar con sus valores predeterminados.

8. Desplácese hasta la parte inferior de la página y, en Generar, agregue un paso de compilación Ejecutar comando por lotes de Windows. Si está utilizando Linux, seleccione Ejecutar shell en su lugar.

9. Copia el contenido del guión aquí y péguelo en el nuevo campo de paso de compilación. Debe cambiar los valores de las dos variables en la parte superior de la secuencia de comandos para reflejar la ruta a su propio archivo localsettings.properties y dónde desea que se cree un espacio de trabajo temporal. SOAtest creará este espacio de trabajo durante el proceso de prueba. Los comentarios en el guión explican lo que sucede en cada línea.

10. Eso es todo. ¡Ahora estamos listos para ejecutar nuestro trabajo de Jenkins! Asegúrese de cerrar primero todas las instancias abiertas de SOAtest. Luego seleccione Guardar en la parte inferior del menú de configuración y haga clic en Construir ahora a la izquierda.

11. Puede hacer clic en el trabajo en ejecución a la izquierda y luego ver la salida de la consola en vivo.

12. Los registros mostrarán el estado de ÉXITO al final de su trabajo si todo funcionó correctamente. Esto significa que obtuvo con éxito un proyecto de prueba SOAtest de GitHub, implementó un contenedor Docker con Parabank y ejecutó pruebas en esta aplicación de Parabank. Al final del proceso, eliminamos automáticamente el contenedor de Parabank y eliminamos nuestro espacio de trabajo temporal para limpiar el entorno de compilación. Pero es posible que haya notado al mirar los registros que tuvimos algunas fallas en las pruebas. Sí, algunas de nuestras pruebas contra Parabank fallaron.

Si queremos que nuestra compilación de Jenkins falle debido a fallas en la prueba SOAtest, agregamos el indicador -fail cuando invocamos soatestcli. Como esto:

soatestcli.exe -fail -data %TEMP_WORKSPACE_PATH% -resource /Parabank -config "builtin://Demo Configuration" -localsettings %LOCALSETTINGS_PATH%

Si abre la prueba en la interfaz de usuario de SOAtest Desktop, descubrirá que esta falla de prueba es principalmente un problema de configuración de los datos de prueba y del entorno de prueba. El Servicio de Procesador de Préstamos rechazó un préstamo que debería haber aprobado.

Resumen

Implementar la integración continua en su proceso de desarrollo de software aumenta significativamente la velocidad de entrega de aplicaciones. Soluciones automatizadas como Prueba SOA ofrecer una estrategia de prueba de regresión escalable y eficiente con la capacidad de ejecutar casos de prueba que verifiquen la funcionalidad del software, cotejen y analicen resultados e informen cualquier problema de regresión. La combinación ayuda a los equipos a alcanzar una mayor velocidad de lanzamiento, mejorar la productividad de las pruebas y garantizar una alta cobertura de las pruebas.