Unidad 3
Unidad 3
Unidad 3
Contenido:
5.Herramientas de depuración
6.Pruebas automáticas
Introducción
Cuando se desarrolla una aplicación informática se desea que sea de calidad (responde a las
necesidades del cliente) y que tenga el menor numero de fallos.
Una de las tareas del ciclo de vida del software son las pruebas, las cuales permiten detectar
los defectos cometidos durante el desarrollo del software
En muchos casos resulta imposible detectar todos los fallos, pero se deben realizar pruebas
que no supongan un esfuerzo excesivo, pero con las que haya una alta probabilidad de
encontrar defectos.
Normalmente son los propios desarrolladores los encargados en realizar las pruebas. No
obstante, en proyectos grandes, se suele involucrar a un equipo de pruebas independiente con
el que se trabajará en conjunto
Las pruebas del software consisten en realizar la validación y verificación del producto.
Estrategias que se deben considerar relacionados con la puesta en práctica de las pruebas:
En caso de que una vez ejecutado la prueba, la salida obtenida no coincida con la salida
esperada, esto significa que se ha detectado un error. Se realizará la tarea de depuración
La depuración es una tarea resultado de una prueba exitosa en la que se localiza el error y se
corrige
Prueba de unidad
Prueba de integración
Prueba del sistema
Prueba de validación
Prueba de unidad:
o En el paradigma estructurado:
Prueba de módulos individuales.
Prueba de integración:
o Comprueba si las clases del software funcionan correctamente cuando cooperan entre
ellas.
o Enfoques para realizar la prueba:
Integración no incremental o bigbang:
Se prueban módulos por separado
Se encuentran muchos errores y la corrección es difícil
Integración incremental:
Se van construyendo el programa completo y probando
La localización de errores es más fácil
Estrategias
Ascendente: comenzar en módulos de nivel bajo
Descendente: empieza por el programa principal hacia abajo
Prueba de validación:
o Examinan los detalles cada modulo para lo que se necesita el código fuente.
o Se prueban los diferentes caminos, bucles, variables etc.
o Se considera el software como una caja negra que recibe una serie de entradas y
salidas
o No se necesita disponer el código fuente solo la función que hace el software
o Su objetivo es validar los requisitos funcionales
Esta técnica permite obtener una medida de complejidad del modulo probado llamada
complejidad ciclomá0.tica de mccabe, es un numero entero que indica cuantos
caminos independientes hay en el código y en consecuencia cuantos casos de prueba
hay que ejecutar para garantizar que se recorren todas las sentencias del código una
vez
Para calcular esta medida es necesario presentar el código fuente haciendo el grafo de
flujo.
Se asigna un numero a cada sentencia del xodiga y cada condición. Si se dispone de varias
instrucciones en secuencia, se puede asignar un numero único a yodas ellas y estas serán
tratadas como un bloque. Cada uno de estos elementos constituirá un nodo, representado por
un circulo en cuyo interior aparecerá el número asignado.
Se unen los nodos mediante flechas llamadas aristas que representan el flujo de control.
Las áreas delimitadas por aristas y nodos se llaman regiones. El área exterior del grafo es otra
región mas
Representación de las estructuras básicas de programación en un grafo de flujo.
Ejemplo 1:
Una vez creado el grafo de flujo, se puede calcular la complejidad ciclomática de McCabe V(G)
de cualquiera de las tres formas siguientes:
V(G)=A - N +2
V(G)=NP + 1
A:numero de aristas
N:numero de nodos
sssssssssssssssssssssssssssssssssssssssss
El valor V(G) indica el numero de caminos posibles independientes del grafo de flujo, y por
tanto, el numero de casos de prueba que hay que generar
Un camino independiente es cualquier camino del programa que introduce por lo menos, n
nuevo conjunto de sentencias de proceso o una condición, en un diagrama de flujo, un camino
independiente está constituido por lo menos por una arista que no haya sido recorrida
anteriormente a la definición del camino
El ultimo paso de este método es generar casos de prueba que recorran cada uno de los
caminos eligiendo los datos de entrad que fuercen cada uno de los mismos.
Puede ocurrir que alguno de los caminos no se pueda recorrer de forma de forma
independiente, sino como parte de otro camino.
Para cada caso de prueba, se deben comparar los resultados obtenidos con los esperados.
Existirá algún defectos en caso de que no haya coincidencia en cuyo caso se llevará un proceso
de depuración.
Prueba de bucles.