INTRODUCCIÓN A LA

VERIFICACION
Y
VALIDACION
VERIFICACION Y
VALIDACION DE SOFTWARE
 La validación y verificación (V y V) de
software se define como un conjunto de
procedimientos, actividades, técnicas y
herramientas que se utilizan, paralelamente al
desarrollo, para asegurar que un producto de
software cumpla con los requerimientos
planteados por los usuarios finales.
 El buen software depende de los detalles, en el
proceso de validación y verificación se pulen
los detalles y se atan los cabos sueltos.
VERIFICACION Y
VALIDACION DE SOFTWARE
 La visión del desarrollo de software, formada
por un conjunto de fases, no sólo facilita el
desarrollo, sino también el esfuerzo de la V y
V.
 Se puede dividir el esfuerzo de V y V indicando
las actividades, procedimientos y técnicas a
emplear en cada fase del ciclo de vida.
 Para ello es necesario definir un Plan de
Verificación y Validación de software al inicio
del proyecto que determine estas actividades.
Objetivos de la Verificación y
Validación de Software
 Detectar y corregir los defectos tan pronto como
sea posible en el ciclo de vida del software.
 Disminuir los riesgos, las desviaciones sobre los
presupuestos y sobre el programa de tiempos.
 Mejorar la calidad y fiabilidad del software.
 Mejorar la visibilidad de la gestión del proceso
de desarrollo.
 Valorar rápidamente los cambios propuestos y
sus consecuencias.
 Verificación vs Validación

 La validación tiene por objetivo

determinar la corrección del producto
final con respecto a las necesidades
planteadas por los usuarios finales.
 La verificación tiene por objetivo
demostrar la consistencia y corrección
del software entre las fases del ciclo
de desarrollo de un proyecto.
 Verificación vs Validación

 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.
 Verificación vs 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.
Verificación vs Validación
 Conceptos relacionados con la
VyV
 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.
 Error (errores): Es un error cometido por el desarrollador: Tipeo incorrecto;
malinterpretación de un requerimiento o la funcionalidad de un método; una
acción humana que conduzca a un resultado incorrecto; Por ejemplo divisiones
entre cero es un tipo de manifestación del defecto en el sistema que se ejecuta.
 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.
Relación entre Defecto, Error y Fallo
Lista de Fallos. Ejemplos
Lista de Fallos. Ejemplos
 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:

1. El enfoque estructurado o
de caja blanca.
2. 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

Locate Design Repair Re-test

error error repair error program
 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

Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing

Component Integration testing User

testing testing
 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

Requirements System System Detailed

specification specification desig n design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and tess

Acceptance System Sub-system

Service
test integration test 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

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

Test sequence Test sequence Test sequence

1 2 3
 Prueba top-down

Testing
Level 1 Level 1 . ..
sequence

Level 2 Level 2 Level 2 Level 2

Level 2
stubs

Level 3
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
Level N Level N Level N Level N Level N
sequence

Test
drivers
Level N–1 Level N–1 Level N–1
 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.
Fallas de Software
 Una falla de software ocurre cuando
un programa no cumple con las
especificaciones, es decir, con el
comportamiento esperado de dicho
programa.
Fallas de Software:
Caso de estudio 1
 El costo que producen las fallas del
software se puede apreciar en varios
casos de estudio:
 La explosión del ARIANE 5
ocasionada por un error de software
costó, a la Agencia Espacial Europea,
$370 millones
Fallas de Software:
Caso de estudio 2
 NASA Mars Climate Orbiter: For nine
months, the Mars Climate Orbiter was
speeding through space and speaking
to NASA in metric. But the engineers
on the ground were replying in non-
metric English ($125 millones
perdidos por una confusión de
unidades)
Fallas de Software:
Caso de estudio 3
 El costo de no poder poner un sistema en
producción debido a su baja calidad Un error
en el sistema de manejo de equipajes costó, al
aeropuerto de Denver en EEUU, más de $ 1.1
millones diarios.
 No pudieron abrir el nuevo aeropuerto a
tiempo, tuvieron que esperar hasta resolver el
problema, hacer que el sistema de manejo de
equipaje fuera estable les tomó más de 6
meses.
Fallas de Software:
Caso de estudio 4
 Este costo es incalculable cuando
estas fallas afectan la vida humana:
Una falla en el sistema de defensa
Patriot permitió que un misil SCUD
iraquí impactará una barraca de
soldados americanos en Dhahran
causando la muerte de 28 personas y
dejando 98 heridos.
Fallas de Software:
Caso de estudio 5
 Un ejemplo más dramático: desperfectos en el
software de la máquina de radioterapia Therac-
25 produjeron varias muertes por sobredosis.
 Si los operadores usaban lentamente a IU
entonces el software funcionaba
correctamente, en la medida en que los
operadores se volvieron más diestros usando el
software, comenzaron a utilizar más
rápidamente la IU lo que generó la falla.
 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.