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

Lic.Marisa Gouget - IS - UP 1

Pruebas de Software

Int. a la Ingeniería del Software

UP

2004


Estrategias de prueba del software


Un enfoque estratégicoLas 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.


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.


Validación y VerificaciónVerificació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?


É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.


É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.


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.


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.


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.


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.


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.


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.


DepuraciónOcurre 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).


Técnicas de Prueba del Software


PruebasLas 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.


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


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.


Facilidad de la prueba

Es la facilidad con la que se puede probar un programa de computadora.


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”


Pruebas de CAJA BLANCATambié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.


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.


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).


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.


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.


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.


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.


Pruebas de CAJA NEGRATambié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


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.


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.


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.


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.


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.


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)


Las Pruebas y Los Casos de Uso

El Proceso Unificado de Desarrollo de Software


El producto

Modelo de casos de uso

Modelo delanálisis

Especificado por

Modelo deldiseño

Realizado por

Modelo dedespliegue

Distribuido por

Modelo deimplementación

Implementado por

XOX

XOX

XOX

Modelo depruebas

Verificado por


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


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.


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.


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.


Flujo de trabajo de la Prueba

Ing. Pruebas de integración

Ing. de pruebasde sistema

Diseñador de pruebas Planificar pruebas

Realizar pruebasde integración

Implementar pruebas

Evaluarprueba

Realizar pruebadel sistema

Ingeniero de componentes

Diseñar pruebas


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.


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 - UP1 Pruebas de Software Int. a la Ingeniería del Software UP 2004.

Documents

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