Pruebas del softwareLaura Patricia Pinto Prieto

Introducción Las pruebas del software son un elemento crítico para la garantía

de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación.

La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas.

No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en

las pruebas. En casos extremos,las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) puede costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos!

¿Qué es probar software?

Algunas definiciones incorrectas:• Probar es demostrar que no hay errores

presentes en un programa.• El propósito de probar es mostrar que el programa

realiza correctamente las funciones esperadas.La definición Correcta

• Probar es el proceso ejecución de un programa con el fin de encontrar errores.

Otras Definiciones• Verificar.• Validar.• Pruebas.• Caso de Prueba.• Defecto.• Fallo.• Error.

Producto obtenido Se define y documenta un conjunto de

casos de prueba, diseñados para comprobar la lógica interna y los requisitos externos. Se determinan los resultados esperados y se guardan los resultados realmente obtenidos.

Relación entre error, defecto y fallo

Objetivos de la Prueba. La prueba es el proceso de ejecución de

un programa con la intención de descubrir un error.

Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Principal objetivo Los objetivos anteriores suponen un cambio dramático de

punto de vista. Nos quitan la idea que, normalmente, tenemos de que una prueba tiene éxito si no descubre errores.

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

Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software.

Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento.

Principios de las pruebas A todas las pruebas se les debería poder

hacer un seguimiento hasta los requisitos del cliente.

Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos.

Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo grande”.

Principios de las pruebas No son posibles las pruebas exhaustivas: es

imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.

Para ser más eficaces (pruebas con la más alta probabilidad de encontrar errores), las pruebas deberían ser realizadas por un equipo independiente.

Principios de las pruebas Se debe inspeccionar a conciencia el

resultado de cada prueba para, así, poder descubrir posibles síntomas de defectos.

Cada caso de prueba debe definir el resultado de salida esperado.

Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados.

Principios de las pruebas

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

Se deben evitar los casos desechables.

Principios de las pruebas No deben hacerse planes de prueba

suponiendo que, prácticamente, no hay defectos en los programas, y dedicando pocos recursos a las pruebas.

La experiencia indica que donde hay un defecto hay otros.

Las pruebas son una tarea creativa como el desarrollo de software.

Facilidad de PruebaJames Bach describe la facilidad de prueba de la siguiente

manera:

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora.

Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos.

La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.

Operatividad.«Cuanto mejor funcione, más eficientementese puede probar.»El sistema tiene pocos errores (los errores

añaden sobrecarga de análisis y de generación de informes al proceso de prueba).

Ningún error bloquea la ejecución de las pruebasEl producto evoluciona en fases funcionales

(permite simultanear el desarrollo y las pruebas).

Observabilidad.«Lo que ves es lo que pruebas.» Se genera una salida distinta para cada entrada. Los estados y variables del sistema están visibles o se pueden

consultar durante la ejecución. Los estados y variables anteriores del sistema están

visibles o se pueden consultar (por ejemplo, registros de transacción).

Todos los factores que afectan a los resultados están visibles. Un resultado incorrecto se identifica fácilmente. Los errores internos se detectan automáticamente a través de

mecanismos de auto-comprobación. Se informa automáticamente de los errores internos. El código fuente es accesible.

Controlabilidad«Cuanto mejor podamos controlar el software, más se puede

automatizar y optimizar.» Todos los resultados posibles se pueden generar a través

de alguna combinación de entrada. Todo el código es ejecutable a través de alguna

combinación de entrada. El ingeniero de pruebas puede controlar directamente Los estados y las variables del hardware y del software. Los formatos de las entradas y los resultados son

consistentes y estructurados. Las pruebas pueden especificarse, automatizarse y

reproducirse convenientemente.

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

El sistema software está construido con módulos independientes.

Los módulos del software se pueden probar independientemente

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

rápidamente podremos probarlo.» Simplicidad funcional (por ejemplo, el conjunto

de características es el mínimo necesario para cumplir los requisitos).

Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos).

Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento).

Estabilidad.«Cuanto menos cambios, menos

interrupciones a las pruebas.» Los cambios del software son infrecuentes. Los cambios del software están

controlados. Los cambios del software no invalidan las

pruebas existentes. El software se recupera bien de los fallos.

Facilidad de comprensión. «Cuanta más información tengamos, más inteligentes

serán las pruebas.» El diseño se ha entendido perfectamente. Las dependencias entre los componentes internos,

externos y compartidos se han entendido perfectamente.

Se han comunicado los cambios del diseño. La documentación técnica es instantáneamente

accesible. La documentación técnica está bien organizada. La documentación técnica es específica y detallada. La documentación técnica es exacta.

Bondad de una Prueba

Debe tener una alta probabilidad de encontrar un error.

No debe ser redundante. Debe ser la mejor de todas las posibles. No debe ser ni demasiado sencilla ni

demasiado compleja.

El proceso de Prueba

La depuración (localización y corrección de defectos).

El análisis de la estadística de errores.

Ciclo completo de las Pruebas

Diseño de casos de prueba1. Prueba de caja negra :Conociendo la función

específica para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa y, al mismo, tiempo buscando errores en cada función;

2. Prueba de caja blanca : Conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que «todas las piezas encajan», o sea, que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada.

Pruebas de Software 26Profesor: Juan Antonio López Quesada

Diseño de casos de prueba.Enfoques principales

(Piattini et al. 96)

Pruebas de Software 27Profesor: Juan Antonio López Quesada

Diseño de casos de prueba.Comparación de los Enfoques principales

a) Enfoque estructural o de caja blanca (transparente): se centra en la estructura interna del programa para

elegir los casos de pruebala prueba exhaustiva consistiría en probar todos los

posibles caminos de ejecuciónnº caminos lógicos ( buscar los más importantes)

b) Enfoque funcional o de caja negra: para derivar los casos, se estudia la especificación de

las funciones, la entrada y la salida. No son excluyentes.

Pruebas de Software 28Profesor: Juan Antonio López Quesada

Prueba de caja blanca¿Porqué usar pruebas de caja blanca?

Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa.

A veces creemos que un camino lógico tiene pocas posibilidades de ejecutarse cuando puede hacerlo de forma normal.

“Los errores se esconden en los rincones y se aglomeran en los límites” (Beizer 90)

29

Prueba del camino básico(Mc Cabe 76)

Objetivos:1. Obtener una medida de la complejidad lógica

de un diseño procedimental Complejidad ciclomática de Mc Cabe

2. Usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución

Los casos de prueba obtenidos garantizan que durante la prueba se ejecuta al menos una vez cada sentencia del programa (cobertura de sentencias).

Se puede automatizar.

Grafo de Flujo de las Estructuras Básicas de programa

Separar todas las condiciones Agrupar sentencias ‘simples’ en bloques Numerar todos los bloques y tambien las

condiciones

X

X

X

Secuencia Si x Entonces…(If x Then … Else…)

Hacer … hasta x(Do … Until x)Repetir

Mientras x Hacer …(While x Do … )

Grafo de flujoCada círculo, denominado nododel grafo de flujo, representa una o más sentencias procedimentales.Un solo nodo puede corresponder a unasecuencia de cuadros de proceso y a un rombo de decisión.Las flechas del grafo de flujo, denominadas aristaso enlaces, representan flujo de control y sonanálogas a las flechas del diagrama de flujo. Una aristadebe terminar en un nodo, incluso aunque el nodono represente ninguna sentencia procedimental (porejemplo, véase el símbolo para la construcciónSi-entonces-si-no). Las áreas delimitadas por aristasy nodos se denominan regiones. Cuando contabilizamos las regiones incluimos el área exterior del grafo, contando como otra región más.

Prueba del camino Básico Complejidad Ciclomatica(La complejidad de

McCabe V (G))

La métrica de McCabe ha sido muy popular en el diseño de pruebas.

Define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

¿Cómo sabemos cuántos caminos hemos de buscar?

El cálculo de la complejidad ciclomática nos da la respuesta.La complejidad se puede calcular detres formas:1. El número de regiones del grafo de flujo coincide.

2. La complejidad ciclomática, V(G), de un grafo decon la complejidad ciclomática. flujo G se define como.donde A es el número de aristas del grafo de flujo y N es el

número de nodos del mismo.

3. La complejidad ciclomática, V(G), de un grafo deflujo G también se define como V(G)=P+ 1 donde P es el número de nodos predicado contenidos en

el grafo de flujo G.

Formas de Calcular la Complejidad Ciclomática V(G) V (G) = a – n + 2 V (G) = r V (G) = c + 1Donde

a : # de arcos o aristas del grafo.n : # de nodos.r : # de regiones cerradas del grafo.c : # de nodos de condición.

¿Qué es lo que se logra con la complejidad ciclomática?

V(G) marca el límite mínimo de casos de prueba para un programa.

Cuando V (G) >10 la probabilidad de defectos en el módulo o programa crece mucho entonces quizás sea interesante dividir el módulo.

Ejemplo de calculo de V (G) a) V (G) =14-11+2=5

b) V (G) = 5 Regiones Cerradas.

c) V (G) = 4+1= 5 Condiciones

Es más, el valor de V(G) nos da un límite superior para el número de caminos independientes que componen el conjunto básico y, consecuentemente, un valor límite superior para el número de pruebas que se deben diseñar y ejecutar para garantizar que se cubren todas las sentencias del programa.

1

2

3

4

5

6

7 8

9

10

11

a1a2 a3

a4

a5a6 a7

a8

a9 a10

a11 a12

a13 a14

Región 1

Región 2

Región 3

Región 4

Región 5

Trabajo para entregar la próxima clase (nota 40% segundo corte en grupo de a 3 personas máximo)1. Ejercicio:

a. Myers [MYE79] usa el siguiente programa como autocomprobación de su capacidad para especificar una prueba adecuada: un programa lee tres valores enteros. Los tres valores se interpretan como representación de la longitud de los tres lados de un triángulo. El programa imprime un mensaje indicando si el triángulo es escaleno, isósceles o equilátero.

b. Desarrolle el programa y haga el grafo de flujo ,calcule V(G) y obtenga los casos de prueba. (ver ejemplo del libro de pressman).

2. Investigar sobre Matriz de grafos.3. Pruebas de estructuras de control

Próxima Clase Parcial sobre Diseño de componentes,

pruebas de software, hasta pruebas de caja blanca, incluyendo los puntos del trabajo de investigación.

En el libro de Pressman 5 ed. son capítulos:

16- Diseño a nivel de componentes. 17- Técnicas de prueba de software.

BIBLIOGRAFIA Fairley R. Ingeniería de Software.

Pressman, R.S. Ingeniería del Software. Un enfoque práctico.

Presentación de Juan Antonio López Quesada. Facultado de Informática.