Int. a la Ingeniería del Software UP 2004

Presentación del tema: "Int. a la Ingeniería del Software UP 2004"— Transcripción de la presentación:

1 Int. a la Ingeniería del Software UP 2004
Pruebas de Software Int. a la Ingeniería del Software UP 2004 Lic.Marisa Gouget - IS - UP

2 Estrategias de prueba del software
Lic.Marisa Gouget - IS - UP

3 Un enfoque estratégico
Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente, por lo que es importante definir un conjunto de pasos en los que podamos situar los métodos específicos de diseño de casos de prueba. Lic.Marisa Gouget - IS - UP

4 Un enfoque estratégico cont.
Características generales de las pruebas: Comienzan a nivel módulo y trabajan “hacia fuera”, hacia la integración de todo el sistema basado en computadora. Según el momento, son apropiadas diferentes métodos. La lleva a cabo el responsable de desarrollo del software y un grupo independiente de pruebas (para grandes proyectos). La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba. Lic.Marisa Gouget - IS - UP

5 Validación y Verificación
Verificación: se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica. ¿Estamos construyendo el producto correctamente? Validación: se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. ¿Estamos construyendo el producto correcto? Lic.Marisa Gouget - IS - UP

6 Éxito en la estrategia de pruebas
Se deben abordar los siguientes puntos Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas. Establecer los objetivos de la prueba de manera explícita. Comprender qué usuarios van a manejar el software y desarrollar un perfil de prueba para cada categoría de usuario. Lic.Marisa Gouget - IS - UP

7 Éxito en la estrategia de pruebas cont.
Construir un software “robusto” diseñado para probarse a sí mismo. Usar revisiones técnicas formales efectivas como filtro antes de la prueba. Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Desarrollar un enfoque de mejora continua al proceso de la prueba. Debería medirse la estrategia de la prueba. Lic.Marisa Gouget - IS - UP

8 Lic.Marisa Gouget - IS - UP
Prueba de Unidad Es una prueba a nivel módulo. Esta orientada a ser de “caja blanca”. Pueden llevarse a cabo en paralelo más de una a la vez. Prueba: interfaz, estructura de datos locales, condiciones límite, caminos independientes, camino de manejo de errores, etc. Se simplifica cuando se diseña un módulo con un alto grado de cohesión. Lic.Marisa Gouget - IS - UP

9 Lic.Marisa Gouget - IS - UP
Prueba de integración Busca encontrar errores asociados con la integración. Integración descendente: la prueba se realiza integrando módulos moviéndose hacia abajo en la jerarquía de control. Integración ascendente: comienza la prueba con los módulos atómicos. Se integran de abajo hacia arriba. Lic.Marisa Gouget - IS - UP

10 Prueba de integración cont.
Prueba de regresión: es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurar que los cambios no han propagado efectos colaterales no deseados (por ejemplo cuando se añade un nuevo módulo como parte de la prueba). La selección de una estrategia de integración depende de las características del software y de la planificación del proyecto. Lic.Marisa Gouget - IS - UP

11 Lic.Marisa Gouget - IS - UP
Prueba de Validación La validación del software se consigue mediante una serie de pruebas de “caja negra” que demuestran la conformidad de los requisitos. Pruebas de alfa y beta: la prueba alfa se lleva a cabo en el lugar de desarrollo (por un usuario) y con el desarrollador como observador. Las beta, son llevadas a cabo por los usuarios finales del software en los lugares de trabajo del cliente. Lic.Marisa Gouget - IS - UP

12 Lic.Marisa Gouget - IS - UP
Prueba del sistema El objetivo de esta prueba es ejercitar profundamente el sistema. Como todas las pruebas, esta también trabaja para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. Lic.Marisa Gouget - IS - UP

13 Prueba del sistema cont.
Prueba de recuperación: esta prueba fuerza el fallo del software de muchas formas diferentes y verifica que la recuperación se lleva a cabo apropiadamente. Prueba de seguridad: intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán de accesos impropios. Prueba de resistencia (stress): ejecuta un sistema que demande recursos en cantidad, frecuencia o volúmenes anormales. Prueba de rendimiento: está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado. Lic.Marisa Gouget - IS - UP

14 Lic.Marisa Gouget - IS - UP
Depuración Ocurre como consecuencia de una prueba efectiva. Cuando una prueba descubre un error, el proceso de depuración provoca la eliminación del mismo. No es una prueba, pero ocurre como consecuencia de ella. Tiene siempre uno de los dos resultados siguientes: Se encuentra la causa, se corrige y se elimina No se encuentra la causa (el depurador sospecha la causa, diseña un caso de prueba que la confirme). Lic.Marisa Gouget - IS - UP

15 Técnicas de Prueba del Software
Lic.Marisa Gouget - IS - UP

16 Lic.Marisa Gouget - IS - UP
Pruebas Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. Lic.Marisa Gouget - IS - UP

17 Lic.Marisa Gouget - IS - UP
Objetivos de la Prueba La prueba es el proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Glen Myers Lic.Marisa Gouget - IS - UP

18 Principios de las pruebas
A todas la pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Las pruebas deberían planificarse mucho antes de que empiecen. El principio de Pareto es aplicable a la prueba del software. Las pruebas deberían empezar por ‘lo pequeño’ y progresar hacia ‘lo grande’. No son posibles las pruebas exhaustivas. Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Lic.Marisa Gouget - IS - UP

19 Lic.Marisa Gouget - IS - UP
Facilidad de la prueba Es la facilidad con la que se puede probar un programa de computadora. Lic.Marisa Gouget - IS - UP

20 Facilidad de prueba (cont.)
Lista de comprobación que proporciona un conjunto de características que llevarían a un sw fácil de probar: OPERATIVIDAD - “Cuanto mejor funcione, más eficientemente se puede probar” OBSERVABILIDAD - “Lo que ves es lo que pruebas” CONTROLABILIDAD - “Cuanto mejor podamos controlar el sw, más se puede automatizar y optimizar” CAPACIDAD DE DESCOMPOSICIÓN - “Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión” SIMPLICIDAD - “Cuanto menos haya que probar, más rápidamente podremos probarlo” ESTABILIDAD - “Cuanto menos cambios, menos interrupciones en las pruebas” FACILIDAD DE COMPRENSIÓN - “Cuanta más información tengamos, más inteligentes serán las pruebas” Lic.Marisa Gouget - IS - UP

21 Lic.Marisa Gouget - IS - UP
Pruebas de CAJA BLANCA También llamada “prueba de Caja de Cristal”, es un método de diseño de casos de prueba que usa la estructura de control del diseño procedural para obtener casos de prueba que: garanticen que se ejecutan al menos una vez cada camino independiente de cada módulo, ejerciten todas las decisiones lógicas en sus vertientes verdadero o falso, ejecución de todos los bucles en sus límites y con sus límites operacionales, ejerciten todas las estructuras internas de datos para asegurar su validez. Lic.Marisa Gouget - IS - UP

22 Pruebas de CAJA BLANCA cont.
Prueba del camino básico Permite tener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución que garantizan que durante la prueba se ejecuta al menos una vez cada sentencia,. Se basan en notaciones de grafos, que representan el flujo de control a través de nodos y aristas. Un nodo es un conjunto de sentencias más algún rombo de decisión, una arista un flujo de control, ejemplo: condición if: Complejidad ciclomática: es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa, que nos dice cuál es el número de caminos independientes para calcular la cantidad de pruebas a realizar. V(G)= A-N + 2, donde A es la cantidad de aristas, N la cantidad de nodos. Lic.Marisa Gouget - IS - UP

23 Pruebas de CAJA BLANCA cont.
Prueba del camino básico- Obtención de casos A partir del diseño o del código fuente dibujar el grafo de flujo. Determinar la complejidad ciclomática V(G). Determinar un conjunto básico de caminos linealmente independientes en la cantidad que dio el V(G). Lic.Marisa Gouget - IS - UP

24 Pruebas de CAJA BLANCA cont.
Prueba de estructura de control Prueba de condición: método de diseño de pruebas que ejercita las condiciones lógicas contenidas en el módulo de un programa (and, or,y not). Busca probar cada una de ellas. Lic.Marisa Gouget - IS - UP

25 Pruebas de CAJA BLANCA cont.
Prueba de estructura de control Prueba de Flujo de Datos: selecciona caminos de la prueba de acuerdo con la ubicación de las definiciones y uso de las variables del programa. Son útiles para seleccionar caminos de la prueba de un programa que contenga sentencia de IF o bucle anidado. Lic.Marisa Gouget - IS - UP

26 Pruebas de CAJA BLANCA cont.
Prueba de bucles Se centra exclusivamente en la validez de las construcciones de los blucles simples, anidados, concatenados y no estructurados. Lic.Marisa Gouget - IS - UP

27 El arte de probar el Software
“La prueba es el proceso de ejecutar un programa con el fin de encontrar errores” Ejercicio: Un programa define si un triángulo es escaleno, equilátero o isósceles a partir de 3 números enteros dados. Lic.Marisa Gouget - IS - UP

28 Lic.Marisa Gouget - IS - UP
Pruebas de CAJA NEGRA También denominada “pruebas de comportamiento”. Se centran en los requisitos funcionales del grupo, o sea, permiten al ingeniero obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales del programa, intenta encontrar errores de las siguientes categorías: Funciones incorrectas o ausentes Errores de interfaz Errores en estructura de datos o accesos a BD externas Errores de rendimiento Errores de inicialización y de terminación Lic.Marisa Gouget - IS - UP

29 Pruebas de CAJA NEGRA cont.
Apuntan a: Ver cómo se prueba la validez funcional. Qué clases de entrada componen buenos casos de prueba Ver si el sistema es sensible a ciertos valores de entrada Ver de qué forma están aislados los límites de una clase de datos. Qué volúmenes y niveles de datos tolerará el sistema. Qué efectos tendrán combinaciones específicas de datos. Lic.Marisa Gouget - IS - UP

30 Pruebas de CAJA NEGRA cont.
Métodos de prueba basados en grafos Se crea un grafo de objetos importantes del sistema y sus relaciones, asignándoles “pesos” a los nodos (ej.:atributos que se esperan recibir en una ventana) y a los enlaces (ej.: tiempo de respuesta esperado). Se diseña una serie de pruebas que cubran el grafo de manera que ejerciten todos lo objetos y sus relaciones para descubrir errores en ellas. Lic.Marisa Gouget - IS - UP

31 Pruebas de CAJA NEGRA cont.
Partición equivalente Divide el campo de entrada de un programa en clases de datos de los que se puedan derivar casos de prueba. Se basa en una evaluación de las clases equivalentes de una condiciones de entrada. Clase de equivalencia: conjunto de estados válidos o no válidos de datos de entrada. Lic.Marisa Gouget - IS - UP

32 Pruebas de CAJA NEGRA cont.
Análisis de valores límite Es una técnica de diseño de casos de prueba que complementa a la partición equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, lleva a la elección de casos de prueba en los “extremos” de la clase. No se centra solamente en las condiciones de entrada sino también para el campo de salida. Lic.Marisa Gouget - IS - UP

33 Pruebas de CAJA NEGRA cont.
Prueba de comparación Cuando se desarrollan versiones independientes de una aplicación usando las mismas especificaciones. Se prueban todas las versiones con los mismos datos de prueba para asegurar que todas proporcionan una salida idéntica. Es aplicable en casos de sistemas críticos, como el control aéreo por ejemplo. Lic.Marisa Gouget - IS - UP

34 Pruebas de entornos especializados, arquitecturas y aplicaciones
Pruebas de interfaces gráficas de usuario (GUIs) Prueba de arquitectura cliente/servidor (rendimiento, coordinación de recursos, etc) Prueba de la documentación y facilidades de ayuda Prueba de sistemas de tiempo real (el tiempo) Lic.Marisa Gouget - IS - UP

35 Las Pruebas y Los Casos de Uso
El Proceso Unificado de Desarrollo de Software Lic.Marisa Gouget - IS - UP

36 Lic.Marisa Gouget - IS - UP
El producto Verificado por Distribuido por Implementado por Realizado por Especificado por Modelo de casos de uso Modelo del análisis Modelo del diseño X OX Modelo de despliegue Modelo de implementación Modelo de pruebas Lic.Marisa Gouget - IS - UP

37 Lic.Marisa Gouget - IS - UP
Pruebas Verificación del resultado de la implementación probando cada construcción: Planificación de las pruebas Diseño de las pruebas (Casos de prueba) Realización de las pruebas Lic.Marisa Gouget - IS - UP

38 Artefactos de la Prueba
Modelo de Pruebas: describe cómos se prueban los componentes ejecutables y otros aspectos específicos como la interfaz. Contiene a los casos de prueba, los procedimientos de prueba y componentes de prueba. Casos de prueba: especifica una forma de probar el sistema, incluyendo la entrada con la que se ha de probar y las condiciones bajo las que ha de probarse, más el resultado esperado. Procedimiento de prueba: describe cómo realizar uno o varios casos de prueba. Lic.Marisa Gouget - IS - UP

39 Artefactos de la Prueba
Componente de prueba: automatiza uno o varios procedimientos de prueba o partes de ellos. Plan de prueba: describe las estrategias, recursos y planificación de las pruebas, incluyendo la definición del tipo de pruebas a realizar en cada iteración, sus objetivos, el nivel de cobertura de la prueba y de código necesario, y el porcentaje de pruebas que deberían ejecutarse con un resultado específico. Defecto: anomalía del sistema, síntoma de un problema en el sistema que es necesario controlar y resolver. Evaluación de la prueba: resultados de las pruebas. Lic.Marisa Gouget - IS - UP

40 Trabajadores de la Prueba
Diseñador de pruebas: responsable por la integridad del modelo de pruebas, de la planificación, del diseño de las pruebas, de los procedimientos, y de la evaluación. Ingeniero de componentes: responsables de los componentes de prueba que automatizan los procedimientos. Ingeniero de pruebas de integración: responsables de realizar las pruebas de integración y de la documentación de los defectos encontrados. Ingeniero de pruebas de sistema: responsable de realizar las pruebas de las construcciones de una iteración completa y documentar los resultados. Lic.Marisa Gouget - IS - UP

41 Flujo de trabajo de la Prueba
Ing. Pruebas de integración Ing. de pruebas de sistema Diseñador de pruebas Planificar pruebas Realizar pruebas de integración Implementar Evaluar prueba Realizar prueba del sistema Ingeniero de componentes Diseñar pruebas Lic.Marisa Gouget - IS - UP

42 Actividades de la Prueba
Planificar la prueba: Describir una estrategia de prueba. Estimar los recursos para la prueba (humanos y materiales) Planificar el esfuerzo de la prueba. Diseñar la prueba: Identificar y describir los casos prueba para cada construcción. Identificar y estructurar los procedimientos de prueba especificando cómo realizar los casos de prueba. Implementar la prueba: automatizar los procedimientos de prueba creando componentes de prueba si es posible. Lic.Marisa Gouget - IS - UP

43 Actividades de la Prueba
Realizar pruebas de integración: Realizar las pruebas de integración. Comparar resultados con los esperados. Informar defectos a los ingenieros de componentes y a los diseñadores de la prueba. Realizar pruebas de sistema: Idem anterior, una vez terminadas las pruebas de integración. Evaluar las pruebas: Comparar los resultados de la prueba con los esperados, y confeccionar métricas para determinar el nivel de calidad del software en base a la Compleción de la prueba y la Fiabilidad. Lic.Marisa Gouget - IS - UP