2.2 Pruebas de Software

Son los procesos que permiten verificar y revelar la calidad de un producto software.

Las pruebas de software se integran dentro de las diferentes fases del Ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

Objetivos
– Encontrar defectos en el software
– Una prueba tiene éxito si descubre un defecto
– Una prueba fracasa si hay defectos pero no los descubre

La prueba de software es el proceso de ejecutar el software de manera controlada. Y usualmente se usa en conjunto con los términos verificación y validación.

Pruebas de Verificación
– Ver si cumple las especificaciones de diseño
Pruebas de Validación
– Ver si cumple los requisitos del análisis

Tipos de Pruebas

Pruebas de unidad
Es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.
Características
• Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continúa.
• Completas: deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.
Ventajas
• Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.
• Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
• Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
• Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.
• Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.
Limitaciones
Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.

Pruebas de integración
Son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez.
Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.
Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

Pruebas de validación
Son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?.

Enfoques a la verificación
• Dinámica de verificación, también conocido como ensayos o experimentación.
• Estática de verificación, también conocido como análisis.
Tipos
• Pruebas de aceptación: desarrolladas por el cliente.
• Pruebas alfa realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).
• Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores.
Características
Comprobar que se satisfacen los requisitos:
• Se usan la mismas técnicas, pero con otro objetivo.
• No hay programas de prueba, sino sólo el código final de la aplicación.
• Se prueba el programa completo.
• Uno o varios casos de prueba por cada requisito o caso de uso especificado.
• Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos).
• Pruebas alfa (desarrolladores) y beta (usuarios).

Pruebas de sistema
Cualquier pieza de software completo, desarrollado o adquirido, puede verse como un sistema que debe probarse, ya sea para decidir acerca de su aceptación, para analizar defectos globales o para estudiar aspectos específicos de su comportamiento, tales como seguridad o rendimiento.
• recuperación
• seguridad
• resistencia
• rendimiento

Técnicas de pruebas
Ayudan a definir conjuntos de casos de prueba aplicando un cierto criterio
Los casos de prueba quedarán determinados por los valores a asignar a las entradas en su ejecución

Técnicas de caja blanca
• Criterios basados en el contenido de los módulos
• El criterio de selección de casos de
- prueba buscará cierta cobertura
- caminos independientes
- valores de las condiciones
- bucles dentro y fuera de sus límites operacionales
- estructuras de datos
- los errores se esconden en los rincones y se acumulan en las fronteras

Técnicas de caja negra
• Criterios basados en las interfaces y las especificaciones de los módulos
• Permiten detectar
- funcionamiento incorrecto o incompleto
- errores interface
- errores accesos estructuras de datos externas
- problemas de rendimiento
- errores de inicio y terminación
Cobertura
- valores representativos de conjuntos de datos
- fronteras, valores o combinaciones de valores conflictivos
- capacidad de proceso

Pruebas de regresión
Intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Tipos de regresión
• Clasificación de ámbito
- Local: los cambios introducen nuevos errores.
- Desenmascarada: los cambios revelan errores previos.
• Remota: Los cambios vinculan alguna otra parte del programa (módulo) e introducen errores en ella.
• Clasificación temporal
- Nueva característica: los cambios realizados con respecto a nuevas funcionalidades en la versión introducen errores en otras novedades en la misma versión del software.
- Característica preexistente: los cambios realizados con respecto a nuevas funcionalidades introducen errores en funcionalidad existente de previas versiones.
Usos
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.

La importancia de la detección oportuna de errores en el sistema

En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras antes se detecte una falla, más barato es su correción.