TEMA 7: VALIDACIÓN - infor.uva.esjvalvarez/docencia/tema7.pdf · codificación y antes de las...

Departamento de InformticaUniversidad de Valladolid

Campus de Segovia______________________

TEMA 7:VALIDACIN

TCNICAS DE PRUEBA DEL SOFTWARE

Introduccin Aspectos psicolgicos de las pruebas Flujo de informacin de la prueba Pruebas indirectas. Inspecciones, recorridos,

pruebas de escritorio. Pruebas directas. Tcnicas de diseo de casos de

prueba Pruebas por mdulos o de integracin Depuracin

TCNICAS DE PRUEBAS DEL SOFTWARE. INTRODUCCIN

Representan una revisin final de las especificaciones, del diseo y de la codificacin.

OBJETIVOS: El objetivo de la prueba es descubrir algn error.

Un caso de prueba es bueno cuando su ejecucin conlleva una probabilidad elevada de encontrar un error y tiene xito cuando lo detecta.

LA PRUEBA ES EL PROCESO DE EJECUTAR UN PROGRAMA CON EL FIN DE ENCONTRAR ERRORES

ASPECTOS PSICOLGICOS

Existe un sentimiento generalizado que considera de forma despectiva la misin de la prueba.

Su naturaleza destructiva junto con otros factores externos tales como las limitaciones temporales, el coste, la oportunidad del producto, etc... Hacen que el ingeniero se sienta incomodo y no se involucre de forma adecuada en el proceso.

Este hecho hace que se pueda cuestionar de una forma justificada la objetividad del creador frente a la bsqueda de fallos

Por tanto la prueba deber ser realizada por un equipo de personas, en su mayora, ajenas al proyecto.

FLUJO DE INFORMACIN DEL SOFTWARE

PRUEBA

EVALUACINDEPURACIN

MODELO DEFIABILIDAD

CONFIGURACIN DELSOFTWARE RESULTADOS

DE LA PRUEBAERRORES

DATOS DE TASASDE ERROR

CONFIGURACIN DELA PRUEBA

RESULTADOS ESPERADOS

PREDICCINFIABILIDAD

CORRECCIONES

CONFIGURACIN DEL SOFTWARE:Especificacin de requisitosEspecificacin del diseocdigo fuente

CONFIGURACIN DE PRUEBA:Plan de procedimientoherramienta de pruebaCasos de pruebaResultados que se espera obtener

PRUEBAS INDIRECTAS. INSPECCIONES, RECORRIDAS Y REVISIONES DEL

PROGRAMA

Estos mtodos son conocidos como indirectos o procesos de prueba sin ordenador.

Estas deben realizarse justo despus de la codificacin y antes de las pruebas basadas en el uso de la computadora.

Estos mtodos implican la lectura o inspeccin visual del programa.

Son realizadas por un equipo de personas. Objetivo: Encontrar errores, no soluciones. Este tipo de mtodos detectan grupos de errores lo

que permite a posteriori una correccin masiva.

DISEO DE CASOS DE PRUEBA

Para cualquier producto de ingeniera existen dos enfoques a la hora de probar un producto:

Pruebas de Caja Blanca: Se centra en el estudio minucioso de la operatividad de una

parte del sistema considerando los detalles procedurales (la lgica del sistema).

Pruebas de Caja Negra: Analiza principalmente la compatibilidad entre s, en cuanto

a las interfaces, de cada uno de los componentes del software (no tiene en cuenta la lgica del sistema).

Combinando ambas estrategias se obtiene una ms completa validacin del software

TCNICAS DE DISEO DE CASOS DE PRUEBA

Propsito: Reducir el nmero de casos de prueba manteniendo la

efectividad de la prueba

Enfoques: Caja negra (que es lo que hace) Caja blanca (como lo hace)

PRUEBAS DE CAJA BLANCA

Usa la estructura de control del diseo procedimentalpara obtener los casos de prueba.

Estos casos deben garantizar: Que se ejercita por lo menos una vez todos los caminos

independientes de cada mdulo. Que se ejerciten todas las decisiones lgicas en sus

vertientes verdadera y falsa. Que se ejecuten todos los bucles en sus lmites

operacionales. Que se ejerciten las estructuras internas de datos para

asegurar su validez.

Los errores se esconden en los rincones y se aglomeran en los lmites [Beizer].

PRUEBA DEL CAMINO BSICO

Es una tcnica para obtener casos de prueba de caja blanca.

Este mtodo permite obtener una medida de la complejidad lgica de un diseo procedimental.

Esta medida puede ser usada como gua a la hora de definir un conjunto bsico de caminos de ejecucin (diseo de casos de prueba).

Para la obtencin de la complejidad lgica o ciclomtica emplearemos una representacin del flujo de control en forma de grafo (Grafo del flujo).

REPRESENTACIN DEL GRAFO DE FLUJO DE LAS ESTRUCTURAS DE

CONTROL

SECUENCIA

IF

ELSE

THEN

END-IF SI,..SINO..

WHILE

REPRESENTACIN DEL GRAFO DE FLUJO DE LAS ESTRUCTURAS DE

CONTROL

REPEAT

CASE

OPCION1

ENDCASE

OPCION2

OPCIONn

.........

CASE OF

EJEMPLO. DIAGRAMA DE FLUJO

1

3

6

7 8 5

4

2

910

INICIO

FIN

EJEMPLO. GRAFO DE FLUJO

7 8

9

11

10

6 4,5

2,3

1

GRAFOS ASOCIADOS A CONDICIONES LGICAS

COMPUESTAS

Y X

ENDIF

B X

A

X Y

ENDIF

B Y

A

IF A OR B THEN XELSE Y

F

F

T

T

T

T

F

F

IF A AND B THEN XELSE Y

COMPLEJIDAD CICLOMTICA

Es una medida del software que aporta una valoracin cuantitativa de la complejidad lgica de un programa.

Dentro del contexto del mtodo de pruebas del camino bsico define el nmero de caminos independientes de un programa.

Por camino independiente se entiende aquel que introduce un nuevo conjunto de sentencias o una nueva condicin. En trminos del grafo, por una arista que no haya sido recorrida antes.

Nos da una cota o lmite superior para el nmero de casos de prueba.

CLCULO DE LA COMPLEJIDAD CICLOMTICA

Formas de clculo:

El nmero de regiones del grafo es igual a la complejidad ciclomtica.

V(G)=A-N+2 Donde A es el nmero de aristas y N es el nmero de nodos

contenidos en el grafo. V(G)=P+1

Donde P es el nmero de nodos predicados contenidos en el grafo.

DERIVACIN DE LOS CASOS DE PRUEBA

Pasos a seguir: Representacin del grafo de flujo asociado al cdigo fuente

del programa. Clculo de la complejidad ciclomtica. Determinacin de un conjunto de caminos bsicos. Dicho

conjunto bsico, para un grafo dado, puede no ser nico y existir distintas posibilidades.

Se preparan los casos que obligan a la ejecucin de cada camino del conjunto bsico.

Los casos de prueba as derivados garantizan que: al menos una vez se ejecute cada sentencia cada condicin se haya probado en sus dos vertientes

(verdadera y falsa).

COMPLEJIDAD CICLOMTICA.CAMINOS BSICOS.

V(G)=4 RegionesV(G)= 11A-9N+2=4V(G)=3NP+1=4

CAMINOS BSICOS:Camino 1: 1-11Camino 2: 1-2-3-4-5-10-1-11Camino 3: 1-2-3-6-8-9-10-1-11Camino 4: 1-2-3-6-7-9-10-1-11

7 8

9

11

10

6 4,5

2,3

1

R4

R1

R2

R3

EJEMPLO Disear el conjunto de casos de prueba mediante el

mtodo de la complejidad ciclomtica para el siguiente cdigo:

r:=0;if (x

EJEMPLO

x

EJEMPLO. CONVERSIN AL GRAFO DE FLUJO

5 4

6

3 4

2

1

F

F

T

T

R2R1

R3

V(g)=3 regiones=3V(g)=8A-7N+2=3V(g)=2NP+1=3

EJEMPLO. CONJUNTO DE CAMINOS BSICOS

Habr tantos caminos bsicos como grados de complejidad posee e cdigo.

En este caso tenemos tres caminos bsicos:

C1: 1-2-4-6 C2: 1-2-3-4-5 C3: 1-2-3-5-6

La derivacin de los casos a partir de los caminos bsicos es inmediato:

C1: x

PRUEBAS DE CAJA BLANCA. COBERTURA LGICA

Cobertura de Sentencia.

Cobertura de Decisiones.

Cobertura de Condiciones.

Cobertura de Condicin Mltiple.

COBERTURA DE SENTENCIA

Esta cobertura requiere que se ejecute por lo menos una vez cada sentencia del programa.

Este criterio es necesario pero no suficiente

Es un criterio dbil

No se comprueban ambas vertientes de las condiciones.

COBERTURA DE DECISIN

Este criterio establece que es necesario escribir un nmero suficiente de casos de prueba como para que cada decisin tenga por lo menos un resultado verdadero o falso.

Este criterio es ms fuerte que el de sentencia pero an presenta debilidades.

En sentencias condicionales compuestas puede quedar enmascarada una de las condiciones.

COBERTURA DE CONDICIN

En este criterio es necesario presentar un nmero suficiente de casos de prueba de modo que cada condicin en una decisin tenga, al menos una vez, todos los resultados posibles.

Este criterio es ms fuerte que el anterior. Hay que ser cuidadoso con la eleccin de los casos

de prueba por que aunque se garanticen la ejecucin de las condiciones puede ocurrir que alguna clusula de la decisin no sea ejecutada.

COBERTURA MLTIPLE

La solucin lgica a lo anterior es utilizar un criterio que requiera un nmero suficiente de casos de prueba tal que todas las combinaciones posiblesde resultados de condicin en cada decisin y todos los puntos de entrada se invoquen al menos una vez.

Satisface los criterios de cobertura anteriormente citados.

EJEMPLO. POSIBLES COMBINACIONES

1: x0 e y0 2: x0 e y

EJEMPLO. POSIBLES COMBINACIONES

x

DISEO DE CASOS DE PRUEBA MEDIANTE CAJA NEGRA

Enfoque de caja negra: Tambin denominadas pruebas de comportamiento.

Consideran la funcin especfica para la cul fue creado el producto (lo que hace).

Las pruebas se llevan a cabo sobre la interfaz del sistema.

Reduce el nmero de casos de prueba mediante la eleccin de condiciones de entrada y salida vlidas y no vlidas que ejercitan toda la funcionalidad del sistema.

TIPOS DE ERRORES QUE DETECTA

Funciones incorrectas o ausentes Errores de la interfaz Errores en estructuras de datos o accesos a

bases de datos Errores de rendimiento Errores de inicializacin y terminacin

TCNICAS DE PRUEBA DE CAJA NEGRA

Particin Equivalente

Anlisis de Valores Lmites

EL MTODO DE PARTICIN EQUIVALENTE (PE)

Se basa en la divisin del campo de entradaen un conjunto de clases de datos denominadas clases de equivalencia.

CONCEPTO DE CLASE EQUIVALENTE

Clase de equivalencia: un conjunto de datos de entrada que definen estados vlidos y no vlidos del sistema.

Clase vlida: genera un valor esperado Clase no vlida: genera un valor inesperado

Se obtienen a partir de las condiciones de entrada descritas en las especificaciones.

CONDICIONES DE ENTRADA

Las condiciones de entrada vienen representadas por sentencias en la especificacin.

Un valor especfico

Un conjunto de valoresrelacionados

Un rango de valores

Un condicin lgica

..Introducir cinco valores..

....Palabras reservadas en un lenguaje....

...Valores entre 0 y 10...

Condicin ...debe ser...

EL PROCEDIMIENTO

Identificacin de las clases de equivalencia

Obtencin de los casos de prueba:

Se parte de la premisa de que cualquier elemento de una clase dada es representativo del resto del conjunto.

IDENTIFICACIN DE LAS CLASES DE EQUIVALENCIA

Por cada condicin de entrada se identifican clases de equivalencia vlidas y no vlidas.

Este proceso es heurstico.

Sin embargo existen un conjunto de criterios que ayudan a su identificacin.

CRITERIOS DE IDENTIFICACIN DE LAS CLASES DE EQUIVALENCIA

Condiciones de Entrada Nmero de clases de equivalencia vlidaNmero de clases de equivalencia no vlida

1. Rango de valores 1 clase que contemple los valores del rango

2 clases fuera del rango, una por encima y otrapor debajo de ste

2. Valor especfico 1 clase que contemple dicho valor

2 clases que representen un valor por encimay otro por debajo

3. Elementos de un conjunto tratados de formadiferente por el programa

1 clase de equivalencia por cada elemento

1 clase que representeun elemento fuera delconjunto

4. Condicin lgica 1 clase que cumpla la condicin

1 clase que no cumplala condicin

TABLA DE CONSIGNACIN DE LAS CLASES DE EQUIVALENCIA

Las clases as identificadas se consignan en esta tabla enumerndose de cara a la derivacin de los casos de prueba

Condiciones de Entrada Clases de equivalencia vlidaClases de

equivalencia no vlida


Clases de equivalencia : Cada caso debe contemplar el mximo nmero de clases

de equivalencia vlidas. Generar suficientes casos para cubrir todas las clases.

Generar un caso de prueba por cada clase de equivalencia no vlida que haya sido identificada

Ejemplo 1: Construccin de una batera de pruebas para detectar

posibles errores en la construccin de los identificadores de un hipottico lenguaje de programacin. Las reglas que determinan sus construccin sintctica son:

No debe tener mas de 15 ni menos de 5 caracteres El juego de caracteres utilizables es:

Letras (Maysculas y minsculas) Dgitos (0,9) Guin (-)

Se distinguen las maysculas de las minsculas El guin no puede estar ni al principio ni al final, pero puede

haber varios consecutivos. Debe contener al menos un carcter alfabtico No puede ser una de las palabras reservadas del lenguaje

Consignacin de las condiciones de entrada



-Entre 5 y 15 caracteres

-El identificador debe estarformado por letras, dgitosy guin

-Se diferencia entre letrasmaysculas y minsculas

-El guin no puede estar al principio, ni al final-Puede haber varios seguidos en el medio

-Debe contener al menos un carcter alfabtico

-No se pueden usar palabrasreservadas

Consignacin de las clases de equivalencia

-El identificador debe estarformado por letras, dgitosy guin

5. Alguno de los caracteres delIdent. {letras, dgitos, guin}

-Se diferencia entre letrasmaysculas y minsculas

6. Palabra declarada{Identificadores vlidos}

7. Utilizar la misma palabracon alguna letra conmutada

para hacer referencia al mismoidentificador

-Debe contener al menos un carcter alfabtico

11. Al menos un carcter delIdent. {letras}

12. Ningn carcter del Ident. {letras}

-No se pueden usar palabrasreservadas

13. El Identificador{palabras reservadas}

14, 15, 16 ....un caso porcada palabra reservada

-El guin no puede estar al principio, ni al final-Puede haber varios seguidos en el medio

8. Identificador sin guiones en los extremos y con varios

consecutivos en el medio

9. Identificador con guin al principio

10. Identificador con guinal final



-Entre 5 y 15 caracteres 1. 5n caracteres Ident. 152. n caracteres Id

Derivacin de los casos de pruebaIdentificador Clases de equivalencia cubiertas

Num-1-letra3---d3 (17) 3

Nd3 2

Num-1---d3 (10) 1,4,6,8,11,13 (todas las vlidas)

Nu%m-1---d3 (11) 5

NuM-1---d3 (10) 7

-um-1---d3 (10) 9

Num-1---d- (10) 10

456-1---23 (10) 12

Real 14

..(el resto de palabras reservadas).. 15,16......

El sistema acepta

el identificador

Resultado

Mensaje de error

Mensaje de error

Mensaje deerror

Mensaje de error

Mensaje deerror

Mensaje de error

Mensaje de error

Mensaje de error

Mensaje deerror

EL MTODO DEL ANLISIS DE LOS VALORES LMITES (AVL)

Se basa en la evidencia experimental de que los errores suelen aparecer con mayor probabilidad en los extremos de los campos de entrada.

Un anlisis de las condiciones lmites de las clases de equivalencia aumenta la eficiencia de la prueba.

Condiciones lmites : valores justo por encima y por debajo de los mrgenes de la clase de equivalencia.


Generar tantos casos de prueba como sean necesarios para ejercitar las condiciones lmites de las clases de equivalencia.

Proceso heurstico

Como en el caso anterior se pueden seguir unos criterios que faciliten su obtencin

Obtencin de los casos de pruebaCondiciones dela especificacin

1 caso que ejercite el valor mximo del rango

1 caso que ejercite el valor mnimo del rango

1 caso que ejercite el valor justo por encima del mximo del rango

1 caso que ejercite el valor justo por debajo del mnimo del rango

1 caso que ejercite el valor numrico especfico

1 caso que ejercite el valor justo por encima del valor numrico especfico

1 caso que ejercite el valor justo por debajo de valornumrico especfico

Generar casos de prueba segn el criterio 1 que ejercitendichas condiciones de salida

1. Rango de valorescomo condicin deentrada

2. Valor numrico especfico comocondicin deentrada

3. Rango de valorescomo condicin de salida

Generar casos de prueba segn el criterio 2 que ejercitendichas condiciones de salida

4. Valor numricoespecfico comocondicin de salida

5. Estructura de datos como condicin de salida o de entrada

1 caso que ejercite el primer elemento de la estructura

1 caso que ejercite el ltimo elemento de la estructura

Ejemplo 2 (PE vs AVL):

Programa que establece a partir de tres valores de entrada de que tipo de tringulo se trata.

Condicin:A+B>C and A+C>B and B+C>A

Segn el mtodo de particin equivalente deberamos considerar una clase equivalente vlida y otra no vlida

{A=4, B=5, C=3}, {A=1, B=2, C= 5}

No detectara un error en A+BC

AVL incluira el caso {A=1, B=2, C=3}

AVL aplicado al ejemplo 1Condicin Descripcin de los casos de prueba

Entre 5 y 15 caracteres

1 caso con n de caracteres identificados=15




Condicin Casos de prueba

Entre 5 y 15 caracteres

Num-1-let-3---d3 (15)

Numd3 (5)

Num-1-letr-3---d3 (16)

Nud3 (4)

CONJETURA DE ERRORES

Consiste en la elaboracin previa de una lista de errores no contemplados anteriormente que sirva para generar nuevos casos de prueba.

Ejemplo: subrutina que ejecuta la bsqueda binaria

Un caso que compruebe La presencia de un solo dato en la lista. Que las posiciones de la lista sea una potencia de dos Que las posiciones de la lista sea uno ms de una potencia

de dos Que las posiciones de la lista sea uno menos de una

potencia de dos

ESTRATEGIAS PARA EL DISEO DE CASOS DE PRUEBAS

Cada tcnica: Evala una fuente diferente de errores. El diseo debe involucrar una combinacin de estas

tcnicas.

Procedimiento: En todos los casos utilizar anlisis de valores lmites Complementar con casos de prueba derivados del mtodo

de particin equivalente Aadir nuevos casos mediante la conjetura de errores

SNTESIS FINAL

El proceso de prueba consiste en ejecutar el programa con el fin de localizar errores.

La prueba es una actividad incompleta.

Propsito de las tcnicas: reducir el nmero de casos de prueba sin mermar la efectividad de la prueba.

Existen dos enfoques a la hora de abordar el diseo de los casos de prueba:

Caja Negra: evala la funcionalidad del sistema (lo que hace) Caja Blanca: evala la lgica interna (como lo hace)

SSTESIS FINAL

Tcnicas de diseo:

Particin equivalente: divisin del campo de entrada en clases de equivalencia vlidas y no vlidas, a travs de las condiciones que aparecen en la especificacin.

Anlisis de valores lmites: Evaluar las condiciones lmites de las clases de equivalencia.

La prueba de programas bajo caja negra involucra una combinacin de todas estas tcnicas.

EJECUCIN DE LAS PRUEBAS: PRUEBAS POR MDULOS O DE

INTEGRACIN

Consiste en la comparacin de la funcin del mdulo con respecto de alguna especificacin funcional o interfaz que lo defina.

Motivacin: Es una forma de poder manejar las posibilidades

combinatorias de las pruebas. La prueba por mdulos facilita la tarea de localizacin y

correccin de errores. Introduce un cierto paralelismo en el proceso de prueba ya

que se tiene la oportunidad de probarlos simultneamente.

PROCESO DE PRUEBA POR MDULOS

Se disean los casos de prueba: Se analiza la lgica del programa (caja blanca) Se complementa con casos obtenidos aplicando mtodos de

caja negra.

Se determina el orden en que deben probarse los mdulos, siguiendo unas determinadas recomendaciones prcticas.

PRUEBAS INCREMENTALESy

PRUEBAS NO INCREMENTALES

Debe probarse de forma independiente cada mdulo de un programa, para luego combinarlos y obtener el programa final?.

Se debe probar cada mdulo integrandolo sucesivamente con el resto de los mdulos hasta conformar el programa final?.

La primera consideracin se denomina integracin no incremental frente a la segunda que se conoce como incremental.

PRUEBAS INCREMENTALES,PRUEBAS NO INCREMENTALES.

PROCEDIMIENTO

Prueba no incremental: Primero se efecta la prueba de mdulos. Finalmente los

mdulos se combinan o integran para formar el programa completo.

La prueba de cada mdulo requiere un mdulo impulsor y uno o ms auxiliares.

Prueba incremental: El siguiente mdulo en ser probado se combina con los

mdulos que ya han sido probados. La prueba puedes ser ascendente o descendente.

DEPURACIN

La actividad que se desarrolla despus de ejecutar una caso de prueba exitoso.

Comprende los siguientes pasos: Determinar la naturaleza exacta y la ubicacin del presunto

error dentro del programa. Corregir el error encontrado.

Mtodos de depuracin: Por medio de la fuerza bruta Por induccin Por deduccin Por rastreo hacia atrs Por medio de pruebas

DEPURACIN POR MEDIO DE LA FUERZA BRUTA

Mtodos que utilizan la fuerza bruta: La estrategia de espacir sentencias dentro del programa de

cara a producir mensajes o mostrar el valor de ciertas variables. (es un mtodo de prueba y error).

Uso de herramientas que analizan la dinmica del programa empleando las caractersticas del depurador del lenguaje de programacin empleado.

Estos mtodos son de prueba y error. Generan una cantidad excesiva de datos

irrelevantes. No alientan a pensar en el problema que se trata

resolver.

DEPURACIN POR INDUCCIN

UBICACINDE LOSDATOS

PERTINENTES

ORGANIZACINDE LOS DATOS

ESTUDIODE SUS

RELACIONES

DESARROLLODE UNA

HIPTESIS

PRUEBADE LA

HIPTESIS

CORRECCINDEL ERROR

INDUCCIN: Proceso que pasa de lo particular a lo general.

Enumeracin de todo lo que se sabe que el programa hacecorrectamente e incorrectamente

DEPURACIN POR DEDUCCIN

DEDUCCIN: Se parte de ciertas premisas o leyes generalespara llegar a una conclusin, empleando para ello procesosde eliminacin y clasificacin.

ENUMERARCAUSAS

POSIBLES

USO DEL PROCESO DEELIMINACIN

CLARIFICACINDE LAS

RESTANTES HIPTESIS

PRUEBADE LAS

RESTANTES HIPTESIS

OBTENERMS

DATOS

CORRECCINDEL ERROR

TEMA 7:VALIDACINTCNICAS DE PRUEBA DEL SOFTWARETCNICAS DE PRUEBAS DEL SOFTWARE. INTRODUCCINASPECTOS PSICOLGICOSFLUJO DE INFORMACIN DEL SOFTWAREPRUEBAS INDIRECTAS. INSPECCIONES, RECORRIDAS Y REVISIONES DEL PROGRAMADISEO DE CASOS DE PRUEBATCNICAS DE DISEO DE CASOS DE PRUEBAPRUEBAS DE CAJA BLANCAPRUEBA DEL CAMINO BSICOREPRESENTACIN DEL GRAFO DE FLUJO DE LAS ESTRUCTURAS DE CONTROLREPRESENTACIN DEL GRAFO DE FLUJO DE LAS ESTRUCTURAS DE CONTROLEJEMPLO. DIAGRAMA DE FLUJOEJEMPLO. GRAFO DE FLUJOGRAFOS ASOCIADOS A CONDICIONES LGICAS COMPUESTASCOMPLEJIDAD CICLOMTICACLCULO DE LA COMPLEJIDAD CICLOMTICADERIVACIN DE LOS CASOS DE PRUEBACOMPLEJIDAD CICLOMTICA.CAMINOS BSICOS.EJEMPLOEJEMPLOEJEMPLO. CONVERSIN AL GRAFO DE FLUJOEJEMPLO. CONJUNTO DE CAMINOS BSICOSPRUEBAS DE CAJA BLANCA. COBERTURA LGICACOBERTURA DE SENTENCIACOBERTURA DE DECISINCOBERTURA DE CONDICINCOBERTURA MLTIPLEEJEMPLO. POSIBLES COMBINACIONESEJEMPLO. POSIBLES COMBINACIONESDISEO DE CASOS DE PRUEBA MEDIANTE CAJA NEGRATIPOS DE ERRORES QUE DETECTATCNICAS DE PRUEBA DE CAJA NEGRAEL MTODO DE PARTICIN EQUIVALENTE (PE)CONCEPTO DE CLASE EQUIVALENTECONDICIONES DE ENTRADAEL PROCEDIMIENTOIDENTIFICACIN DE LAS CLASES DE EQUIVALENCIACRITERIOS DE IDENTIFICACIN DE LAS CLASES DE EQUIVALENCIATABLA DE CONSIGNACIN DE LAS CLASES DE EQUIVALENCIADERIVACIN DE LOS CASOS DE PRUEBAEL MTODO DEL ANLISIS DE LOS VALORES LMITES (AVL)DERIVACIN DE LOS CASOS DE PRUEBACONJETURA DE ERRORESESTRATEGIAS PARA EL DISEO DE CASOS DE PRUEBASSNTESIS FINALSSTESIS FINALEJECUCIN DE LAS PRUEBAS: PRUEBAS POR MDULOS O DE INTEGRACINPROCESO DE PRUEBA POR MDULOSPRUEBAS INCREMENTALES y PRUEBAS NO INCREMENTALESPRUEBAS INCREMENTALES,PRUEBAS NO INCREMENTALES.PROCEDIMIENTODEPURACINDEPURACIN POR MEDIO DE LA FUERZA BRUTADEPURACIN POR INDUCCINDEPURACIN POR DEDUCCIN

TEMA 7: VALIDACIÓN - infor.uva.esjvalvarez/docencia/tema7.pdf · codificación y antes de las...

Documents

Transcript of TEMA 7: VALIDACIÓN - infor.uva.esjvalvarez/docencia/tema7.pdf · codificación y antes de las...