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)
Recommended