09-Verificacion-Validacion

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]


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?


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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)


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


Requerimien-tos


Otros Requeri-

mientos delsoftware



Ambientede Uso


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


2008 V&V 131

Enfoque Sincronizar y Estabilizar


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


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


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


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



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



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



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



o Supongamos que P tiene p caminos y que Q tiene q caminos con q

2008 V&V 145


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


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


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


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


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


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


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


Requerimien-tos


Otros Requeri-

mientos delsoftware



Ambientede Uso


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


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


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


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


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)

09-Verificacion-Validacion

Documents

Transcript of 09-Verificacion-Validacion