X
BLOG

Prueba de regresión de sistemas integrados

Prueba de regresión de sistemas integrados Tiempo de leer: 7 minutos

Los equipos de desarrollo realizan pruebas de regresión para verificar que los cambios de código (corregir un error o agregar una nueva funcionalidad) en una aplicación de software no provoquen 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?

A regresión es "una tendencia o cambio hacia un estado inferior o menos que perfecto", que es lo que todos intentamos evitar a medida que desarrollamos software. Las pruebas de regresión ayudan a encontrar defectos que se infiltran en nuestro software a medida que agregamos nuevas funciones, corrigimos errores y al realizar cambios en los propios 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 confiable.

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.

Infografía que muestra cómo las nuevas pruebas unitarias se convierten en pruebas de regresión después de la validación y las pruebas de regresión son las pruebas acumuladas a lo largo del tiempo.
Cada nueva prueba unitaria, una vez validada, se convierte en una prueba de regresión futura. Las pruebas de regresión son pruebas acumuladas a lo largo del tiempo.

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, poner en marcha una solución de automatización de pruebas reutilizable y configurable que pueda realizar una transición sin problemas de forma continua desde la ejecución en un host y / o un sistema virtual, y para verificación y validación en el sistema de destino: proporciona ahorros significativos en recursos, tiempo y costos.

Los equipos de desarrollo pueden usar la prueba Parasoft C / C ++ para ejecutar pruebas unitarias en la plataforma host, el simulador de procesador de destino o el destino integrado. Optimizado para tener una sobrecarga adicional mínima para la huella binaria o los ciclos de proceso, el arnés de prueba de Parasoft C / C ++ viene en forma de código fuente. Eso significa que los equipos pueden personalizar las modificaciones específicas de la plataforma necesarias. 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 de seguridad y protección y lo requieren los estándares de proceso como DO-178B / C, ISO 26262, IEC 62304, y más.

Infografía que muestra una vista de alto nivel de la implementación, ejecución y observación de pruebas desde el host hasta el destino en la prueba de Parasoft C / C ++.
Una vista de alto nivel de la implementación, ejecución y observación de pruebas desde el host hasta el destino en la prueba de Parasoft C / C ++.

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.

¿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 empresa y reduce la productividad del equipo. Esta incapacidad para concentrarse en las pruebas obstaculiza gran parte de los beneficios de los procesos iterativos y continuos, lo que puede agravarse en el software integrado donde los objetivos de las pruebas son un recurso limitado.

Lo que se necesita es una forma de identificar qué pruebas deben volver a ejecutarse y centrar los esfuerzos de prueba (pruebas unitarias, pruebas funcionales automatizadas y pruebas manuales) en la validación de 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 ++, Jtest para Java, y dotTEST para C #) y Process Intelligence Engine (PIE) dentro Parasoft DTP, los desarrolladores y evaluadores pueden comprender los cambios en la base del código entre compilaciones y, con esta eficiencia mejorada, cumplir la promesa de Agile. Esta forma de ejecución de prueba inteligente se denomina análisis de impacto de prueba (a veces denominado prueba basada 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 C / C ++ test, Jtest y dotTest proporcionan 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.

Captura de pantalla del informe de prueba basado en cambios de Parasoft DTP que muestra las áreas del código que se probaron y no se probaron.
Un ejemplo de un informe de prueba basado en cambios de Parasoft DTP. Muestra áreas del código que se prueban y no se prueban.

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 subestime esta recompensa. Puede ahorrar importantes costes posteriores. La detección temprana de defectos en el SDLC reduce el costo de reparación y reduce el impacto en las actividades posteriores. Mira el diagrama a continuación.

Gráfico animado. Jones, alcaparras. Medición de Software Aplicado: Análisis Global de Productividad y Calidad. Muestra los defectos encontrados desplazarse a la izquierda.

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 iniciar las pruebas de regresión casi tan pronto como se escribe el código. Efectivamente desplaza las pruebas hacia la izquierda y detecta errores antes cuando son más baratos y fáciles de corregir.

Descargas de llamadas a la acción whitepaper Optimización de las pruebas unitarias para sistemas integrados y críticos para la seguridad

Escrito por

Ricardo Camacho

Gerente sénior de marketing técnico de productos para las soluciones de pruebas integradas de Parasoft. Ricardo tiene experiencia en SDLC y automatización de pruebas de aplicaciones integradas en tiempo real, de seguridad y críticas, y cumplimiento de software con los estándares de la industria.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft