Prueba de regresión de sistemas integrados

Equipos de desarrollo realizar pruebas de regresión para verificar que los cambios en el código (corregir un error o agregar una nueva funcionalidad) en una aplicación de software no resulten en la introducción de otro error o rompan ninguna de las funciones del sistema existente.

Para muchos, si no la mayoría de los sistemas integrados, los equipos realizan pruebas de regresión al final del ciclo de vida para determinar la estabilidad de cada versión de software. Este es un proceso iterativo que continúa hasta que el proyecto llega al final del desarrollo o al final del mantenimiento.

En otros flujos de trabajo, las pruebas de regresión son una actividad que es la realidad del día a día de los desarrolladores. De hecho, se puede argumentar que en los procesos iterativos y ágiles, la mayoría de las pruebas son pruebas de regresión. Antes de continuar, veamos qué es la prueba de regresión y por qué es una parte tan importante de las prácticas de desarrollo de software.

¿Qué es la prueba de regresión?

Una regresión es “una tendencia o cambio hacia un estado inferior o menos que perfecto”, que es lo que todos intentamos evitar cuando desarrollamos software. Las pruebas de regresión ayudan a encontrar defectos que se infiltran en nuestro software a medida que agregamos nuevas funciones, solucionamos errores y realizamos cambios en los casos de prueba.

Como parte de la mayoría de los procesos de desarrollo de software, los desarrolladores realizan pruebas de regresión después de realizar cambios en el software. Estas pruebas determinan si los nuevos cambios tuvieron un impacto en el funcionamiento existente del software.

Las pruebas de regresión son necesarias, por supuesto, pero solo indican que los cambios recientes en el código no han provocado que las pruebas fallen. No hay garantía de que los cambios funcionen por sí mismos. Además, la naturaleza de los cambios que motivan la necesidad de realizar pruebas de regresión pueden ir más allá de la aplicación actual e incluir cambios en el hardware, el sistema operativo y el entorno operativo.

Por qué es importante la prueba de regresión en sistemas integrados

Dado que los sistemas integrados tienden a tener restricciones críticas de seguridad y protección, los equipos de desarrollo prueban el sistema o subsistema para detectar regresiones. Podría decirse que la prueba ocurre al final de cada ciclo de vida iterativo del sistema o subsistema. Esto significa que todos los casos de prueba unitaria que se definieron para un sistema de software anterior o una versión del subsistema, más los nuevos casos de prueba unitaria que se han agregado para verificar la nueva funcionalidad, deben ejecutarse para exponer regresiones en el software.

Si un caso de prueba unitario anterior pasó y ahora falla, es posible que se haya identificado una regresión potencial. La nueva funcionalidad podría causar la falla. Si este es el escenario, es posible que el caso de prueba deba actualizarse teniendo en cuenta los cambios en los valores de entrada y salida.

También es crucial comprender que las pruebas de regresión no solo implican casos de prueba unitaria. Las pruebas de regresión de sistemas embebidos también incluyen la ejecución de casos de prueba de integración, casos de prueba del sistema, casos de prueba de rendimiento, casos de prueba de esfuerzo y más. De hecho, los desarrolladores deben ejecutar todos los casos de prueba creados previamente para garantizar:

• No existen regresiones.
• Construcción de una nueva versión de software de alta calidad.

Ambos son fundamentales porque cada nueva versión de sistema o subsistema de software se crea o desarrolla a partir de su versión anterior. Si no tiene una base sólida, todo puede colapsar.

Parasoft C / C ++test puede generar automáticamente casos de prueba. Combinarlos con casos de prueba creados manualmente da como resultado un conjunto colectivo: un conjunto de pruebas. Los desarrolladores y probadores ejecutan el conjunto de pruebas para identificar defectos de la aplicación.

La prueba Parasoft C / C ++ captura los resultados de la prueba e identifica fallas para analizar y corregir. Después de este ciclo inicial, los equipos pueden reutilizar los casos de prueba existentes o el conjunto de pruebas para las pruebas de regresión.

Pruebas de regresión en desarrollo ágil

Probablemente sea obvio que es necesario probar las actualizaciones y los cambios en el software. En ese sentido, las pruebas de regresión son un paso obvio en el proceso de desarrollo. En el desarrollo de software moderno con procesos ágiles e integración e implementación continuas, las pruebas de regresión se convierten en un paso crítico en cada ciclo.

A medida que crece el software, también lo hace el conjunto de pruebas de regresión. A medida que la suite crece, también lo hace el tiempo de ejecución y depuración y, a menudo, el cuello de botella en la canalización. Es difícil tener un desarrollo ágil y una canalización de DevOps optimizada sin pruebas de regresión enfocadas y optimizadas.

Prueba de regresión para dispositivos integrados

Trabajar en sistemas integrados agrega otra dimensión a las pruebas porque a menudo es preferible o necesario realizar pruebas en el hardware de destino. Las pruebas de regresión pueden ser más desafiantes debido a la complejidad de iniciar y observar pruebas en objetivos integrados. Agregue a eso el acceso limitado al hardware de destino que tienen los equipos de software debido al alto costo de estos sistemas de destino.

Por lo tanto, implementar una solución de automatización de pruebas reutilizable y configurable que pueda realizar una transición fluida y continua desde la ejecución en un host y/o un sistema virtual, y para la verificación y validación en el sistema de destino: proporciona ahorros significativos en recursos, tiempo y costos.

Los equipos de desarrollo pueden usar Parasoft para ejecutar pruebas unitarias en la plataforma host, el simulador de procesador de destino o el destino incorporado. Optimizado para asumir una sobrecarga adicional mínima para la huella binaria o los ciclos de proceso, el arnés de prueba de Parasoft C/C++test viene en forma de código fuente. Eso significa que los equipos pueden personalizar las modificaciones específicas de la plataforma requeridas. Esto es necesario porque los resultados de las pruebas y la recopilación de datos de cobertura de código del sistema de destino es esencial para los sistemas críticos para la seguridad y la protección, y es requerido por los estándares de proceso como DO-178B / C, ISO 26262, IEC 62304, y más.

Además, la prueba Parasoft C / C ++ ofrece integraciones dedicadas con IDE y depuradores integrados que hacen que el proceso de ejecución de casos de prueba sea fluido y automatizado. Los entornos IDE compatibles incluyen Eclipse, VS Code, Green Hills Multi, Wind River Workbench, IAR EW, ARM MDK, ARM DS-5, TI CCS, Visual Studio y muchos otros. Ver todas las pruebas de Parasoft C / C ++ Especificaciones técnicas.

Mejores prácticas y técnicas de pruebas de regresión

En el centro de las pruebas de regresión se encuentra el legado de los casos de prueba de la versión anterior del software probada. Las pruebas de regresión consisten en reutilizar casos de prueba existentes para identificar una recaída en la calidad del código entre cada actualización de software y nueva versión. Por lo tanto, las mejores prácticas consisten en aplicando la automatización para gestionar la gran colección de casos de prueba de regresión.

Para garantizar un conjunto de pruebas sólido para cada prueba de regresión realizada, los equipos deben realizar las siguientes tareas.

• Identifique los casos de prueba que necesitan actualización.
• Actualice los casos de prueba para probar los cambios de código.
• Cree nuevos casos de prueba para probar el nuevo código.
• Eliminar casos de prueba irrelevantes.

Debido a que puede haber miles de casos de prueba, los equipos de control de calidad querrán automatizar la gestión de las pruebas de regresión. Las organizaciones querrán adoptar una solución que identifique automáticamente los casos de prueba que deben actualizarse debido a cambios de software. A continuación se explican las pruebas de base de cambios para las soluciones de prueba de Java, C# y VB.Net. Las soluciones como Parasoft aceleran los cambios en la lógica de los casos de prueba existentes, incluida la creación de apéndices y la gestión de las variaciones de los valores de prueba de entrada y salida.

Para el código recién agregado, se deberán crear nuevos casos de prueba. Parasoft permite la generación automatizada de casos de prueba unitaria. Además, una interfaz gráfica ayuda a acelerar la creación manual de casos de prueba. Para el código eliminado, no olvide eliminar todas las pruebas irrelevantes correspondientes.

¿Cómo decidir qué prueba de regresión?

El desafío clave con las pruebas de regresión es determinar qué partes de una aplicación probar. No es raro ejecutar de forma predeterminada todas las pruebas de regresión cuando hay dudas sobre los impactos de los cambios de código recientes. Es ese enfoque de "todo o nada". Sin embargo, para grandes proyectos de software, esto se convierte en una gran tarea y reduce la productividad del equipo. Esta incapacidad para enfocar las pruebas obstaculiza muchos de los beneficios de los procesos iterativos y continuos, potencialmente exacerbados en el software integrado donde los objetivos de prueba son un recurso limitado.

Lo que se necesita es una forma de identificar qué pruebas deben volver a ejecutarse y enfocar los esfuerzos de prueba (pruebas unitarias, prueba funcional automatizaday pruebas manuales) para validar las funciones y el código relacionado que se ven afectados por los cambios más recientes. Usando una combinación de los motores de análisis de cobertura patentados de Parasoft (Prueba C / C ++ para C y C ++, jprueba para Java, y puntoPRUEBA para C #) y Process Intelligence Engine (PIE) dentro DTP de Parasoft, los desarrolladores y evaluadores pueden comprender los cambios en la base de código entre compilaciones y, con esta eficiencia mejorada, lograr la promesa de Agile. Esta forma de ejecución de prueba inteligente se denomina análisis de impacto de prueba, a veces denominado pruebas basadas en cambios.

Comprender el impacto de los cambios de código en las pruebas con el análisis de impacto de las pruebas

El análisis de impacto de prueba utiliza datos recopilados durante las ejecuciones de prueba y cambios en el código entre compilaciones para determinar qué archivos cambiaron y qué pruebas específicas tocaron esos archivos. El motor de análisis de Parasoft puede analizar el delta entre dos compilaciones e identificar el subconjunto de pruebas de regresión a ejecutar. También comprende las dependencias de las unidades modificadas para determinar qué efecto dominó los cambios realizados en otras unidades.

Parasoft Jtest y dotTest brindan información sobre el impacto de los cambios de software y ofrecen recomendaciones sobre dónde agregar pruebas y dónde ejecutar más pruebas de regresión. Consulte el ejemplo de informe de prueba basado en cambios a continuación.

Prueba de regresión antes y con más frecuencia

La simplificación de las pruebas de regresión con el análisis de impacto de las pruebas reduce considerablemente la carga general de las pruebas. Permite a los desarrolladores y evaluadores centrarse únicamente en el código y las pruebas afectados. ¿Los resultados?

• Más pruebas para aumentar la cobertura del código.
• Más ciclos para converger en un mejor producto.
• O una combinación de los dos.

Las pruebas de regresión ya no son una carga, sino un paso clave para mejorar la calidad y la seguridad del producto. Genera métricas para ayudar a medir la calidad, la seguridad y el progreso general.

Con soporte de herramientas de última generación y pruebas basadas en objetivos, también es posible comenzar las pruebas de regresión tan pronto como los desarrolladores creen el código. Cada nueva prueba unitaria se convierte en una prueba de regresión a lo largo del tiempo y los desarrolladores pueden aprovechar las pruebas basadas en cambios de inmediato.

Realizar pruebas de regresión de forma temprana (desplazándolas a la izquierda de la línea de tiempo de desarrollo) significa una detección más temprana de defectos. Cambiar a la izquierda ahorra tiempo y dinero de inmediato. Vale la pena aún más más adelante en el ciclo de vida del software.

No subestimes esta recompensa. Puede ahorrar costos significativos aguas abajo. La detección temprana de defectos en el SDLC reduce el costo de solucionarlos y reduce el impacto en las actividades posteriores. Mira el diagrama a continuación.

Resumen

Las pruebas de regresión son una actividad fundamental en las pruebas de software integrado. Cada característica, corrección de errores o cambio de configuración recién agregado requiere pruebas para confirmar lo que ya funciona y continúa funcionando. Sin embargo, a medida que crece un proyecto y crece la complejidad del software, también lo hace el número de pruebas de regresión.

Con el tiempo, la automatización de las pruebas se vuelve necesaria para ayudar a lidiar con la carga de las pruebas. La nueva tecnología, como la ejecución de pruebas inteligentes, facilita las pruebas de regresión. Impulsa a los desarrolladores y evaluadores a centrarse en las pruebas que prueban específicamente el código modificado y afectado.

La combinación de mejoras de procesos como Agile, CI/CD y DevOps con la automatización de pruebas de software hace posible comenzar las pruebas de regresión casi tan pronto como se escribe el código. Cambia efectivamente las pruebas a la izquierda y detecta errores antes cuando son más baratos y fáciles de corregir.