Your SlideShare is downloading. ×
0
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Doo 13-testing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Doo 13-testing

176

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
176
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
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
  • CMU/SEI-95-TR-003 May 1995 The Subject Matter of Process Improvement: A Topic and Reference Source for Software Engineering Educators and Trainers pg. 15-16
  • CMU/SEI-95-TR-003 May 1995 The Subject Matter of Process Improvement: A Topic and Reference Source for Software Engineering Educators and Trainers pg. 15-16
  • CMU/SEI-95-TR-003 May 1995 The Subject Matter of Process Improvement: A Topic and Reference Source for Software Engineering Educators and Trainers pg. 15-16
  • CMU/SEI-95-TR-003 May 1995 The Subject Matter of Process Improvement: A Topic and Reference Source for Software Engineering Educators and Trainers pg. 15-16
  • CMU/SEI-95-TR-003 May 1995 The Subject Matter of Process Improvement: A Topic and Reference Source for Software Engineering Educators and Trainers pg. 15-16
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • The Capability Maturity Model Guidelines for Improving the Software Process pg. 7-8
  • Transcript

    • 1. El Testing
    • 2. Contexto
    • 3. Agenda Objetivos e Introducción La Calidad Tipos de Prueba. Ciclo de Vida y Mediciones. Escenarios en las Pruebas. Tácticas de Prueba Técnicas de Prueba
    • 4. Objetivos del Testing Verificar la correcta interacción entre los objetos Verificar la apropiada integración de los componentes del software. Verificar que todos los requerimientos se han implantado correctamente. Identificar y asegurar que los defectos y su tratamiento se han priorizado sobre el desarrollo del software.
    • 5. Introducción En muchas organizaciones la prueba del software significa el 30 o 50 % de los costos de desarrollo del software, no obstante mucha gente sostiene que la mayoría del software no se prueba lo suficiente antes de ser distribuido.
    • 6. Introducción Factores:  La prueba del software es tremendamente difícil. Las interrelaciones son tantas que probar todo el comportamiento es incuantificable.  La pruebas no se hacen con una clara metodología y sin la automatización requerida.
    • 7. Introducción Pruebas bien hechas y planificadas desde el comienzo del ciclo de vida del software reducen significativamente los costos de terminar y mantener el software. También reducen los riesgos asociados con una pobre calidad del software: productividad deficiente, errores de ingreso y cálculo de datos, comportamiento funcional inaceptable, entre otros.
    • 8. Calidad Alcanzar la calidad no consiste solamente en lograr conformidad en la “satisfacción de requerimientos” o de cumplir con las expectativas de los usuarios.... ...Radica en identificar las medidas y criterios que demuestren que se ha alcanzado en implantar un proceso que asegure que cualquier producto realizado siempre alcance el mismo nivel de calidad.
    • 9. Calidad del producto. Es la calidad del resultado tangible o producto del proceso que lo llevó a cabo. En el desarrollo del software el producto es la suma de muchos artefactos, como:  El ejecutable y su código (sistemas de aplicación) que es el producto primario objeto o motivo de un proyecto de desarrollo.  Artefactos no ejecutables como manuales de usuario y materiales de curso.
    • 10. Calidad del producto. .....  Ejecutables no implementados como la especificación de pruebas y herramientas de desarrollo.  Artefactos no ejecutables ni implementados como los planes de implementación, de prueba y modelos.
    • 11. Calidad del producto. Como muchos artefactos se basan en otros, la calidad de los mismos está relacionada en cierto grado. Por esta razón todos los artefactos deben ser sometidos a métricas de calidad.
    • 12. Dimensiones de la CalidadDimensiones propuestas por el RUP: Confiabilidad: Consiste en la fiabilidad y robustez del software (resistencia a fallas, interrupciones, caidas y falta de memoria) uso adecuado de recursos e integridad del código.
    • 13. Dimensiones de la Calidad Funcionalidad: Es la habilidad de implementar los casos de uso tal como se han requerido.
    • 14. Dimensiones de la Calidad (cont.) Rendimiento: Es el perfil de tiempo de operación del software y sus características operacionales.  El perfil incluye el flujo de ejecución del código, el acceso a los datos, las llamadas a funciones y las llamadas del sistema.  Las características operacionales incluyen: el tiempo de respuesta, la recuperación y límites en horas pico y estrés.
    • 15. Niveles de Calidad Existen 4 niveles de calidad: prueba, verificación, validación y certificación: Prueba  Las pruebas se llevan a cabo para demostrar que no hay errores en un programa. Esto es prácticamente imposible cuando se ejecuta por primera vez.  Las pruebas involucran la ejecución de procesos con la intención explícita de hallar errores, hacer que el proceso falle.
    • 16. Niveles de Calidad Verificación (Alpha test)  La verificación (alpha test) involucra la ejecución de partes o todo el sistema en ambientes simulados, con el fin de encontrar errores.  La retroalimentación de esta fase produce cambios en el software para resolver los errores y fallas que se descubren.  Los Alpha test se llevan a cabo en un ambiente controlado, en el cual el desarrollador está presente.
    • 17. Niveles de Calidad Validación (Beta Test)  La validación (beta test) involucra el uso del software en un ambiente real.  Las transacciones y personas que usan el sistema son reales y trabajan en su área de trabajo real.  El desarrollador no está presente.  Los usuarios están advertidos de que están usando un sistema que puede fallar.
    • 18. Niveles de Calidad Certificación  Es una garantía de un programa o sistema.  La garantía identifica que el software hace apropiadamente lo que el vendedor afirma que realiza.
    • 19. Tipos de Prueba.  Como ya se mencionó antes hay mucho mas en la prueba del software que solamente probar las funciones, interfaces y tiempos de respuesta. Algunos criterios adicionales de prueba son:  Integridad (resistencia a fallas)  Habilidad para ser instalado / ejecutado en diferentes plataformas.  Habilidad de manejar diferentes requerimientos de manera simultánea (concurrencia)  Y otros mas....
    • 20. Tipos de Prueba (cont.) Para cada dimensión existe un conjunto de pruebas....... Confiabilidad  Prueba de Integridad: Se concentra en determinar la robustez del sistema (resistencia a fallas) y las facilidades técnicas del lenguaje, sintaxis y uso de recursos.
    • 21. Tipos de Prueba (cont.) Confiabilidad  Prueba de Estructura : Se enfoca en asegurar la adherencia del objeto de prueba a su diseño y concepción. Típicamente se realiza para aplicaciones WEB enable asegurando que todos los enlaces estén conectados, el contenido sea apropiado y no existan contenidos huérfanos.
    • 22. Tipos de Prueba (cont.) Funcionalidad  Prueba de Configuración: Pruebas enfocadas a asegurar la calidad de resolución de las funciones del sistema. Están encaminadas a probar diferentes configuraciones de hardware y software.
    • 23. Tipos de Prueba (cont.) Funcionalidad  Pruebas de Función: Se concentran en la funcionalidad propiamente dicha; si tiene los servicios requeridos, métodos o casos de uso. Se implementan y ejecutan en diferentes objetos de prueba como: unidades funcionales, unidades integradas, subsistemas, aplicaciones y sistemas completos.
    • 24. Tipos de Prueba (cont.) Funcionalidad  Pruebas de instalación: Concentradas en las diferentes instalaciones del hardware y software en distintas configuraciones y condiciones tales como: espacio de disco insuficiente o cortes de energía.
    • 25. Tipos de Prueba (cont.) Funcionalidad  Pruebas de Seguridad: Focalizadas en asegurar que la disponibilidad de los datos esté solamente para aquellas personas o usuarios autorizados.
    • 26. Tipos de Prueba (cont.) Funcionalidad  Pruebas de Volumen: Focalizadas en verificar el comportamiento del sistema en la administración de grandes volúmenes de datos, tanto en la entrada, salida como en la comunicación con la base de datos. Estas pruebas se concentran en la elaboración de queries que recuperen el contenido completo de la base de datos o manejen variadas restricciones.
    • 27. Tipos de Prueba (cont.) Rendimiento  Prueba de Benchmark: Compara el comportamiento de una nueva funcionalidad u objeto de prueba versus otro que se comporta de manera óptima.
    • 28. Tipos de Prueba (cont.) Rendimiento  Prueba de Contención: Concentrada en verificar la concurrencia esto es muchas demandas a un mismo recurso (registros de datos, memoria, etc.)
    • 29. Tipos de Prueba (cont.) Rendimiento  Prueba de Carga: Es un tipo de prueba que verifica y asegura los límites aceptables de operación del sistema bajo variadas cargas de trabajo. Las métricas incluyen las características de la carga de trabajo y los tiempos de respuesta. Cuando los sistemas incluyen arquitecturas distribuidas o balance de carga, se deben hacer pruebas especiales que aseguren que los métodos de distribución y carga balanceada funcionen apropiadamente.
    • 30. Tipos de Prueba (cont.) Rendimiento  Perfil de Rendimiento: Es una prueba en donde el rendimiento es probado y monitoreado en la ejecución de flujos de trabajo, acceso a los datos, llamadas a funciones y al sistema con el propósito de encontrar cuellos de botella y procesos ineficientes.
    • 31. Tipos de Prueba (cont.) Rendimiento  Pruebas de Estrés: Es un tipo de prueba que se efectúa como consecuencia de haber encontrado un comportamiento anormal en el sistema. Se concentra en probar las funciones implicadas en situaciones extremas como sobrecarga del sistema, memoria insuficiente, no disponibilidad de servicios de software y/o hardware o disminución de los recursos compartidos.
    • 32. El ciclo de Vida de la Prueba. Durante su Ciclo de Vida, el Software se refina en cada iteración. Bajo este contexto el ciclo de vida de la prueba debe tener la misma aproximación. Este ciclo de vida debe ser integrado con el enfoque iterativo, lo que significa que cada iteración va a tener un ciclo de pruebas siguiendo ese mismo patrón.
    • 33. El ciclo de Vida de la Prueba.
    • 34. El ciclo de Vida de la Prueba. Este enfoque iterativo permite las pruebas de regresión. Muchas de las pruebas efectuadas en la iteración X se usan como pruebas de regresión en la iteración X +1 y así sucesivamente. Debido a que la misma prueba se repite varias veces es necesario un esfuerzo adicional para automatizarla.
    • 35. El ciclo de Vida de la Prueba.
    • 36. Mediciones clave en lasPruebas. Las mediciones clave en la prueba incluyen: cobertura y calidad.
    • 37. Mediciones clave en lasPruebas. La cobertura es la medición de cuan completo está el software en su funcionalidad.
    • 38. Mediciones clave en lasPruebas. La calidad es la medición de la confiabilidad, estabilidad y rendimiento del objeto de prueba. La calidad se basa en los resultados de las pruebas de evaluación y el análisis de los defectos identificados durante la prueba.
    • 39. Mediciones clave en lasPruebas. La métricas de Cobertura responden a la pregunta: ¿Cuan completa está la prueba? Estas pruebas se miden respecto a los requerimientos y casos de uso, o al código desarrollado versus el diseñado (ejecución del código).
    • 40. Mediciones clave en lasPruebas. Calidad es un indicativo de que el software también cumple con los requerimientos. Aquí los defectos son identificados como requerimientos de cambio.
    • 41. Escenarios en las Pruebas. Unidad de Prueba  Las unidades de prueba se deben definir en la fase inicial de una iteración y se debe concentrar en probar elementos pequeños. Usualmente estos elementos son componentes y como estos participan en la ejecución de un caso de uso.
    • 42. Escenarios en las Pruebas. Prueba de Integración o Integral  Esta prueba está orientada a asegurar que los componentes implementados operan apropiadamente cuando combinan esfuerzos en la ejecución de un use case.
    • 43. Escenarios en las Pruebas. Prueba del Sistema  Se realiza cuando el software está funcionando como un todo o cuando se esta probando todo un subsistema completo.
    • 44. Escenarios en las Pruebas. Prueba de Aceptación  Esta prueba es el test final antes de distribuir el software para su operación y uso.
    • 45. Tácticas en las Pruebas.  Una Táctica busca reducir la posibilidad de que un riesgo específico tenga lugar.  Se enfatizará en dos tipos de tácticas:  Inspecciones.  Pruebas dinámicas.
    • 46. Inspección  Las inspecciones son aplicables en todas las etapas de desarrollo del producto (no sólo para código).  No requieren herramientas sofisticadas.
    • 47. Inspección  Inspecciones: Roles y responsabilidades  Autor: Desarrollador del producto que será inspeccionado.  Inspectores:  Colegas del autor.  Uno de otro proyecto.  Moderador: Miembro del grupo de aseguramiento de calidad.
    • 48. Inspección  Preparación de la Inspección: Proceso  Autor prepara el producto para revisar, lista de chequeo y material de soporte.  Moderador selecciona 2 inspectores y elabora cronograma.  Autor distribuye material.  Autor presenta el producto a los participantes en la inspección.
    • 49. Inspección  Revisión individual: Proceso:  Inspectores y moderador revisan individualmente, según lista de chequeo.  Inspectores registran defectos.  Inspectores registran tiempo invertido en revisión.
    • 50. Inspección Preparación Rev. Individual Reunión de Ins. Cambios Corr. De errs. ? Verif. De corr. Congelar versión An. Causal de errs.
    • 51. Pruebas dinámicas Consiste en la ejecución de programas para detectar errores. Son menos efectivas que inspecciones. Los defectos se manifiestan como discrepancias en el comportamiento esperado. La corrección de un error puede ser difícil, porque:  Puede ser difícil aislar errores.  Los problemas pueden ser intermitentes, difíciles de repetir.
    • 52. Técnicas de Prueba Caja blanca o Pruebas estructurales  El conocimiento del diseño interno del software se usa para construir casos de prueba. Caja negra o Pruebas funcionales  Casos de prueba basados en la especificación del software. Pruebas basadas en escenarios o casos de uso  Actuar como usuario final.  Crear escenarios para detección de errores.
    • 53. Técnicas de Prueba Pruebas selectivas  Más casos de prueba para componentes más usados.  Más rigor en prueba de componentes críticos.  Más casos de prueba para componentes más complejos.
    • 54. Técnicas de Prueba

    ×