Unidad 3

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 9

Unidad 3: diseño y realización de pruebas

Contenido:

1.Filosofia de las pruebas de software

2.Estrategia de las pruebas del software

3.Tecnicas de diseño de los casos de prueba

4.Documentacion de las pruebas

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.

El objetivo de la etapa de pruebas es descubrir defectos en la aplicación antes de entregarla al


cliente

1.Filosofia de las pruebas de software

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

El objetivo de las pruebas es la detección de defectos y no la demostración de que no los tiene.

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.

VALIDACIÓN: Comprobacion de si se está construyendo el producto correcto, es decir, el que


se desea el cliente y cumple con los requisitos especificados

VERIFICACIÓN: Comprobación de si el producto funciona correctamente, es decir, si lo que


hace la realización y de forma correcta.

Estrategias que se deben considerar relacionados con la puesta en práctica de las pruebas:

-Estrategia de aplicación de las pruebas:

Establecer qué partes del software se deben probar


-técnicas de diseño de casos de prueba:

Decidir de que manera se deben realizar, es decir, seleccionar la técnica apropiada.

Un caso de prueba consiste en indicar:

-qué datos de entrada se deben suministrar al programa

-qué datos de salida se deberán obtener

-Cuál es el fin de llevar a cabo este caso de prueba

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

2. Estrategia de pruebas del software

Las pruebas comienzan por porciones pequeñas de software y posteriormente se van


incrementando

Se suelen llevar a cabo 4 tipos de pruebas secuenciales:

 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.

o En el paradigma orientado a objetos:


 Prueba de clases (prueba de todos sus métodos)

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 del sistema:

o Comprueba la robustez del sistema, es decir si cumple con los requsiitos


especificados:
 Cumplimiento de los requisitos funcionales
 Funcionamiento de interfaces
 Adecuación de la documentación del usuario
 Ejecución y rendimiento en condiciones limite y de sobrecarga
 Tipos de prueba del sistema (no funcionales):
 Pruebas de recuperación: se fuerza un fallo y se comprueba
que el sistema se recuperar adecuadamente
 Pruebas de seguridad: se verifica que el sistema está protegido
contra accesos ilegales
 Pruebas de esfuerzo o resistencia: se somete al sistema a
situación extremas es decir que demanden muchos recursos
 Pruebas de rendimiento: se comprueba su respuesta en un
tiempo limitado
 Pruebas de despliegue o configuración: se prueba en distintas
plataformas

Prueba de validación:

o Comprueba so el software es considerado valido por la persona usuario y si esta


preparado para su implantación.
o Los criterios de validación deben estar especificados en la ERA (especificación de
requisitos del software).
o Tipos de pruebas de validación:
Pruebas alfa:
 Se realizan por el cliente o el usuario en el lugar de
desarrollo
 El cliente utiliza el software (a veces sin terminar) de
forma natural bajo la observación del desarrollador
que ira registrando los errores y problemas de uso.
Pruebas beta:
 Se realizan después de la alfa
 Se hacen por los usuarios finales de software en sus
trabajos
 El desarrollador no esta presente
 El user registra lo que encuentra e informa al
desarrollador de manera que este realice las
modificaciones y prepare otra version
3. Técnicas de diseño de casos de prueba

Prueba de caja blanca o pruebas estructurales:

o Examinan los detalles cada modulo para lo que se necesita el código fuente.
o Se prueban los diferentes caminos, bucles, variables etc.

Prueba de caja negra o funcionales:

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

 Pruebas de caja blanca:


o Del camino básico
o De bucles
o De flujo de datos
 Pruebas de caja negra
o Particiones o clases de equivalencia
o Análisis de valores limite
o Conjetura de errores

PRUEBA DE CAJA BLANCA

-Prueba del camino básico:

 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.

Como se crean los grafos 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) =número de regiones

V(G)=A - N +2

V(G)=NP + 1

A:numero de aristas

N:numero de nodos

NP:numero de nodos predicados


s

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.

caminos Casos de prueba Resultados


esperados
C1 Cadena vacía 0
C2
C3
C4

Prueba de bucles.

Se centra solamente en las estructuras de bucles

Los casos que se deben generar son:

Bucles simples:si el numero máximo de iteraciones por el bucle es n, se deben probar


los siguientes casos
Saltarse completamente el bucle

También podría gustarte