09-verificacion-validacion
DESCRIPTION
Verificacion-ValidacionTRANSCRIPT
-
2008 V&V 1
Verificacin y Validacin
-
2008 V&V 2
Verificacin y Validacin
Temario IntroduccinProceso de V&VVerificacin Unitaria
o Tcnicas Estticas (anlisis)o Ejecucin Simblicao Tcnicas Dinmicas (pruebas)
Pruebas de IntegracinPruebas de Sistemas Orientados a ObjetosPruebas de SistemaHerramientasPlanificacin de V&VTerminacin de la prueba
-
2008 V&V 3
Introduccin
TemarioErrores, faltas y fallas.Objetivos y definicin de V&VEjemploTipos de faltasClasificacin de defectos
-
2008 V&V 4
?!un error humano
una falta
(interna)
una falla
(externa)
puede generar que puede generar
Errores, Faltas y FallasIntroduccin
-
2008 V&V 5
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 implementarFaltas en el diseoFaltas en el cdigo
La idea es detectar y corregir estas faltas antes de liberar el producto
Introduccin
-
2008 V&V 6
Objetivos de V&V
Descubrir defectos (para corregirlos)Provocar fallas (una forma de detectar defectos)
Revisar los productos (otra forma de detectar defectos)
Evaluar la calidad de los productosEl probar o revisar el software da una idea de la calidad del mismo
Introduccin
-
2008 V&V 7
Identificacin y Correccin de
Defectos Identificacin de defectos
Es el proceso de determinar que defecto o defectos causaron la falla
Correccin de defectosEs el proceso de cambiar el sistema para remover los defectos
Introduccin
-
2008 V&V 8
Definicin de V&V
SommervilleVerificacin
o Busca comprobar que el sistema cumple con los requerimientos especificados (funcionales y no funcionales)
o El software est de acuerdo con su especificacin?
Validacino Busca comprobar que el software hace lo que el usuario espera.o El software cumple las expectativas del cliente?
Introduccin
-
2008 V&V 9
Definicin de V&V
BoehmVerificacin
o Estamos construyendo el producto correctamente?
Validacino Estamos construyendo el producto correcto?
GhezziVerificacin
o Todas las actividades que son llevadas a cabo para averiguar si el software cumple con sus objetivos
Introduccin
-
2008 V&V 10
Definicin de V&V
IEEEVerificacin
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
Validacino The process of evaluating a system or component during or at theend of the development process to determine whether it satisfiesspecified requirements
Introduccin
-
2008 V&V 11
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
Introduccin
-
2008 V&V 12
Ejemplo
Comparo el resultado esperado con el obtenidoSi 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
Introduccin
-
2008 V&V 13
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 andSe puede revisar soloSe puede revisar en grupos
o Veremos ms adelante tcnicas conocidas para revisiones en grupo
Introduccin
-
2008 V&V 14
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
Introduccin
-
2008 V&V 15
Tipos de Faltas
En algoritmosFaltas tpicas
o Bifurcar a destiempoo Preguntar por la condicin equivocadao No inicializar variableso No evaluar una condicin particularo Comparar variables de tipos no adecuados
De sintaxisEjemplo: Confundir un 0 por una OLos compiladores detectan la mayora
Introduccin
-
2008 V&V 16
Tipos de Faltas
De precisin o de clculoFaltas tpicas
o Formulas no implementadas correctamenteo No entender el orden correcto de las operacioneso Faltas de precisin como un truncamiento no esperado
De documentacinLa documentacin no es consistente con lo que hace el software
Ejemplo: El manual de usuario tiene un ejemplo que no funciona en el sistema
Introduccin
-
2008 V&V 17
Tipos de Faltas
De estrs o sobrecargaExceder el tamao mximo de un rea de almacenamiento intermedio
Ejemploso El sistema funciona bien con 100 usuarios pero no con 110o 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 bordeMs de lo que el sistema puede manejarEjemplos
o El sistema funciona bien con importes
-
2008 V&V 18
Tipos de Faltas
De sincronizacin o coordinacinNo cumplir requerimiento de tiempo o frecuencia.Ejemplo
o Comunicacin entre procesos con faltas
De capacidad de procesamiento o desempeoNo terminar el trabajo en el tiempo requeridoTiempo de respuesta inadecuado
De recuperacinNo poder volver a un estado normal luego de una falla
Introduccin
-
2008 V&V 19
Tipos de Faltas
De estndares o procedimientosNo cumplir con la definicin de estndares y/o procedimientos
De hardware o software del sistema Incompatibilidad entre componentes
Introduccin
-
2008 V&V 20
Clasificacin de Defectos
Categorizar y registrar los tipos de defectosGua para orientar la verificacin
o Si conozco los tipos de defectos en que incurre la organizacin me puedo ocupar de buscarlos expresamente
Mejorar el procesoo Si tengo identificada la fase en la cual se introducen muchos defectos me ocupo de mejorarla
Clasificacin OrtogonalCada defecto queda en una nica categoraSi pudiera quedar en ms de una de poco servira
Introduccin
-
2008 V&V 21
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
Introduccin
-
2008 V&V 22
EspecificacinRequerimientos
Ambiente/soporte
Documentacin OtroDiseo Codific.
ORIGEN: POR QU?
Falta Oscuro Mal Cambiado Mejor manera
MODO:FORMA?
TIP
O:
E
N Q
U
? Requerimientoso
Especificaciones
Funcionalidad
Interfaz HW
Interfaz SW
Interfaz Usuario
Descripcin Funcional
HW de Test
SW de Test
SW Integracin
Herramientas de desarrollo
Lgica
Clculo
Manejo de Datos
Interfaz Mdulo/
implementacin
Estndares
Comunicaciones (entre) Procesos
Definicin de Datos
Diseo de Mdulo
Descripcin de Lgica
Control de Errores
Estndares
Clasificacin de Defectos - HPIntroduccin
-
2008 V&V 23
Manejo Datos6%
Documentacin
19%
Requerimientos5%
Hardware4%
Proceso/entre procesos
5%
Lgica32%
Clculo18%
Otros Cdigo11%
Faltas en un departamento de HPIntroduccin
-
2008 V&V 24
Proceso de V&V
TemarioProceso y pruebas en el proceso Quin verifica?Actitudes respecto a la verificacin
-
2008 V&V 25
ProcesoProceso de V&V
Unit
Unit
Unit
PruebaIntegracin
Prueba Funcional
Prueba desempeo
Prueba Aceptacin
PruebaInstalacin
Com
pone
nt c
ode
.
.
.
com
pone
nte
verif
icad
o
Mdulos Integrados
Sistema Funcionando
Software Verificado
Sistema Aceptado
SISTEMAEN USO
Especifi-cacionesde Diseo
Requerimien-tos
funcionalesdel Sistema
Otros Requeri-
mientos delsoftware
Especificacin de Requeri-
mientos para el Cliente
Ambientede Uso
Visin simplificada....
-
2008 V&V 26
Pruebas en el Proceso
Mdulo, Componente o unitariaVerifica las funciones de los componentes
IntegracinVerifica que los componentes trabajan juntos como un sistema integrado
FuncionalDetermina si el sistema integrado cumple las funciones de acuerdo a los requerimientos
Proceso de V&V
-
2008 V&V 27
Pruebas en el Proceso
DesempeoDetermina 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
InstalacinEl sistema queda instalado en el ambiente de trabajo del cliente y funciona correctamente
Proceso de V&V
-
2008 V&V 28
Quin Verifica?
Pruebas UnitariasNormalmente 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 IntegracinNormalmente las realiza el equipo de desarrolloEs necesario el conocimiento de las interfaces y funciones en general
Resto de las pruebasEn general un equipo especializado (verificadores)Es necesario conocer los requerimientos y tener una visin global
Proceso de V&V
-
2008 V&V 29
Quin Verifica?
Por qu un equipo especializado?Maneja mejor las tcnicas de pruebasConoce los errores ms comunes realizados por el equipo de programadores
Problemas de psicologa de pruebaso 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
Proceso de V&V
-
2008 V&V 30
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)
Proceso de V&V
-
2008 V&V 31
Verificacin Unitaria
TemarioTcnicas de verificacin unitariaTcnicas estticas - Anlisis
o Anlisis de cdigo fuenteo Anlisis automatizado de cdigo fuenteo Anlisis formal
Ejecucin simblicaTcnicas dinmicas Pruebas
o Definiciones, proceso para un mdulo, conceptos bsicos, teorao Caja Blancao Caja Negra
Comparacin de las tcnicas
-
2008 V&V 32
Tcnicas de Verificacin Unitaria
Tcnicas estticas (analticas)Analizar el producto para deducir su correcta operacin
Tcnicas dinmicas (pruebas) Experimentar con el comportamiento de un producto para ver si el producto acta como es esperado
Ejecucin simblicaTcnica hbrida
Verificacin unitaria
-
2008 V&V 33
Tcnicas Estticas
Anlisis de cdigoSe revisa el cdigo buscando defectosSe puede llevar a cabo en gruposRecorridas e Inspecciones (tcnicas conocidas con resultados conocidos)
Anlisis automatizado de cdigo fuenteLa entrada es el cdigo fuente del programa y la salida es una serie de defectos detectados
Verificacin formalSe parte de una especificacin formal y se busca probar (demostrar) que el programa cumple con la misma
Verificacin unitaria
-
2008 V&V 34
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 personao Permiten
Unificar el estilo de programacin Igualar hacia arriba la forma de programar
o No deben usarse para evaluar a los programadores
V. U. - Anlisis
-
2008 V&V 35
Anlisis de Cdigo
RecorridasSe simula la ejecucin de cdigo para descubrir faltasNmero reducido de personasLos participantes reciben antes el cdigo fuenteLas reuniones no duran ms de dos horasEl foco est en detectar faltas y no en corregirlasLos roles clave son:
o Autor: Presenta y explica el cdigoo Moderador: Organiza la discusino Secretario: Escribe el reporte de la reunin para entregarle al autor
El autor es el que se encarga de la ejecucin del cdigo
V. U. - Anlisis
-
2008 V&V 36
Anlisis de Cdigo
InspeccionesSe 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 inicializadaso 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 necesario
V. U. - Anlisis
-
2008 V&V 37
Anlisis de Cdigo
Proceso de la Inspeccin
V. U. - Anlisis
Planeacin
Visin de Conjunto
PreparacinIndividual
Reunin deInspeccin
Correccin
Seguimiento
Seleccionar equipo de inspeccin.
Asegurar que el material est completo
Presentacin del programa
Objetivos del programa
Bsqueda de defectos de forma individual
Dedicada solamente a detectar defectos
Correccin por parte del autor del cdigo
Es necesaria otra inspeccin?
Tarea del Moderador
-
2008 V&V 38
Anlisis de Cdigo
En un estudio de Fagan:Con Inspeccin se detect el 67% de las faltas detectadasAl 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
V. U. - Anlisis
-
2008 V&V 39
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 vecesa := 2 la variable sin usarla entre las asignaciones
V. U. - Anlisis
-
2008 V&V 40
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
ObjecionesDemostracin ms larga (y compleja) que el propio programa
La demostracin puede ser incorrectaDemasiada matemtica para el programador medioNo se consideran limitaciones del hardwareLa especificacin puede ser incorrecta igual hay que validar mediante pruebas. Esto ocurre siempre (nada es 100% seguro)
V. U. - Anlisis
-
2008 V&V 41
Anlisis Formal
Que sea la mquina la que demuestre Desarrollar herramientas que tomen:
Especificacin formalCdigo 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
V. U. - Anlisis
-
2008 V&V 42
Ejecucin Simblica
Ejemplo:
read(a); read(a); read(b); [a = A] VALOR SIMBLICOx := 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]
Verificacin Unitaria
-
2008 V&V 43
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;
elsey := x + 3; HACEMOS CADA CASO Y
[x = Y + 2, a = A, y = Y + 5] [Y + 2
-
2008 V&V 44
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?
Verificacin Unitaria
-
2008 V&V 45
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 requerimientoso 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
V. U. - Prueba
-
2008 V&V 46
Visin de los Objetos a Probar
Caja NegraEntrada a una caja negra de la que no se conoce el contenido y ver que salida generao Casos de prueba - No se precisa disponer del cdigoo Se parte de los requerimientos y/o especificacino Porciones enteras de cdigo pueden quedar sin ejercitar
Caja BlancaA partir del cdigo identificar los casos de prueba interesanteso Casos de prueba Se necesita disponer del cdigoo Tiene en cuenta las caractersticas de la implementacino Puede llevar a soslayar algn requerimiento no implementado
V. U. - Prueba
-
2008 V&V 47
Un Proceso para un MduloV. U. - Prueba
Especificar Mdulo Plan de Prueba (Caja Negra)
Implementar
Completar Plan de Prueba ( Caja Blanca)
Revisin
-
2008 V&V 48
Conceptos Bsicos
Es imposible realizar pruebas exhaustivas y probar todas las posibles secuencias de ejecucin
La prueba (test) demuestra la presencia de faltas y nunca su ausencia (Dijkstra)
Es necesario elegir un subconjunto de las entradas del programa para testearConjunto de prueba (test set)
V. U. - Prueba
nicas que aseguraran correctitud
-
2008 V&V 49
Conceptos Bsicos
El test debe ayudar a localizar faltas y no solo a detectar su presencia
El test debe ser repetibleEn 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.
V. U. - Prueba
-
2008 V&V 50
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 dsi 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
V. U. - Prueba
-
2008 V&V 51
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
V. U. - Prueba
-
2008 V&V 52
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
V. U. - Prueba
-
2008 V&V 53
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} }
CriterioQue al menos est el nmero 1C = { {1}, {1,2}, {1,3}, {1,2,3} }
Conjuntos de prueba que satisfacen CT1 = {1} T2 = {1,2} T3 = {1,3} T4 = {1,2,3}
V. U. - Prueba
-
2008 V&V 54
Principios Empricos
Se necesitan estrategias para seleccionar casos de prueba significativos
Test Set de SignificanciaTiene un alto potencial para descubrir erroresLa 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)
V. U. - Prueba
-
2008 V&V 55
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
V. U. - Prueba
-
2008 V&V 56
Principios Empricos
Si las clases Di cumplen U Di = D El test set satisface el principio de cubrimiento completo
Extremos de criteriosDivido 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
V. U. - Prueba
-
2008 V&V 57
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?
V. U. - Prueba
-
2008 V&V 58
Caja BlancaV. U. - Prueba
Tipos de tcnicas de caja blancaBasadas 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 programao Expresan los cubrimientos del testing en trminos de las asociaciones definicin-uso del programa
Mutation testingo 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 59
Caja Blanca
Criterio de cubrimiento de sentenciasAsegura que el conjunto de casos de pruebas (CCP) ejecuta al menos una vez cada instruccin del cdigo
V. U. - Prueba
Que pasa si tena un or en lugar del and de la primera decisin?
Que pasa si tena x > 0 en lugar de x > 1 en la segunda decisin?
Hay una secuencia en la cual x se mantiene sin cambios y esta no es probada
Este criterio es tan dbil que normalmente se lo considera intil. Es necesario pero no suficiente (Myers)
If (a > 1) and (b = 0) {x = x / a
}If (a = 2) or (x > 1) {x = x + 1
}
CP : Entrada a=2, b=0, x=3
-
2008 V&V 60
Caja BlancaV. U. - Prueba
a>1andb=0
a=2or
X>1
x = x/a
x = x + 1
True
True
False
False
a
c
b
e
d
If (a > 1) and (b = 0) {x = x / a
}If (a = 2) or (x > 1) {x = x + 1
}
-
2008 V&V 61
Caja BlancaV. U. - Prueba
a>1andb=0
a=2or
X>1
x = x/a
x = x + 1
True
True
False
False
a
c
b
e
d
CP a = 2, b = 0, x = 3
Secuencia: ace
-
2008 V&V 62
Caja Blanca
Criterio de cubrimiento de decisinCada decisin dentro del cdigo toma al menos una vez el valor true y otra vez el valor false para el CCP
V. U. - Prueba
Qu pasa si en la segunda decisin tuviera x < 1 en lugar de x > 1?
Hay una secuencia en la cual x se mantiene sin cambios y esta no es probada
Hay que extender el criterio para sentencias del tipo CASE
Es ms fino que el criterio de sentencias
If (a > 1) and (b = 0) {x = x / a
}If (a = 2) or (x > 1) {x = x + 1
}
CP1 a=3, b=0, x=3CP2 a=2, b=1, x=1
-
2008 V&V 63
Caja BlancaV. U. - Prueba
a>1andb=0
a=2or
X>1
x = x/a
x = x + 1
True
True
False
False
a
c
b
e
d
CP1 a = 3, b = 0, x = 3
Secuencia: acd
-
2008 V&V 64
Caja BlancaV. U. - Prueba
a>1andb=0
a=2or
X>1
x = x/a
x = x + 1
True
True
False
False
a
c
b
e
d
CP2 a = 2, b = 1, x = 1
Secuencia: abe
-
2008 V&V 65
Caja Blanca
Criterio de cubrimiento de condicinCada condicin dentro de una decisin debe tomar al menos una vez el valor true y otra el false para el CCP
V. U. - Prueba
Si se tiene If (A and B) . el criterio de condicin se puede satisfacer con estos dos casos de prueba:C1: A=true B=falseC2: A=false B=trueEsto no satisface el criterio de decisin
Este criterio es generalmentems fino que el de decisin
aIf (a > 1) and (b = 0) {x = x / a}bIf (a = 2) or (x > 1) {x = x + 1}
Hay que tener casos tal que a>1, a1 y x
-
2008 V&V 66
Caja BlancaV. U. - Prueba
a>1andb=0
a=2or
X>1
x = x/a
x = x + 1
True
True
False
False
a
c
b
e
d
CP1 a = 2, b = 0, x = 4
Secuencia: ace
-
2008 V&V 67
Caja BlancaV. U. - Prueba
a>1andb=0
a=2or
X>1
x = x/a
x = x + 1
True
True
False
False
a
c
b
e
d
CP1 a = 1, b = 1, x = 1
Secuencia: abd
-
2008 V&V 68
Caja Blanca
Criterio de cubrimiento de decisin/condicinCombinacin de los dos criterios anteriores
V. U. - Prueba
Este criterio no tiene porque invocar a todas las salidas producidas por el cdigo mquina No todas las faltas debido a errores en expresiones lgicas son detectadas
aIf (a > 1) and (b = 0) {x = x / a}bIf (a = 2) or (x > 1) {x = x + 1}
CP1 a=2, b=0, x=4CP2 a=1, b=1, x=1
Es un criterio bastante fino dentro de caja blanca (Myers)
-
2008 V&V 69
Caja BlancaV. U. - Prueba
a>1
a=2
x = x/a
x = x + 1
True
True
False
False
b=0True
False
x>1
True
False
If (a > 1) {If (b > 0) {x = x / a}}
If (a = 2) goto SumIf (x > 1) goto Sumgoto FinSum: x = x + 1Fin:
-
2008 V&V 70
Caja BlancaV. U. - Prueba
a>1
a=2
x = x/a
x = x + 1
True
True
False
False
b=0True
False
x>1
True
False
CP1 a = 2, b = 0, x = 4
-
2008 V&V 71
Caja BlancaV. U. - Prueba
a>1
a=2
x = x/a
x = x + 1
True
True
False
False
b=0True
False
x>1
True
False
CP1 a = 1, b = 1, x = 1
-
2008 V&V 72
Caja BlancaV. U. - Prueba
a>1
a=2
x = x/a
x = x + 1
True
True
False
False
b=0True
False
x>1
True
False
FALTO TESTEAR
-
2008 V&V 73
Caja Blanca
Criterio de cubrimiento de condicin mltipleTodas las combinaciones posibles de resultados de condicin dentro de una decisin se ejecuten al menos una vez
V. U. - Prueba
La secuencia acd queda sin ejecutar este criterio no asegura testear todos los caminos posibles
Se deben satisfacer 8 combinaciones:1) a>1, b=0 2) a>1, b03) a
-
2008 V&V 74
Caja BlancaV. U. - Prueba
a>1
a=2
x = x/a
x = x + 1
True
True
False
False
b=0True
False
x>1
True
False
CP1 y CP4 ya los vimos
-
2008 V&V 75
Caja BlancaV. U. - Prueba
a>1
a=2
x = x/a
x = x + 1
True
True
False
False
b=0True
False
x>1
True
False
CP2 a = 2, b = 1, x = 1
-
2008 V&V 76
Caja BlancaV. U. - Prueba
a>1
a=2
x = x/a
x = x + 1
True
True
False
False
b=0True
False
x>1
True
False
CP3 a = 1, b = 0, x = 2
-
2008 V&V 77
Caja Blanca
Falta no detectada con el CCCM
If x 0 y = 5
else z = z x
If z > 1 z = z / x
else z = 0
El siguiente conjunto de casos de prueba cumple con el criterio de condicin mltiple
C1 x=0, z=1 C2 x=1 z=3
Este CCP no controla una posible divisin entre cero. Por ejemplo:
C3 x=0 z=3 El criterio no asegura recorrer todos los caminos posibles del programa. Como el caso acd del ejemplo anterior
En el ejemplo puede haber una divisin por cero no detectada
V. U. - Prueba
-
2008 V&V 78
Caja Blanca
Criterio de cubrimiento de arcosSe pasa al menos una vez por cada arco del grafo de flujo de control del programa
El criterio no especifica con qu grafo se trabaja; el comn o el extendido (grafo de flujo de control dnde est dividida cada decisin en decisiones simples)
Si es con el comn este criterio es igual al de decisin
V. U. - Prueba
-
2008 V&V 79
Caja Blanca
Criterio de cubrimiento de trayectorias indep.Ejecutar al menos una vez cada trayectoria independiente
V. U. - Prueba
El nmero de trayectorias independientes se calcula usando la complejidad ciclomticaCC = Arcos Nodos + 2
El CC da el nmero mnimo de casos de prueba necesarios para probar todas las trayectorias independientes y un nmero mximo de casos necesarios para cubrimiento de arcosEn el ejemplo tengo que tener 4 casos de prueba para cumplir con el criterio de cubrimiento de trayectoria
La cantidad de casos de prueba suele ser demasiado grande. Es un criterio de referencia
Si se divide en decisiones de una nica condicin (esto no est especificado en el criterio), es el ms fino de los vistos hasta ahora.
-
2008 V&V 80
Caja Blanca
Trayectorias independientesEl ejemplo que venimos siguiendo
V. U. - Prueba
Cuntas trayectorias hay desde el nodo inicial al nodo final? Repuesta: 9
Cuntas trayectorias independientes hay? Respuesta: CC = 5
-
2008 V&V 81
Caja Blanca
Trayectorias independientesUn ejemplo ms sencillo
V. U. - Prueba
Cuntas trayectorias hay desde el nodo inicial al nodo final sin repetir el bucle? Repuesta: 4
Y repitiendo el bucle? Respuesta: Puede ser infinito
Cuntas trayectorias independientes hay? Respuesta: CC = 3
-
2008 V&V 82
Caja Blanca
Trayectorias independientesUn ejemplo ms sencillo Las 4 trayectorias
V. U. - Prueba
T1 T2 T3 T4
-
2008 V&V 83
Caja Blanca
Trayectorias independientesUn ejemplo ms sencillo 3 Trayectorias independientes
V. U. - Prueba
T1 T3 T4
-
2008 V&V 84
Caja Blanca
Trayectorias independientesUn ejemplo ms sencillo Como llego a T2
V. U. - Prueba
T1 T1 + T4 T1 + T4 T3
X 2
-
2008 V&V 85
Caja Blanca
Trayectorias independientes Este criterio detecta el defecto de ejemplo que no detecta CCCM?
V. U. - Prueba
If x 0 y = 5
else z = z x
If z > 1 z = z / x
else z = 0
-
2008 V&V 86
Caja BlancaV. U. - Prueba
Criterio de cubrimiento de caminosSe ejecutan al menos una vez todos los caminos posibles (combinaciones de trayectorias)
>= 20 veces
En el ejemplo hay 100 trillones de caminos posibles.
Si determinar cada dato de prueba, el resultado esperado, ejecutar el caso y verificar si es correcto lleva 5 minutos la tarea llevaraproximadamente un billon de aos
-
2008 V&V 87
Caja BlancaV. U. - Prueba
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 88
Caja BlancaV. U. - Prueba
Ms definicionesDada 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 89
Caja BlancaV. U. - Prueba
Ms definicionescamino-du para una variable x:Es un camino-du si se cumple alguna de las dos condiciones siguienteso (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 90
Caja BlancaV. U. - Prueba
Ejemplo
x = a + b
x = x + 1
if x > 10
true
false
1
2
3 4
5
Definiciones de x: Nodos 1 y 4C-uso de x: Nodo 4P-uso de x: Nodo 5Camino libre-def: (1,2,4) y (1,2,3,5)Camino-du (1,2,4) establece una definicin-c-uso (1,4,x)Camino-du (1,2,3,5) establece dos definicin-p-uso (1,(5,t),x) y (1,(5,f),x)
-
2008 V&V 91
Caja BlancaV. U. - Prueba
Criterios de coberturaTodas 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-usoso Para cada definicin se ejecuta al menos un camino libre-definicin hasta todos los c-usos correspondientes
Todos los c-usos/algn p-usoo Como el anterior pero si no existe ningn c-uso entonces tiene que ir a algn p-uso
Todos los p-usoso Similar a todos los c-usos
Todos los p-usos/algn c-usoo Similar a todos los c-usos/algn p-uso
-
2008 V&V 92
Caja BlancaV. U. - Prueba
Criterios de coberturaTodos 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-duo 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 93
Caja BlancaV. U. - Prueba
Volvamos al ejemplo no resuelto
If x 0 y = 5
else z = z x
If z > 1 z = z / x
else z = 0
Def x
Def z
x 0
y = 5 z = z - x
z > 1
z = z / x z = 0
Definiciones de z: Nodos 2, 5, 7 y 8C-uso de z: Nodos 5 y 7 P-uso de z: Nodo 6Definicin-c-uso que resuelve nuestro problema: (5,7,z)Esto es vlido ya que (5,6,7) es un camino libre-definicin
Observar que la definicin-uso (2,7,z) no tiene porqu detectar el defecto
1
2
354
6
7 8
9
-
2008 V&V 94
Caja BlancaV. U. - Prueba
Consideremos criterio Todas las definiciones
Definicin-c-uso que resuelve nuestro problema: (5,7,z)
Este criterio nos dice que si consideramos la definicin de z en el nodo 5 tenemos que incluir al menos un camino libre-definicin para algn uso (p-uso o c-uso)
Basta con tomar (5,6,z) para cumplir con el criterio para el nodo 5Este criterio de cubrimiento no nos asegura encontrar el defecto
Def x
Def z
x 0
y = 5 z = z - x
z > 1
z = z / x z = 0
1
2
354
6
7 8
9
-
2008 V&V 95
Caja BlancaV. U. - Prueba
Consideremos criterio Todos los c-usos
Definicin-c-uso que resuelve nuestro problema: (5,7,z)
Este criterio nos dice que si consideramos la definicin de z en el nodo 5 tenemos que incluir al menos un camino libre-definicin para todos los c-usos
Para cumplir con este criterio a partir de la definicin de z en el nodo 5 hay que tomar el siguiente caso: (5,7,z)
Este criterio de cubrimiento nos asegura encontrar el defecto
Def x
Def z
x 0
y = 5 z = z - x
z > 1
z = z / x z = 0
1
2
354
6
7 8
9
-
2008 V&V 96
Caja BlancaV. U. - Prueba
Como seleccionamos los casos de prueba
Supongamos que queremos cumplir con el criterio de cubrimiento Todos los c-usos, entonces hay que cumplir con las siguientes definiciones-c-uso (sin considerar variable y):(1,5,x) (1,7,x) (2,5,z) (2,7,z) (5,7,z)
Para todas estas definiciones-c-uso existe al menos un camino libre-definicin
Descubrir las definiciones-c-uso para cumplir con el criterio es muy complejo. Seleccionar los casos de prueba a partir de estas tambin es muy complejo Herramientas automatizadas
Def x
Def z
x 0
y = 5 z = z - x
z > 1
z = z / x z = 0
1
2
354
6
7 8
9
-
2008 V&V 97
Caja BlancaV. U. - Prueba
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 98
Caja BlancaV. U. - Prueba
Todos los caminos
Todos los caminos-du
Todos los usos
Todos los c-usos/ Algunos p-usos
Todos los c-usos Todas las defs
Todos los p-usos /Algunos c-usos
Todos los p-usos
Arcos
Instrucciones
-
2008 V&V 99
Caja Negra
Las pruebas se derivan solo de la especificacin. Solo interesa la funcionalidad y no su implementacin
El probador introduce las entradas en los componentes y examina las salidas correspondientes
Si las salidas no son las previstas probablemente se detecto una falla en el software
Problema clave = Seleccionar entradas con alta probabilidad de hacer fallar al software (experiencia y algo ms)
V. U. - Prueba
-
2008 V&V 100
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.
Escriban casos de prueba para esta especificacin.
V. U. - Prueba
-
2008 V&V 101
Caja NegraV. U. - Prueba
Tringulo escaleno vlido Tringulo equiltero vlido Tringulo issceles 3 permutaciones de tringulos issceles 3,3,4 3,4,3 4,3,3 Un caso con un lado con valor nulo Un caso con un lado con valor negativo Un caso con 3 enteros mayores que 0 tal que la suma de 2 es igual a la del 3 (esto no es un tringulo vlido)
Las permutaciones del anterior Suma de dos lados menor que la del tercero (todos enteros positivos)
Permutaciones Todos los lados iguales a cero Valores no enteros Numero errneo de valores (2 enteros en lugar de 3)Todos los casos tienen especificada la salida esperada?
-
2008 V&V 102
Caja Negra
Myers presenta 4 formas para guiarnos a elegir los casos de prueba usando caja negraParticiones de equivalenciaAnlisis de valores lmitesGrafos causa-efectoConjetura de errores
Vamos a ver los dos primeros
V. U. - Prueba
-
2008 V&V 103
Caja Negra Part. Eq.
Propiedades de un buen caso de pruebaReduce significativamente el nmero de los otros casos de prueba
Cubre un conjunto extenso de otros casos de prueba posibles
Clase de equivalenciaConjunto de entradas para las cuales suponemos que el software se comporta igual
Proceso de particin de equivalencia Identificar las clases de equivalenciaDefinir los casos de prueba
V. U. - Prueba
-
2008 V&V 104
Caja Negra Part. Eq.
Identificacin de las clases de equivalenciaCada condicin de entrada separarla en 2 o ms grupos Identificar las clases vlidas as como tambin las clases invlidas
Ejemplos:o la numeracin es de 1 a 999 clase vlida 1
-
2008 V&V 105
Caja Negra Part. Eq.
Proceso de definicin de los casos de prueba1. Asignar un nmero nico a cada clase de equivalencia2. Hasta cubrir todas las clases de eq. con casos de prueba, escribir un nuevo caso de prueba que cubra tantas clases de eq. vlidas, no cubiertas, como sea posible
3. Escribir un caso de prueba para cubrir una y solo una clase de equivalencia para cada clase de equivalencia invlida (evita cubrimiento de errores por otro error)
V. U. - Prueba
-
2008 V&V 106
Caja Negra Valores Lmite
La experiencia muestra que los casos de prueba que exploran las condiciones lmite producen mejor resultado que aquellas que no lo hacen
Las condiciones lmite son aquellas que se hallan arriba y debajo de los mrgenes de las clases de equivalencia de entrada y de salida (aplicable a caja blanca)
Diferencias con particin de equivalenciaElegir casos tal que los mrgenes de las clases de eq. sean probados
Se debe tener muy en cuenta las clases de eq. de la salida (esto tambin se puede considerar en particiones de equivalencia)
V. U. - Prueba
-
2008 V&V 107
Caja Negra Valores Lmite
EjemplosLa entrada son valores entre -1 y 1 Escribir casos de prueba con entrada 1, -1, 1.001, -1.001
Un archivo de entrada puede contener de 1 a 255 registros Escribir casos de prueba con 1, 255, 0 y 256 registros
Se registran hasta 4 mensajes en la cuenta a pagar (UTE, ANTEL, etc) Escribir casos de prueba que generen 0 y 4 mensajes. Escribir un caso de prueba que pueda causar el registro de 5 mensajes. LMITES DE LA SALIDA
USAR EL INGENIO PARA ENCONTRAR CONDICIONES LMITE
V. U. - Prueba
-
2008 V&V 108
Caja Negra
En el ejemplo del tringulo detectar:Clases de equivalencia de la entradaValores lmite de la entradaClases de equivalencia de la salidaValores lmite de la salida
V. U. - Prueba
-
2008 V&V 109
Caja Negra
Algunas clases de equivalencia de la entradaLa suma de dos lados es siempre mayor que la del terceroLa suma de dos lados no siempre es mayor que la del terceroo Combinacin para todos los lados
No ingreso todos los lados
Algunos valores lmite de la entradaLa suma de dos lados es igual a la del tercero
o Combinacin para todos los lados
No ingreso ningn lado
V. U. - Prueba
-
2008 V&V 110
Caja Negra
Algunas clases de equivalencia de la salidaTringulo escalenoTringulo isscelesTriangulo equilteroNo es un tringulo vlido
Algunos valores lmite de la salida Quizs un tringulo casi vlido
o Ejemplo: lado1 = 1, lado2 =2, lado3= 3
V. U. - Prueba
-
2008 V&V 111
Un Proceso para un MduloV. U. - Prueba
Especificar Mdulo
Plan de Prueba (Caja Negra)
Implementar
Completar Plan de Prueba ( Caja Blanca)
Revisin
Jacobson sugiere ejecutar primero las pruebas de caja negra y cuando estas sean todas correctas completar con caja blanca. Esto se debe a que la caja blanca depende del cdigo y cuando se detecten errores con caja negra el cdigo cambia al corregir los errores detectados.
-
2008 V&V 112
Comparacin de las Tcnicas
Estticas (anlisis)Efectivas en la deteccin temprana de defectosSirven para verificar cualquier producto (requerimientos, diseo, cdigo, casos de prueba, etc)
Conclusiones de validez general Sujeto a los errores de nuestro razonamiento Normalmente basadas en un modelo del producto y no en el producto
No se usan para validacin (solo verificacin) Dependen de la especificacin No consideran el hardware o el software de base
Verificacin Unitaria
-
2008 V&V 113
Comparacin de las Tcnicas
Dinmicas (pruebas)Se considera el ambiente donde es usado el software (realista)
Sirven tanto para verificar como para validarSirven para probar otras caractersticas adems de funcionalidad
Est atado al contexto donde es ejecutado Su generalidad no es siempre clara (solo se aseguran los casos probados)
Solo sirve para probar el software construido Normalmente se detecta un nico error por prueba (los errores cubren a otros errores o el programa colapsa)
Verificacin Unitaria
-
2008 V&V 114
Pruebas de Integracin
TemarioPruebas de MdulosEstrategias de Integracin
o Big-Bango Bottom-Upo Top-Downo Sandwicho Por disponibilidad
Comparacin de EstrategiasBuilds en Microsoft
-
2008 V&V 115
Proceso de V&VPruebas de Integracin
Unit
Unit
Unit
PruebaIntegracin
Prueba Funcional
Prueba desempeo
Prueba Aceptacin
PruebaInstalacin
Com
pone
nt c
ode
.
.
.
com
pone
nte
verif
icad
o
Mdulos Integrados
Sistema Funcionando
Software Verificado
Sistema Aceptado
SISTEMAEN USO
Especifi-cacionesde Diseo
Requerimien-tos
funcionalesdel Sistema
Otros Requeri-
mientos delsoftware
Especificacin de Requeri-
mientos para el Cliente
Ambientede Uso
Visin simplificada....
-
2008 V&V 116
Pruebas de Mdulos
El mdulo A usa a los mdulos B, C, D.El mdulo B usa a los mdulos E y FEl mdulo D usa al mdulo G
Pruebas de Integracin
A
DCB
FE G
-
2008 V&V 117
Pruebas de Mdulos
Quiero probar al mdulo B de forma aislada No uso los mdulos A, E y FEl mdulo B es usado por el mdulo A
o Debo simular la llamada del modulo A al B Drivero Normalmente el Driver es el que suministra los datos de los casos de prueba
El mdulo B usa a los mdulos E y Fo Cuando llamo desde B a E o F debo simular la ejecucin de estos mdulos Stub
Se prueba al mdulo B con los mtodos vistos en pruebas unitarias
Driver A B
StubE
Stub F
CallCall
Call
Pruebas de Integracin
Esto quiere decir definir criterios y generar test set que cubran esos criterios
-
2008 V&V 118
Pruebas de Mdulos
Stub (simula la actividad del componente omitido)Es una pieza de cdigo con los mismos parmetros de entrada y salida que el mdulo faltante pero con una alta simplificacin del comportamiento. De todas maneras es costoso de realizar
Por ejemplo puede producir los resultados esperados leyendo de un archivo, o pidindole de forma interactiva a un testeador humano o no hacer nada siempre y cuando esto sea aceptable para el mdulo bajo test
Si el stub devuelve siempre los mismos valores al mdulo que lo llama es probable que est mdulo no sea testeado adecuadamente. Ejemplo: el Stub E siempre devuelve el mismo valor cada vez que B lo llama Es probable que B no sea testeado de forma adecuada
Pruebas de Integracin
-
2008 V&V 119
Pruebas de Mdulos
DriverPieza de cdigo que simula el uso (por otro mdulo) del mdulo que est siendo testeado. Es menos costoso de realizar que un stub
Puede leer los datos necesarios para llamar al mdulo bajo test desde un archivo, GUI, etc
Normalmente es el que suministra los casos de prueba al mdulo que est siendo testeado
Pruebas de Integracin
-
2008 V&V 120
Estrategias de Integracin
No incrementalBig-Bang
IncrementalesBottom-Up (Ascendente)Top-Down (Descendente)Sandwich (Intercalada)Por disponibilidad
El objetivo es lograr combinar mdulos o componentes individuales para que trabajen correctamente de forma conjunta
Pruebas de Integracin
-
2008 V&V 121
Big-Bang
Se prueba cada mdulo de forma aislada y luego se prueba la combinacin de todos los mdulos a la vez
A
B
StubF
StubE
StubD
StubC
StubB
DriverAPrueba del
mdulo APrueba del mdulo B
Se prueban los otros mdulos de manera similar: C, D, E, F y G
A
DCB
FE G
Despus se integran todos los mdulos a la vez y se prueba el funcionamiento en conjunto
Pruebas de Integracin
No se hacen integraciones parciales
-
2008 V&V 122
Big-Bang
Pros y contrasExisten buenas oportunidades para realizar actividades en paralelo (todos los mdulos pueden ser probados a la vez)
Se necesitan stubs y drivers para cada uno de los mdulos a ser testeados ya que cada uno se testea de forma individual
Es difcil ver cul es el origen de la falla ya que integr todos los mdulos a la vez
No se puede empezar la integracin con pocos mdulos Los defectos entre las interfaces de los mdulos no se pueden distinguir fcilmente de otros defectos
No es recomendable para sistemas grandes
Pruebas de Integracin
-
2008 V&V 123
Bottom-Up
Comienza por los mdulos que no requieren de ningn otro para ejecutar
Se sigue hacia arriba segn la jerarqua usa Requiere de Drivers pero no de Stubs
Pruebas de Integracin
FE
DriverB
DriverB
C
DriverA
G
DriverD
B
DriverA
FE
D
DriverA
G
A
DCB
FE G
En los mdulos marcados con color bordo se aplican mtodos de prueba unitaria
Es de suma importancia testear la integracin entre los mdulos. Asegurarse que se testean las distintas formas de comunicacin entre los mismos
-
2008 V&V 124
Bottom-Up
La regla general indica que para probar un mdulo todos los de abajo del mdulo a probar deben estar probados
Supongamos que C, F y D son mdulos crticos (mdulo complicado, con un algoritmo nuevo o con posibilidad alta de contener errores, etc) entonces es bueno probarlos lo antes posible
Pruebas de Integracin
F E
DriverB
DriverB
C
DriverA
G
DriverD
B
DriverA
FE
D
DriverA
G
A
DCB
FE G Hay que considerar que hay que disear e implementar de forma tal que los mdulos crticos estn disponible lo antes posible. Es importante la planificacin
-
2008 V&V 125
Top-Down
Comienza por el mdulo superior de la jerarqua usa Se sigue hacia abajo segn la jerarqua usa Requiere de Stubs pero no de Drivers
Pruebas de Integracin
BStub
FStub
E
AStub
DStub
CStub
B
AStub
DStub
C BStub
FStub
E
AStub
DC BStub
FStub
E
A
DCStub
G
BStub
FE
A
DCStub
G
B
FE
A
DCStub
G
B
FE
A
DC
G
-
2008 V&V 126
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
Pruebas de Integracin
AStub
DStub
CStub
BStub
B
AStub
DCB
StubF
StubE
AStub
DC B
FStubE
AStub
DC
B
FStubE
A
DCStub
G
B
FE
A
DCStub
G
B
FE
A
DC
G
-
2008 V&V 127
Otras Tcnicas
SandwichUsa Top-Down y Bottom-Up. Busca probar los mdulos ms crticos primero
Pruebas de Integracin
AStub
DStub
CStub
B
FE G
Por DisponibilidadSe integran los mdulos a medida de que estos estn disponibles
-
2008 V&V 128
Comparacin de las Estrategias
No incremental respecto a incrementalRequiere mayor trabajo. Se deben codificar mas Stubs y Drivers que en las pruebas incrementales
Se detectan ms tardamente los errores de interfaces entre los mdulos ya que estos se integran al final
Se detectan ms tardamente las suposiciones incorrectas respecto a los mdulos ya que estos se integran al final
Es ms difcil encontrar la falta que provoc la falla. En la prueba incremental es muy factible que el defecto est asociado con el mdulo recientemente integrado (en s mismo) o en interfaces con los otros mdulos
Los mdulos se prueban menos. En la incremental vuelvo a probar indirectamente a los mdulos ya probados.
Pruebas de Integracin
-
2008 V&V 129
Comparacin de las Estrategias
Top-down (focalizando en OO)Resulta fcil la representacin de casos de prueba reales ya que los mdulos superiores tienden a ser GUI
Permite hacer demostraciones tempranas del producto Los stubs resultan muy complejos Las condiciones de prueba pueden ser imposibles o muy difciles de crear (pensar en casos de prueba invlidos)
Bottom-Up (focalizando en OO) Las condiciones de las pruebas son ms fciles de crearAl no usar stubs se simplifican las pruebas El programa como entidad no existe hasta no ser agregado el ltimo mdulo
Pruebas de Integracin
-
2008 V&V 130
Builds en Microsoft
Iteracin: diseo, construccin, prueba (clientes involucrados en proceso de prueba) Equipos de tres a ocho desarrolladores Diferentes equipos responsables por distintas caractersticas (features)
Autonoma relativa de cada equipo sobre la especificacin de las caractersticas
Descomposicin en caractersticas
Pruebas de Integracin
-
2008 V&V 131
Enfoque Sincronizar y Estabilizar
Pruebas de Integracin
Hito 1: caractersticas ms crticas y componentes compartidos
Diseo, codificacin, prototipacin / Verificacin de Usabilidad
Builds diarios / Integracin de CaractersticasEliminar faltas severas
Hito 2: caractersticas deseablesDiseo, codificacin, prototipacin / Verificacin de Usabilidad
Builds diarios / Integracin de Caractersticas
Hito 3: caractersticas menos crticasDiseo, codificacin, prototipacin / Verificacin de Usabilidad
Builds diarios / Integracin de Caractersticas Co mpletasLiberacin a Produccin
-
2008 V&V 132
Pruebas de Sistemas OO
TemarioCaractersticasAlgunos problemas Object-Oriented programs and testing Perry y KaiserEstrategia N+
-
2008 V&V 133
Caractersticas
Normalmente son sistemas ms complicados de probar (testear)
Caractersticas que lo diferencian de otros sistemasEncapsulacin de la informacinLas clases tienen estado y comportamiento. El estado afecta al comportamiento y el comportamiento afecta al estado. Esto no es comn en lenguajes procedurales
Las unidades son ms pequeas (clases, objetos)Los mtodos son ms pequeosUn sistema OO tiene muchas ms integraciones que uno procedural
Herencia, polimorfismo y dynamic binding
Pruebas de SOO
-
2008 V&V 134
Algunos Problemas
Debido a la encapsulacin de la informacinSi tengo que testear un mtodo multX (multiplica al atributo x por el pasado en el mtodo) de una clase A y ese mtodo cambia el valor del atributo x de la clase A, Cmo s si lo cambi correctamente? Es vlido confiar en el mtodo getX de la clase A?
Pruebas de SOO
Class A {int x;public A(int px) {x = px
}public void multX(int y) {x = (x * y) - 1;
}public int getX(){return x + 1;
}}
Class PruebaMetX {main {a = new A(5);a.multX(2);int res = a.getX();if res = 10 pruebaOKelse pruebaFail
}}
En este caso la prueba pasa (resultado pruebaOK), sin embargo el valor de x en el objeto a es 9 y este es un valor incorrecto
-
2008 V&V 135
Algunos Problemas
Debido a la encapsulacin de la informacinSi la clase est debidamente testeada se crea (en los primeros tiempos de la OO) que podra ser usada en cualquier otro sistema comportndose de manera correcta. Ms adelante veremos que esto no es como se pensaba.
En definitiva, una gran bondad de la OO que es la reutilizacin no se pierde, sin embargo, hay que volver a testear la integracin (esto es debido al cambio de contexto)
Pruebas de SOO
-
2008 V&V 136
Algunos ProblemasPruebas de SOO
Debido al estado y comportamiento de los objetosCuando un objeto recibe un mensaje no siempre acta de la misma manera sino que depende del estado en que este se encuentre (el estado es el valor de todos los atributos del objeto; incluyendo otros objetos)
Cuando un objeto termina de ejecutar el mtodo, puede ser que su estado haya cambiado
Esto trae aparejado que los mtodos convencionales de testing no pueden ser aplicados tal cual. Existen mtodos que usan diagramas de estado de clases para realizar pruebas de objetos (vamos a ver uno ms adelante, estrategia N+)
-
2008 V&V 137
Algunos ProblemasPruebas de SOO
Unidades ms pequeas, mtodos ms pequeos y mayor integracin que lenguajes proceduralesSi bien los objetos manejan estados y esto hace distintas las pruebas respecto a las tradicionales, como los mtodos son ms pequeos es ms fcil realizar pruebas de caja blanca en OO que en lenguajes procedurales
Por otro lado la cantidad de objetos que interactan entre s es mucho ms grande que los mdulos que interactan en un lenguaje procedural
Se considera que la prueba de unidad es ms sencilla en sistemas OO pero las pruebas de integracin son ms extensas y tienden a ser ms complejas
-
2008 V&V 138
Algunos ProblemasPruebas de SOO
Debido a herencia, polimorfismo y dynamic bindingCuando una superclase cambia un mtodo hay que testear la subclase ya que puede haber introducido inconsistencias en est ltima. Esto es sabido desde siempre
Se crea que cuando una clase heredaba de otra que ya estaba adecuadamente testeada, los mtodos heredados no deban ser testeados. Mostraremos ms adelante que este concepto esta equivocado
-
2008 V&V 139
OO Programs and Testing
E. Perry y G. Kaiser Tiran abajo algunos mitos sobre las pruebas de sistemas Orientados a Objetos
Para hacerlo se basan en los axiomas de J. Weyuker: Axiomatizing Software Test Data Adequacy
DefinicinUn programa est adecuadamente testeado si a sido cubierto de acuerdo al criterio seleccionado (el criterio puede ser tanto estructural como funcional)
Pruebas de SOO
-
2008 V&V 140
OO Programs and Testing
E. Perry y G. Kaiser Axiomas de J. Weyuker
Applicabilityo Para cada programa existe un test set adecuado
Non-Exhaustive Applicabilityo Para un programa P existe un test set T tal que P es adecuadamente testeado por T, y T no es un test exhaustivo
Monotonicityo Si T es adecuado para P y T es un subconjunto de T entonces T es adecuado para P
Inadequate empty seto El conjunto vaco no es un test set adecuado para ningn programa
Pruebas de SOO
-
2008 V&V 141
OO Programs and Testing
E. Perry y G. Kaiser Axiomas de J. Weyuker
Renamingo Sea P un renombre de Q entonces T es adecuado para P si y solo si T es adecuado para Q
o Un programa P es un renombre de Q si P es idntico a Q excepto que todas las instancias de un identificador x de Q ha sido reemplazado en P por un identificador y, donde y no aparece en Q. O si hay un conjunto de estos renombres
Complexityo Para todo n > 0, hay un programa P, tal que P es adecuadamente testeado por un test set de tamao n pero no por un test set de tamao n 1
Statement coverageo Si T es adecuado para P entonces T causa que toda sentencia ejecutable de P sea ejecutada
Pruebas de SOO
-
2008 V&V 142
OO Programs and Testing
E. Perry y G. Kaiser Axiomas de J. Weyuker
Antiextensionalityo Si dos programas computan la misma funcin, un test set adecuado para uno no es necesariamente adecuado para el otro
General Multiple Changeo Cuando dos programas son sintcticamente similares (tienen la misma forma) usualmente requieren test set diferentes
o Existen programas P y Q que tienen la misma forma y un test set T que es adecuado para P, pero T no es adecuado para Q
o Dos programas son de la misma forma si uno puede ser transformado en el otro aplicando las siguientes reglas
Reemplazar el operador r1 por el r2 Reemplazar la constante c1 por la c2
Pruebas de SOO
-
2008 V&V 143
OO Programs and Testing
E. Perry y G. Kaiser Axiomas de J. Weyuker
Antidecompositiono Testear un componente en el contexto de un programa puede ser adecuado respecto a ese programa pero no necesariamente respecto a otros usos de esa componente
o Se testea adecuadamente el programa P con el test set T pero el test set T que es la entrada a Q desde P no es adecuado para Q
Anticompositiono Testear adecuadamente cada componente de forma aislada no necesariamente testea adecuadamente todo el programa. La integracin de dos componentes resulta en interacciones que no pueden surgir en aislamiento
Pruebas de SOO
-
2008 V&V 144
OO Programs and Testing
E. Perry y G. Kaiser Axiomas de J. Weyuker
o Supongamos que P tiene p caminos y que Q tiene q caminos con q
-
2008 V&V 145
OO Programs and Testing
E. Perry y G. Kaiser Encapsulacin en clases Mito:
Si mantenemos las interfaces de una clase sin cambiar, y cambiamos la implementacin interna manteniendo la misma funcionalidad, no hay que volver a testear las clases que usan la clase modificada
Realidad:El axioma anticomposition nos recuerda la necesidad de volver a testear tambin todas las unidades dependientes porque un programa que fue testeado adecuadamente de forma aislada puede no estar adecuadamente testeado en combinacin. Esto significa que adems del testeo de unidad que hay que realizar en la clase modificada tambin hay que realizar testeo de integracin
Pruebas de SOO
-
2008 V&V 146
OO Programs and Testing
E. Perry y G. Kaiser Encapsulacin en clases
Cuando modifico una clase se debe volver a testear esa clase y todas las que se relacionan explcitamente con esta
Clase Modificada
Volver a Testear
No se vuelve a testear
El re-test en este caso es obvio
Pruebas de SOO
-
2008 V&V 147
OO Programs and Testing
E. Perry y G. Kaiser Subclases nuevas o modificaciones de subclases Mito:
No se deben testear los mtodos heredados de la superclase ya que fueron testeados en esta
Realidad:El axioma antidecomposition nos dice lo contrario. El uso de subclases agrega esta inesperada forma de dependencia porque provee un nuevo contexto para las componentes heredadas.
Pruebas de SOO
-
2008 V&V 148
OO Programs and Testing
E. Perry y G. Kaiser
Pruebas de SOO
A
met1() {met2(p1,p1)
}
met2(p1,p2){}
B
//redefine met2met2(p1,p2){}
El mtodo met2 se redefine en la clase B. Esto genera un nuevo contexto y es por esto que se debe volver a testear met1 para la clase B, debido a que met1 llama a met2
-
2008 V&V 149
OO Programs and Testing
E. Perry y G. Kaiser Cuando la subclase es una extensin pura de la superclase entonces no es necesario volver a testear.
Definicin de extensin puraLas nuevas variables creadas por la subclase as como los nuevos mtodos no interactan en ninguna direccin con las variables heredadas ni con los mtodos heredados
Pruebas de SOO
-
2008 V&V 150
OO Programs and Testing
E. Perry y G. Kaiser Sobre-escritura de mtodos Mito:
Al sobre-escribir un mtodo heredado se puede testear adecuadamente la subclase con un test set adecuado para la superclase
Realidad:Aunque muy probablemente los dos mtodos (el de la superclase y el sobre-escrito en la subclase) computen una funcin semnticamente similar un test set adecuado para uno no tiene porque ser adecuado para el otro. Esto se deduce a partir del axioma antiextensionality
Pruebas de SOO
-
2008 V&V 151
OO Programs and Testing
E. Perry y G. Kaiser Conclusin ms general
Se revoca la intuicin que antes se tena de que la encapsulacin y la herencia iban a reducir los problemas del testing
Pruebas de SOO
-
2008 V&V 152
Testeo de Unidad en OO
Es un acuerdo casi universal que el objeto es la unidad bsica para el diseo de casos de prueba
Otras unidades para testear son agregaciones de clases: class cluster (normalmente patterns de diseo) y pequeos subsistemas
El testing de sistemas orientados a objetos difiere en algunos aspectos del testing de sistemas estructurados
Pruebas de SOO
-
2008 V&V 153
Estrategia N+
Como mencionamos hay clases que son estado-dependientesEjemplo: Lista o Pila
o Estados: Vaca, ConElementos, Llena
Mtodos de la clase Pilao Pila(t:int) / pre: t>1 ; post: maxSize=t@pre y n=0o Pila(t:int,e:Elemento) / pre: t>1 ; post: maxSize=t@pre y e pertenece a la pila como ltimo elemento insertado y n=1
o push(e:Element) / pre: n!=maxSize ; post: n=n@pre+1 y e pertenece a la pila como ltimo elemento insertado
o get():Element / pre: n>0 ; post: n=n@pre-1 y el ltimo elemento insertado no est ms en la pila y result=al ltimo elemento insertado
Estos mtodos los sabemos testear (caja negra o blanca)
Pruebas de SOO
-
2008 V&V 154
Estrategia N+
Diagrama de estado de la clase Pila
Pruebas de SOO
Vacia
ConElementos
Llena
Pila(t:int) [t>=1]
Pila(t:int, e:Element) [t>1]
Pila(t:int, e:Element) [t=1]
push(e:Element) [n=maxSize-1]
push(e:Element) [n=maxSize-1]
push(e:Element) [n
-
2008 V&V 155
Estrategia N+
La estrategia N+ es una estrategia propuesta por Binder y se divide en dos partesAll round-trip pathSneak paths
All round-trip pathLos casos de prueba deben cubrir:
o Todos los caminos simples desde el estado inicial al finalo y todos los caminos que empiezan y terminan en un mismo estado
Sneak pathsLos casos de prueba deben cubrir:
o Todos los mensajes no esperados en cierto estado (ejemplo: un push en el estado lleno)
Pruebas de SOO
-
2008 V&V 156
Estrategia N+
All round-trip pathPrimero construimos el rbol de transicin haciendo una recorrida en profundidad (tambin puede ser en amplitud) del diagrama de estados
La recorrida de un camino se detiene siempre que el estado al que se llega ya est presente en el rbol
En el caso de guardas con varios conectores se agregan transiciones. No vamos a profundizar en este tema
Luego para cada camino desde el nodo inicial hasta el final se realiza un caso de prueba (esto asegura cumplir con el criterio All round-trip path)o TODOS LOS CASOS JUNTOS CUBREN ALL ROUND TRIP PATH
Pruebas de SOO
-
2008 V&V 157
Estrategia N+Pruebas de SOO
Start
Vacia
Pila(t:int) [t>=1]
ConElementos
push(e:Element) [n1]
1
87
6
54
32
-
2008 V&V 158
Estrategia N+
Un caso de prueba:Pila p = new Pila(2);Chequear poscondiciones del mtodo PilaChequear estado de la clase = VaciaElement e = new Element();p.push(e);Chequear poscondiciones del mtodo pushChequear estado de la clase = ConElementosp.push(e);Chequear poscondiciones del mtodo pushChequear estado de la clase = LlenaElement z = p.get();Chequear poscondiciones del mtodo getChequear estado de la clase = ConElementos
Pruebas de SOO
-
2008 V&V 159
Estrategia N+
Cada estado debe estar definido en funcin de restricciones respecto a los miembros de la clase
A partir de estas restricciones se puede chequear en que estado est la clase
Otra forma es proveer mtodos isEstate() que devuelven true si la clase se encuentra en el estado y false en caso contrario. Estos mtodos chequean las restricciones
Pruebas de SOO
-
2008 V&V 160
Estrategia N+
Sneak paths
Pongo a la clase en un estado y le mando mensajes no vlidos
Ejemplos:o La clase est en el estado Llena y le mando mensaje push(e)o La clase est en el estado Vaca y le mando un mensaje get()
Estos test complementan los realizados por All round-trippath
Pruebas de SOO
-
2008 V&V 161
Tipos de Testing OO
Propuesta muy comn:Testing de mtodos individuales
o Dada la definicin funcional de un mtodo se testea segn tcnicas que ya vimos
Testing intraclaseo Se busca testear la relacin entre los mtodos de una clase. Porejemplo, estrategia N+. Existen otras formas
Testing interclaseso Similar al test de integracin solo que como ya se comento es ms complejo por la cantidad de interacciones
Testing funcionalEtc...
Los dos primeros se corresponden al testing unitario
Pruebas de SOO
-
2008 V&V 162
Pruebas del Sistema
TemarioPrueba Funcional
o A partir de casos de uso
Prueba de DesempeoPrueba de AceptacinPrueba de Instalacin
-
2008 V&V 163
Proceso de V&VPruebas del Sistema
Unit
Unit
Unit
PruebaIntegracin
Prueba Funcional
Prueba desempeo
Prueba Aceptacin
PruebaInstalacin
Com
pone
nt c
ode
.
.
.
com
pone
nte
verif
icad
o
Mdulos Integrados
Sistema Funcionando
Software Verificado
Sistema Aceptado
SISTEMAEN USO
Especifi-cacionesde Diseo
Requerimien-tos
funcionalesdel Sistema
Otros Requeri-
mientos delsoftware
Especificacin de Requeri-
mientos para el Cliente
Ambientede Uso
Visin simplificada....
-
2008 V&V 164
Las Distintas Pruebas del Sist.
Prueba de funcinVerifica que el sistema integrado realiza sus funciones especificadas en los requerimientos
Prueba de desempeoVerifica los requerimientos no funcionales del sistema
Prueba de aceptacinSe realiza junto con el cliente. Busca asegurar que el sistema es el que el cliente quiere
Prueba de instalacinSe realizan las pruebas en el ambiente objetivo
Pruebas del Sistema
-
2008 V&V 165
Prueba de Funcin
La idea es probar las distintas funcionalidades del sistemaSe prueba cada funcionalidad de forma individual
o Esto puede ser testeo de casos de uso
Se prueban distintas combinaciones de funcionalidadeso Ciclos de vida de entidades (alta cliente, modificacin del cliente, baja del cliente)
o Procesos de la organizacin (pedido de compra, gestin de la compra, envi y actualizacin de stock)
o Esto se puede ver como testeo de ciclos de casos de usos
El enfoque es ms bien de caja negra Est prueba est basada en los requerimientos funcionales del sistema
Pruebas del Sistema
-
2008 V&V 166
Prueba de Funcin Use Case
Se hace la prueba funcional a partir de los casos de uso
Se identifican los distintos escenarios posibles y se usan como base para las condiciones de prueba
Se completan las condiciones en funcin de los tipos de datos de entrada y de salida
A partir de las condiciones se crean los Casos de Prueba
Pruebas del Sistema
-
2008 V&V 167
Precondicin:el cliente ingres una tarjeta vlida e ingres nro. de PIN
Flujo Principal:1. El CA despliega las distintas alternativas disponibles,el Cliente elige Retiro2. El CA pide cuenta y monto y el Cliente los elige (o ingresa)3. CA enva Id. Tarjeta, PIN, cuenta y monto 4. SC (Servicio de Cajeros) contesta: Continuar (OK) o No Continuar5. CA dispensa el dinero6. CA devuelve la tarjeta7. CA imprime el recibo
4A. Importe invlidoSi el monto indicado por el cliente no puede obtenerse a partir de los billetes de que dispone el CA, este despliega un mensaje de advertencia y le solicita que ingrese nuevamente el importe. No hay lmite de repeticiones.
4B. No hay suficiente saldo en la cuenta.4B1. CA despliega mensaje al Cliente y devuelve la tarjeta (no se imprime recibo)
Caso de Uso: RetiroPruebas del Sistema
-
2008 V&V 168
Instancias de un Casos de Uso1. Flujo Principal2. Flujo Principal- Importe invlido (n)3. Flujo Principal- No hay suficiente saldo en
cuenta
Caso de Uso: RetiroPruebas del Sistema
-
2008 V&V 169
No exitoso3. Normal- sin saldo
Retiro exitoso2. Normal-Importe invlido (n)
Retiro exitoso1. Normal
CasoTipo de ResultadoCondiciones
Condiciones de PruebaPruebas del Sistema
-
2008 V&V 170
No exitoso3. Normal- sin saldo
Retiro exitoso2. Normal-Importe invlido (n)
1.2 Normal Cuenta Corriente
1.1 Normal Caja de Ahorros
Retiro exitoso1. Normal
CasoTipo de ResultadoCondiciones
Condiciones de PruebaPruebas del Sistema
-
2008 V&V 171
13131...13131...13131...Recibo
SSSSDev.tarjeta
$1200$500$100Dispensa
Sin saldoImporte invlido
Salidas
100120012500100Monto
1.2
CC321
9001
13131
A2
CC321
9001
13131
A3
21.1
CA128
9001
13131
A1
9002PIN
23232Tarjeta
3Condics.
CA228Cuenta
Entradas
A4\Caso
Casos de PruebaPruebas del Sistema
-
2008 V&V 172
Prueba de Desempeo
Lo esencial es definirProcedimientos de prueba
o Ejemplo: Tiempo de respuesta Simular la carga, tomar los tiempos de tal manera, nmero de
casos a probar, etc
Criterios de aceptacino Ejemplo
El cliente lo valida si en el 90% de los casos de prueba en el ambiente de produccin se cumple con los requerimientos de tiempo de respuesta
Caractersticas del ambienteo Definir las caractersticas del ambiente de produccin ya que estas hacen grandes diferencias en los requerimientos no funcionales
Pruebas del Sistema
-
2008 V&V 173
Prueba de Desempeo
Prueba de estrs (esfuerzo)Prueba de volumenPrueba de facilidad de usoPrueba de seguridadPrueba de rendimientoPrueba de configuracinPrueba de compatibilidadPrueba de facilidad de instalacinPrueba de recuperacinPrueba de confiabilidadPrueba de documentacin
Pruebas del Sistema
-
2008 V&V 174
Prueba de Desempeo
Prueba de estrs (esfuerzo)Esta prueba implica someter al sistema a grandes cargas o esfuerzos considerables.
No confundir con las pruebas de volumen. Un esfuerzo grande es un pico de volmenes de datos (normalmente por encima de sus lmites) en un corto perodo de tiempo
No solo volmenes de datos sino tambin de usuarios, dispositivos, etc
Analoga con dactilgrafoo Volumen: Ver si puede escribir un documento enormeo Esfuerzo: Ver si puede escribir a razn de 50 palabras x minuto
Ejemploo Un sistema de conmutacin telefnica es sometido a esfuerzo generando un nmero grande de llamadas telefnicas
Pruebas del Sistema
-
2008 V&V 175
Prueba de Desempeo
Prueba de volumenEsta prueba implica someter al sistema a grandes volmenes de datos
El propsito es mostrar que el sistema no puede manejar el volumen de datos especificado
Ejemploso A un compilador lo ponemos a compilar un programa absurdamente grande
o Un simulador de circuito electrnico puede recibir un circuito diseado con miles de componentes
Pruebas del Sistema
-
2008 V&V 176
Prueba de Desempeo
Prueba de facilidad de usoTrata de encontrar problemas en la facilidad de usoAlgunas consideraciones a tener en cuenta
o Ha sido ajustada cada interfaz de usuario a la inteligencia y nivel educacional del usuario final y a las presiones del ambiente sobr el ejercidas?
o Son las salidas del programa significativas, no-abusivas y desprovistas de la jerga de las computadoras?
o Son directos los diagnsticos de error (mensajes de error) o requieren de un doctor en ciencias de la computacin?
Myers presenta ms consideraciones. Lo que importa es darse cuenta lo necesario de este tipo de pruebas. Si no se realizan el sistema puede ser inutilizable.
Algunas se pueden realizar durante el prototipado
Pruebas del Sistema
-
2008 V&V 177
Prueba de Desempeo
Prueba seguridadLa idea es tratar de generar casos de prueba que burlen los controles de seguridad del sistema
Ejemploo Disear casos de prueba para vencer el mecanismo de proteccin de la memoria de un sistema operativo
Una forma de encontrar casos de prueba es estudiar problemas conocidos de seguridad en sistemas similares. Luego mostrar la existencia de problemas parecidos en el sistema bajo test.
Existen listas de descripciones de fallas de seguridad en diversos tipos sistemas
Pruebas del Sistema
-
2008 V&V 178
Prueba de Desempeo
Prueba de rendimientoGenerar casos de prueba para mostrar que el sistema no cumple con sus especificaciones de rendimiento
Casoso Tiempos de respuesta en sistemas interactivoso Tiempo mximo en ejecucin de alguna tarea
Normalmente esto est especificado bajo ciertas condiciones de carga y de configuracin del sistemao Ejemplo
El proceso de facturacin no debe durar ms de una hora en las siguientes condiciones:
Se ejecuta en el ambiente descrito en el anexo 1 Se ejecuta para 10.000 empleados
Pruebas del Sistema
-
2008 V&V 179
Prueba de Desempeo
Prueba de configuracinSe prueba el sistema en distintas configuraciones de hardware y software
Como mnimo las pruebas deben ser realizadas con las configuraciones mnima y mxima posibles
Prueba de compatibilidadSon necesarias cuando el sistema bajo test tiene interfaces con otros sistemas
Se trata de determinar que las funciones con la interfaz no se realizan segn especifican los requerimientos
Pruebas del Sistema
-
2008 V&V 180
Prueba de Desempeo
Prueba de facilidad de instalacinSe prueban las distintas formas de instalar el sistema
Prueba de recuperacinSe 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
Pruebas del Sistema
-
2008 V&V 181
Prueba de Desempeo
Prueba de confiabilidadEl propsito de toda prueba es aumentar la confiabilidad del sistema
Este tipo de prueba es aquella que se realiza cuando existen requerimientos especficos de confiabilidad del sistema Se deben disear casos de prueba especiales
Esto no siempre es fcilo Ejemplo: El sistema Bell TSPS dice que tiene un tiempo de detencin de 2 horas en 40 aos.
No se conoce forma de probar este enunciado en meses o en unos pocos aos
De otros casos se puede estimar la validez con modelos matemticoso Ejemplo: El sistema tiene un valor medio de tiempo entre fallas de 20 horas
Pruebas del Sistema
-
2008 V&V 182
Prueba de Desempeo
Prueba de documentacinLa documentacin del usuario debe ser objeto de inspeccin controlando su exactitud y claridad (entre otros)
Adems todos los ejemplos que aparezcan en la misma deben ser codificados como casos de prueba. Es importantsimo que al ejecutar estos casos de prueba los resultados sean los esperadoso Un sistema uruguayo tiene en su manual de usuario un ejemplo que no funciona en el sistema
Pruebas del Sistema
-
2008 V&V 183
Prueba de Desempeo
Se mostraron algunos de los tipos de prueba pero no se dio ningn mtodo de cmo estas se realizan
Los mtodos y los tipos de prueba dependen mucho del sistema que se est diseando
Existen herramientas que automatizan algn tipo de estas pruebas. Por ejemplo las pruebas de esfuerzo
Pruebas del Sistema
-
2008 V&V 184
Prueba de Aceptacin e
Instalacin Prueba de aceptacin
El cliente realiza estas pruebas para ver si el sistema funciona de acuerdo a sus requerimientos y necesidades
Prueba de instalacinSu mayor propsito es encontrar errores de instalacinEs de mayor importancia si la prueba de aceptacin no se realiz en el ambiente de instalacin
Pruebas del Sistema
-
2008 V&V 185
Otras Pruebas
Desarrollo para mltiples clientesPrueba Alfa
o Realizada por el equipo de desarrollo sobre el producto final
Prueba Betao Realizada por clientes elegidos sobre el producto finalo Se podra decir que Windows est siempre en Beta testing
Desarrollo de un sistema que sustituye a otroPruebas en paralelo
o Se deja funcionando el sistema viejo mientras se empieza a usar al nuevo
o Se hacen comparaciones de resultados y se intenta ver que el sistema nuevo funciona adecuadamente
Pruebas del Sistema
-
2008 V&V 186
Otras Pruebas
Pruebas de regresinDespus de que se realizan modificaciones se verifica que lo que ya estaba probado sigue funcionando
Conviene tener automatizadas las pruebas as las pruebas de regresin se pueden hacer con mucha mayor rapidez?
Pruebas pilotoSe pone a funcionar el sistema en produccin de forma localizada
Menor impacto de las fallas
Pruebas del Sistema
-
2008 V&V 187
Herramientas
TemarioDistintos tipos de herramientasClasificacin de testingfaqs.org
-
2008 V&V 188
Distintos Tipos de Herramientas
Cada vez son ms utilizadas. Existen procesos en los cuales su uso es obligatorio (XP)
Herramientas para verificacin automatizada (centradas en el cdigo)Estticas (no se ejecuta el programa)
o Chequean sintaxiso Generan grafos de flujo de control y pueden detectar problemas de estructura
Dinmicas (se ejecuta el programa)o Rastreo de la ejecucino Examinar el contenido de la memoria o instancias de datos
Herramientas
-
2008 V&V 189
Distintos Tipos de Herramientas
Herramientas para ejecucin de pruebasAutomatizacin
o Elaboracin del plan de pruebao Ejecucin
Captura y reproduccino Digitaciones, clicks y movimientos del mouseo Se guardan los datos y los resultados esperadoso Luego de detectar un defecto y corregirlo son usadas para repetir las pruebas
Generacin de drivers y de stubso Asisten en la generacin automtica de drivers y stubs
Herramientas
-
2008 V&V 190
Distintos Tipos de Herramientas
OtrasEvaluadoras de cobertura
o Instrumentacin automtica (modificacin) del cdigo para registrar la cobertura (por ejemplo: Hansel)
Generadores de casos de pruebao A partir del cdigo fuenteo Generan casos de prueba para asegurar determinada coberturao Tambin a partir de especificaciones
Ambientes integradoso Ofrecen conjunto de facilidadeso Integran los tipos de herramientas mencionados ms algunos otros tipos no vistos en el curso
Herramientas
-
2008 V&V 191
Clasificacin www.testingfaqs.org/tools.htm
Test Design ToolsHerramientas que ayudan a decidir cuales tests se necesitan ejecutar (Ej: McCabe Test)
GUI Test DriversHerramientas que automatizan la ejecucin de tests para productos que usan interfaces grficas
Load and Performance ToolsHerramientas que se especializan en poner una carga alta en el sistema
Unit Test ToolsHerramientas que soportan el testing unitario
Herramientas
-
2008 V&V 192
Clasificacin www.testingfaqs.org/tools.htm
Test Implementation ToolsGeneran stubsGeneran assertions para hacer las faltas mas obvias
Test Evaluation ToolsAyudan a evaluar que tan buenos son los test setPor ejemplo code coverage
Static Analysis ToolsHerramientas que analizan programas sin correrlos
Defect Tracking ToolsHerramientas que ayudan a manejar una base de datos de reportes de errores
Herramientas
-
2008 V&V 193
Clasificacin www.testingfaqs.org/tools.htm
Test ManagersAyudan a gerenciar grandes cantidades de test set
Herramientas
-
2008 V&V 194
JUnit
Artculo a leer: Infected: Programmers Love Writing Tests
JUnit es una herramienta de testing unitario para Java
Para cada clase creamos otra que es la que va a testear el correcto funcionamiento de esta
Herramientas
-
2008 V&V 195
JUnit El famoso ejemplo del tringulo
Herramientas
public class Triangulo {
private int lado1 = 0; private int lado2 = 0; private int lado3 = 0;
public Triangulo(int parLado1, int parLado2, int parLado3) throws Exception {if ( ((parLado1 + parLado2)