La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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

Presentaciones similares


Presentación del tema: "Lic.Marisa Gouget - IS - UP1 Pruebas de Software Int. a la Ingeniería del Software UP 2004."— Transcripción de la presentación:

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

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

3 Lic.Marisa Gouget - IS - UP3 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.

4 Lic.Marisa Gouget - IS - UP4 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.

5 Lic.Marisa Gouget - IS - UP5 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?

6 Lic.Marisa Gouget - IS - UP6 É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.

7 Lic.Marisa Gouget - IS - UP7 É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.

8 Lic.Marisa Gouget - IS - UP8 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.

9 Lic.Marisa Gouget - IS - UP9 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.

10 Lic.Marisa Gouget - IS - UP10 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.

11 Lic.Marisa Gouget - IS - UP11 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.

12 Lic.Marisa Gouget - IS - UP12 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.

13 Lic.Marisa Gouget - IS - UP13 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.

14 Lic.Marisa Gouget - IS - UP14 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).

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

16 Lic.Marisa Gouget - IS - UP16 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.

17 Lic.Marisa Gouget - IS - UP17 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

18 Lic.Marisa Gouget - IS - UP18 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.

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

20 Lic.Marisa Gouget - IS - UP20 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

21 Lic.Marisa Gouget - IS - UP21 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.

22 Lic.Marisa Gouget - IS - UP22 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.

23 Lic.Marisa Gouget - IS - UP23 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).

24 Lic.Marisa Gouget - IS - UP24 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.

25 Lic.Marisa Gouget - IS - UP25 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.

26 Lic.Marisa Gouget - IS - UP26 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.

27 Lic.Marisa Gouget - IS - UP27 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.

28 Lic.Marisa Gouget - IS - UP28 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

29 Lic.Marisa Gouget - IS - UP29 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.

30 Lic.Marisa Gouget - IS - UP30 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.

31 Lic.Marisa Gouget - IS - UP31 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.

32 Lic.Marisa Gouget - IS - UP32 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.

33 Lic.Marisa Gouget - IS - UP33 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.

34 Lic.Marisa Gouget - IS - UP34 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)

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

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

37 Lic.Marisa Gouget - IS - UP37 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

38 Lic.Marisa Gouget - IS - UP38 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.

39 Lic.Marisa Gouget - IS - UP39 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.

40 Lic.Marisa Gouget - IS - UP40 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.

41 Lic.Marisa Gouget - IS - UP41 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 pruebas Evaluar prueba Realizar prueba del sistema Ingeniero de componentes Diseñar pruebas

42 Lic.Marisa Gouget - IS - UP42 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.

43 Lic.Marisa Gouget - IS - UP43 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.


Descargar ppt "Lic.Marisa Gouget - IS - UP1 Pruebas de Software Int. a la Ingeniería del Software UP 2004."

Presentaciones similares


Anuncios Google