Software testing 1
- 1. Software testingDA4 – 2010/2011
- 2. IntroSoftware testing“Proceso que ayuda a identificar la corrección, completitud, seguridad y calidad del software desarrollado”
- 3. Intro2Prueba“Proceso de ejecutar un conjunto de elementos de software con el fin de encontrar errores”No es:Demostrar que no hay errores en el programaMostrar que el programa funciona correctamente
- 4. Intro3Caso 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”
- 5. Intro4Error“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.
- 6. Intro5Defecto técnico“Desviación en el valor esperado para una cierta característica” - Fallo software es la consecuencia de un defecto.
- 7. Principios básicosEs 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.
- 8. Principios básicos2Un 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.
- 9. Principios básicos3La 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.
- 10. VerificaciónLa 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?
- 11. ValidaciónLa validación comprueba si los requisitos del usuario se cumplen y los resultados obtenidos son los previstos. ¿Se ha construido el sistema correcto?
- 12. Proceso de pruebasDiseñ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
- 13. Proceso de pruebas2) 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.
- 14. Proceso de pruebas3) 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.
- 15. Proceso de pruebas4) Comparación y evaluación de resultadosTeniendo 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.
- 16. Proceso de pruebas5) 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.
- 17. Pruebas basadas en la ejecución del códigoPruebas de caja blancaSe 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.
- 18. Técnicas de caja blancaPara realizar pruebas de caja blanca, el código debe estar disponible.Pruebas de interfaces entre módulos o clasesAnaliza 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.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.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.
- 19. Técnicas de caja blanca2b) Pruebas de estructuras de datos localesEstas 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.Se localizan errores derivados del uso de variables: overflow, underflow, NaN…
- 20. Técnicas de caja blancac) Prueba del camino básicoSe definen para este tipo de pruebas un camino básico de caminos de ejecución, a partir de la propuesta de McCabe.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
- 21. Prueba del camino básicoSecuenciaendifno opción1no opción2no opciónN...CASE...opción2opciónNthenelseWhileopción1ifEND CASE
- 22. Prueba del camino básicoComplejidad ciclomáticade un grafo de flujo V(G) establece el número de caminos independientesPuede calcularse de tres formas alternativas:El número de regiones del grafo de flujoV(G) = A - N + 2, donde A es el número de aristas y N es el número de nodosV(G) = P + 1, donde P es el número de nodos predicado
- 23. Prueba del camino básico (Ejemplo)112, 34, 5664, 587879910101111
- 24. Prueba del camino básicoV(G) = 411 aristas - 9 nodos + 2 = 43 nodos predicado + 1 = 4
- 25. Prueba del camino básicoUn 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-11El camino 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11No se considera un camino independiente, ya que es simplemente una combinación de caminos ya especificadosLos cuatrocaminosanterioresconstituyen un conjuntobásicopara el grafo
- 26. Prueba del camino básicoPasospararealizarlaspruebas:A partir del diseño o del código fuente, dibujar el grafo de flujo asociadoSe calcula la complejidad ciclomática del grafoSe determina un conjunto básico de caminos independientesSe preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico
- 27. Prueba del camino básicoTratamiento de CondicionesCompuestasEjemplo :IF a OR b THEN procedimiento x ELSE procedimiento y ENDIFNodos PredicadoaFalseTruebxFalseTruexy
- 28. Ejercicio 1PROCEDURE imprime_media(VAR x, y : real;)VAR resultado : real;resultado:=0;31IF (x < 0 OR y < 0)2THEN“x e y deben ser positivos”);WRITELN(ELSE4resultado := (x + y)/25WRITELN(“La media es: “, resultado);ENDIF6END imprime_media
- 29. ResoluciónV(G) = 2+1 = 3. Por lo tanto, hay quedeterminartrescaminosindependientes. Porejemplo: Camino 1: 1-2-3-5-6 Camino 2: 1-2-4-6 Camino 3: 1-2-3-4-6Casos de pruebaparacadacamino:Camino 1: Escoger algún x e y tales que se cumpla x >= 0 AND y >= 0Camino 2: Escoger algún x tal que se cumpla x < 0Camino 3: Escoger algún x e y tales que se cumpla x >= 0 AND y < 01x < 02TrueFalsey < 043TrueFalse456
- 30. Ejercicio 2
- 31. ResoluciónV(MCD) = 7 – 6 + 2 = 3
- 32. NotasLos 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 regularLos errores tipográficos son aleatorios“Los errores se esconden en los rincones y se aglomeran en los límites” (Beizer)