software testing 2

Software testing

DA4 – 2010/2011

Intro

Software testing

“Proceso que ayuda a identificar la corrección, completitud, seguridad y calidad del software desarrollado”

Intro2

Prueba“Proceso de ejecutar un conjunto de elementos

de software con el fin de encontrar errores”

– No es:• Demostrar que no hay errores en el programa• Mostrar que el programa funciona correctamente

Intro3

Caso de prueba“Conjunto de condiciones , datos o variables

bajo las cuales el desarrollador determinará si el o los correspondientes requisitos de un sistema software se cumplen de forma parcial, de forma completa o no se cumplen”

Intro4

Error“Discrepancia entre un valor o condición

calculado, observado o medido y el valor o condición específica o teóricamente correcta.”

- Es un fallo cometido por el desarrollador.

Intro5

Defecto técnico“Desviación en el valor esperado para una cierta

característica”

- Fallo software es la consecuencia de un defecto.

Principios básicos

• Es conveniente definir la mayor parte de los casos de prueba y, al menos, esbozar el plan de pruebas en la fase de diseño.

• Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error o fallo.

• La definición del resultado esperado del programa es una parte integrante y necesaria del caso de prueba.

Principios básicos2

• Un programador, NO PRUEBA SU PROPIO CÓDIGO.

• Los casos de prueba deben ser escritos tanto para condiciones de entrada válidas y esperadas como para condiciones inválidas e inesperadas. Examinar un programa para comprobar si hace o no lo que se supone que debe hacer es la mitad del trabajo. La otra mitad consiste en averiguar si no hace lo que no tiene que hacer y que los errores y fallos estén controlados.

Principios básicos3

• La probabilidad de encontrar errores adicionales en una función del programa o método de una clase es proporcional al número de errores ya encontrados en la misma función o método. Es implica que cuanto más se modifiquen los elementos presentes en el código fuente, más hay que probarlo.

• Es imprescindible documentar los casos de prueba. Esto permite volver a ejecutar en el futuro aquellos casos que sean necesarios.

Verificación

• La verificación comprueba el funcionamiento del software, es decir, asegura que se ha implementado correctamente una funcionalidad específica.

¿Se ha construido el sistema correctamente?

Validación

• La validación comprueba si los requisitos del usuario se cumplen y los resultados obtenidos son los previstos.

¿Se ha construido el sistema correcto?

Proceso de pruebas

1) Diseño del plan de pruebas.– En la etapa de diseño.– Consiste en la planificación temporal de las distintas

pruebas (cuándo, cómo y quién va a llevarlas a cabo)– Definición de la estrategia de pruebas (ascendente,

descendente, sandwich…)– Procedimiento a seguir cuando una prueba no obtiene el

resultado esperado.– Asignación de responsabilidades

Proceso de pruebas

2) Diseño de casos de pruebas.– Se definirán los casos de prueba de tal forma que con un

número de casos cuidadosamente seleccionados se realice un número de pruebas que alcancen el nivel de cobertura deseado.

Proceso de pruebas

3) Prueba.– Se lleva a cabo la escritura del código de pruebas

encargado de la ejecución de los casos de prueba anteriormente diseñados.

– Se ejecuta la prueba propiamente dicha.

Proceso de pruebas

4) Comparación y evaluación de resultados– Teniendo en cuenta los resultados esperados, se

comparan éstos con los obtenidos. Si son iguales, la prueba se considera válida, si no es así se aplican los procedimientos definidos en el plan de pruebas.

Proceso de pruebas

5) Localización del error.– Es necesario localizar el segmento de código fuente en el

que se encuentra el error.– Se utilizan herramientas como JUnit y los ejecución en

debuggers con puntos de interrupción.

Pruebas basadas en la ejecución del código

• Pruebas de caja blanca– Se centran en probar el comportamiento interno y

la estructura del programa examinando la lógica interna. Para ello:

• Se ejecutan todas las sentencias (al menos una vez)• Se recorren todos los caminos independientes de cada

módulo.• Se comprueban todas las decisiones lógicas.• Se comprueban todos los bucles.• En todos los casos se intenta provocar situaciones

extremas o límites.

Técnicas de caja blanca

• Para realizar pruebas de caja blanca, el código debe estar disponible.a) Pruebas de interfaces entre módulos o clases

I. Analiza el flujo de datos que pasa a través de la interfaz de la clase objetivo de la prueba. Se distingue entre interfaz interna o externa.

II. En las pruebas de interfaces internas (entre métodos) es necesario comprobar los argumentos de llamada a funciones y la consistencia de las definiciones de variables globales entre los módulos. Las pruebas de interfaces internas corresponden al conjunto de pruebas unitarias, que están enfocadas a verificar el correcto funcionamiento de un módulo o clase aisladamente del resto.

III. En las pruebas de interfaces externas se ha de verificar que el flujo de datos intercambiado entre clases es el correcto. Este tipo de pruebas es una parte de las pruebas de integración.

Técnicas de caja blanca2

b) Pruebas de estructuras de datos localesI. Estas pruebas aseguran la integridad de los datos

durante todos los pasos de la ejecución del módulo. Se comprueban las referencias de datos, la posible utilización de variables no inicializadas, no salirse del límite de matrices o vectores, la correcta declaración de datos o el hecho de no realizar comparaciones entre variables de distinto tipo.

II. Se localizan errores derivados del uso de variables: overflow, underflow, NaN…

Técnicas de caja blanca

c) Prueba del camino básicoI. Se definen para este tipo de pruebas un camino

básico de caminos de ejecución, a partir de la propuesta de McCabe.

II. La complejidad ciclomática indica el número de caminos básicos a probar y responde a la siguiente fórmula:

V(G) = Aristas – Nodos + 2

Prueba del camino básico• Secuencia

• if• While

• then • else

• end• if

• CASE

• opción1

• no opción1

• END CASE

• opción2

• no opción2

• ...

• ...

• no opciónN

• opciónN

Prueba del camino básico

• Complejidad ciclomática de un grafo de flujo V(G) establece el número de caminos independientes

• Puede calcularse de tres formas alternativas:

– El número de regiones del grafo de flujo

– V(G) = A - N + 2, donde A es el número de aristas y N es el número de nodos

– V(G) = P + 1, donde P es el número de nodos predicado

Prueba del camino básico (Ejemplo)

11

2, 3

1111

1010

99

8877

66 4, 54, 5

Prueba del camino básico

V(G) = 4

– 11 aristas - 9 nodos + 2 = 4

– 3 nodos predicado + 1 = 4

Prueba del camino básico

• Un conjunto de caminos independientes

Camino 1: 1-11

Camino 2: 1-2-3-4-5-10-1-11

Camino 3: 1-2-3-6-8-9-10-1-11

Camino 4: 1-2-3-6-7-9-10-1-11

• El camino

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

No se considera un camino independiente, ya que es simplemente una combinación de caminos ya especificados

• Los cuatro caminos anteriores constituyen un conjunto básico para el grafo

Prueba del camino básico

• Pasos para realizar las pruebas:1. A partir del diseño o del código fuente, dibujar el

grafo de flujo asociado2. Se calcula la complejidad ciclomática del grafo3. Se determina un conjunto básico de caminos

independientes4. Se preparan los casos de prueba que obliguen a

la ejecución de cada camino del conjunto básico

Prueba del camino básico

• Tratamiento de Condiciones Compuestas

• Ejemplo :

IF a OR b THEN procedimiento x

ELSE procedimiento y

ENDIF

a

xy

b x

Nodos Predicado

False True

False True

Ejercicio 1• PROCEDURE imprime_media(VAR x, y : real;)

• VAR resultado : real;• resultado:=0;• IF (x < 0 OR y < 0)• THEN

• WRITELN(• “x e y deben ser positivos”);

• ELSE• resultado := (x + y)/2• WRITELN(• “La media es: “, resultado);

• ENDIF• END imprime_media

• 1

• 2

• 3

• 4

• 5

• 6

Resolución

• 1

• 2

• 3 • 4

• 4

• 6

• 5

• False

• False

• True

• True

• x < 0

• y < 0

V(G) = 2+1 = 3. Por lo tanto, hay que

determinar tres caminos independientes.

Por ejemplo:

Camino 1: 1-2-3-5-6Camino 2: 1-2-4-6Camino 3: 1-2-3-4-6

Casos de prueba para cada camino:

Camino 1: Escoger algún x e y tales que se cumpla x >= 0 AND y >= 0

Camino 2: Escoger algún x tal que se cumpla x < 0

Camino 3: Escoger algún x e y tales que se cumpla x >= 0 AND y < 0

Ejercicio 2

Resolución

V(MCD) = 7 – 6 + 2 = 3

Notas– Los errores lógicos y las suposiciones incorrectas son

inversamente proporcionales a la probabilidad de que se ejecute un camino del programa

– A menudo creemos que un camino lógico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma regular

– Los errores tipográficos son aleatorios

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

Pruebas de condiciones límite

Pruebas de condiciones límite2

• Simples– No entrar– Entrar una vez– Entrar dos veces– Entrar m veces, con m<n– Entrar n-1, n y n+1 veces

Pruebas de condiciones límite3

• Anidados– Del más interior hacia afuera

• Concatenados– Si son independientes, como los simples. Si son

anidados, como los anidados.• No estructurados

– ¡CUIDADO! -> GOTO.

Pruebas de condición

• Errores comunes– Error en el operador lógico

• Incorrecto• Desaparecido• Sobrante

– Error en la variable lógica– Error en la expresión aritmética– Error en el operador relacional– Error en los paréntesis

Pruebas de condición2

• Pruebas:– Probar la rama verdadera y la rama falsa

Pruebas de condición3

• Cobertura de decisión

Pruebas de condición4• Cobertura de condición

CP1: D1 = V, D2 = V, D3 = VCP2: D1 = V, D2 = V, D3 = FCP3: D1 = V, D2 = FCP4: D1 = F

Pruebas de condición5

Pruebas de condición6