Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Verificacion Validacion PDF
Verificacion Validacion PDF
2008 V&V 1
Verificacin y Validacin
Temario
Introduccin
Proceso de V&V
Verificacin Unitaria
o Tcnicas Estticas (anlisis)
o Ejecucin Simblica
o Tcnicas Dinmicas (pruebas)
Pruebas de Integracin
Pruebas de Sistemas Orientados a Objetos
Pruebas de Sistema
Herramientas
Planificacin de V&V
2008 Terminacin de la prueba V&V 2
Introduccin
Temario
Errores, faltas y fallas.
Objetivos y definicin de V&V
Ejemplo
Tipos de faltas
Clasificacin de defectos
2008 V&V 3
Introduccin
Errores, Faltas y Fallas
2008 V&V 4
Introduccin
Fallas del Software
El software fall?
No hace lo requerido (o hace algo que no debera)
Razones:
Las especificaciones no estipulan exactamente lo que el
cliente precisa o quiere (reqs. faltantes o incorrectos)
Requerimiento no se puede implementar
Faltas en el diseo
Faltas en el cdigo
2008 V&V 6
Introduccin
Identificacin y Correccin de
Defectos
Identificacin de defectos
Es el proceso de determinar que defecto o defectos
causaron la falla
Correccin de defectos
Es el proceso de cambiar el sistema para remover los
defectos
2008 V&V 7
Introduccin
Definicin de V&V
Sommerville
Verificacin
o Busca comprobar que el sistema cumple con los requerimientos
especificados (funcionales y no funcionales)
o El software est de acuerdo con su especificacin?
Validacin
o Busca comprobar que el software hace lo que el usuario espera.
o El software cumple las expectativas del cliente?
2008 V&V 8
Introduccin
Definicin de V&V
Boehm
Verificacin
o Estamos construyendo el producto correctamente?
Validacin
o Estamos construyendo el producto correcto?
Ghezzi
Verificacin
o Todas las actividades que son llevadas a cabo para averiguar si el
software cumple con sus objetivos
2008 V&V 9
Introduccin
Definicin de V&V
IEEE
Verificacin
o The process of evaluating a system or component to determine
whether the products of a given development phase satisfy the
conditions imposed at the start of the phase
Validacin
o The process of evaluating a system or component during or at the
end of the development process to determine whether it satisfies
specified requirements
2008 V&V 10
Introduccin
Ejemplo
El programa lee tres nmeros enteros, los que son
interpretados como representaciones de las
longitudes de los lados de un tringulo. El programa
escribe un mensaje que informa si el tringulo es
escaleno, issceles o equiltero
Quiero detectar defectos probando (testeando) el
programa
Posibles casos a probar:
lado1 = 0, lado2 = 1, lado3 = 0 Resultado = error
lado1 = 2, lado2 = 2, lado3 = 3 Resultado = issceles
Estos son Casos de Prueba
2008 V&V 11
Introduccin
Ejemplo
Comparo el resultado esperado con el obtenido
Si son distintos probablemente haya fallado el programa
Intuitivamente que otros casos sera bueno probar
lado1 = 2, lado2 = 3, lado3 = 4 Resultado = escaleno
lado1 = 2, lado2 = 2, lado3 = 2 Resultado = equiltero
Porqu estos casos?
o Al menos prob un caso para cada respuesta posible del programa
(error, escaleno, issceles, equiltero)
o Ms adelante veremos tcnicas para seleccionar casos
interesantes
2008 V&V 12
Introduccin
Ejemplo
Otra forma para detectar defectos es revisar el
cdigo
If l1 = l2 or l2 = l3 then
write (equiltero)
else ...
En lugar del or me doy cuenta que debera ir un and
Se puede revisar solo
Se puede revisar en grupos
o Veremos ms adelante tcnicas conocidas para revisiones en
grupo
2008 V&V 13
Introduccin
Tipos de Faltas
en algoritmos
de sintaxis
de precisin y clculo
de documentacin
de estrs o sobrecarga
de capacidad o de borde
de sincronizacin o coordinacin
de capacidad de procesamiento o desempeo
de recuperacin
de estndares y procedimientos
relativos al hardware o software del sistema
2008 V&V 14
Introduccin
Tipos de Faltas
En algoritmos
Faltas tpicas
o Bifurcar a destiempo
o Preguntar por la condicin equivocada
o No inicializar variables
o No evaluar una condicin particular
o Comparar variables de tipos no adecuados
De sintaxis
Ejemplo: Confundir un 0 por una O
Los compiladores detectan la mayora
2008 V&V 15
Introduccin
Tipos de Faltas
De precisin o de clculo
Faltas tpicas
o Formulas no implementadas correctamente
o No entender el orden correcto de las operaciones
o Faltas de precisin como un truncamiento no esperado
De documentacin
La documentacin no es consistente con lo que hace el
software
Ejemplo: El manual de usuario tiene un ejemplo que no
funciona en el sistema
2008 V&V 16
Introduccin
Tipos de Faltas
De estrs o sobrecarga
Exceder el tamao mximo de un rea de almacenamiento
intermedio
Ejemplos
o El sistema funciona bien con 100 usuarios pero no con 110
o Sistema que funciona bien al principio del da y se va degradando
paulatinamente el desempeo hasta ser espantoso al caer la
tarde. Falta: haba tareas que no liberaban memoria
De capacidad o de borde
Ms de lo que el sistema puede manejar
Ejemplos
o El sistema funciona bien con importes <1000000
o Ao 2000. sistema trata bien fechas hasta el 31/12/99
2008 V&V 17
Introduccin
Tipos de Faltas
De sincronizacin o coordinacin
No cumplir requerimiento de tiempo o frecuencia.
Ejemplo
o Comunicacin entre procesos con faltas
De capacidad de procesamiento o desempeo
No terminar el trabajo en el tiempo requerido
Tiempo de respuesta inadecuado
De recuperacin
No poder volver a un estado normal luego de una falla
2008 V&V 18
Introduccin
Tipos de Faltas
De estndares o procedimientos
No cumplir con la definicin de estndares y/o
procedimientos
De hardware o software del sistema
Incompatibilidad entre componentes
2008 V&V 19
Introduccin
Clasificacin de Defectos
Categorizar y registrar los tipos de defectos
Gua para orientar la verificacin
o Si conozco los tipos de defectos en que incurre la organizacin me
puedo ocupar de buscarlos expresamente
Mejorar el proceso
o Si tengo identificada la fase en la cual se introducen muchos
defectos me ocupo de mejorarla
Clasificacin Ortogonal
Cada defecto queda en una nica categora
Si pudiera quedar en ms de una de poco servira
2008 V&V 20
Introduccin
Clasificacin de Defectos
Clasificacin Ortogonal de IBM
Funcin: afecta capacidad de brindarla, interfaz usuario, de
producto, con hardware o estructura global de datos
Interfaz: al interactuar con otros componentes o drivers va call,
macros, control blocks o lista de parmetros
Validacin: no valida de forma adecuada los datos antes de usarlos
Asignacin: falta en inicializacin de estructura de datos o bloque
Tiempo/serializacin: recursos compartidos o tiempo real
Build/package/merge: problemas en repositorios, control de
cambios o versiones
Documentacin: publicaciones o notas de mantenimiento
Algoritmo: involucra eficiencia o correctitud de algoritmo o
estructura de datos, pero no diseo
2008 V&V 21
Introduccin
Clasificacin de Defectos - HP
ORIGEN: POR QU?
Especificacin Diseo Codific. Ambiente/ Documentacin Otro
Requerimientos soporte
o (entre) Procesos
Interfaz SW Clculo
Especificaciones SW de Test
Definicin
Interfaz Usuario Manejo de Datos
de Datos
Funcionalidad Descripcin Interfaz Mdulo SW Integracin
Diseo de
Funcional /
Mdulo
implementacin Herramientas
Descripcin de desarrollo
de Lgica Estndares
Control de Errores
Estndares
MODO:
FORMA? Falta Oscuro Mal Cambiado Mejor manera
2008 V&V 22
Introduccin
Faltas en un departamento de HP
Otros Cdigo Manejo Datos
11% 6%
Documentacin
19%
Clculo
18%
Requerimientos
5%
Hardware
4%
Proceso/
Lgica entre procesos
32%
5%
2008 V&V 23
Proceso de V&V
Temario
Proceso y pruebas en el proceso
Quin verifica?
Actitudes respecto a la verificacin
2008 V&V 24
Proceso de V&V
Proceso
Unit Especifi- Requerimien- Otros Especificacin Ambiente
caciones tos Requeri- de Requeri- de Uso
de Diseo funcionales mientos del mientos
Component code
Unit
.
. Prueba Prueba Prueba Prueba Prueba
componente verificado
Unit
SISTEMA
EN USO
Visin simplificada....
2008 V&V 25
Proceso de V&V
Pruebas en el Proceso
Mdulo, Componente o unitaria
Verifica las funciones de los componentes
Integracin
Verifica que los componentes trabajan juntos como un
sistema integrado
Funcional
Determina si el sistema integrado cumple las funciones de
acuerdo a los requerimientos
2008 V&V 26
Proceso de V&V
Pruebas en el Proceso
Desempeo
Determina si el sistema integrado, en el ambiente objetivo
cumple los requerimientos de tiempo de respuesta,
capacidad de proceso y volmenes
Aceptacin
Bajo la supervisin del cliente, verificar si el sistema
cumple con los requerimientos del cliente (y lo satisface)
Validacin del sistema
Instalacin
El sistema queda instalado en el ambiente de trabajo del
cliente y funciona correctamente
2008 V&V 27
Proceso de V&V
Quin Verifica?
Pruebas Unitarias
Normalmente las realiza el equipo de desarrollo. En
general la misma persona que lo implement.
Es positivo el conocimiento detallado del mdulo a probar
Pruebas de Integracin
Normalmente las realiza el equipo de desarrollo
Es necesario el conocimiento de las interfaces y funciones
en general
Resto de las pruebas
En general un equipo especializado (verificadores)
Es necesario conocer los requerimientos y tener una visin
global
2008 V&V 28
Proceso de V&V
Quin Verifica?
Por qu un equipo especializado?
Maneja mejor las tcnicas de pruebas
Conoce los errores ms comunes realizados por el equipo
de programadores
Problemas de psicologa de pruebas
o El autor de un programa tiende a cometer los mismos errores al
probarlo
o Debido a que es SU programa inconcientemente tiende a hacer
casos de prueba que no hagan fallar al mismo
o Puede llegar a comparar mal el resultado esperado con el
resultado obtenido debido al deseo de que el programa pase las
pruebas
2008 V&V 29
Proceso de V&V
Actitudes Respecto a la
Verificacin
Qu sabemos de un programa si pas
exitosamente un conjunto de pruebas?
Orgullo de nuestra obra (como programador) no es
mi culpa
Conflictos posibles entre
encargado de verificacin (encontrar faltas)
Desarrollador (mostrar las bondades de su obra)
Soluciones:
Trabajo en equipo (roles distintos, igual objetivo)
Se evala al producto (no la persona)
Voluntad de Mejora (personal y del equipo)
2008 V&V 30
Verificacin Unitaria
Temario
Tcnicas de verificacin unitaria
Tcnicas estticas - Anlisis
o Anlisis de cdigo fuente
o Anlisis automatizado de cdigo fuente
o Anlisis formal
Ejecucin simblica
Tcnicas dinmicas Pruebas
o Definiciones, proceso para un mdulo, conceptos bsicos, teora
o Caja Blanca
o Caja Negra
Comparacin de las tcnicas
2008 V&V 31
Verificacin unitaria
Tcnicas de Verificacin Unitaria
Tcnicas estticas (analticas)
Analizar el producto para deducir su correcta operacin
Ejecucin simblica
Tcnica hbrida
2008 V&V 32
Verificacin unitaria
Tcnicas Estticas
Anlisis de cdigo
Se revisa el cdigo buscando defectos
Se puede llevar a cabo en grupos
Recorridas e Inspecciones (tcnicas conocidas con
resultados conocidos)
Anlisis automatizado de cdigo fuente
La entrada es el cdigo fuente del programa y la salida es
una serie de defectos detectados
Verificacin formal
Se parte de una especificacin formal y se busca probar
(demostrar) que el programa cumple con la misma
2008 V&V 33
V. U. - Anlisis
Anlisis de Cdigo
Se revisa el cdigo buscando problemas en
algoritmos y otras faltas
Algunas tcnicas:
Revisin de escritorio
Recorridas e Inspecciones
o Criticar al producto y no a la persona
o Permiten
Unificar el estilo de programacin
Igualar hacia arriba la forma de programar
o No deben usarse para evaluar a los programadores
2008 V&V 34
V. U. - Anlisis
Anlisis de Cdigo
Recorridas
Se simula la ejecucin de cdigo para descubrir faltas
Nmero reducido de personas
Los participantes reciben antes el cdigo fuente
Las reuniones no duran ms de dos horas
El foco est en detectar faltas y no en corregirlas
Los roles clave son:
o Autor: Presenta y explica el cdigo
o Moderador: Organiza la discusin
o Secretario: Escribe el reporte de la reunin para entregarle al
autor
El autor es el que se encarga de la ejecucin del cdigo
2008 V&V 35
V. U. - Anlisis
Anlisis de Cdigo
Inspecciones
Se examina el cdigo (no solo aplicables al cdigo)
buscando faltas comunes
Se usa una lista de faltas comunes (check-list). Estas listas
dependen del lenguaje de programacin y de la
organizacin. Por ejemplo revisan:
o Uso de variables no inicializadas
o Asignaciones de tipos no compatibles
Los roles son: Moderador o Encargado de la Inspeccin,
Secretario, Lector, Inspector y Autor
Todos son Inspectores. Es comn que una persona tenga
ms de un rol
Algunos estudios indican que el rol del Lector no es
2008 necesario V&V 36
V. U. - Anlisis
Anlisis de Cdigo
Proceso de la Inspeccin
Planeacin Seguimiento
Visin de
Correccin
Conjunto
Preparacin Reunin de
Seleccionar
Individual Inspeccin
equipo de Correccin por
inspeccin. parte del autor
Asegurar que del cdigo
Bsqueda de
el material Presentacin defectos de
est completo del programa forma Dedicada Es necesaria
individual solamente a otra inspeccin?
Objetivos del
detectar Tarea del
programa
defectos Moderador
2008 V&V 37
V. U. - Anlisis
Anlisis de Cdigo
En un estudio de Fagan:
Con Inspeccin se detect el 67% de las faltas detectadas
Al usar Inspeccin de Cdigo se tuvieron 38% menos
fallas (durante los primeros 7 meses de operacin) que
usando recorridas
Ackerman et. al.:
reportaron que 93% de todas las faltas en aplicacin de
negocios fueron detectadas a partir de inspecciones
Jones:
report que inspecciones de cdigo permitieron detectar
85% del total de faltas detectadas
2008 V&V 38
V. U. - Anlisis
Anlisis Automatizado
Herramientas de software que recorren cdigo
fuente y detectan posibles anomalas y faltas
No requieren ejecucin del cdigo a analizar
Es mayormente un anlisis sintctico:
Instrucciones bien formadas
Inferencias sobre el flujo de control
Complementan al compilador
Ejemplo
a := a + 1 El analizador detecta que se asigna dos veces
a := 2 la variable sin usarla entre las asignaciones
2008 V&V 39
V. U. - Anlisis
Anlisis Formal
Un programa es correcto si cumple con la
especificacin
Se busca demostrar que el programa es correcto a
partir de una especificacin formal
Objeciones
Demostracin ms larga (y compleja) que el propio
programa
La demostracin puede ser incorrecta
Demasiada matemtica para el programador medio
No se consideran limitaciones del hardware
La especificacin puede ser incorrecta igual hay que
validar mediante pruebas. Esto ocurre siempre (nada es
2008 100% seguro) V&V 40
V. U. - Anlisis
Anlisis Formal
Que sea la mquina la que demuestre
Desarrollar herramientas que tomen:
Especificacin formal
Cdigo del componente a verificar
Responda al usuario:
(1) el componente es correcto o
(2) muestre un contraejemplo para mostrar que la entrada
no se transforma de forma adecuada en la salida
Esta herramienta no puede ser construida (problema
de la parada) Demostracin Asistida
2008 V&V 41
Verificacin Unitaria
Ejecucin Simblica
Ejemplo:
read(a); read(a);
read(b); [a = A] VALOR SIMBLICO
x := a + 1; read(b);
y := x * b; [a = A, b = B]
write(y); x := a + 1;
[a = A, b = B, x = A + 1]
y := x * b;
[a = A, b = B, x = A + 1, y = (A + 1) * B]
write(y);
[se despliega el valor (A + 1) * B]
2008 V&V 42
Verificacin Unitaria
Ejecucin Simblica
Ejemplo 2:
[x = X, a = A, y = Y]
x := y + 2;
[x = Y + 2, a = A, y = Y]
if x > a then ES Y + 2 > A?
a := a + 2;
else
y := x + 3; HACEMOS CADA CASO Y
[x = Y + 2, a = A, y = Y + 5] [Y + 2 <= A] REGISTRAMOS LAS
end if CONDICIONES ASUMIDAS
x := x + a + y;
[x = 2Y + A + 7, a = A, y = Y + 5] [Y + 2 <= A]
2008 V&V 43
Verificacin Unitaria
Ejecucin Simblica
El resultado es ms genrico que las pruebas
Es experimental
Tiene problemas de escala
Qu pasa con las interfaces grficas?
Y con SQL?
2008 V&V 44
V. U. - Prueba
Algunas Definiciones
Prueba (test)
Proceso de ejecutar un programa con el fin de encontrar
fallas (G. Myers)
Ejecutar un producto para:
o Verificar que satisface los requerimientos
o Identificar diferencias entre el comportamiento real y el esperado
(IEEE)
Caso de Prueba (test case)
Datos de entrada, condiciones de ejecucin y resultado
esperado (RUP)
Conjunto de Prueba (test set)
Conjunto de casos de prueba
2008 V&V 45
V. U. - Prueba
Visin de los Objetos a Probar
Caja Negra
Entrada a una caja negra de la que no se conoce el
contenido y ver que salida genera
o Casos de prueba - No se precisa disponer del cdigo
o Se parte de los requerimientos y/o especificacin
o Porciones enteras de cdigo pueden quedar sin ejercitar
Caja Blanca
A partir del cdigo identificar los casos de prueba
interesantes
o Casos de prueba Se necesita disponer del cdigo
o Tiene en cuenta las caractersticas de la implementacin
o Puede llevar a soslayar algn requerimiento no implementado
2008 V&V 46
V. U. - Prueba
Un Proceso para un Mdulo
Especificar
Mdulo Plan de Prueba (Caja Negra)
Implementar Revisin
2008 V&V 47
V. U. - Prueba
Conceptos Bsicos
Es imposible realizar pruebas exhaustivas y probar
todas las posibles secuencias de ejecucin
2008 V&V 48
V. U. - Prueba
Conceptos Bsicos
El test debe ayudar a localizar faltas y no solo a
detectar su presencia
El test debe ser repetible
En programas concurrentes es difcil de lograr
Cmo se hacen las pruebas?
Se ejecuta el caso de prueba y se compara el resultado
esperado con el obtenido.
2008 V&V 49
V. U. - Prueba
Fundamentos Tericos
Consideremos a un programa P como una funcin
(posiblemente parcial) con dominio D (entradas de
P) y codominio R (salidas de P)
Sean RS los requerimientos sobre la salida de P
Para cierto d D decimos que P es correcto para d
si P(d) satisface RS. P es correcto sii es correcto
para todo d en D
Un caso de prueba es un elemento d de D
Un conjunto de prueba es un conjunto finito de
casos de prueba
2008 V&V 50
V. U. - Prueba
Fundamentos Tericos
Decimos que P es correcto para un conjunto de
pruebas T, si es correcto para todos los casos de
prueba de T. En este caso decimos que P es exitoso
en T
Un criterio de seleccin C es un subconjunto del
conjunto de subconjuntos finitos de D
Un conjunto de prueba T satisface C si pertenece a
C
Un criterio de seleccin C es consistente si para
cualquier par T1,T2 que satisfacen C, P es exitoso
en T1 si y slo si es exitoso en T2
2008 V&V 51
V. U. - Prueba
Fundamentos Tericos
Un criterio de seleccin C es completo si, siempre
que P sea incorrecto, existe un conjunto de prueba
T que satisface C para el que P no es exitoso
Si C fuera a la vez consistente y completo,
podramos discriminar (de forma automtica) si un
programa es o no correcto
Podremos construir un algoritmo para generar C?
No. Este es otro problema indecidible
2008 V&V 52
V. U. - Prueba
Fundamentos Tericos
Entrada:
Un nmero del 1 al 3
Conjunto de subconjuntos finitos:
{ {1}, {2}, {3}, {1,2}, {1,3}, {2,3}, {1,2,3} }
Criterio
Que al menos est el nmero 1
C = { {1}, {1,2}, {1,3}, {1,2,3} }
Conjuntos de prueba que satisfacen C
T1 = {1} T2 = {1,2} T3 = {1,3} T4 = {1,2,3}
2008 V&V 53
V. U. - Prueba
Principios Empricos
Se necesitan estrategias para seleccionar casos de
prueba significativos
Test Set de Significancia
Tiene un alto potencial para descubrir errores
La ejecucin correcta de estos test aumenta la confianza
en el producto
Ms que correr una gran cantidad de casos de
prueba nuestra meta en las pruebas debe ser correr
un suficiente nmero de casos de prueba
significativos (tiene alto porcentaje de posibilidades
de descubrir un error)
2008 V&V 54
V. U. - Prueba
Principios Empricos
Como intentamos definir test sets de significancia?
Agrupamos elementos del dominio de la entrada en clases
Di, tal que, elementos de la misma clase se comportan (o
suponemos se comportan) exactamente de la misma
manera (consistencia)
De esta manera podemos elegir un nico caso de prueba
para cada clase
2008 V&V 55
V. U. - Prueba
Principios Empricos
Si las clases Di cumplen U Di = D El test set
satisface el principio de cubrimiento completo
Extremos de criterios
Divido las entradas en una nica clase
o No tiene sentido ya que no se provocarn muchas fallas
Divido las entradas en tantas clases como casos posibles
(exhaustiva)
o Es imposible de realizar
Para asegurarnos mas, en clases Di que tenemos
dudas de que sus elementos se comporten de la
misma manera tomamos mas de un caso
representativo
2008 V&V 56
V. U. - Prueba
Qu Estamos Buscando?
Cul es el subconjunto de todos los
posibles casos de prueba que tiene la
mayor probabilidad de detectar el mayor
nmero posible de errores dadas las
limitaciones de tiempo, costo, tiempo de
computador, etc?
2008 V&V 57
V. U. - Prueba
Caja Blanca
Tipos de tcnicas de caja blanca
Basadas en el flujo de control del programa
o Expresan los cubrimientos del testing en trminos del grafo de
flujo de control del programa
Basadas en el flujo de datos del programa
o Expresan los cubrimientos del testing en trminos de las
asociaciones definicin-uso del programa
Mutation testing
o Se basan en crear mutaciones del programa original provocando
distintos cambios en este ltimo
o La idea atrs de esta forma de test es poder distinguir (usando los
casos de test) los mutantes del original
o No se va a entrar en detalle
2008 V&V 58
V. U. - Prueba
Caja Blanca
Criterio de cubrimiento de sentencias
Asegura que el conjunto de casos de pruebas (CCP)
ejecuta al menos una vez cada instruccin del cdigo
a>1 True
If (a > 1) and (b = 0) { and c
b=0
x=x/a
False x = x/a
} b
If (a = 2) or (x > 1) {
x=x+1
a=2 True
} or
X>1 e
x=x+1
d False
2008 V&V 60
V. U. - Prueba
Caja Blanca
a
CP a = 2, b = 0, x = 3 a>1 True
and c
b=0
Secuencia: ace False x = x/a
b
a=2 True
or
X>1 e
x=x+1
d False
2008 V&V 61
V. U. - Prueba
Caja Blanca
Criterio de cubrimiento de decisin
Cada decisin dentro del cdigo toma al menos una vez el
valor true y otra vez el valor false para el CCP
a=2 True
or
X>1 e
x=x+1
d False
2008 V&V 63
V. U. - Prueba
Caja Blanca
a
a=2 True
or
X>1 e
x=x+1
d False
2008 V&V 64
V. U. - Prueba
Caja Blanca
Criterio de cubrimiento de condicin
Cada condicin dentro de una decisin debe tomar al
menos una vez el valor true y otra el false para el CCP
a
Si se tiene If (A and B) . el criterio
If (a > 1) and (b = 0) {x = x / a} de condicin se puede satisfacer con
b estos dos casos de prueba:
If (a = 2) or (x > 1) {x = x + 1} C1: A=true B=false
C2: A=false B=true
Hay que tener casos tal que a>1, Esto no satisface el criterio de decisin
a<=1, b=0 y b<>0 en el punto a y
casos en los cuales a=2, a<>2, x>1
y x<=1 en el punto b Este criterio es generalmente
CP1 a=2, b=0, x=4 ms fino que el de decisin
CP2 a=1, b=1, x=1
2008 V&V 65
V. U. - Prueba
Caja Blanca
a
a=2 True
or
X>1 e
x=x+1
d False
2008 V&V 66
V. U. - Prueba
Caja Blanca
a
a=2 True
or
X>1 e
x=x+1
d False
2008 V&V 67
V. U. - Prueba
Caja Blanca
Criterio de cubrimiento de decisin/condicin
Combinacin de los dos criterios anteriores
a
Este criterio no tiene porque invocar
If (a > 1) and (b = 0) {x = x / a} a todas las salidas producidas por el
b cdigo mquina No todas las
If (a = 2) or (x > 1) {x = x + 1} faltas debido a errores en
expresiones lgicas son detectadas
x>1 x=x+1
False
2008 V&V 69
V. U. - Prueba
Caja Blanca
True True
a>1 b=0
CP1 a = 2, b = 0, x = 4
True
a=2
False
True
x>1 x=x+1
False
2008 V&V 70
V. U. - Prueba
Caja Blanca
True True
a>1 b=0
CP1 a = 1, b = 1, x = 1
True
a=2
False
True
x>1 x=x+1
False
2008 V&V 71
V. U. - Prueba
Caja Blanca
True True
a>1 b=0
FALTO TESTEAR
True
a=2
False
True
x>1 x=x+1
False
2008 V&V 72
V. U. - Prueba
Caja Blanca
Criterio de cubrimiento de condicin mltiple
Todas las combinaciones posibles de resultados de
condicin dentro de una decisin se ejecuten al menos
una vez
Se deben satisfacer 8 combinaciones:
La secuencia acd queda sin ejecutar
1) a>1, b=0 2) a>1, b<>0 este criterio no asegura testear
3) a<=1, b=0 4) a<=1, b<>0 todos los caminos posibles
5) a=2, x>1 6) a=2, x<=1
7) a<>2, x>1 8) a<>2, x<=1
Los casos 5 a 8 aplican en el punto b
Incluye al criterio de
CP1 a=2, b=0, x=4 cubre 1 y 5
condicin/decisin.
CP2 a=2, b=1, x=1 cubre 2 y 6
CP3 a=1, b=0, x=2 cubre 3 y 7
Myers lo considera un criterio
CP4 a=1, b=1, x=1 cubre 4 y 8
aceptable
2008 V&V 73
V. U. - Prueba
Caja Blanca
True True
a>1 b=0
CP1 y CP4 ya los vimos
True
a=2
False
True
x>1 x=x+1
False
2008 V&V 74
V. U. - Prueba
Caja Blanca
True True
a>1 b=0
CP2 a = 2, b = 1, x = 1
True
a=2
False
True
x>1 x=x+1
False
2008 V&V 75
V. U. - Prueba
Caja Blanca
True True
a>1 b=0
CP3 a = 1, b = 0, x = 2
True
a=2
False
True
x>1 x=x+1
False
2008 V&V 76
V. U. - Prueba
Caja Blanca
Falta no detectada con el CCCM
2008 V&V 78
V. U. - Prueba
Caja Blanca
Criterio de cubrimiento de trayectorias indep.
Ejecutar al menos una vez cada trayectoria independiente
El nmero de trayectorias
independientes se calcula usando la Si se divide en
complejidad ciclomtica decisiones de una
CC = Arcos Nodos + 2 nica condicin (esto
no est especificado
El CC da el nmero mnimo de casos en el criterio), es el
de prueba necesarios para probar ms fino de los vistos
todas las trayectorias independientes hasta ahora.
y un nmero mximo de casos
necesarios para cubrimiento de arcos La cantidad de casos de
En el ejemplo tengo que tener 4 prueba suele ser demasiado
casos de prueba para cumplir con el
criterio de cubrimiento de trayectoria
grande. Es un criterio de
2008
referencia V&V 79
V. U. - Prueba
Caja Blanca
Trayectorias independientes
El ejemplo que venimos siguiendo
Cuntas trayectorias
independientes hay?
Respuesta: CC = 5
2008 V&V 80
V. U. - Prueba
Caja Blanca
Trayectorias independientes
Un ejemplo ms sencillo
2008 V&V 81
V. U. - Prueba
Caja Blanca
Trayectorias independientes
Un ejemplo ms sencillo Las 4 trayectorias
T1 T2 T3 T4
2008 V&V 82
V. U. - Prueba
Caja Blanca
Trayectorias independientes
Un ejemplo ms sencillo 3 Trayectorias independientes
T1 T3 T4
2008 V&V 83
V. U. - Prueba
Caja Blanca
Trayectorias independientes
Un ejemplo ms sencillo Como llego a T2
T1 T1 + T4 T1 + T4 T3
X2
2008 V&V 84
V. U. - Prueba
Caja Blanca
Trayectorias independientes
Este criterio detecta el defecto de ejemplo que no
detecta CCCM?
If x <> 0
y=5
else
z=zx
If z > 1
z=z/x
else
z=0
2008 V&V 85
V. U. - Prueba
Caja Blanca
Criterio de cubrimiento de caminos
Se ejecutan al menos una vez todos los caminos posibles
(combinaciones de trayectorias)
2008 V&V 86
V. U. - Prueba
Caja Blanca
Criterios basados en el flujo de datos
Definiciones
Una variable en el lado izquierdo de una asignacin es una
definicin de la variable
Una variable en el lado derecho de una asignacin es
llamada un uso computacional o un c-uso
Una variable en un predicado booleano resulta en un par
uso predicado o p-uso correspondiendo a las
evaluaciones verdadero y falso del predicado
Un camino (i,n1,n2,,nm,j) es un camino limpio-
definicin desde la salida de i hasta la entrada a j si no
contiene una definicin de x en los nodos de n1 a nm
2008 V&V 87
V. U. - Prueba
Caja Blanca
Ms definiciones
Dada una definicin de x en el nodo nd y un c-uso de x en
el nodo nc-uso, la presencia de un camino limpio-definicin
para x desde nd hasta nc-uso establece la asociacin
definicin-c-uso (nd, nc-uso, x)
Similar al anterior pero con p-uso establece un par de
asociaciones definicin-p-uso (nd, (np-uso,t), x) y
(nd, (np-uso,f), x) correspondiendo a las evaluaciones de
true y false en el nodo np-uso respectivamente
2008 V&V 88
V. U. - Prueba
Caja Blanca
Ms definiciones
camino-du para una variable x:
Es un camino-du si se cumple alguna de las dos
condiciones siguientes
o (n1,,nj,nk) y n1 contiene una definicin de x y nk es un c-uso de x
y (n1,,nj,nk) es limpio-definicin para x y solamente pueden ser
iguales n1 y nk (es decir, no se repiten nodos a menos de n1 y nk)
o Similar para p-uso. La diferencia es que el camino desde n1 hasta
nk no contiene nodos iguales
2008 V&V 89
V. U. - Prueba
Caja Blanca
Ejemplo
Definiciones de x: Nodos 1 y 4
C-uso de x: Nodo 4
x=a+b 1 P-uso de x: Nodo 5
Camino libre-def: (1,2,4) y (1,2,3,5)
Camino-du (1,2,4) establece una
2
definicin-c-uso (1,4,x)
false Camino-du (1,2,3,5) establece dos
definicin-p-uso (1,(5,t),x) y (1,(5,f),x)
3 x=x+1 4
if x > 10 5
true
2008 V&V 90
V. U. - Prueba
Caja Blanca
Criterios de cobertura
Todas las definiciones
o Se ejecuta para cada definicin al menos un camino libre-
definicin para algn uso correspondiente (c-uso o p-uso)
Todos los c-usos
o Para cada definicin se ejecuta al menos un camino libre-
definicin hasta todos los c-usos correspondientes
Todos los c-usos/algn p-uso
o Como el anterior pero si no existe ningn c-uso entonces tiene
que ir a algn p-uso
Todos los p-usos
o Similar a todos los c-usos
Todos los p-usos/algn c-uso
o Similar a todos los c-usos/algn p-uso
2008 V&V 91
V. U. - Prueba
Caja Blanca
Criterios de cobertura
Todos los usos
o Se ejecuta para cada definicin al menos un camino libre-
definicin que lleve a todos los c-usos y p-usos correspondientes
Todos los caminos-du
o Se ejecutan para cada definicin todos los caminos-du. Esto
quiere decir que si hay mltiples caminos-du entre una definicin y
un uso todos deben ser ejecutados
2008 V&V 92
V. U. - Prueba
Caja Blanca
Volvamos al ejemplo no resuelto
1
Definiciones de z: Nodos 2, 5, 7 y 8
Def x
C-uso de z: Nodos 5 y 7
If x <> 0
Def z 2 P-uso de z: Nodo 6
y=5
Definicin-c-uso que resuelve
else x <> 0 3 nuestro problema: (5,7,z)
z=zx 4 5 Esto es vlido ya que (5,6,7) es un
If z > 1 y=5 z = z - x camino libre-definicin
z=z/x
z>1 6
else Observar que la definicin-uso (2,7,z)
7 8
z=0 no tiene porqu detectar el defecto
z=z/x z=0
2008 V&V 93
V. U. - Prueba
Caja Blanca
Consideremos criterio Todas las definiciones
1
Definicin-c-uso que resuelve nuestro
Def x
problema: (5,7,z)
Def z 2
Este criterio nos dice que si consideramos la
x <> 0 3 definicin de z en el nodo 5 tenemos que incluir
4 5 al menos un camino libre-definicin para
y=5 z=z-x algn uso (p-uso o c-uso)
2008 V&V 94
V. U. - Prueba
Caja Blanca
Consideremos criterio Todos los c-usos
1
Definicin-c-uso que resuelve nuestro
Def x
problema: (5,7,z)
Def z 2
Este criterio nos dice que si consideramos la
x <> 0 3 definicin de z en el nodo 5 tenemos que incluir
4 5 al menos un camino libre-definicin para
y=5 z=z-x todos los c-usos
2008 V&V 96
V. U. - Prueba
Caja Blanca
El testing basado en flujo de datos es menos usado
que el testing basado en el flujo de control
Es altamente complejo seleccionar los casos de test
2008 V&V 97
V. U. - Prueba
Caja Blanca
Todos los caminos
Arcos
2008 V&V 99
V. U. - Prueba
Caja Negra
El programa lee tres nmeros enteros, los que son
interpretados como representaciones de las
longitudes de los lados de un tringulo. El programa
escribe un mensaje que informa si el tringulo es
escaleno, issceles o equiltero.
Unit
.
. Prueba Prueba Prueba Prueba Prueba
componente verificado
Unit
SISTEMA
EN USO
Visin simplificada....
2008 V&V 115
Pruebas de Integracin
Pruebas de Mdulos
El mdulo A usa a los mdulos B, C, D.
El mdulo B usa a los mdulos E y F
El mdulo D usa al mdulo G
B C D
E F G
A A A
B C D B C D B C D
Stub Stub Stub
E F G E F G E F G
2008 V&V 125
Pruebas de Integracin
Top-Down
La regla general indica que para probar un mdulo todos los
de arriba (respecto al mdulo a probar) deben estar
probados
Supongamos que C, F y D son mdulos crticos entonces es
bueno probarlos lo antes posible
A A
A A
Stub Stub
Stub Stub Stub Stub Stub
B C D B C D
B C D B C D
Stub Stub Stub
E F E F
A A A
B C D B C D B C D
Stub Stub
E F E F Stub
E F
2008
G
G GV&V 126
Pruebas de Integracin
Otras Tcnicas
Sandwich
Usa Top-Down y Bottom-Up. Busca probar los mdulos
ms crticos primero
A
Stub Stub Stub
B C D
E F G
Por Disponibilidad
Se integran los mdulos a medida de que estos estn
disponibles
Clase
Modificada
El re-test en
este caso es
Volver a No se
obvio
Testear vuelve a
testear
}
met2(p1,p1) El mtodo met2 se redefine en la
clase B. Esto genera un nuevo
met2(p1,p2){}
contexto y es por esto que se debe
volver a testear met1 para la clase B,
debido a que met1 llama a met2
B
//redefine met2
met2(p1,p2){}
push(e:Element) [n<maxSize-1]
get():Element [n=1]
get():Element [n!=1]
get():Element [n>1]
push(e:Element) [n<maxSize-1]
push(e:Element) [n=maxSize-1]
push(e:Element) [n<maxSize-1] 7 8
push(e:Element) [n=maxSize-1]
ConElementos Llena
get():Element [n=1]
push(e:Element) [n<maxSize-1] 6
get():Element [n>1]
1 2 3 get():Element [n!=1]
get():Element [n=1]
ConElementos Vacia
4 5
2008 V&V 157
Pruebas de SOO
Estrategia N+
Un caso de prueba:
Pila p = new Pila(2);
Chequear poscondiciones del mtodo Pila
Chequear estado de la clase = Vacia
Element e = new Element();
p.push(e);
Chequear poscondiciones del mtodo push
Chequear estado de la clase = ConElementos
p.push(e);
Chequear poscondiciones del mtodo push
Chequear estado de la clase = Llena
Element z = p.get();
Chequear poscondiciones del mtodo get
Chequear estado de la clase = ConElementos
2008 V&V 158
Pruebas de SOO
Estrategia N+
Cada estado debe estar definido en funcin de
restricciones respecto a los miembros de la clase
Unit
.
. Prueba Prueba Prueba Prueba Prueba
componente verificado
Unit
SISTEMA
EN USO
Visin simplificada....
2008 V&V 163
Pruebas del Sistema
Las Distintas Pruebas del Sist.
Prueba de funcin
Verifica que el sistema integrado realiza sus funciones
especificadas en los requerimientos
Prueba de desempeo
Verifica los requerimientos no funcionales del sistema
Prueba de aceptacin
Se realiza junto con el cliente. Busca asegurar que el
sistema es el que el cliente quiere
Prueba de instalacin
Se realizan las pruebas en el ambiente objetivo
Dev.tarjeta S S S S
Recibo 13131... 13131... 13131...
Prueba de recuperacin
Se intenta probar que no se cumplen los requerimientos
de recuperacin
Para esto se simulan o crean fallas y luego se testea la
recuperacin del sistema
Prueba de instalacin
Su mayor propsito es encontrar errores de instalacin
Es de mayor importancia si la prueba de aceptacin no se
realiz en el ambiente de instalacin
ANALISIS DE
Modelo V OPERACION
REQUERIMIENTOS Y MANTENIMIENTO
Plan de Pruebas de
Aceptacin
Validar requerimientos PRUEBA DE
ACEPTACION
DISEO DEL Plan de Pruebas del
SISTEMA Sistema
IMPLEMENTACION
DE PROGRAMAS Y
PRUEBA UNITARIA
Pruebas independientes