Estrategias de Pruebas de Software

Transcripción

1 Estrategias de Software

2 Software Es el proceso de probar el sistema con el fin de encontrar errores antes de la entrega al usuario final.

3 Qué muestran las pruebas errores Concordancia con los requerimientos Rendimiento Indicadores de calidad

4 Quién prueba el software? Desarrolladores Entienden el producto pero suelen ser gentiles con las pruebas. Su móvil es la entrega. Probadores independientes Conocen el sistema y se dedican a botar el mismo. Su móvil es la calidad.

5 Estrategia de prueba unidad integración sistemas validación

6 Estrategias de integración de pruebas de unidad Opciones Integración top bottom Los módulos son probados con los submódulos Estos submódulos probados uno a la vez Cuando se agregan submódulos se realizan de nuevo. Integración bottom up Los módulos son agrupados en clusters y se prueban éstos primero y luego el módulo al que pertenecen

7 Estrategias de integración de pruebas de unidas (cont.) Pruebas orientadas a objetos Se inicia probando la correctitud y la consistencia de los módulos. El concepto de unidad se amplia a encapsulación La integración se centra en las clases y cómo estas viajan por los escenarios.

8 Estrategias de integración de pruebas de unidas (cont.) regresión : Cada vez que se agrega un módulo el software cambia. Las pruebas de regresión consisten en ejecutar el mismo subconjunto de pruebas que ya se han aplicado para asegurarse de que los cambios no han propagado efectos colaterales indeseables.

9 Estrategias de integración de pruebas de unidas (cont.) humo Es un enfoque de prueba de integración se utilizan cuando el tiempo es crítico, abarca: Integrar los componentes Diseñar las prueba para exponer errores paralizantes Integrar las construcción con otras y aplicar pruebas diariamente.

10 Documentación de las pruebas de unidad Se denomina Especificación de la prueba e incluye: Plan de pruebas Procedimiento de pruebas Estrategia general de integración

11 Validación Estas se realizan para demostrar que el sistema cumple con los requisitos. La revisión de la configuración tiene con objetivo asegurar que todos los elementos de la configuración se hayan desarrollado correctamente, estén catalogados y que tengan el detalle suficiente para reforzar la fase de soporte.

12 Validación (cont.) Pruebas alfa beta Las pruebas Alfa: Se aplican en el lugar de trabajo de los desarrolladores la idea es observar el uso controlado del sistema Las prueba Beta : Se aplican en el lugar de trabajo de los usuarios finales

13 sistema Se aplica : Recuperación: se obliga al software a fallar y reanudar el proceso en un tiempo determinado. Seguridad: comprueba que los mecanismos de protección integrados los protejan de irrupciones inapropiadas. La prueba de resistencia: ejecuta el sistema de forma tal que requiera una cantidad, una frecuencia o un volumen anormal de recursos prueba de desempeño: se pretende probar el desempeño del sistema dentro de un contexto o un tiempo determinado.

14 Metodología de Calidad del Software

15 Metodología de Calidad del Software Introducción Objetivo de la Prueba Definición de la Prueba Flujo de la Prueba Metas de la Prueba Fases de Prueba Aceptación Sistema Integración Unidad Verificación y Validación

16 Técnicas de Pruebas Caja Negra Caja Blanca Estrategia de las Pruebas Tipos de Pruebas Especiales Usabilidad Regresión Seguridad Estrés Volúmen Configuración

17 Introducción La metodología de calidad de software nos ofrece métodos y técnicas que nos ayudan a obtener resultados de calidad, con el firme propósito de incrementar la efectividad y eficiencia de las actividades que el grupo de calidad realiza, a fin de lograr la máxima satisfacción de nuestros clientes.

18 Calidad del software þ Aplicando métodos efectivos (mejorar los procesos) þ Medidas (indicación cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaños de algunos atributos de un proceso o producto) þ Métricas (medida cuantitativa que proporciona indicadores que conducirá a una estrategia de mejora) þ Herramientas modernas

19 Producto y Proceso þproceso: marco de trabajo de las tareas que se requieren para construir software de alta calidad. þproducto: es el resultado de un proceso

20 Proceso del Desarrollo de Software Pre-Analisis Analisis El proceso de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos puedan estar especificados de forma errónea o imperfecta; así como en pasos posteriores del diseño y construcción. Diseño Construcción Pruebas Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo del software ha de ir acompañado de una actividad que garantice la calidad.

21 Verificar y Validar Verificar: Es el proceso de evaluación del software para determinar si el producto cumple satisfactoriamente cada una de las fases de desarrollo. La verificación se realiza por medio de una inspección. Validar: Es el proceso de evaluación del software durante o al final del proceso de desarrollo para determinar si este satisface los requerimientos especificados por el cliente. La validación se realiza con algunas revisiones pero siempre es completada con las pruebas.

22 Verificar y Validar Pre-Analisis Verificar Analisis Validar Verificar Verificar Diseño Construcción Verificar Pruebas

23 Definición de la Prueba La prueba del software es un conjunto de a c t i v i d a d e s q u e s e l l e v a a c a b o sistemáticamente, que puede planificarse por adelantado y ejecutar una vez construido el c ó d i g o p a r a l a r e v i s i ó n f i n a l d e l a s especificaciones, del diseño y de la codificación del software.

24 Objetivo de la Prueba E l o b j e t i v o e s d i s e ñ a r p r u e b a s q u e sistemáticamente saquen a la luz el máximo número de errores tempranamente, para así minimizar el riesgo e impacto que el producto pueda tener al ser liberado.

25 Ciclo de Vida del Desarrollo de Software Pre-Analisis Planear Aceptación Fases de Desarrollo Analisis Construir incrementalmente los requerimientos del software Diseño Planear Planear Construcción & Unidad Integración Sistema Fases de Pruebas Asegurar que el producto final trabaja correctamente en base a los requerimientos.

26 Pre-Análisis Pre-Analisis Analisis Actividades de V&V Verificar el análisis de los Requerimientos Inicializar la elaboración del Plan de Calidad Crear un proyecto para las pruebas Crear y verificar el Plan de Aceptación Cierre de la fase del Pre- Análisis Sistema Aceptación Diseño Integración Construcción & Unidad

27 Análisis Pre-Analisis Analisis Actividades de V&V Verificar el modelo del análisis Verificar la rastreabilidad de los requerimientos Verificar los casos de uso validados Crear y verificar el Plan de Sistema Cierre de la fase de Análisis Sistema Aceptación Diseño Integración Construcción & Unidad

28 Diseño Actividades de V&V Pre-Analisis Analisis Verificar el modelo del diseño Verificar el diseño de las BD Verificar la Rastreabilidad de los requerimientos Verificar el prototipo Crear y verificar el Plan de Integración y Plan de Unidad Cierre de la fase diseño Sistema Aceptación Diseño Integración Construcción & Unidad

29 Construcción Actividades de V&V Pre-Analisis Analisis Verificar el código, las BD, etc. Verificar la Rastreabilidad Ejecutar las Unidad Documentar las Unidad Cierre de la fase de construcción Sistema Aceptación Diseño Integración Construcción & Unidad

30 Integración Actividades de V&V Pre-Analisis Ejecutar las Integración para validar el diseño Documentar las Integración Aceptación Analisis Sistema Diseño Integración Construcción & Unidad

31 Sistema Actividades de V&V Pre-Analisis Ejecutar las Sistema para validar el anàlisis Documentar las Sistema Aceptación Analisis Sistema Diseño Integración Construcción & Unidad

32 Aceptación Actividades de V&V Pre-Analisis Ejecutar las Aceptación para validar los requerimientos Documentar las Aceptación Aceptación Analisis Sistema Diseño Integración Construcción & Unidad

33 Ciclo de Vida del Desarrollo de Software Pre-Analisis Planear Aceptación Proceso de Desarrollo de Software Analisis Diseño Planear Planear Construcción & Unidad Integración Sistema A medida que se lleva a cabo la prueba se van recogiendo datos que proporcionan una buena indicación de la fiabilidad del software y de alguna manera indican la calidad del software. Proceso de Ejecución de Pruebas

34 Principios de la Prueba þ Rastreabilidad, a todas las pruebas se les debería poder hacer un seguimiento hasta los requerimientos del cliente. þ Las berían planificarse mucho antes de que empiecen. þ Las pruebas deben empezar por lo pequeño y progresar hacia lo grande. þ Las pruebas deben ser ejecutadas por un grupo independiente del desarrollo. þ La prueba no puede asegurar la ausencia de defectos, sólo puede demostrar que existen defectos en el software. þ Una prueba tiene éxito si descubre un error no detectado hasta entonces.

35 Metas de la Prueba þ Detectar errores. Es mejor y más económico encontrar el máximo de errores lo más temprano posible durante el Proceso de Desarrollo de una Solución de Software. þ Asegurar la calidad. Cuando el producto cumple con los requerimientos y expectativas del cliente y no tiene errores se asegura su calidad. þ Reducir el mantenimiento. Cuando los errores se descubren tempranamente y se evita que ocurran durante la vida útil de la aplicación, el mantenimiento sufre una reducción considerable.

36 Flujo de la Prueba Configuración del Software Configuración de la Prueba Prueba Resultados Esperados Resultados de la Prueba Evaluación Prueba Exitosa Prueba No Exitosa Liberación Correcciones

37 Técnicas de Prueba þ Prueba de Caja Negra: es una técnica que se enfoca en pruebas de funcionalidad de programas, componentes ó aplicaciones, se basa en especificaciones externas sin conocer como el sistema esta construido. Entra da Salid a þ Prueba de Caja Blanca: es una técnica de prueba que se basa en el conocimiento de la estructura interna del código y las rutas ó caminos lógicas de un programa ó componente. Entra da Salid a

38 Utilización de las Técnicas Caja Blanca Caja Negra Unidad X Integración X X Sistema X Aceptación X

39 Estrategia de las Pruebas La estrategia de la prueba debe incorporar la planeación de las pruebas, el diseño de casos de prueba, la ejecución de las pruebas, la documentación de las pruebas y la agrupación y evaluación de los resultados

40 Unidad Que? Probar programas individuales o componentes para validar que su lògica trabaja correctamente de acuerdo a las especificaciones Quien? Son realizadas por desarrollador quien creo el componente Cuando? Inician una vez que el componente ha sido desarrollado completamente

41 Integraciòn Que? Probar la integridad de los componentes que han sido exitosos en las pruebas de unidad Quien? Son realizadas por el desarrollador y el grupo de pruebas Cuando? Inician una vez que los componentes han pasado exitosamente las pruebas de unidad

42 Sistema Que? Probar el sistema completo y las interfaces con otras aplicaciones para validar los requerimientos funcionales y no funcionales. Quien? Son realizadas por el grupo de pruebas junto con el LP Cuando? Inician cuando las pruebas de integraciòn han sido completadas exitosamente

43 Aceptaciòn Que? Validar que el sistema es adecuado para el usuario, además de evaluar como el sistema se integra con el manual de proceso de negocios. Quien? Son realizadas por el usuario y dirigidas por el LP y el grupo de pruebas Cuando? Inician cuando las pruebas de sistema han sido completadas exitosamente

44 Ejemplo de Fases de Pruebas þ Un auto es un sistema complejo, con muchos componentes. þ Cada componente individual es inspeccionado y probado. ( Unidad) þ Una vez que todos los componentes son probados individualmente, los componentes son integrados hasta construir un auto. ( Integraciòn) þ Las Sistema se realizan una vez ensamblado el auto completo para aseguara que el auto trabaja correctamente en varias condiciones.

45 Pruebas Especiales Usabilidad Pruebas de Unidad Integración Sistema Aceptación Conversión Stress Seguridad Configuración Rendimiento/Volumen Regresión

46 Usabilidad þ Identificar áreas en el sistema que puedan ser difíciles de usar. þ Se recomienda hacerlas con el usuario representativo o con el cliente durante la verificación del prototipo.

47 Conversión þ Validar la eficiencia del proceso de conversión (interpretación de datos, mapeo de campos, etc.) þ Son realizadas por el desarrollador durante las pruebas de integración o por el grupo de pruebas al inicio de las pruebas de sistema.

48 Performance/ Volumen þ Una variación de volumen y stress que miden el rendimiento del sistema. þvalida que la respuestas en tiempo on-line es apropiado a los requerimientos de rendimiento establecido: gráficos, queries en BD, transacciones progresivas, etc. þconducidas por el desarrollador y el grupo de pruebas son realizadas durante las pruebas de integración y/o de sistema.

49 Configuración þ Estas pruebas son necesarias en software cliente-servidor o en aplicaciones del web para validar que la aplicación correrá correctamente en todos los ambientes del los usuarios finales (SO de la PC, Configuración del HW, Versión del Browser y el SW instalado como Word y Excel) þtambién son necesarias el SW correrá con varias configuraciones del servidor.

50 Seguridad þ Valida que la aplicación esta protegida de usuarios no autorizados. þasegura que los datos están protegidos de accesos no autorizados y/o modificaciones. þconducidas por el grupo de pruebas durante las pruebas de sistema.

51 Fallo þ Valida que el sistema puede recuperarse de las siguientes fallas: þ Transmisión de archivo interrumpido þ Fallo de la red entre la aplicación y el servidor de datos. þ Se reseteo el servidor þ Componentes inernos de la aplicación fallaron þ Job Batch interrumpidos þ Verificar que la aplicación le notifica al usuario el estado de las transacciones. þverificar si la aplicación notifica que algun componente a fallado. þverificar si las transacciones incompletas o con alguna falla son restauradas automaticamente.

52 Regresión þse llevan a cabo en cualquier momento en que el código ha sido modificado para asegurar que dichas modificaciones no afectan al resto del sistema. þ Reusar los scripts de pruebas automáticas de pruebas previas.

53 Stress þmide el soporte máximo de un sistema bajo condiciones de carga y volúmen de datos criticos en un periodo de tiempo determinado. þidentificar el impacto del sistema en tipo de procesamiento. þse llevan a cabo una vez que se han concliudo las pruebas de sistema.