Unidad4 PDF

Pruebas de Software
Ingeniera del Software I Universidad Rey Juan Carlos
Csar Javier Acu Acua cesar.acuna@urjc.es
Introduccin
|
Verificacin de Software:
z
Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase Evaluacin de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos.
Validacin de Software:
z
Ingeniera del Software I
Introduccin
|
Verificacin
z
Estamos construyendo correctamente el producto? Estamos Estamos construyendo el producto correcto?
Validacin
z
Las pruebas permiten validar y verificar el software
Introduccin
|
Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto Caso de Prueba (test case): un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular
4
Introduccin
|
Defecto (defect, fault, bug): un defecto en el software como, por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados
5
Introduccin
|
Error (error):
z
z z z
La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o tericamente correcto. Un defecto Un resultado incorrecto Una accin humana que conduce a un resultado incorrecto .
Introduccin
Error
Equivocacin del programador Sistema de gestin de aeropuerto
2+2=5 Accidente (seguridad) Defecto (calidad)

Xyx// ???
S.Aproximacin
Fallo (fiabilidad)
Introduccin
| | |
Probar exhaustivamente el SW es imposible Es imposible evaluar todas las posibilidades Un proceso de prueba ser exitoso cuando encuentre errores Los errores no son siempre fruto de la negligencia del programador
Introduccin
|
Recomendaciones
z z
Cada caso de prueba debe definir el resultado de salida esperado El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas Se debe inspeccionar a conciencia el resultado de cada prueba, as, poder descubrir posibles sntomas de defectos
Introduccin
|
Recomendaciones
z
Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados. Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo):
Probar si el software no hace lo que debe hacer Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios adversos
10
Introduccin
|
Recomendaciones
z
Se deben evitar los casos desechables, es decir, los no documentados ni diseados con cuidado No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas.
11
Introduccin
|
Recomendaciones
z
La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubierto. Las pruebas son una tarea tanto o ms creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.
12
El Proceso de Prueba
Planear Planear pruebas pruebas
Informacin sobre proyecto Plan de pruebas
Disear Disear pruebas pruebas
Configuracin de pruebas (casos y procedimientos)
Ejecutar Ejecutar pruebas pruebas

Resultados
Informacin sobre software (ERS, diseo, etc)
Configuracin de software revisada Resultados esperados Correcciones
DESARROLLO DESARROLLO Depuracin Depuracin

Acciones preventivas (formacin, mejora de procesos, etc) Errores: histrico e informes de pruebas
Evaluar Evaluar pruebas pruebas
Prediccin de fiabilidad
Anlisis de Anlisis de errores errores
Estadstica de errores
13
Tcnicas de Diseo de Casos de Prueba

|
Utilizamos tcnicas para conseguir una confianza aceptable en que se detectarn los defectos existentes Equilibrio entre los recursos empleados y la confiabilidad de los casos de prueba Elegir los casos de prueba que puedan representar a los demas. La eleccin no debe ser al azar
14
Tcnicas de Diseo de Casos de Prueba

|
Existen tres enfoques para el diseo de casos de prueba:

z z z
El enfoque estructural o de caja blanca El enfoque funcional o de caja negra El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba
15
Tcnicas de Diseo de Casos de Prueba Caja blanca

Entrada Salida
Caja negra
Entrada Funciones Salida
16
Pruebas Estructurales
z
z z
El diseo de los casos debe basarse en la eleccin de caminos importantes que ofrezcan una seguridad aceptable. Se utilizan criterios de cobertura lgica Es conveniente construir un diagrama de flujo de control (flowchart)
17
1
Abrir archivos; Leer archivo ventas, al final indicar no ms registros; Limpiar lnea de impresin; WHILE (haya registros ventas) DO Total nacional = 0; Total extranjero = 0; WHILE (haya reg. ventas) y IF (nacional) THEN Sumar venta nacional a total nacional ELSE Sumar venta extranjero a total extranjero ENDIF; Leer archivo ventas, al final indicar no ms registros; ENDWHILE; Escribir lnea de listado; Limpiar rea de impresin; ENDWHILE; Cerrar archivos. (mismo producto)
2 3 4 5 6 7a 8,9 10,11 12,13 7b
18
|
Cmo dibujar un grafo de flujo

z
Sealar sobre el cdigo cada condicin de cada decisin tanto en sentencias If-then y Case-of como en los bucles While o Until. Agrupar el resto de las sentencias en secuencias situadas entre cada dos condiciones . Numerar tanto las condiciones como los grupos de sentencias, de manera que se les asigne un identificador nico
19
|
Criterios de Cobertura
z
De Sentencias:
Se trata de generar los casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute, al menos, una vez. Consiste en escribir casos suficientes para que cada decisin tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso.
De decisiones:
20
10
z
De condiciones:
Se trata de disear tantos casos como sea necesario para que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el falso al menos una vez. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla tambin el criterio de decisiones. En el caso de que se considere que la evaluacin de las condiciones de cada decisin no se realiza de forma simultnea.
De decisin/condicin.
De condicin mltiple.
21
|
| |
La cobertura de caminos es el criterio mas elevado Cada camino debe ser probado Caminos de prueba: ejecutar cada bucle por lo menos una vez Utilizando caminos de prueba se puede cuantificar la cantidad de caminos (permite asignar correctamente los recursos)
22
11
|
Complejidad Ciclomtica de McCabe (V(G))

z z z
Empleada para determinar el N de caminos independientes. Valor de la mtrica es un buen criterio V(G)
a-n+2, siendo a el nmero de arcos y n el nmero de nodos r, siendo r el nmero de regiones cerradas c+1, sindo c el nmero de nodos de condicin
23
Regin 1
Regin 3
a3
a7
a10
a12
Regin 4
a8
a14
a4
a1
a5
a11
a13
10
Regin 2
a2
a6
24
Regin 5
a9
11
12
|
Para elegir los caminos independientes a probar se utiliza el mtodo del camino bsico Consiste en realizar variaciones sobre un camino de prueba tpico que llamamos bsico
z z z z z
1-2-11 1-2-3-4-10-2 1-2-3-4-5-10-2 1-2-3-4-5-6-7-9 1-2-3-4-5-6-8-9

25
Pruebas Funcionales
|
Particiones o Clases de Equivalencia

z
Las cualidades que definen un buen caso de prueba:

Cada caso debe cubrir el mximo nmero de entradas Debe tratarse el dominio de valores de entrada dividido en un nmero finito de clases de equivalencia que cumplan la siguiente propiedad: la prueba de un valor representativo de una clase permite suponer razonablemente que el resultado obtenido (existan defectos o no) ser el mismo que el obtenido probando cualquier otro valor de la clase
26
13
Pruebas Funcionales
z
El mtodo consiste entonces en:

Identificacin de las clases de equivalencia Creacin de los casos de prueba correspondientes
Identificacin de las Clases de Equivalencia

Identificar las restricciones al formato y contenido de los datos de las entradas Identificar las clases de equivalencia:
De datos Vlidos De Datos no Vlidos o Errneos
27
Pruebas Funcionales
z
Existen algunas reglas que ayudan a identificar clase:

Si se especifica un rango de valores para los datos de entrada, se crear una clase vlida y dos clases no vlidas Si se especifica un nmero de valores, se crear una clase vlida y dos no vlidas Si se especifica una situacin del tipo debe ser o booleana (por ejemplo, el primer carcter debe ser una letra), se identifican una clase vlida (es una letra) y una no vlida (no es una letra)
28
14
Pruebas Funcionales
Si se especifica un conjunto de valores admitidos y se sabe que el programa trata de forma diferente cada uno de ellos, se identifica una clase vlida por cada valor y una no vlida. En cualquier caso, si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, deben dividirse en clases menores.
z
Desarrollar los casos de prueba

Este proceso consta de los siguientes pasos
Asignacin de un nmero nico a cada clase de equivalencia
29
Pruebas Funcionales
Hasta que todas las clases de equivalencia hayan sido cubiertas por (incorporadas a) casos de prueba, se tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, escribir un caso para una nica clase no vlida sin cubrir.
30
15
Pruebas Funcionales
|
Ejemplo:
z
Especificacin
Cdigo rea: nmero de 3 dgitos que no empieza ni por 0, ni por 1. Nombre de identificacin: 6 caracteres. Ordenes posibles: "cheque", "depsito", "pago factura", "retirada de fondos".
31
Pruebas Funcionales
|
Ejemplo:
Clases vlidas (1) 200 cdigo 999 Clases invlidas (2) cdigo <200 (3) cdigo >999 (4) no es nmero (6) menos de 6 caracteres (7) ms de 6 caracteres (12) ninguna orden vlida
Condicin de entrada Cdigo rea
Nombre para identificar la operacin Orden
(5) seis caracteres (8) (9) (10) (11) cheque depsito pago factura retirada de fondos
32
16
Pruebas Funcionales
|
Casos vlidos:
z z z z
300 Nomina 400 Viajes 500 Coches 600 Comida 180 1032 XY <CR> Regalos Casa
Depsito Cheque Pago Factura Retirada Fondos
(1) (1) (1) (1) (2) (3) (4) (6) (7) (12)
(5) (5) (5) (5)
(9) (8) (10) (11)
Casos No Vlidos
z z z z z z
33
Pruebas Funcionales
|
Anlisis de Valores Lmites (AVL)

z z z
Exploran las condiciones lmites de un programa. Tcnica Complementaria a las Clases de Equivalencia. Diferencias:
Ms que elegir cualquier elemento como representativo de una clase de equivalencia, se requiere la seleccin de uno o ms elementos tal que los mrgenes se sometan a prueba.
34
17
Pruebas Funcionales
Ms que elegir cualquier elemento como representativo de una clase de equivalencia, se requiere la seleccin de uno o ms elementos tal que los mrgenes se sometan a prueba. Ms que concentrarse nicamente en el dominio de entrada (condiciones de entrada), los casos de prueba se generan considerando tambin el espacio de salida 1) Si una condicin de entrada especifica un rango de valores, se deben generar casos para los extremos del rango y casos no vlidos para situaciones justo ms all de los extremos
Reglas:
35
Pruebas Funcionales
2) Si la condicin de entrada especifica un nmero de valores, hay que escribir casos para los nmeros mximo, mnimo, uno ms del mximo y uno menos del mnimo de valores 3) Usar la regla 1 para la condicin de salida 4) Usar la regla 2 para cada condicin de salida En esta regla 3 y 4, debe recordarse que:
los valores lmite de entrada no generan necesariamente los valores lmite de salida no siempre se pueden generar resultados fuera del rango de salida (pero es interesante considerarlo).
36
18
Pruebas Funcionales
5) Si la entrada o la salida de un programa es un conjunto ordenado (por ejemplo, una tabla, un archivo secuencial, ...), los casos deben concentrarse en el primero y en el ltimo elemento
37
Pruebas Funcionales
|
Conjetura de Errores
z z z z
Enumerar una lista de errores comunes En funcin de ella elaborar los casos de prueba Es importante la intuicin y la experiencia Ejemplos:
El valor cero es una situacin propensa a error tanto en la salida como en la entrada Cuando se introduce un nmero variable de valores, centrarse en el caso de no introducir ningn valor y en el de un solo valor. Tambin puede ser interesante un lista que tiene todos los valores iguales
38
19
Pruebas Funcionales
Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificacin Tambin interesa imaginar lo que el usuario puede introducir como entrada a un programa
39
Pruebas Aleatorias
|
Se simula la entrada de datos habitual de un programa. Se crean datos que sigan la frecuencia y la secuencia que tendran en la prctica Se usan generadores de pruebas:
z z z
Descripcin de datos Secuencias de entradas posibles Probabilidad de ocurrencia
40
20
Enfoque prctico para generar los casos de prueba

|
Si la especificacin contiene combinaciones de condiciones de entrada, comenzar formando sus grafos de causa-efecto (ayudan a la comprensin de dichas combinaciones). En todos los casos, usar el anlisis de valores-lmites para aadir casos de prueba: elegir lmites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia.
41

|
Identificar las clases vlidas y no vlidas de equivalencia para la entrada y la salida, y aadir los casos no incluidos anteriormente (cada causa es una nica clase de equivalencia? Deben dividirse en clases?). Utilizar la tcnica de conjetura de errores para aadir nuevos casos, referidos a valores especiales.
42
21

|
Ejecutar los casos generados hasta el momento (de caja negra) y analizar la cobertura obtenida (usar herramientas de anlisis de cobertura) Examinar la lgica del programa para aadir los casos precisos (de caja blanca) para cumplir el criterio de cobertura elegido.
43
Documentacin del Diseo de Pruebas

|
Documentos relacionados con el diseo de pruebas segn IEEE std. 829 -1998
Plan de pruebas Plan de pruebas Especificacin de Especificacin de diseo de pruebas diseo de pruebas Especificacin de Especificacin de diseo de pruebas diseo de pruebas
Especificacin de Especificacin de caso de pruebas caso de pruebas
Especificacin de Especificacin de procedimiento procedimiento de pruebas de pruebas
Ejecucin Ejecucin
Informes 44
22

|
Plan de Pruebas
z
Sealar:
El enfoque Los recursos El esquema de actividades de prueba Los elementos a probar Las caractersticas Las actividades de prueba El personal responsable Los riesgos asociados
45

z
Estructura Fijada en el estndar

Identificador nico del documento (para la gestin de configuracin). Introduccin y resumen de elementos y caractersticas a probar. Elementos software que se van a probar (p. ej., programas o mdulos). Caractersticas que se van a probar. Caractersticas que no se prueban. Enfoque general de la prueba (actividades, tcnicas, herramientas, etc.). Criterios de paso/fallo para cada elemento. Criterios de suspensin y requisitos de reanudacin. Documentos a entregar (como mnimo, los descritos en el estndar).
46
23

z
Estructura Fijada en el estndar

Actividades de preparacin y ejecucin de pruebas. Necesidades de entorno. Responsabilidades en la organizacin y realizacin de las pruebas. Necesidades de personal y de formacin. Esquema de tiempos (con tiempos estimados, hitos, etc.). Riesgos asumidos por el plan y planes de contingencias para cada riesgo. Aprobaciones y firmas con nombre y puesto desempeado.
47

|
Especificacin del Diseo de Pruebas

z
Objetivo: Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las caractersticas que se deben probar con este diseo de pruebas. Estructura Fijada por el estndar:
Identificador (nico) para la especificacin. Proporcionar tambin una referencia del plan asociado (si existe). Caractersticas a probar de los elementos software (y combinaciones de caractersticas).
48
24

z
Estructura Fijada por el estndar:

Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las tcnicas de prueba especfica y los mtodos de anlisis de resultados. Identificacin de cada prueba:
Identificador. Casos que se van a utilizar. Procedimientos que se van a seguir.
Criterios de paso/fallo de la prueba (criterios para determinar si una caracterstica o combinacin de caractersticas ha pasado con xito la prueba o no).
49

|
Especificacin de un Caso de Prueba z Objetivo: definir uno de los casos de prueba identificado por una especificacin del diseo de las pruebas.
z
Estructura Fijada por el estndar

Identificador nico de la especificacin. Elementos software (p. ej., mdulos) que se van a probar: definir dichos elementos y las caractersticas que ejercitar este caso. Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; p. ej., la sincronizacin de las mismas). Especificaciones de todas las salidas y las caractersticas requeridas (p. ej., el tiempo de respuesta) para los elementos que se van a probar.
50
25

z

Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal). Requisitos especiales de procedimiento (o restricciones especiales en los procedimientos para ejecutar este caso). Dependencias entre casos (p. ej., listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba).
51

|
Especificacin de un Procedimiento de Prueba z Objetivo: especificar los pasos para la ejecucin de un conjunto de casos de prueba o, ms generalmente, los pasos utilizados para analizar un elemento software con el propsito de evaluar un conjunto de caractersticas del mismo.
z

Identificador nico de la especificacin y referencia a la correspondiente especificacin de diseo de prueba. Objetivo del procedimiento y lista de casos que se ejecutan con l. Requisitos especiales para la ejecucin (p. ej., entorno especial o personal especial).
52
26

z

Pasos en el procedimiento. Adems de la manera de registrar los resultados y los incidentes de la ejecucin, se debe especificar: La secuencia necesaria de acciones para preparar la ejecucin. Acciones necesarias para empezar la ejecucin. Acciones necesarias durante la ejecucin. Cmo se realizarn las medidas (p. ej., el tiempo de respuesta). Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen). Puntos para reinicio de la ejecucin y acciones necesarias para el reinicio en estos puntos. Acciones necesarias para detener ordenadamente la ejecucin. Acciones necesarias para restaurar el entorno y dejarlo en la situacin existente antes de las pruebas. Acciones necesarias para tratar los acontecimientos anmalos
53
Ejecucin de las pruebas

EJECUTAR PRUEBAS EJECUTAR PRUEBAS DEPURAR PRUEBAS S (DEFECTO DE PRUEBAS) ALGN ALGN FALLO? FALLO? NO COMPROBAR COMPROBAR TERMINACIN TERMINACIN S (DEFECTO DEL SOFTWARE) DEPURAR CDIGO
PRUEBAS ADICIONALES
NO S CRITERIOS DE COMPLECIN DEL PLAN DE PRUEBAS
CONDICIONES CONDICIONES ANORMALES ANORMALES
PRUEBAS PRUEBAS ADICIONALES? ADICIONALES?
S TERMINACIN ANORMAL
NO
TERMINACIN NORMAL
EVALUAR EVALUAR RESULTADOS RESULTADOS
54
27
Documentacin de la Ejecucin de las pruebas

ESPECIFICACIN DE LAS PRUEBAS CASOS PROCEDIMIENTOS
EJECUCIN EJECUCIN
Histrico Histrico de pruebas de pruebas (test log )) (test log
Informes Informes de incidentes de incidentes
...
Histrico Histrico de pruebas de pruebas (test log )) (test log
Informes Informes de incidentes de incidentes
Informe resumen Informe resumen de las pruebas de las pruebas
55

|
Historico de Pruebas z Documenta todos los hechos relevantes ocurridos durante la ejecucin de las pruebas.
Informe de Incidente:
z
Documenta cada incidente (p. ej., una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido en la prueba y que requiera una posterior investigacin.
56
28

|
Informe resumen z Resume los resultados de las actividades de prueba (las reseadas en el propio informe) y aporta una evaluacin del software, basada en dichos resultados.
57
Depuracin
|
Es proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el software. Suele ser la consecuencia de una prueba con xito. Consecuencias
z
Encontrar la causa del error, analizarla y corregirla No encontrar la causa. (casos de prueba para depuracin).
58
29
Depuracin
|
Etapas:
z z
Localizacin del Error (mayor esfuerzo) Correccin del defecto
Casos de Prueba
Causas Sintomas de Errores Correcin Causas

59
Anlisis de errores o anlisis causal

| | | | | | |
Cundo se cometi? Quin lo hizo Qu se hizo mal? Cmo se podra haber prevenido? Por qu no se detect antes? Cmo se podra haber detectado antes? Cmo se encontr el error?
60
30
Ciclo de Vida de Pruebas (V)

Contrato. Contrato. Requisitos de Requisitos usuario de usuario Prueba de Prueba de aceptacin aceptacin
Planificar Tipos: Alfa Beta
Especificacin de Especificacin de requisitos del requisitos del software software
Prueba de Prueba de sistema sistema
Requisitos no funcionales Documentacin
Documentacin de Documentacin de diseo y arquitectura diseo y arquitectura
Prueba de Prueba de integracin integracin
Interfaces Mezcla con prueba de unidad Tipos de integracin
Especificacin de Especificacin de mdulos o mdulos o elementos elementos
Prueba de Prueba de unidad unidad
Exhaustiva Enfoque recomendado: Caja negra Cobertura de pruebas
Cdigo Cdigo
61
Pruebas de Unidad
|
Puede abarcar desde un mdulo, a un grupo de pocos mdulos o un programa completo Las pruebas de unidad suelen ser realizadas por personal de desarrollo Utilizar el enfoque prctico ya visto.
62
31
Pruebas de Integracin
|
Ligadas a la forma prevista de integrar los distintos componentes del software hasta contar con el producto global que debe entregarse Tipos de Integracin
z
Incremental (ascendente y descendente)

Se combina el siguiente mdulo que se debe probar con el conjunto de mdulos que ya estn probados
No Incremental
Se prueba cada mdulo por separado y, luego, se integran todos de una vez y se prueba el programa completo
63
Pruebas del Sistema

|
Verifica:
z
z z
Cumplimiento de todos los requisitos funcionales, considerando el producto software final al completo, en un entorno de sistema. El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador. Adecuacin de la documentacin de usuario. Ejecucin y rendimiento en condiciones lmite y de sobrecarga.
64
32
Pruebas de Aceptacin
|
Objetivo
z
Comprobar si el producto est listo para ser implantado para el uso operativo en el entorno del usuario. Participacin del Usuario Est enfocada hacia la prueba de los requisitos de usuario especificados Est considerada como la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotacin
Caractersticas
z z z
65
33

Unidad4 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad4 PDF

Cargado por

Copyright:

Formatos disponibles

Pruebas de Software

Ingeniera del Software I Universidad Rey Juan Carlos

Csar Javier Acu Acua cesar.acuna@urjc.es

Ingeniera del Software I

Estamos construyendo correctamente el producto? Estamos Estamos construyendo el producto correcto?

Las pruebas permiten validar y verificar el software

Ingeniera del Software I

Ingeniera del Software I

2+2=5 Accidente (seguridad) Defecto (calidad)

Ingeniera del Software I

Ingeniera del Software I

Ingeniera del Software I

Ingeniera del Software I

Disear Disear pruebas pruebas

Configuracin de pruebas (casos y procedimientos)

Ejecutar Ejecutar pruebas pruebas

Informacin sobre software (ERS, diseo, etc)

Configuracin de software revisada Resultados esperados Correcciones

DESARROLLO DESARROLLO Depuracin Depuracin

Evaluar Evaluar pruebas pruebas

Anlisis de Anlisis de errores errores

Ingeniera del Software I

Tcnicas de Diseo de Casos de Prueba

Ingeniera del Software I

Tcnicas de Diseo de Casos de Prueba

Existen tres enfoques para el diseo de casos de prueba:

Ingeniera del Software I

Tcnicas de Diseo de Casos de Prueba Caja blanca

Ingeniera del Software I

Ingeniera del Software I

2 3 4 5 6 7a 8,9 10,11 12,13 7b

Ingeniera del Software I

Cmo dibujar un grafo de flujo

Ingeniera del Software I

Ingeniera del Software I

Complejidad Ciclomtica de McCabe (V(G))

Ingeniera del Software I

Ingeniera del Software I

1-2-11 1-2-3-4-10-2 1-2-3-4-5-10-2 1-2-3-4-5-6-7-9 1-2-3-4-5-6-8-9

Particiones o Clases de Equivalencia

Las cualidades que definen un buen caso de prueba:

Ingeniera del Software I

El mtodo consiste entonces en:

Identificacin de las Clases de Equivalencia

Ingeniera del Software I

Existen algunas reglas que ayudan a identificar clase:

Ingeniera del Software I

Desarrollar los casos de prueba

Ingeniera del Software I

Ingeniera del Software I

Ingeniera del Software I

Condicin de entrada Cdigo rea

Nombre para identificar la operacin Orden

Ingeniera del Software I

Depsito Cheque Pago Factura Retirada Fondos

(5) (5) (5) (5)

(9) (8) (10) (11)

Ingeniera del Software I

Anlisis de Valores Lmites (AVL)

Ingeniera del Software I

Ingeniera del Software I

Ingeniera del Software I

Ingeniera del Software I