INTRODUCCIN A LA

VERIFICACION
Y
VALIDACION
 Verificacin y Validacin
Objetivos
Introducir los conceptos de :
verificacin del proceso de software.
validacin del producto de software.
Describir las fases del proceso de
pruebas.
Explicar la importancia de la planificacin
de las pruebas.
Describir estrategias complementarias de
prueba.
Verificacin y Validacin
Tpicos
El proceso de prueba.
Planificacin de las pruebas.
Estrategias de prueba.
 Verificacin v/s Validacin
Verificacin:
El producto se esta construyendo en
forma correcta ?"
El proceso de desarrollo debe estar
conforme con sus sus estndares o
prcticas de desarrollo.
Cmo Verificar ?
Qu caratersticas del proceso de
desarrollo se deben verificar ?
 Verificacin v/s Validacin
Validacin
"Se esta construyendo el producto correcto?"
El software debe hacer lo que el usuario
requiere, debe haber concordancia con :
la especificacin de requisitos.
La satisfaccin de necesidades del cliente.
Cmo ?
Qu caractersticas del software debemos
validar?
Podemos ?
Introduccin
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 evaluacin de algn aspecto.
Casos de Pruebas: un conjunto de entradas, condiciones de
ejecucin y resultados esperados desarrollados para un objetivo
particular.
Defecto (bug): un defecto en el software como, por ejemplo, un
proceso, una definicin 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 situacin
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,

prcticamente, 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 sntomas 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 vlidos y esperados como no vlidos 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 nmero de defectos
ya descubierto.
Las pruebas son una tarea tanto o ms
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
sntomas de la presencia de uno o mas
errores.
Tcnicas de diseo de pruebas
Imposibilidad de Prueba Exhaustiva del
Software:
Se deben seguir determinados criterios para
seleccionar los casos de prueba
Objetivo Tcnicas Diseo de Pruebas:
Garantizar con el mayor grado de confianza
posible en que se detectarn los defectos
del software.
Equilibro entre Recursos y Garanta para
descubrir los defectos existentes
Tcnicas de diseo de pruebas
Existen dos enfoques clsicos:

1. El enfoque estructurado o
de caja blanca.
2. El enfoque funcional o de
caja negra.
 Algunos tipos de pruebas
Prueba de defectos
Pruebas diseadas para descubrir defectos
en el sistema.
Un prueba de defectos exitosa es aquella
que revela la presencia de defectos en el
sistema.
 Prueba y depuracin
La prueba de defectos y la depuracin son
distintos procesos.
La prueba de defectos se refiere a la
confirmacin de la presencia de errores.
La depuracin se refiere a la localizacin y
reparacin de estos errores.
 El proceso de depuracin

Locate Design Repair Retest

error errorrepair error program
 Fases de prueba
Pruebas de Unidad
prueba de componentes individuales
Prueba de Mdulo
prueba de conjuntos de componentes dependientes
Prueba de sub-sistemas ( Integracin )
prueba de colecciones de mdulos integrados en sub-
sistemas
Prueba del sistema
prueba del sistema completo.
Prueba de aceptacin
pruebas de los usuarios para verificar que el sistema cumple
con los requerimientos.
Llamado en ocasiones prueba alfa.
 El proceso de pruebas

Unit
testing
Module
testing
Subsystem
testing
System
testing
Acceptance
testing

Component Integrationtesting User

testing testing
 Planificacin de las pruebas
Describe las fases principales del proceso
de pruebas.
Describe el seguimiento de las pruebas a
los requerimientos.
Estimar la planificacin general y la
necesidad de recursos.
Describir el mtodo 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 Clsico

Requirements System System Detailed

specification specification desig n design

System Subsystem Moduleand

Acceptance
integration integration unitcode
testplan
testplan testplan andtess

Acceptance System Subsystem

Service
test integrationtest integrationtest
 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
n Pruebas top-down
n Pruebas bottom-up
n Prueba de estres
 Prueba incremental

A T1
T1
A
T1 T2
A B
T2
T2 B T3
T3
B C
T3 T4
C
T4
D T5

Testsequence Testsequence Testsequence

1 2 3
 Prueba top-down

Testing
Level1 Level1 ...
sequence

Level2 Level2 Level2 Level2

Level2
stubs

Level3
stubs
 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

Test
drivers
Testing
LevelN LevelN LevelN LevelN LevelN
sequence

Test
drivers
LevelN1 LevelN1 LevelN1
 Pruebas bottom-up

Son necesarias para componentes crticos.

Comienza con los niveles inferiores y se
mueven hacia los niveles superiores del
sistema.
Solo encuentra problemas de diseo 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 estrs verifica prdidas
inaceptables de servicio o datos.
Particularmente relevante en sistemas
distribuidos que presentan una degradacin
severa cuando la red se sobre carga.
 Resumen

Verificacin y validacin 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 mdulos, prueba de sub-
sistemas, prueba de integracin y
prueba de aceptacin.
 Resumen

Las pruebas deben ser planificadas

como parte del proceso de
planeacin. Deben estar disponibles
los recursos necesarios
Deben disearse planes de pruebas
para guiar el proceso de pruebas
Las estrategias de pruebas son :
pruebas top-down, pruebas bottom-
up, pruebas de estrs, entre otras.