Pruebas del software

1. Laura Patricia Pinto Prieto Pruebas del software

2. 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,laspruebas 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!

3. ¿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.

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

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

6. Relación entre error, defecto y fallo

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

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

9. 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”.

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

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

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

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

14. Facilidad de Prueba James 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.

15. Operatividad. «Cuanto mejor funcione, más eficientemente se 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 pruebas El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).

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

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

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

19. 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).

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

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

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

23. El proceso de Prueba • La depuración (localización y corrección de defectos). • El análisis de la estadística de errores.

24. Ciclo completo de las Pruebas

25. Diseño de casos de prueba • 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; • 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.

26. Diseño de casos de prueba.Enfoques principales (Piattini et al. 96) Pruebas de Software

27. 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 prueba • la prueba exhaustiva consistiría en probar todos los posibles caminos de ejecución • nº 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

28. 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) Pruebas de Software

29. Prueba del camino básico(Mc Cabe 76) Objetivos: • 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.

30. X X X 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 Mientras x Hacer … (While x Do … ) Si x Entonces… (If x Then … Else…) Hacer … hasta x (Do … Until x) Repetir Secuencia

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

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

33. ¿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 de tres formas: 1. El número de regiones del grafo de flujo coincide. 2. La complejidad ciclomática, V(G), de un grafo de con 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 de flujo 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.

34. Formas de Calcular la Complejidad Ciclomática V(G) • V (G) = a – n + 2 • V (G) = r • V (G) = c + 1 Donde • a : # de arcos o aristas del grafo. • n : # de nodos. • r : # de regiones cerradas del grafo. • c : # de nodos de condición.

35. ¿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.

36. 1 a1 a2 a3 2 a4 3 Región 1 a5 a6 a7 4 Región 2 a8 5 Región 3 a9 a10 6 a11 a12 7 Región 4 8 a14 a13 9 10 Región 5 11 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.

37. Trabajo para entregar la próxima clase (nota 40% segundo corte en grupo de a 3 personas máximo) • Ejercicio: • 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. • Desarrolle el programa y haga el grafo de flujo ,calcule V(G) y obtenga los casos de prueba. (ver ejemplo del libro de pressman). • Investigar sobre Matriz de grafos. • Pruebas de estructuras de control

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

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