TÉCNICAS DE PRUEBA DEL SOFTWARE

EL INGENIERO INTENTA CONSTRUIREL SOFTWARE PARTIENDO DE UN CONCEPTO ABSTRACTO Y LLEGANDO A UNA IMPLEMENTACIÓN TANGIBLE

Objetivos de las pruebas

La prueba es el proceso de

ejecución de un programa

con la intención de descubrir un

error.

Nuestro objetivo es diseñar pruebas que sistemáticamentesaquen a la luz diferentes clases de errores, haciéndolocon la menor cantidad de tiempo y de esfuerzo.

Una prueba tiene éxito si descubre un

error no detectado

hasta entonces.

Nos quitan la idea que, normalmente,tenemos de que una prueba tiene

éxito si nodescubre errores..

Un buen caso de prueba es aquel que tiene una

altaprobabilidad de mostrar un error no descubierto

hastaentonces.

FUNDAMENTOS DE LAS PRUEBAS

EL INGENIERO CREA UNA SERIE DE CASOS DE PRUEBAQUE INTENTAN «DEMOLER» EL SOFTWARE CONSTRUIDO

Las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente)como destructivo en lugar de constructivo.

Para ser más eficaces, Para ser más eficaces, las pruebas deberían las pruebas deberían

ser realizadasser realizadaspor un equipo por un equipo independiente.independiente.

Principios de las Principios de las pruebaspruebas

A todas las pruebas se les A todas las pruebas se les debería poder hacer undebería poder hacer un

seguimiento hasta cumplir seguimiento hasta cumplir con los requisitos del con los requisitos del

clienteclienteLas pruebas deberían Las pruebas deberían

planificarse mucho planificarse mucho antes de que empiecen.antes de que empiecen.

El principio de Pareto El principio de Pareto es aplicable a la prueba es aplicable a la prueba

del software.del software.

Las pruebas deberían Las pruebas deberían empezar por «lo empezar por «lo

pequeño» y pequeño» y progresar hacia «lo progresar hacia «lo

grandegrande

No son posibles las No son posibles las pruebas exhaustivas.pruebas exhaustivas.

Operatividad. «Cuanto mejor funcione, más eficientementese puede probar.»

Controlabilidad. «Cuanto mejor podamos controlar

el software, más se puede automatizar y optimizar.»

Capacidad de descomposición. «Controlando el

ámbito de las pruebas, podemos aislar más rápidamente

los problemas y llevar a cabo mejores pruebas de regresión.»

Observabilidad. «Lo que ves es lo que pruebas.»

Simplicidad. «Cuanto menos haya que probar, más

rápidamente podremos probarlo.»Estabilidad. «Cuanto menos cambios,

menos interrupcionesa las pruebas.»

Facilidad de comprensión.

«Cuanta más informacióntengamos, más inteligentes serán las pruebas.»

Una buena prueba tiene una alta probabilidad deencontrar un error.

Una buena prueba no debe ser redundante. El tiempoy los recursos para las pruebas son limitados.

El diseño se ha entendido perfectamente

Una buena prueba debería ser «la mejor de la cosecha »

Las dependencias entre los componentes internos,externos Una buena prueba no

debería ser ni demasiado sencillani demasiado compleja.

Se han comunicado los cambias del diseño.

LAS PRUEBAS

comprueban los caminos lógicos del software proponiendo

casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el

«estado del programa» en varios puntos para determinar si el estado real coincide con el esperado o mencionado.

DE LA CAJA BLANCA

DE LA CAJA NEGRA Se basa las pruebas sobre la interfaz del software

operatividad del sistemaSe basa Es el minucioso examen de los detalles procedimentales

(Código Fuente). Es diseñada después de tener el

código fuente

LA PRUEBA DEL CAMINO BÁSICOPermite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución

Construcciones estructurales en forma de grafo de flujo:Según-sea(Case)

Secuencia Si-si-no Mientras Repetir-hasta- Según Sea (If) (While) (Untii) (Case)

Donde cada círculo representa una o más sentencias, sin bifurcaciones, en LDP o código fuente

Diagramas de FlujoDiagrama de Flujo Representa

la estructura y control del programa

Grafo de FlujoRepresenta el Flujo de control lógico mediante

notación ilustradaCada circula es un Nodo y

corresponde a una secuencia de cuadros de proceso y a un rombo de

decisión

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-11Fíjese que cada nuevo camino introduce una nuevaarista. Cual es el nuevo camino?

Complejidad ciclomática

La complejidad ciclomática es una métrica del software

que proporciona una medición cuantitativa de la complejidad lógica de

un programa

Definición: El número de caminos

independientes del conjunto básico

de un programa y nos da un límite

superior para elnúmero de pruebas

que se deben realizar para

asegurarque se ejecuta cada

sentencia al menos una vez

Un camino independiente es cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva

condición

Determinamos la complejidad ciclomática delgrafo de flujo resultante.

Se determina aplicando uno de los algoritmos descritos en la Sección Se debe tener en cuenta que se puede determinar V(G) sin desarrollar el grafo de flujo, contando todas las sentencias condicionales del LDP

V(G) = 6 regionesV(G) = 17 aristas - 13 nodos +2 = 6V(G) = 5 nodos predicado + 1 = 6

Determinamos un conjunto básico de caminoslinealmente independientes.

camino 1: 1-2-10-11-13camino 2: 1-2-10-12-13

camino 3: 1-2-3-10-11-13camino 4: 1 -2-3-4-5-8-9-2-...

camino 5: 1 -2-3-4-5-6-8-9-2-...camino 6: 1-2-3-4-5-6-7-8-9-2- ...

Los puntos suspensivos (...) que siguen a los

caminos 4,5 y 6 indican que cualquier camino del

resto de la estructura de control es aceptable