Pruebas de regresión
De Wikipedia, la enciclopedia libre
Pruebas de Regresión son cualquier tipo de Pruebas de software las cuales buscan descubrir bugs de regresión. Los bugs de Regresión ocurren cuandoquiera que la funcionalidad del software que previamente funcionaba como era deseado para de funcionar de la misma forma en la cual fue planeada. Normalmente los bugs de regresión ocurren por consecuencias involuntarias de los cambios en el programa.
Los métodos comunes de las pruebas de regresión incluyen re-ejecutar previamente pruebas y comprobar si los fallos solucionados previamente han reaparecido.
La experiencia ha mostrado que cuando el software es desarrollado, este tipo de reaparición de fallos es bastante común. A veces ocurre porque una corrección se pierde a través de pobres practicas de control de revisión (o simples errores humanos en el control de revisión), pero a menudo una correción para un problema será "fragil" - por ejemplo si otro cambio se realiza sobre el programa, la corrección no seguirá funcionando. Finalmente, se ha dado el caso a menudo de que cuando alguna característica se rediseña, se realizan los mismos errores en el rediseño que se cometieron en la implementación original de la característica.
Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente después de los cambios subsiguientes que experimente el programa. Aunque esto puede hacerse a través de procedimientos de pruebas manuales usando técnicas de programación, ha menudo se hace usando herramientas de pruebas automatizadas. Una 'suite de pruebas'(test suite) contiene herramientas software que permiten al entorno de pruebas ejecutar todos los casos de pruebas de regresión automáticamente; algunos proyectos incluso configuran sistemas automatizados para re-ejecutar automáticamente todas las pruebas de regresión en intervalos específicos e informar de cualquier regresión. Las estrategias comunes son ejecutar tal sistema después de cada compilación exitosa (para proyectos pequeños), cada noche, o semanalmente.
Las pruebas de regresión son una parte integrante de la metodología de desarrollo de software Programación extrema. En esta metodología, los documentos de diseño son reemplazados por pruebas extensivas, repetibles y automatizadas del paquete de software completo en cada etapa en el ciclo de vida del desarrollo software.
Tabla de contenidos |
[editar] Tipos de regresión
- Local - cmabios introducen nuevos bugs
- Unmasked - cambios desenmascaran bugs existentes previos
- Remota - Cambiar una parte rompe otra parte del programa. Por ejemplo, el Módulo A escribe en una base de datos. El Módulo B lee de una base de datos. Si cambias para que el Módulo A escribe a la base de datos rompe el Módulo B, esto es una regresión remota.
Existe otra forma de clasificar regresión.
- Regresión de nueva característica - cambios al código que es nuevo para la release 1.1 rompe otro código que es nuevo para la release 1.1.
- Regresión de característica existente - cambios al códigi que es nuevo para la release 1.1 rompe código que existía en release 1.0.
[editar] Mitigando los riesgos de regresión
- Repetición completa de la suite de pruebas
- Automatización de las pruebas de regresión (GUI, API, CLI)
- Repetición de las pruebas parcial basándose en la trazabilidad y el análisis de los riesgos de negocio y técnicos
- Pruebas de usuario o cliente
- Beta - temprana release para clientes actuales y potenciales
- Piloto - desplegar a un subconjunto de usuarios
- Paralelas - usuarios usan los nuevos y viejos sistemas simultáneamente
- Usar releases mayores. Probar nuevas funciones a menudo cubre las funciones existentes. Cuantas más nuevas características haya en un release, habrá mayor nivel de pruebas de regresión "accidental".
- Parches de emergencia - estos parches se publican inmediatamente, y serán incluidos en releases de mantenimiento futuras.
[editar] Usos
Las Pruebas de Regresión pueden usarse no solo para probar la corrección de un programa, sino a menudo usarse para rastrear la calidad de su salida. Por ejemplo en el diseño de un compilador, las pruebas de regresión deben rastrear el tamaño del código, tiempo de simulación, y el tiempo de compilación de las suites de prueba. Cuando quiera que aparece un nuevo build, el proceso de regresión aparece.
[editar] Citas
- "También como consecuencia de la introducción de nuevos bugs, el mantenimiento del programa necesita más pruebas del sistema por sentencia escrita que cualquier otra programación. En teoría, después de cada corrección uno debe ejecutar el batch completo de casos de prueba antes de ejecutar contra el sistema, para asegurarse de que no ha sido dañado de forma oscura. En la práctica, tales pruebas de regresión deben aproximarse a esta idea teórica, y es muy costoso." -- Fred Brooks, The Mythical Man Month (p 122)
