Your SlideShare is downloading. ×
Introducción de pruebas de software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Introducción de pruebas de software

24,738
views

Published on


4 Comments
33 Likes
Statistics
Notes
No Downloads
Views
Total Views
24,738
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
4
Likes
33
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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.co11. http://www.iso.org/iso/home.html12. http://iso25000.com/index.php/iso-iec-9126.html13. http://softwaretestingstandard.org/ 2 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 3. Fundamentos de las Pruebas de SoftwareEl software como producto puede tenerdefectos 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 softwareLas 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 SoftwareObjetivos 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 SoftwareUn 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 SoftwareNorma 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
  • 15. Fundamentos de las Pruebas de SoftwareNorma estándar para las pruebas de software 29119 – Proceso de Pruebas Fuente: http://softwaretestingstandard.org/ 15 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 16. Fundamentos de las Pruebas de SoftwareNorma estándar para las pruebas de software 29119 – Proceso de Pruebas Fuente: http://softwaretestingstandard.org/ 16 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 17. Fundamentos de las Pruebas de SoftwareNorma estándar para las pruebas de software 29119 – Proceso de Pruebas Fuente: http://softwaretestingstandard.org/ 17 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 18. Fundamentos de las Pruebas de SoftwareNorma estándar para las pruebas de software 29119 – Proceso de Pruebas Fuente: http://softwaretestingstandard.org/ 18 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 19. LA TRAZABILIDAD DE REQUISITOS –PRÁCTICA VITAL PARA LAS PRUEBAS DESOFTWARE 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 SoftwareEl 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 SoftwareEl 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 1Cambios en Solicitud Ingeniero de Desarrollo Contexto del negocio de del Softwarecondiciones Solicitud cambiode negocio de Solicitud cambio de Intervención en Producto en Operación cambio ambiente deEscenario 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 unidadDirección del laprueba 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 NegraPruebas en etapas tempranas del (pruebas estructurales) (pruebas funcionales)desarrollo del Software. Pruebas en tiempo de Pruebas en tiempo de ejecución. Se hacenBuscan defectos sin ejecutar código, ejecución. Estas pruebas pruebas que demuestrenes decir se pueden hacer desde los aseguran que todas las que cada funciónrequisitos y sobre los modelos de piezas encajan y que el la identificada es operativaaná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ónse escriba el código, pero se hacen interna especificada. P. ej.: Pruebas sobre lafuera de ejecución interfaz del software 32 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 33. Tipos de Pruebas 33Material académico preparado por Marta Silvia Tabares B. UdeM
  • 34. Tipos de Pruebas PRUEBA DEL SISTEMACuando se hacen pruebas en grupo o un grupo de analistas entrega un conjunto deartefactos de software a los testers, un problema típico es la «delegación deculpabilidad»,.Esto ocurre cuando se descubre un error y cada uno de los creadores de cadaelemento del sistema echa la culpa del problema a los otros. Se debe anticipar a losposibles 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 delUn 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ÓNEl objetivo de las pruebas de aceptación es validar que un sistema cumplecon el funcionamiento esperado y permitir al usuario de dicho sistema quedetermine su aceptación, desde el punto de vista de su funcionalidad yrendimiento.Las pruebas de aceptación son definidas por el usuario del sistema ypreparadas por el equipo de desarrollo, aunque la ejecución y aprobaciónfinal corresponden al usuario.La validación del sistema se consigue mediante la realización de pruebas decaja negra que demuestran la conformidad con los requisitos y que serecogen en el plan de pruebas, el cual define las verificaciones a realizar ylos casos de prueba asociados. 37 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 38. Tipos de Pruebas PRUEBA DE UNIDADLa prueba de unidad centra el proceso de verificación en lamenor unidad del diseño del software(Módulo). Aquí seprueban los caminos de control importantes, con el fin dedescubrir errores dentro del ámbito de un módulo.Estas pruebas se pueden hacer desde etapas tempranas dedesarrollo 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 UNIDAD1. Procedencia aritmética incorrecta mal aplicada2. 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 delprograma mientras que al mismo tiempo, se llevan a cabopruebas 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ÓNNo incremental: Al inicio se combinan todos los módulospor anticipado, se prueba todo el producto.Incremental: En la segunda prueba se hace de formaincremental, es decirse desarrollan módulos pequeños yfuncionales que hacen que los errores sean más fácil de aislary corregir. 42 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 43. Tipos de Pruebas Formas de hacer la Integración1. 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 PruebasIlustración: Integración descendente M1 M2 M3 M4M5 M6 M7M8 44 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 45. Tipos de PruebasLa desventaja de la integración descendente es lanecesidad de resguardos. La principal desventaja de laintegración ascendente es que el “el programacomo entidad no existe hasta que se haya añadido elultimo módulo”.La selección de una estrategia de integracióndepende de las características del software y, a vecesde la planificación del proyecto, en algunos de loscasos se puede usar un enfoquecombinado(denominado pruebas Sándwich). 45 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 46. Tipos de Pruebas Formas de hacer la Integración2. 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ÓNCada vez que se añade un nuevo modulo como parte de unaprueba de integración el software cambia.La prueba de regresión es volver a ejecutar unsubconjunto de pruebas que se han llevado a caboanteriormente para asegurarse de que los cambios no hanpropagado efectos colaterales no deseados. 47 Material académico preparado por Marta Silvia Tabares B. UdeM
  • 48. Tipos de Pruebas PRUEBA DE HUMOLa prueba de humo es un método de prueba de integración quees comúnmente utilizada cuando se ha desarrollado unsoftware “empaquetado”. Es diseñado como una mecanismopara proyectos críticos por tiempos, permitiendo que elequipo 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ÓNLa prueba de recuperación es una prueba del sistema que la hacen expertosen infraestructura. Esta fuerza el fallo del software de muchas formas yverifica que la recuperación se lleva a cabo apropiadamente.Cuando la recuperación es automática hay que evaluar la corrección de lainicialización, de los mecanismos de recuperación del estado del sistema, dela recuperación de datos y del proceso de re-arranque.Cuando la recuperación es manual hay que evaluar los tiempos medios dereparación (TMR) para determinar si están dentro de unos límitesaceptables. 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.aspxESTRATEGIAS 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 PruebasUn plan de pruebas debe estar diseñado paraasegurar que se satisfacen todos los requisitos funcionales especificados por el usuarioteniendo en cuenta también los requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos yprocesos, 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