INTRODUCCIÓN A LAVERIFICACION

YVALIDACION

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: ”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

Verificación v/s Validación

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.

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

El proceso V & V

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.

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.

Prueba de programas

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:

1. El enfoque estructurado o de caja blanca.

2. El enfoque funcional o de caja negra.

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.

Algunos tipos de pruebas

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.

Prueba y depuración

El proceso de depuración

Locateerror

Designerror repair

Repairerror

Re-testprogram

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.

Fases de prueba

El proceso de pruebas

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptancetesting

Componenttesting

Integration testing Usertesting

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

Planificación 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

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

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

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence1

Test sequence2

Test sequence3

Prueba top-down

Level 2Level 2Level 2Level 2

Level 1 Level 1Testing

sequence

Level 2stubs

Level 3stubs

. . .

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”

Level NLevel NLevel NLevel NLevel N

Level N–1 Level N–1Level N–1

Testingsequence

Testdrivers

Testdrivers

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.

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.

Prueba de estres

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.