1. Borre el titulo con el cuadrado y cuando salga “Haga click para agregar el titulo”

1. BORRAR 1. Borre el titulo con el cuadrado y cuando salga “Haga click para agregar el titulo” Escribe el que estaba y ya 2. Cambie los verdes porfavor q se ve re feo JAJAJAJA 3. Y Borre de su parte lo q no crea q sea necesario, igual ya borre algunas

2. El hombre que ha cometido un error y no lo corrige comete otro error mayor. Confucio (551 AC-478 AC) Filósofo chino. Pruebas de Software The Big Five- Henry Cafiero, Guillermo Malagón

3. AGENDA • Introducción. • Objetivo. • Características. • Ejemplos Defecto, Falla Error • Tipos de defecto • Tipos de prueba • Casos de prueba • Tipos de casos de prueba • Stub y manejadores de prueba • Correcciones. • Técnicas de control de calidad • Técnicas para evitar defectos • Técnicas para detectar defectos • prueba unitaria • pruebas de integración • pruebas del sistema. • Técnicas de tolerancia de defectos. • Actividades de Prueba. • Conclusiones • Bibliografía

4. INTRODUCCION IEEE Standard 1999 • Proceso de analizar un producto de software para: • Detectar diferencias entre el comportamiento real con el pedido. • Para evaluar las funcionalidades y características no funcionales del software. • Las pruebas en la Ingeniería de Software son muy importantes y deben realizarse en cada una de las fases de la construcción del producto, las cuales incluyen especificaciones en: • Requisitos. • Casos de Uso. • Diagramas. • Código Fuente

5. Pruebas en la planeación

6. Objetivo Principal Diseñar pruebas sistematicamente

7. Objetivo ¿Estamos construyendo correctamente el producto? Objetivos • Detectar un error. • Lograr confianza acerca del nivel de calidad. • Tener un buen caso de prueba: que tenga más probabilidad de mostrar un error no descubierto antes. • Descubrir un error no descubierto antes (éxito de la prueba). ¿Estamos construyendo el Producto correcto?

8. ¿POR QUÉ ES IMPOSIBLE PROBAR POR COMPLETO UN SISTEMA? Porque es imposible probar por completo un sistema • Las pruebas no son determinantes. • Es necesario realizar las pruebas bajo restricciones de tiempo y presupuesto. Los sistemas se entregan sin estar probados por completo, esto conduce a defectos que son descubiertos por los usuarios finales.

9. Características de una buena prueba • Alta probabilidad de encontrar un error. • No ser redundante. • Ser la mejor de su clase. • No muy simple, no muy compleja. • Trazable. • Planeada. • Ir de lo pequeño a lo grande. • Diseñar y documentar es muy importante.

10. Ejemplos I Error Defecto Shega-Cindy Sánchez, Guillermo Malagon

11. Ejemplos II Mecánico Algorítmico

12. Tipos de Defectos (1/3) Tipos de defectos (1/3)

13. Tipos de Defectos (2/3) Tipos de defectos (2/3)

14. Tipos de Defectos (3/3) Tipos de defectos (3/3)

15. Tipos de Pruebas Basadosen Ejecución:Se creanlos casos de prueba teniendo en cuenta el códigoejecutable. Basados en la No Ejecución : Se revisametodicamente el código paraencontrarfallas, no se usan los casos de prueba

16. Casos de prueba Casos de Prueba

17. Casos de Prueba (2)

18. Casos de prueba (3) Casos de Prueba (3)

19. Tipos de Casos de Prueba (Enfoques Principales) Enfoque Aleatorio: consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba creando datos de entrada en la secuencia y con la frecuencia con las que podrían aparecer en la Práctica (de manera repetitiva) Para ello habitualmente se utilizan generadores automáticos de casos de prueba

20. Enfoque estructural o de caja blanca (transparente): • Estructura interna del programa • La prueba exhaustiva: probar todos los posibles caminos de ejecución • nº caminos lógicos  • ( buscar los más importantes) Enfoque funcional o de caja negra: • Para derivar los casos: se estudia la especificación de las funciones, la entrada y la salida.

21. STUBS Y MANEJADORES DE PRUEBAS Stubs y manejadores de Pruebas • Se usan para sustituir las partes faltantes de un sistema mientras estas se encuentran aisladas en una ejecución de casos de pruebas. Simula a los componentesque son llamadospor el componente a probar Simula la parte del sistemaque llama al componente a probar

22. CORRECCIONES Correcciones • Es un cambio a un componente con el propósito de reparar un defecto. • Las correcciones pueden ir desde una simple modificación de un solo componente, hasta el rediseño completo de una estructura de datos o un subsistema. • Existe una probabilidad alta de que el desarrollador introduzca nuevos defectos en el componente revisado.

23. Tecnicas de Control de Calidad

24. Técnicas de control de calidad Tecnicas de Control de Calidad Trata de impedir la ocurrencia de errores y fallos encontrando defectos en el sistema antes de lanzarlo Ayuda a encontrar defectos en los sistemas pero no tratan de recuperar las fallas que causa Recuperación de una falla mientras el sistema se encuentra en ejecución

25. Técnicas para evitar defectos Tecnicas para evitar defectos Técnicas que minimizan la introducción de defectos en los modelos del sistema y el código. Evita cambios causados por cambios no controlados en los modelos del sistema Encontrar defectos antes de la ejecución del programa Inspección manual de algunos o todos los aspectos del sistema sin ejecutar.

26. Técnicas para detectar defectos Tecnicas para detectar defectos Encontrar cualquier desviación entre los requerimientos funcionales observados y los especificados. Desviación entre los requerimientos no funcionales observados y los especificados. Trata de encontrar defectos en los subsistemas, con respecto a los casos de uso Probar los componentes cuando están en conjunto en un sistema activo. Prueba los componentes juntos vistos como el sistema final, para identificar errores Asume que los defectos pueden encontrarse a partir de una falla no planeada Técnica de detección de defectos que trata de crear fallas o errores en forma planeada

27. Prueba Unitaria

28. Tecnicas para pruebas unitarias

29. Prueba de Equivalencia

30. Ejemplo • Método que retorna la cantidad de días de un mes recibiendo el mes y el día como parámetro.

31. Ejemplo

32. Tecnicas para pruebas unitarias

33. Prueba de Frontera • Se deben seleccionar los casos de los extremos de las clases de equivalencia. • desventaja: no exploran combinaciones de datos de entrada de prueba • EJ:

34. Tecnicas para pruebas unitarias

35. Prueba de ruta • Se deben recorrer todas las rutas posibles del código para encontrar las fallas producidas por los defectos. • El punto inicial son los diagramas de flujo.

36. Este método permite obtener una medida de la complejidad lógica de un diseño procedimental. • •Esta medida puede ser usada como guía a la hora de definir un conjunto básico de caminos de ejecución (diseño de casos de prueba). DIAGRAMA DE FLUJO GRAFO DE FLUJO

37. Ejemplo prueba de ruta

38. Ejemplo prueba de ruta (2/2) Complejidad ciclomática CC = #aristas – #nodos +2

39. Complejidad Ciclomatica • V (G) = a - n + 2 • siendo a el número de arcos o aristas del grafo y n el número de nodos. • 2. V (G) = r • siendo r el número de regiones cerradas del • grafo. • 3. V(G) = c + 1 • siendo c el número de nodos de condición.

40. Tecnicas para pruebas unitarias

41. Pruebas basadas en estado

42. Ejemplo de pruebas basadas en estado

43. Pruebas resultantes para ajustar la hora • (los 8 primeros estimulos)

44. Pruebas de la estructura de control • Prueba de condición: Encontrar errores en condiciones lógicas en un módulo • Prueba de flujo de datos: De acuerdo con la ubicación de las definiciones y los usos de las variables del programa. • Prueba de bucles: exclusivamente en la validez de las construcciones de Bucles • Tipos de bucles: • Simples • Anidados • Concatenados • No estructurados

45. Estrategia para pruebas de integracion

46. Prueba de gran explosion • Cuando todos los componentes se prueban por separado existe la tentación de mezclarlos juntos desde la primera vez. • Utilizado para sistemas pequeños.

47. Desventaja

48. Ejemplo gran explosion

49. Ejemplo gran explosion

50. Estrategias para prueba de integracion