Técnicas de Prueba Del Software

MODULO 3:
Tema 14: T cnicas de Prueba del Software
Ingeniera del Software (3 I.T.I.S., I.T.I.G.)
Mdulo 3. Tema 14: Tcnicas de Prueba del Software
Contenidos
p p p p p p
Objetivos de la prueba Importancia de la prueba Principios de la prueba El proceso de prueba Mtodos de diseo de casos de prueba Enfoque estructural Prueba del camino bsico - Notacin de grafo de flujo - Complejidad ciclomtica - Derivacin de los casos de prueba Prueba de bucles Enfoque funcional Particiones o clases de equivalencia Anlisis de Valores Lmite (AVL)
Prueba de interfaces grficas de usuario Estrategias de prueba del software Relacin entre productos de desarrollo y niveles de prueba Organizacin para la prueba del software Prueba de unidad Prueba de integracin Integracin incremental descendente Integracin incremental ascendente Mdulos crticos Prueba de aceptacin
Bibliografa del tema

p p p
(Piattini et al. 96) Captulo 12 (Pressman 02) Captulos 17 y 18 (MAP 95) Ministerio de Administraciones Pblicas. Gua de Tcnicas de Mtrica y Gua de Referencia. v.2.1. 1995
Prueba del software

Objetivos de las pruebas (Myers 79):
1. La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error. 2. Un buen caso de prueba es aquel que tiene una alta probabilidad de descubrir un error no encontrado hasta entonces. 3. Una prueba tiene xito si descubre un error no detectado hasta entonces.
p
Actividad de Valdacin y Verificacin (V&V) que implica la ejecucin del cdigo. Hay otras actividades de V&V en las que no se ejecuta el cdigo: Walkthroughs y pruebas formales. No slo se prueba el cdigo: tb. documentacin y ayuda.
Mdulo 3. Tema 14: Tcnicas de Prueba del Software 4
Prueba del software (II)

p
ndice de la fiabilidad del software:

Se comporta de acuerdo a las especificaciones y requisitos de rendimiento.
La prueba no puede asegurar la ausencia de defectos: slo puede demostrar que existen defectos en el software.
No es una actividad secundaria:

30-40% del esfuerzo de desarrollo En aplicaciones crticas (p.ej. control de vuelo, reactores nucleares, aplicaciones mdicas, etc.), De 3 a 5 veces ms que el resto de pasos juntos de la ingeniera del software!
Principios de la prueba
(Davis 95, Myers 79)
p
A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos de los clientes (trazabilidad). Las pruebas deberan planificarse antes de que empiecen. El Principio de Pareto es aplicable a la prueba del software: La mayor parte de los defectos encontrados pertenece slo a 2 3 tipos de defectos, de manera que si se eliminan las causas que los provocan desaparecera la mayor parte de los defectos Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande. No son posibles las pruebas exhaustivas. Para ser ms efectivas, las pruebas deberan ser conducidas por un equipo independiente. Se deben evitar los casos de prueba no documentados ni diseados con cuidado. No deben realizarse planes de prueba suponiendo que prcticament e no hay defectos en los programas y, por tanto, dedicando pocos recursos a las pruebas.
Ingeniera del Software (3 I.T.I.S., I.T.I.G.) Mdulo 3. Tema 14: Tcnicas de Prueba del Software 6
p p
p p p
p p
El proceso de prueba
(Piattini et al. 96)

Diseo de casos de prueba

p
Seguridad total: prueba exhaustiva (no practicable) Objetivo: conseguir confianza aceptable en que se encontrarn todos los defectos existentes, sin consumir una cantidad excesiva de recursos. Disear las pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo posible.
Diseo de casos de prueba. Enfoques principales

Diseo de casos de prueba. Enfoques principales (II)

a) Enfoque estructural o de caja blanca (transparente):
Usa la estructura de control del diseo procedimental para obtener los casos de prueba. La prueba exhaustiva consistira en probar todos los posibles caminos de ejecucin Se basa en el estudio minucioso de los detalles procedimentales. Problema: n caminos lgicos demasiado alto ( buscar los ms importantes)
b) Enfoque funcional o de caja negra:

Tambin denominada prueba de comportamiento Se centra en los requisitos funcionales del software. Los casos de prueba pretenden demostrar que las funciones del software son operativas. Para derivar los casos, se estudia la especificacin de las funciones, la entrada y la salida. Examina aspectos del modelo fundamental del sistema sin tener en cuenta la estructura lgica interna del software.
p
No son excluyentes. Mas bien complementarios.

Prueba de caja blanca

Porqu no dedicar todo el esfuerzo a probar que se cumplen los requisitos? Porqu usar pruebas de caja blanca? Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. A veces creemos que un camino lgico tiene pocas posibilidades de ejecutarse cuando puede hacerlo de forma normal. Los errores tipogrficos son aleatorios. Los errores se esconden en los rincones y se aglomeran en los lmites (Beizer 90)
11
Bastara con una prueba exhaustiva de caja blanca?

Consideremos un programa de 100 lneas en C. Despus de la declaracin de algunos datos, el programa contiene dos bucles que se ejecutan 1..20 veces cada uno, dependiendo de las condiciones especficas de entrada. Dentro del bucle interior, se utilizan cuatro construcciones If-then-else. Existen 104 caminos posibles que se pueden ejecutar en el programa. Un procesador de pruebas, trabajando 24 horas los 356 das del ao tardara 3170 aos para probar el programa. Conclusin: No es posible una prueba exhaustiva sobre todos los caminos del programa, porque el nmero de caminos es simplemente demasiado grande
12
Bastara con una prueba exhaustiva de caja blanca?

Sin embargo, la prueba de caja blanca no se debe desechar como impracticable. Se pueden elegir y ejercitar una serie de caminos lgicos importantes. Se pueden comprobar las estructuras de los datos ms importantes para verificar su validez. Se pueden combinar los atributos de la pruebas de caja blanca con los de la caja negra para llegar a un mtodo que valide la interfaz del software y asegure selectivamente que el funcionamiento interno del software es correcto.
13
Prueba del camino bsico

- Tcnica de prueba de Caja Blanca
(Mc Cabe 76)
Objetivos:
1. Obtener una medida de la complejidad lgica de un diseo procedimental Complejidad ciclomtica de Mc Cabe 2. Usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin
p
Los casos de prueba obtenidos del conjunto bsico garantizan que durante la prueba se ejecuta al menos una vez cada sentencia del programa. Se puede automatizar.
14
Prueba del camino bsico
(Mc Cabe 76)
- El flujo de control de un programa puede representarse mediante un Grafo de Flujo. -Cada nodo del grafo corresponde a una o ms sentencias de cdigo fuente. Cada nodo que contiene una condicin se denomina nodo predicado, y se caracteriza porque 2 o mas arstas emergen de l. - Cualquier representacin del diseo procedural se puede traducir a un grafo de flujo
15
Notacin de grafo de flujo
x x
Secuencia
Si x entonces...
Hacer ... hasta x
Mientras x hacer...
16
17

Definiciones
- Cada crculo se denomina nodo. Representa una o ms sentencias procedimentales. - Un nodo puede corresponder a una secuencia de cuadros de proceso y a un rombo de decisin. - La flechas se denominan aristas o enlaces, y representan flujo de control (son anlogas a las flechas del diagrama de flujo) - Las areas delimitadas por aristas y nodos se denominan regiones
18

1
1
2,3
2 3 11 7 9 6 8 10
11 6 4,5 8 9 10
4 5
19

Definiciones
p
Camino: secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta su sentencia final. Camino de prueba: un camino que atraviesa, como mximo, una vez el interior de cada bucle que encuentra.
Algunos autores hablan de pasar 3 veces: una sin entrar en su interior otra entrando una vez otra entrando dos veces
Camino linealmente independiente de otros: introduce por lo menos un nuevo conjunto de sentencias de proceso o una nueva condicin
en trminos del grafo de flujo, introduce una nueva arista que no haya sido recorrida anteriormente a la definicin del camino
21
- Si se disean casos de prueba que cubran los caminos bsicos, se garantiza la ejecucin de cada sentencia al menos una vez y la prueba de cada condicin (sus dos posibilidades, verdadera o Falsa) - El conjunto bsico para un grafo dado puede no ser nico - Cuando aparecen condiciones lgicas compuestas la confeccin del grafo es ms complejo
22
23
Complejidad Ciclomtica
p
Buen criterio de prueba: ejecucin de un conjunto de caminos independientes. Complejidad ciclimtica:

Mtrica del SW que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Define el n de caminos independientes del conjunto bsico de un programa. Determina el nmero de casos de prueba que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.
Nmero mximo de caminos independientes? Complejidad ciclomtica de Mc Cabe, V(G). Tres formas de calcularla: V(G) = A - N + 2 donde A: n de arcos del grafo N: n de nodos V(G) = R donde R: n de regiones del grafo
V(G) = P +1 donde P: n de nodos predicado (Case of 1 ... N cuenta como n-1 en V(G)= c+1)
25
Derivacin de casos de prueba. Pasos

1. Usando el diseo o el cdigo como base, dibujamos el correspondiente grafo de flujo. 2. Determinamos la complejidad ciclomtica del grafo de flujo resultante, V(G). 3. Determinamos un conjunto bsico de hasta V(G) caminos linealmente independientes. 4. Preparamos los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico.
26
Derivacin de casos de prueba

Algunos consejos:
p
Numerar los nodos del grafo secuencialmente Describir el conjunto de caminos independientes (subrayar aristas que los hacen independientes de los anteriores)
1-2-11 1-2-3 -4-... ...
Algunos caminos no se pueden ejecutar solos y requieren la concatenacin con otro Algunos caminos pueden ser imposibles seleccionar otros A partir de los caminos, analizar el cdigo para ver qu datos de entrada son necesarios, y qu salida se espera
28
29
Complejidad ciclomtica. Conclusiones

Segn Beizer 90: V(G) marca un lmite mnimo del n de casos de prueba, contando cada condicin de decisin como un nodo individual. Parece que cuando V(G) es mayor que 10 la probabilidad de defectos en el mdulo crece bastante si dicho valor alto no se debe a sentencias CASE (en ese caso, es recomendable replantearse el diseo modular).
30
Ejemplo
31
Ejemplo
32
OR AND
Ejemplo
33
Ejemplo
34
Prueba del Camino Bsico

MATRICES DE GRAFOS
p
La prueba del camino bsico es una tcnica que se puede automatizar mediante la estructura de datos denominada Matriz de Grafo. Matriz de Grafo:
Matriz Cuadrada. Tamao = N de nodos del grafo de flujo. Filas y columnas corresponden a nodos. Las entradas de la matriz corresponden a aristas (conexiones entre nodos).
35

MATRICES DE GRAFOS
p
Ejemplo:
1
a
1 1
3 a
e b
3
f c
2 3 d c g e b f
d
4 5
2
Matriz del Grafo Grafo de Flujo

MATRICES DE GRAFOS
p
Peso de enlace: Nos da informacin adicional sobre el flujo de control. Se aade a cada entrada de la matriz. En su forma ms sencilla toma dos valores:
1: Si existe conexin. 0: Si no existe conexin.
Gracias a los pesos de enlace se pueden derivar propiedades ms interesantes:

La probabilidad de que un enlace (arista) sea ejecutado; El tiempo de procesamiento asociado al recorrido de un enlace; La memoria requerida durante el recorrido de un enlace; Los recursos requeridos durante el recorrido de un enlace.
37

MATRICES DE GRAFOS
p
Ejemplo:
1 1 2 3 4 5
3 a
5 1 2
1 0 0 0 0 0
2 0 0 1 1 1
3 1 0 0 0 1
4 0 0 1 0 0
5 0 0 0 1 0
d c g e
b f
3 4 5
Matriz del Grafo
Matriz de Conexiones
38

MATRICES DE GRAFOS
p p
Cada fila con dos o mas entradas representa un Nodo Predicado. A partir de la matriz de conexiones se puede calcular el conjunt o bsico de caminos linealmente independientes.
1 1 2 3 4 5 0 0 0 0 0
2 0 0 1 1 1
3 1 0 0 0 1
4 0 0 1 0 0
5 0 0 0 1 0
Conexiones 11=0
21=1 21=1 21=1 3 + 1 =4
Matriz de Conexiones Complejidad Ciclomtica

Pruebas de Caja Blanca

Estructuras de Control
p
La tcnica de prueba del camino bsico es una de las muchas existentes para las pruebas de la estructura de control. Aunque sea alta la efectividad de la prueba del camino bsico, no nos asegura completamente la correccin del software. Veremos a continuacin otras variantes para probar la estructura de control. Estas variantes amplian el abanico de pruebas mejorando la fiabilidad de las pruebas de caja blanca.
40

Prueba de condicin
p
Es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo del programa. Los tipos de errores que pueden aparecer en una condicin son las siguientes:
Existe un error en un operador lgico (sobra, falta o no es el que corresponde) Existe un error en el operador relacional (en el operador de comparacin de igualdad, menor, mayor, etc). Existe un error en una expresin aritmtica
41

Prueba de condicin
p
El mtodo de la prueba de condiciones se centra en la prueba de cada una de las condiciones del programa.
Algunas pruebas de condicin son:

p
Pruebas de ramificaciones: Es las ms sencilla. Prueba al menos una vez cada una de las condiciones simples (rama verdadera y falsa) de una condicin compuesta. Prueba de dominio: Para cada expresin relacional (E1 <operador-relacional> E2), se requieren tres pruebas para comprobar que el valor de E1 es mayor, menor o igual que E2 respectivamente.
Para una expresin lgica con n variables, hay que realizar las 2n pruebas posibles (n >0). Slo es prctica cuando el valor de n es pequeo.
42

Prueba de bucles
p
Las estructuras de bucles complejas son uno de los lugares mas propensos a errores. La prueba de bucles es una tcnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se definen 4 clases de bucles diferentes:
Bucles simples. Bucles concatenados. Bucles anidados. Bucles no estructurados.
43

Prueba de bucles
44

Prueba de bucles Simples
A los bucles simples se les aplica el siguiente conjunto de pruebas, siendo n el nmero mximo de iteraciones permitidas por el bucle: Pasar por alto totalmente el bucle Pasar una sola vez por el bucle Pasar dos veces por el bucle Hacer m pasos por el bucle con m<n Hacer n-1, n y n+1 pasos por el bucle
45

Prueba de bucles anidados
p
Pruebas para bucles anidados

Comenzar con el bucle interior estableciendo los demas bucles en sus valores mnimos Realizar las pruebas de bucle simple para el ms interior manteniendo los demas en sus valores mnimos Avanzar hacia fuera confeccionando pruebas para el siguiente bucle manteniendo todos los externos en los valores mnimos y los dems bucles anidados en sus valores tpicos Continuar el proceso hasta haber comprobado todos los bucles
46

Prueba de bucles concatenados/no estructurados
Pruebas para bucles concatenados

Siempre que los bucles concatenados sean independientes se puede aplicar los relativo a bucles simples/anidados. En caso de ser dependientes (e.d. se utiliza el controlador del bucle 1 como valor inicial del bucle 2) se evaluarn como bucles anidados.
Puebas para bucles no estructurados

Siempre que se usen los mecanismos que aporta la programacin estructurada, este tipo de bucles no estarn presentes. En caso de existir alguno, se recomienda redisear los algoritmos.
47
Prueba de caja negra

p
Tambin se denominan Pruebas de Comportamiento. Se centran en los requisitos funcionales del software. Estudia la especificacin del software, las funciones que debe realizar, las entradas y las salidas. La prueba de caja negra trata de encontrar errores de las siguientes categoras:
Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin.
48
Prueba de caja negra

p
Las pruebas se disean para responder a las siguientes preguntas:

Qu clases de entrada compondrn unos buenos casos de prueba? Es el sistema particularmente sensible a ciertos datos de entrada? Qu volumen de datos tolerar el sistema? Qu efectos tendrn determinadas combinaciones de datos sobre el funcionamiento del sistema? .....
Un conjunto de casos de prueba est bien elegido si satisface dos condiciones:

Reduce el n de casos de prueba adicionales para alcanzar una prueba razonable Nos dice algo sobre la presencia o ausencia de clases de errores, en lugar de errores asociados solamente con la prueba que estamos realizando.
49
Pruebas de Caja Negra

Particiones equivalentes
p
La particin equivalente es un mtodo que divide el campo de ent rada de un programa en clases de datos a partir de los cuales se pueden derivar casos de prueba La particin equivalente se enfoca pues a definir casos de prueba para descubrir clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar. Un caso de prueba ideal es aquel que descubre de forma inmediata una clase de errores, que de otro modo requeriran la ejecucin de muchos casos antes de detectar el error genrico. Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos para condiciones de entrada. Se define una condicin de entrada (valor numrico especfico, rango de valores, conjunto de valores relacionados o condicin lgica).
Pruebas de Caja Negra

Particiones equivalentes
Las clases de equivalencia se pueden definir de acuedo a las siguientes directrices:
1. 2. Si una condicin de entrada especifica un rango, se define una clase de equivalencia vlida y dos no vlidas Si la condicin de entrada es un valor especfico, se define una clase de equivalencia vlida y dos no vlidas Si la condicin de entrada especifica un miembro de un conjunto, se define una clase de equivalencia vlida y otra no vlida Si la condicin de entrada es lgica, se define una clase de equivalencia vlida y otra no vlida
3.
4.
51
Paso 1. Identificar las clases de equivalencia (II)

1.3. Algunas reglas para identificar clases de equivalencia:
1. Por cada rango de valores, se especifica una clase vlida y dos no vlidas
(vlida) 1 nmero 49; (no v lidas) nmero < 1, nmero > 49
2.
Si se especifica un n de valores, se crear una clase vlida y dos no vlidas

(vlida) num propietarios = 3; (no vlidas) num propietarios < 3, num propietarios > 3
3.
Si se especifica una situacin del tipo debe ser o booleana, se identifica una clase vlida y una no vlida
(vlida) El primer carcter es una letra; (no vlida) (...) no es una letra (vlida) X es un nmero; (no vlida) X no es un nmero
4.
Si se especifica un conjunto de valores admitidos, y el programa trata de forma distinta cada uno de ellos, se crea una clase vlida por cada valor, y una no vlida
Tres tipos de inmuebles: (vlidas) pisos, chalets, locales comerciales; (no vlida) jkll
52
Paso 2. Identificar los casos de prueba

2.1. Asignacin de un nmero nico a cada clase de equivalencia. 2.2. Hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba, se tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible. 2.3. 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.
53
Ejemplo
Un programa toma como entrada un fichero cuyo formato de registro es el siguiente: Nmero-empleado es un campo de nmeros enteros positivos de 3 dgitos (excluido el 000). Nombre-empleado es un campo alfanumrico de 10 caracteres. Meses-Trabajo es un campo que indica el nmero de meses que lleva trabajando el empleado; es un entero positivo (incluye el 000) de 3 dgitos. Directivo es un campo de un solo carcter que puede ser + para indicar que el empleado es un directivo y - para indicar que no lo es.
El programa asigna una prima (que se imprime en un listado) a cada empleado segn las normas siguientes: P1 a los directivos con, al menos, 12 meses de antigedad. P2 a los no directivos con, al menos, 12 meses de antigedad, P3 a los directivos sin un mnimo de 12 meses de antigedad, P4 a los no directivos sin un mnimo de 12 meses de antigedad
Ejemplo
Se pide: Crear una tabla de clases de equivalencia (las clases debern ser numeradas) en la que se indiquen las siguientes columnas en cada fila:
- Condicin de entrada que se analiza - Clases vlidas y - Clases no vlidas que se generan para la condicin
55
Ejemplo
p p p p p p p p p p p p p p p p
VLIDOS Regla: Cada caso vlido debe cubrir tantas clases vlidas como sea posible Entrada: 123, FERNNDEZ, 9, + (1)(5)(8)(13) 456, DOMNGUEZ, 13, - (1)(5)(9)(14) NO VLIDOS Regla: cada caso no vlido debe cubrir una y slo una clase no vlida 000, GUMERSINDO, 14, + (2) (5) (9) (13) 1024, MINOTAUROS, 16, (3) (5) (9) (14) ABC, SEBASTIANO, 8, + (4) (5) (8) (13) 123, COBOS, 6, + (1) (6) (8) (13) 123, TORRECEBALLOS, 3, + (1) (7) (8) (13) 123, MARGARITOS, -1, + (1) (5) (10) (13) 123, MARGARITOS, 1024, (1) (5) (11) (14) 123, MARGARITOS, ABC, (1) (5) (12) (14) 123, MARGARITOS, 13, * (1)(5)(9)(15) Salida: P4 P2
56
Anlisis de Valores Lmite (AVL)

p
Los casos de prueba que exploran las condiciones lmite producen mejores resultados Los defectos del software se acumulan en las situaciones lmite Diferencias de AVL con particiones de equivalencia:
No se elige cualquier elemento de la clase de equivalencia, sino uno o ms de manera que los mrgenes se sometan a prueba. Los casos de prueba se generan considerando tambin el espacio de salida.
57
Anlisis de Valores Lmite. Reglas para identificar casos

1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben generar casos para a y b y casos no vlidos justo por debajo y justo por encima de a y b, respectivamente. Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo, uno ms el mximo y uno menos el mnimo. Aplicar las directrices 1 y 2 a las condiciones de salida. Si las estructuras de datos internas tienen lmites preestablecidos, hay que asegurarse de disear un caso de prueba que ejercite la estructura de datos en sus lmites.
2.
3. 4.
58
Anlisis de Valores Lmite. Reglas para identificar casos (II)

1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben generar casos para a y b y casos no vlidos justo por debajo y justo por encima de a y b, respectivamente
Rango de entrada: [-1.0, 1.0]

Casos de prueba para 1.0, +1.0, -1.001, +1.001 (si se admiten 3 decimales)
2.
Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo, uno ms el mximo y uno menos el mnimo
El fichero de entrada tendr de 1 a 255 registros

Casos para 0, 1, 254, 255 registros
3.
Aplicar las directrices 1 y 2 a las condiciones de salida
El programa podr mostrar de 1 a 4 listados

Casos para intentar generar 0, 1, 4 y 5 listados
Prueba de Interfaces Grficas de Usuario

(GUI, Graphical User Interface)
Uso de una lista de chequeo preestablecida : p Para ventanas:

p
Se abrirn las ventanas mediante rdenes basadas en el teclado o en un men? Se puede ajustar el tamao, mover y desplegar la ventana? Se regenera adecuadamente cuando se escribe y se vuelve a abrir? ...
Para mens emergentes y operaciones con el ratn:

Se muestra la barra de men apropiada en el contexto apropiado? Es correcto el tipo, tamao y formato del texto? Si el ratn tiene varios botones, estn apropiadamente reconocidos en el contexto? ... Se repiten y son introducidos adecuadamente los datos alfanumricos? Funcionan adecuadamente los modos grficos de entrada de datos? (p.e. barra deslizante) Se reconocen adecuadamente los datos no vlidos? Son inteligibles los mensajes de entrada de datos?
Entrada de datos:
Conclusiones
p
La aplicacin de casos de pruebas apropiados es esencial para la validacin y verificacin del sistema construido. Las pruebas normalmente deberan ocupar cerca del 40% del tiempo total de desarrollo de una aplicacin. An as, no puede asegurarse un 100% de fiabilidad para el sistema. En sistemas donde la fiabilidad y correccin del software es un aspecto crtico, las pruebas deben ser ms exhaustivas. En estos casos pueden aplicacarse tambin pruebas de comparacin. Las herramientas que reducen los tiempos de prueba son muy valiosas. Se pueden distinguir varias categoras de herramientas de prueba: analizadores estticos, auditores de cdigo, generadores de archivos de prueba, generadores de datos de prueba y controladores de prueba.
61
Estrategias de prueba del software. Niveles de prueba

1.
Prueba de unidad: es la prueba de cada mdulo, que normalmente

realiza el propio personal de desarrollo en su entorno
2. Prueba de integracin: con el esquema del diseo del software, los

mdulos probados se integran para comprobar sus interfaces en el trabajo conjunto
3. Prueba de validacin: el software totalmente ensamblado se prueba

como un todo para comprobar si cumple los requisitos funcionales y de rendimiento, facilidad de mantenimiento, recuperacin de errores, etc.
4. Prueba del sistema: el SW ya validado se integra con el resto del

sistema (rendimiento, seguridad, recuperacin y resistencia)
5. Prueba de aceptacin: el usuario comprueba en su propio entorno de

explotacin si lo acepta como est o no.
62
Relacin entre productos de desarrollo y niveles de prueba
Requisitos de usuario Especificacin de requisitos Diseo modular Especificacin lgica del mdulo
Pruebas de aceptacin
Pruebas de sistema
Pruebas de integracin Pruebas de unidad

Cdigo
Organizacin para la prueba del software

p
El responsable del desarrollo del SW es siempre responsable de probar las unidades del programa. Muchas veces tambin se encarga de la prueba de integracin. Cuando hay una arquitectura del sw. completa, debe entrar en juego un Grupo Independiente de Prueba (GIP), que garantice independencia (ha debido participar tambin en la especificacin). El GIP es ayudado por el desarrollador.
64
Prueba de unidad
Conductor
Mdulo que se va a probar
Interfaz Estructuras de datos locales Condiciones lmite Caminos independientes Caminos de manejo de errores
Resguardo
Resguardo Casos de prueba
RESULTADOS
65
Prueba de unidad (II)

p
A menudo, se dice que est orientada a caja blanca, aunque se puede completar con caja negra Un enfoque ms realista:
1. 2. Disear un conjunto de pruebas de caja negra, basadas en la especificacin del mdulo Ejecutar las pruebas y comprobar la cobertura obtenida, usando una herramienta de pruebas:
Buscamos al menos C1 + C2 C1 Cobertura de sentencias C2 Cobertura de condicin
3.
Completar con pruebas de caja blanca hasta alcanzar la cobertura deseada
66
Prueba de integracin
p p
Objetivo: prueba de los interfaces entre mdulos Tipos de integracin:

Incremental:
Se sigue el diseo modular Se solapa con la prueba de unidad Tipos:

ascendente Descendente
No probado Probado Probado
No 1. 2. -
incremental (Big-bang) Realizar todas las pruebas unitarias Realizar toda la integracin En este caso las pruebas unitarias no se solapan con las de integracin
67
Integracin incremental descendente

p
Se empieza con el mdulo principal Se sustituyen los resguardos uno a uno Enfoques:
primero-en-profundidad primero-en-anchura Aunque a veces se puede retocar el enfoque...
- Conviene probar pronto los mdulos de E/S - Mdulos crticos
Se llevan a cabo las pruebas (uso de resguardos) Se hace la prueba de regresin

Integracin descendente. Ejemplo

(Primero en profundidad)
69
Tipos de resguardos
p
Mostrar un mensaje de traza Mostrar el parmetro pasado Devolver valor (de una tabla o archivo externo) Hacer una bsqueda en una tabla de un parmetro de entrada y devolver el parmetro de salida asociado
70
Prueba de regresin
p
Cada vez que el se aade un nuevo mdulo como parte de una prueba de integracin, el sw. cambia Estos cambios pueden producir errores con funciones que antes trabajaban perfectamente Las pruebas de regresin consisten en volver a ejecutar un subconjunto de las pruebas realizadas anteriormente, con el fin de asegurarse de que los cambios no han propagado efectos laterales no deseados Fuera de la prueba de integracin, las pruebas de regresin tambin se utilizan cuando cambia la configuracin del software p.ej. durante el mantenimiento correctivo
71
Integracin descendente. Ventajas e inconvenientes

p
Ventajas:
Lo ms importante es probar el control cuanto antes
- Si la jerarqua est bien diseada, es lo que se hace con esta aproximacin
Inconvenientes:
Si se requiere un procesamiento no trivial en los niveles ms bajos de la jerarqua para probar los niveles superiores, qu se hace con los resguardos?
- Desarrollar resguardos con funciones limitadas esfuerzo++ - Retrasar las pruebas hasta que los resguardos sean sustituidos por mdulos reales - Integrar el sw. desde abajo integracin ascendente
72
Integracin incremental ascendente

1. Se combinan los mdulos de bajo nivel en grupos que realicen alguna subfuncin Se escribe un controlador para coordinar la E/S de los casos de prueba Se prueba el grupo Se eliminan los controladores y se combinan los grupos movindose hacia arriba por la estructura del programa
2.
3. 4.
73
Integracin ascendente. Ejemplo
74
Integracin ascendente. Ventajas e inconvenientes
Ventajas:
No se necesitan resguardos
Inconvenientes:
Hay que escribir controladores (impulsores)
- Son menos complejos que los resguardos - Se pueden automatizar ms fcilmente
75
Integracin mixta o sandwich

p p
Se comienza en los mdulos superiores de forma descendente Simultneamente, se empieza de forma ascendente desde los mdulos inferiores Se contina hasta que ambas aproximaciones se encuentran en un nivel intermedio En la integracin ascendente,
si los dos niveles superiores de la estructura se prueban de forma descendente, se elimina la necesidad de muchos controladores
76
Mdulos crticos
p
Debe probarse lo antes posible

Estn dirigidos a varios requisitos del SW Tienen un mayor nivel de control Son complejos o propensos a errores (p.ej., usar complejidad ciclomtica como indicador) Tienen unos requisitos de rendimiento muy definidos
Las pruebas de regresin deben centrarse en los mdulos crticos
77
Prueba de aceptacin
p
La realiza el usuario Si el SW se desarrolla como un producto que se va a usar por muchos usuarios, no es prctico realizar pruebas de aceptacin formales para cada uno de ellos:
pruebas alfa: en el lugar de desarrollo pero por un cliente. El desarrollador observa y registra los problemas y errores. pruebas beta: por los usuarios finales (o un conjunto limitado de ellos) en sus entornos de explotacin. El cliente registra los errores e informa al desarrollador.
78

Técnicas de Prueba Del Software

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Técnicas de Prueba Del Software

Diunggah oleh

Hak Cipta:

Format Tersedia

MODULO 3:

Tema 14: T cnicas de Prueba del Software

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Bibliografa del tema

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Prueba del software

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Prueba del software (II)

ndice de la fiabilidad del software:

No es una actividad secundaria:

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

(Piattini et al. 96)

Diseo de casos de prueba

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Diseo de casos de prueba. Enfoques principales

(Piattini et al. 96)

Diseo de casos de prueba. Enfoques principales (II)

b) Enfoque funcional o de caja negra:

No son excluyentes. Mas bien complementarios.

Prueba de caja blanca

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Bastara con una prueba exhaustiva de caja blanca?

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Bastara con una prueba exhaustiva de caja blanca?

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Prueba del camino bsico

(Mc Cabe 76)

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Prueba del camino bsico

(Mc Cabe 76)

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Notacin de grafo de flujo

Hacer ... hasta x

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Notacin de grafo de flujo

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Notacin de grafo de flujo

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Notacin de grafo de flujo

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Notacin de grafo de flujo

Notacin de grafo de flujo

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Notacin de grafo de flujo

Ingeniera del Software (3 I.T.I.S., I.T.I.G.)

Mdulo 3. Tema 14: Tcnicas de Prueba del Software

Notacin de grafo de flujo