Introducción de pruebas de software

1. Introducción a las Pruebas de Software - Fundamentos de las Pruebas de Software - Metodologías de desarrollo y las Pruebas - Tipos de Pruebas de Software Material académico preparado por: Ph.D Marta Silvia Tabares B. Fecha última actualización 26-Sep-2011

2. Bibliografía Los conceptos utilizados en esta presentación fueron estudiados y tomados en su mayoría de las siguientes referencias bibliográficas. 1. Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004). 2. Glenford J. Myers.; Corey Sandler; Tom Badgett. The Art of Software Testing. Third Edition. Jonh Wiley & Sons. 2012. 3. Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005. 4. OMG-UML. Unified Modeling Language: Superstructure. Version 2.0, formal/05-07-04. 2005. 5. Jacobson, I., Booch, G., Rumbaugh, J. El Proceso Unificado de Desarrollo de Software. Addison Wesley. 2000. 6. Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John Wiley & Sons © 2005. 7. Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del Sistema, Usando UML. McGraw-Hill, 2006. 8. Bass, L., Clements, P., Kazman, R. Software Architecture in Practice Second Edition. 9. Pressman, R. Ingeniería del Software un Enfoque Práctico. 10. www.sei.cmu.edu.co 11. http://www.iso.org/iso/home.html 12. http://iso25000.com/index.php/iso-iec-9126.html 13. http://softwaretestingstandard.org/ 2 Material académico preparado por Marta Silvia Tabares B. UdeM

3. Fundamentos de las Pruebas de Software El software como producto puede tener defectos o fallos, desde el momento de concebirlo y modelarlo, durante su desarrollo y después de la puesta en producción de la aplicación software Las pruebas del software corresponde a la necesidad de garantizar un producto de calidad 3 Material académico preparado por Marta Silvia Tabares B. UdeM

4. Fundamentos de las Pruebas de Software • Glosario – Prueba: proceso de evaluar un producto particular para determinar si un producto tiene defectos. – Pruebas de Software: es un proceso de evaluar un sistema ya sea manual o automático y verificar que este satisface los requisitos o identifica diferencias entre lo esperados y los resultados actuales. 4 Material académico preparado por Marta Silvia Tabares B. UdeM

5. Fundamentos de las Pruebas de Software • Por qué es importante hacer pruebas de software: – Sistema libre de errores – Eficiencia de la aplicación – Aseguramiento de la calidad del software (p.ej.: la norma 9126) – Evaluación de la flexibilidad del software construido 5 Material académico preparado por Marta Silvia Tabares B. UdeM

6. Fundamentos de las Pruebas de Software • Por qué es importante hacer pruebas de software: • Misiones fallidas • Impacto inesperado en la ejecución operacional • Falta de confiabilidad en casos de que no se ejecute acertadamente 6 Material académico preparado por Marta Silvia Tabares B. UdeM

7. Fundamentos de las Pruebas de Software Objetivos de las pruebas: 1. La prueba es el proceso de ejecución de un programa con la intención de descubrir un error. 2. Un buen caso de prueba es aquel que tiene una alta probabilidad de descubrir un error no encontrado hasta entonces. 3. Una prueba tiene éxito si descubre un error no detectado hasta entonces. • No sólo se prueba el código, también la documentación , los manuales, las ayudas, las interfaces de todo tipo 7 Material académico preparado por Marta Silvia Tabares B. UdeM

8. Fundamentos de las Pruebas de Software • Índice de la fiabilidad del software: se comporta de acuerdo a las especificaciones y requisitos de rendimiento. “La prueba no puede asegurar la ausencia de defectos: sólo puede demostrar que existen defectos en el software”. • No es una actividad secundaria: – 30-40% del esfuerzo de desarrollo – En aplicaciones críticas (p.ej. control de vuelo, reactores nucleares), ¡de 3 a 5 veces más que el resto de pasos juntos de la ingeniería del software! – El costo aproximado de los errores del software (bugs) para la economía americana es el equivalente al 0,6% de su PIB, unos 60.000 millones de dólares ⇒ ¡Evitar bugs puede ser un gran negocio! 8 Material académico preparado por Marta Silvia Tabares B. UdeM

9. Fundamentos de las Pruebas de Software Un software fácil de probar tiene las siguientes características: Operatividad Observatividad Controlabilidad Capacidad de descomposición Simplicidad Estabilidad Facilidad de comprensión. 9 Material académico preparado por Marta Silvia Tabares B. UdeM

10. Fundamentos de las Pruebas de Software • A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos de los clientes (trazabilidad). • Las pruebas deberían planificarse antes de que empiecen. • El principio de Pareto es aplicable a la prueba del software (“donde hay un defecto, hay otros”). • Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo grande”. • No son posibles las pruebas exhaustivas. • Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente. • Se deben evitar los casos de prueba no documentados ni diseñados con cuidado. • No deben realizarse planes de prueba suponiendo que prácticamente no hay defectos en los programas y, por tanto, dedicando pocos recursos a las pruebas. 10 Material académico preparado por Marta Silvia Tabares B. UdeM

11. Fundamentos de las Pruebas de Software Verificación y validación • Verificación “¿Estamos construyendo el producto corréctamente?”. • El software debería ajustarse a su especificación • Validación “¿estamos construyendo el producto correcto?”. • El software debería hacer lo que el cliente realmente reclama. 11 Material académico preparado por Marta Silvia Tabares B. UdeM

12. Fundamentos de las Pruebas de Software Verificación y validación • La V & V debe aplicarse en cada etapa del software. • Tiene dos objetivos principales – El descubrimiento de defectos en el sistema; – La evaluacíón de si el sistema es útil y utilizable en una situación operacional o no. 12 Material académico preparado por Marta Silvia Tabares B. UdeM

13. Fundamentos de las Pruebas de Software Normas de Calidad asociadas a las pruebas de software • Desarrollo del software - Validación y Verificación del software – Norma ISO/IEC 12207 – Norma ISO/IEC 17025 (http://www.lysconsultores.com/Descargar/NT006.pdf) • Mantenimiento del software – Norma ISO 14764 • Software Testing – Norma ISO/IEC 29119 (http://softwaretestingstandard.org/) 13 Material académico preparado por Marta Silvia Tabares B. UdeM

14. Fundamentos de las Pruebas de Software Norma estándar para las pruebas de software 29119 – Proceso de Pruebas Fuente: http://softwaretestingstandard.org/ 14 Material académico preparado por Marta Silvia Tabares B. UdeM

19. LA TRAZABILIDAD DE REQUISITOS – PRÁCTICA VITAL PARA LAS PRUEBAS DE SOFTWARE Material académico preparado por Marta Silvia Tabares B. UdeM

20. La Trazabilidad del Software • Es la habilidad de dejar huella de los movimientos y procesos por los que pasa un determinado pr oducto principalmente destinado al consumo humano. • Procedimientos preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y la trayectoria de un producto o lote de productos a lo largo de la cadena de suministros en un momento dado, a través de unas herramientas determinadas 20 Material académico preparado por Marta Silvia Tabares B. UdeM

21. Naturaleza de la Trazabilidad del Software El producto esta siendo caracterizado de manera iterativa e incremental lo cual hace más complejo seguir su traza 21 Material académico preparado por Marta Silvia Tabares B. UdeM

22. Naturaleza de la Trazabilidad del Software Trazabilidad (Rastreabilidad) Es el grado en el cual una relación puede ser establecida entre dos o más productos del proceso de desarrollo, especialmente productos que tienen relaciones de predecesor-sucesor o maestro-subordinado entre uno y otro” [IEEE-STD-610] 22 Material académico preparado por Marta Silvia Tabares B. UdeM

23. Naturaleza de la Trazabilidad del Software El esfuerzo invertido en mantener las relaciones de traza, obtiene su retorno cuando se van a realizar modificaciones en el software Modelos de Trazabilidad Alteración del software y pruebas sobre todos los elementos impactados 23 Material académico preparado por Marta Silvia Tabares B. UdeM

24. Naturaleza de la Trazabilidad del Software Contexto del negocio Modelos del Product producto V1 o Instalad Todo es o Producto en Operación consistente y Artefactos ejecutables trazado Escenario del producto V1 1 Cambios en Solicitud Ingeniero de Desarrollo Contexto del negocio de del Software condiciones Solicitud cambio de negocio de Solicitud cambio de Intervención en Producto en Operación cambio ambiente de Escenario 2 desarrollo Artefactos Artefactos ejecutables ejecutables Artefactos del producto V4 Modelos del del producto V3 ejecutables producto V1 del producto V2 Posible pérdida de consistencia de los modelos y productos 24 Material académico preparado por Marta Silvia Tabares B. UdeM

25. Naturaleza de la Trazabilidad del Software 2, 9 Definir / Modificar Repositorio de Modelos y Modelos 1. Definir Traza Y Matriz de Requisitos Chec trazabilidad 7. k-out (Ej: Enterprise 4, Analiz Architect) Ingenier ar 11Chec o k-in Desarro Impac Check- Cliente del Report llador 3, 10 to in++ producto ar Construir/ 6. Colocar seguim Modificar 5, solicitud iento Servidor de 12Chec Configuracio de cambio Entorno de k-in nes Desarrollo Check- (Ej: CVS, 6. (Ej: Eclipse, Subversión) Reportar in++ 8. Establecer NetBeans) No Acuerdo Conformi dades Manejador Área Comercial / Área de tickets Gerente SQA (Ej: Mantis) Proyecto 25 Material académico preparado por Marta Silvia Tabares B. UdeM

26. METODOLOGÍAS DE DESARROLLO Y LAS PRUEBAS Material académico preparado por Marta Silvia Tabares B. UdeM

27. Metodologías de desarrollo y las Pruebas • Prueba para modelos en espiral 27 Material académico preparado por Marta Silvia Tabares B. UdeM

28. Metodologías de desarrollo y las Pruebas 28 Material académico preparado por Marta Silvia Tabares B. UdeM

29. Metodologías de desarrollo y las Pruebas • Pruebas para modelos procedimentales Requisitos Pruebas de alto nivel Diseño Prueba de Integración Codificación Prueba de unidad Dirección del la prueba Etapas de prueba del SW 29 Material académico preparado por Marta Silvia Tabares B. UdeM

30. Metodologías de desarrollo y las Pruebas • Pruebas desde el Modelo V Especificación Especificación Diseño Diseño del sistema De requisitos Del sistema detallado Plan de pruebas Plan de pruebas de Código y Plan de pruebas de integración del integración prueba de los De aceptación sistema De los subsistemas módulos y unidades Prueba de Prueba de integración Prueba de Servicio integración del De los subsistemas aceptación sistema 30 Material académico preparado por Marta Silvia Tabares B. UdeM

31. TIPOS DE PRUEBAS DEL SOFTWARE Material académico preparado por Marta Silvia Tabares B. UdeM

32. Tipos de Pruebas Pruebas de Software Estáticas Dinámicas Pruebas Caja Blanca Pruebas Caja Negra Pruebas en etapas tempranas del (pruebas estructurales) (pruebas funcionales) desarrollo del Software. Pruebas en tiempo de Pruebas en tiempo de ejecución. Se hacen Buscan defectos sin ejecutar código, ejecución. Estas pruebas pruebas que demuestren es decir se pueden hacer desde los aseguran que todas las que cada función requisitos y sobre los modelos de piezas encajan y que el la identificada es operativa análisis y diseño estructuración del código que de acuerdo a los ejecuta una función interno resultados esperados. También se pueden hacer una vez corresponde a la operación se escriba el código, pero se hacen interna especificada. P. ej.: Pruebas sobre la fuera de ejecución interfaz del software 32 Material académico preparado por Marta Silvia Tabares B. UdeM

33. Tipos de Pruebas 33 Material académico preparado por Marta Silvia Tabares B. UdeM

34. Tipos de Pruebas PRUEBA DEL SISTEMA Cuando se hacen pruebas en grupo o un grupo de analistas entrega un conjunto de artefactos de software a los testers, un problema típico es la «delegación de culpabilidad»,. Esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros. Se debe anticipar a los posibles problemas y: 1. diseñar caminos de manejo de errores que prueben toda la información procedente de los elementos del sistema; 2. llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de otros posibles errores en la interfaz del software; 3. registrar los resultados de las pruebas como «evidencia» en el caso de que se le señale con el dedo; 4. participar en la planificación y el diseño de pruebas del sistema para asegurarse de que el software se prueba de forma adecuada. 34 Material académico preparado por Marta Silvia Tabares B. UdeM

35. Tipos de Pruebas • Pruebas de defectos – Pruebas diseñadas para descubrir defectos en el sistema. – Una prueba de defectos exitosa es aquella que revela la presencia de defectos en un sistema. • Pruebas de validación – Previsto para mostrar que el software cumple sus requerimientos. – Una prueba con éxito es aquella que muestra que un requerimiento se ha implementado correctamente. Vínculos sugeridos para estudio complementario a este capítulo: - http://www.sistedes.es/TJISBD/Vol-1/No-4/articles/pris-07-raja-ctps.pdf 35 Material académico preparado por Marta Silvia Tabares B. UdeM

36. Tipos de Pruebas CRITERIOS DE LA PRUEBA DE VALIDACIÓN PRUEBA DE VALIDACIÓN La prueba alfa se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del Un software está validado usuario y registrando los errores y los problemas de cuando se consigue que uso. Las pruebas alfa se llevan a cabo en un entorno controlado. este funcione de acuerdo con las expectativas La prueba beta se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A razonables del cliente. diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una aplicación «en vivo» del software en un entorno que no puede ser controlado por el desarrollador. 36 Material académico preparado por Marta Silvia Tabares B. UdeM

37. Tipos de Pruebas PRUEBA DE ACEPTACIÓN El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario. La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las verificaciones a realizar y los casos de prueba asociados. 37 Material académico preparado por Marta Silvia Tabares B. UdeM

38. Tipos de Pruebas PRUEBA DE UNIDAD La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software(Módulo). Aquí se prueban los caminos de control importantes, con el fin de descubrir errores dentro del ámbito de un módulo. Estas pruebas se pueden hacer desde etapas tempranas de desarrollo como pruebas estáticas. 38 Material académico preparado por Marta Silvia Tabares B. UdeM

39. Tipos de Pruebas ERRORES SON LOS MÁS COMUNES DURANTE LA PRUEBA DE UNIDAD 1. Procedencia aritmética incorrecta mal aplicada 2. Operaciones de modo mezcladas. 3. Inicializaciones incorrectas. 4. Falta de precisión. 5. Representación incorrecta de una expresión. 39 Material académico preparado por Marta Silvia Tabares B. UdeM

40. Tipos de Pruebas • Pruebas de Unidad • Ver video en: http://channel9.msdn.com/blogs/channel9spain /pruebas-unitarias-unit-testing-con-visual-studio 40 Material académico preparado por Marta Silvia Tabares B. UdeM

41. Tipos de Pruebas PRUEBA DE INTEGRACIÓN “Si todos funcionan bien ¿Por qué dudar de que no funcionen todos juntos?” «Es una técnica sistemática para construir la estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción». Un poco de métodos ágiles con integración: http://www.youtube.com/watch?v=UT_s1aZCfAw 41 Material académico preparado por Marta Silvia Tabares B. UdeM

42. Tipos de Pruebas TIPOS DE PRUEBAS INTEGRACIÓN No incremental: Al inicio se combinan todos los módulos por anticipado, se prueba todo el producto. Incremental: En la segunda prueba se hace de forma incremental, es decirse desarrollan módulos pequeños y funcionales que hacen que los errores sean más fácil de aislar y corregir. 42 Material académico preparado por Marta Silvia Tabares B. UdeM

43. Tipos de Pruebas Formas de hacer la Integración 1. Descendente «Es una estrategia de integración incremental a la construcción de la estructura de programas, en cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía de control comenzando con el módulo principal». «Los módulos subordinados al módulo de control principal se incorpora en la estructura, de forma primero-en-profundidad, ó primero-en-anchura». 43 Material académico preparado por Marta Silvia Tabares B. UdeM

44. Tipos de Pruebas Ilustración: Integración descendente M1 M2 M3 M4 M5 M6 M7 M8 44 Material académico preparado por Marta Silvia Tabares B. UdeM

45. Tipos de Pruebas La desventaja de la integración descendente es la necesidad de resguardos. La principal desventaja de la integración ascendente es que el “el programa como entidad no existe hasta que se haya añadido el ultimo módulo”. La selección de una estrategia de integración depende de las características del software y, a veces de la planificación del proyecto, en algunos de los casos se puede usar un enfoque combinado(denominado pruebas Sándwich). 45 Material académico preparado por Marta Silvia Tabares B. UdeM

46. Tipos de Pruebas Formas de hacer la Integración 2. Ascendente «Es un modelo de integración no incremental, en donde la construcción del diseño empieza de los módulos atómicos (es decir, módulos de los niveles mas bajos de la estructura del programa). Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponible y elimina la necesidad de resguardos». 46 Material académico preparado por Marta Silvia Tabares B. UdeM

47. Tipos de Pruebas PRUEBA DE REGRESIÓN Cada vez que se añade un nuevo modulo como parte de una prueba de integración el software cambia. La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados. 47 Material académico preparado por Marta Silvia Tabares B. UdeM

48. Tipos de Pruebas PRUEBA DE HUMO La prueba de humo es un método de prueba de integración que es comúnmente utilizada cuando se ha desarrollado un software “empaquetado”. Es diseñado como una mecanismo para proyectos críticos por tiempos, permitiendo que el equipo de software valore su proyecto sobre una base sólida. 48 Material académico preparado por Marta Silvia Tabares B. UdeM

49. Tipos de Pruebas PRUEBA DE RECUPERACIÓN La prueba de recuperación es una prueba del sistema que la hacen expertos en infraestructura. Esta fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Cuando la recuperación es automática hay que evaluar la corrección de la inicialización, de los mecanismos de recuperación del estado del sistema, de la recuperación de datos y del proceso de re-arranque. Cuando la recuperación es manual hay que evaluar los tiempos medios de reparación (TMR) para determinar si están dentro de unos límites aceptables. 49 Material académico preparado por Marta Silvia Tabares B. UdeM

50. Casos de Prueba • Qué es un CASO DE PRUEBA DE SOFTWARE? – Conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio (wikipedia). – Plantilla Recomendada: http://readyset.tigris.org/nonav/es/templates/test- case-format.html 50 Material académico preparado por Marta Silvia Tabares B. UdeM

51. http://msdn.microsoft.com/es-es/library/dd286594.aspx ESTRATEGIAS DE PRUEBAS Material académico preparado por Marta Silvia Tabares B. UdeM

52. Estrategias de Pruebas • Ton Gilb, plantea que se deban abordar los siguientes puntos si se desea implementar con éxito una estrategia de prueba del SW: – Especificar los requisitos del producto de manera cuantificable mucho antes que comiencen las pruebas. – Establecer los objetivos de la prueba de manera explicita. – Comprender que usuarios van a manejar el SW y desarrollar un perfil para cada categoría de usuario. Vínculos complementario para el estudio de este tema: - http://www.willydev.net/descargas/oguzman-diseno_pruebas.pdf 52 Material académico preparado por Marta Silvia Tabares B. UdeM

53. Estrategias de Pruebas – Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido. – Construir un SW robusto diseñado para probarse así mismo. – Usar revisiones técnicas formales y efectivas como filtro antes de la prueba. – Llevar acabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. – Desarrollar un enfoque de manera continua al proceso de prueba. Debería medirse la estrategia de prueba. Vínculo complementarios para estudio de este tema: - http://msdn.microsoft.com/es-es/library/dd286594.aspx 53 Material académico preparado por Marta Silvia Tabares B. UdeM

54. Estructura de un Plan de Pruebas • Proceso de pruebas • Trazabilidad de requerimientos. • Elementos probados. • Calendario de pruebas. • Procedimientos de registro de las pruebas. • Requerimientos hardware y software. • Restricciones. Vínculo complementarios para estudio de este tema: - http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/urcid_p_p/capitulo5.pdf 54 Material académico preparado por Marta Silvia Tabares B. UdeM

55. Estructura de un Plan de Pruebas Un plan de pruebas debe estar diseñado para asegurar que se satisfacen todos los requisitos funcionales especificados por el usuario teniendo en cuenta también los requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos y procesos, así como a los distintos recursos del sistema. 55 Material académico preparado por Marta Silvia Tabares B. UdeM

56. Algunas Herramientas Open Source para Pruebas del Software • JCRAWLER: http://www.youtube.com/watch?v=W-NkHNOxPRM • WebInject: www.goldb.org • LoadUI: http://www.loadui.org/About-loadUI/what-is-loadui.html • http://www.opensourcetesting.org/

57. Sitios de consulta recomendados • Además de los definidos en la bibliografía y en el transcurso de la presentación, sugiero: – http://www.softwareqatest.com/ – http://www.nickjenkins.net/prose/testingPrimer.pdf – http://www.sparxsystems.com.ar/resources/testing.html – http://sunnyday.mit.edu/16.355/oct20.pdf – http://www.cs.helsinki.fi/u/paakki/software-testing-s05.html – Pruebas de usabilidad: http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/com _h_m/EvaluacionInterfacesUsuario.pdf – Listas de chequeo: • http://www.usereffect.com/topic/25-point-website-usability-checklist • http://www.testinggeek.com/performance-security-testing-checklist

Introducción de pruebas de software

You are reading a preview.

Check these out next

Introducción de pruebas de software

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to Introducción de pruebas de software (20)

More from Marta Silvia Tabares (20)

Introducción de pruebas de software