INTRODUCCIÓN A LA VERIFICACION Y VALIDACION

Verificación y Validación Objetivos Introducir los conceptos de : verificación del proceso de software. validación del producto de software. Describir las fases del proceso de pruebas. Explicar la importancia de la planificación de las pruebas. Describir estrategias complementarias de prueba.

Verificación y Validación Tópicos El proceso de prueba. Planificación de las pruebas. Estrategias de prueba.

Verificación v/s Validación ”El producto se esta construyendo en forma correcta ?" El proceso de desarrollo debe estar conforme con sus sus estándares o prácticas de desarrollo. Cómo Verificar ? Qué caraterísticas del proceso de desarrollo se deben verificar ?

Verificación v/s Validación "Se esta construyendo el producto correcto?" El software debe hacer lo que el usuario requiere, debe haber concordancia con : la especificación de requisitos. La satisfacción de necesidades del cliente. ¿Cómo ? ¿Qué características del software debemos validar? ¿Podemos ?

Introducción Conceptos relacionados Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto. Casos de Pruebas: un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular. Defecto (bug): un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa. Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

El proceso V & V Cubre todo el ciclo de vida V & V debe aplicarse en cada fase del proceso de software Tiene dos objetivos principales El descubrimiento de defectos en el sistema. El aseguramiento de que el sistema será útil o no, en una determinada situación operacional

Objetivos y/o recomendaciones Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo): Probar si el software no hace lo que debe hacer. Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios. No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas.

Objetivos y/o recomendaciones El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos. Cada caso de prueba debe definir el resultado de salida esperado. Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados

Objetivos y/o recomendaciones La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto. Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.

Prueba de programas Permite revelar la presencia de errores, no su ausencia. Una prueba exitosa consiste en detectar síntomas de la presencia de uno o mas errores.

Técnicas de diseño de pruebas Imposibilidad de Prueba Exhaustiva del Software: Se deben seguir determinados criterios para seleccionar los casos de prueba Objetivo Técnicas Diseño de Pruebas: Garantizar con el mayor grado de confianza posible en que se detectarán los defectos del software. Equilibro entre Recursos y Garantía para descubrir los defectos existentes

Técnicas de diseño de pruebas Existen dos enfoques clásicos: El enfoque estructurado o de caja blanca. El enfoque funcional o de caja negra.

Algunos tipos de pruebas Prueba de defectos Pruebas diseñadas para descubrir defectos en el sistema. Un prueba de defectos exitosa es aquella que revela la presencia de defectos en el sistema.

Prueba y depuración La prueba de defectos y la depuración son distintos procesos. La prueba de defectos se refiere a la confirmación de la presencia de errores. La depuración se refiere a la localización y reparación de estos errores.

El proceso de depuración

Fases de prueba Pruebas de Unidad prueba de componentes individuales Prueba de Módulo prueba de conjuntos de componentes dependientes Prueba de sub-sistemas ( Integración ) prueba de colecciones de módulos integrados en sub-sistemas Prueba del sistema prueba del sistema completo. Prueba de aceptación pruebas de los usuarios para verificar que el sistema cumple con los requerimientos. Llamado en ocasiones prueba alfa.

El proceso de pruebas

Planificación de las pruebas Describe las fases principales del proceso de pruebas. Describe el seguimiento de las pruebas a los requerimientos. Estimar la planificación general y la necesidad de recursos. Describir el método usado para archivar los resultados de las pruebas

El plan de pruebas El proceso de pruebas. El seguimiento (traceability) de los requerimientos. Componentes probados. El calendario de las pruebas. Los procedimientos para archivar pruebas. Los requerimientos del hardware y software. Las restricciones.

El modelo Clásico

Algunas Estrategias de prueba Las estrategias de pruebas son formas de enfocar el proceso de pruebas Distintas estrategias pueden aplicarse para las distintas fases del proceso de pruebas Estrategias consideradas Pruebas top-down Pruebas bottom-up Prueba de estres

Prueba incremental

Prueba top-down

Prueba top-down Comienza con los altos niveles del sistema y sigue hacia los niveles inferiores. Es una estrategia de pruebas que es usada junto con el desarrollo denominados “top-down”

Pruebas “bottom-up”

Pruebas bottom-up Son necesarias para componentes críticos. Comienza con los niveles inferiores y se mueven hacia los niveles superiores del sistema. Solo encuentra problemas de diseño hasta muy avanzado el proceso.

Prueba de estres Ejercita el sistema mas allá de los limites de carga del sistema. Esta prueba causa que los defectos surjan. Al estresar el sistema se prueba el comportamiento frente a fallas (tolerancia). La prueba de estrés verifica pérdidas inaceptables de servicio o datos. Particularmente relevante en sistemas distribuidos que presentan una degradación severa cuando la red se sobre carga.

Resumen Verificación y validación no son lo mismo. Las pruebas son usadas para establecer la presencia de defectos. Las actividades necesarias en las pruebas son prueba de unidades, prueba de módulos, prueba de sub-sistemas, prueba de integración y prueba de aceptación.

Resumen Las pruebas deben ser planificadas como parte del proceso de planeación. Deben estar disponibles los recursos necesarios Deben diseñarse planes de pruebas para guiar el proceso de pruebas Las estrategias de pruebas son : pruebas top-down, pruebas bottom-up, pruebas de estrés, entre otras.