Introducción. El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo.

Presentación del tema: "Introducción. El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo."— Transcripción de la presentación:

1 Introducción. El desarrollo 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 inicio del proceso, en el que los objetivos pueden estar especificados de forma errónea o imperfecta, así como dentro de pasos de diseño y desarrollo posteriores..

2 Introducción. Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantice la calidad La prueba del software es 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.

3 Objetivos de la prueba Los objetivos principales de realizar una prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga más probabilidad de mostrar un error no descubierto antes. Descubrir un error no descubierto antes (éxito de la prueba).

4 Objetivos de la prueba Nuestro objetivo, es diseñar pruebas que sistemáticamente descubran diferentes tipos de errores con menor tiempo y esfuerzo. La prueba no puede asegurar que no existen errores sólo puede mostrar que existen defectos en el software.

5 Un software fácil de probar tiene las siguientes características:
Operatividad Observatividad Controlabilidad Capacidad de descomposición Simplicidad Estabilidad Facilidad de comprensión.

6 Principios de la prueba
Hacer un seguimiento de las pruebas hasta los requisitos del cliente. Plantear y diseñar las pruebas antes de generar ningún código. El 80% de todos los errores se centran sólo en el 20% de los módulos.

7 Principios de la prueba
Empezar las pruebas en módulos individuales y avanzar hasta probar el sistema entero. No son posibles las pruebas exhaustivas. Deben realizarse por un equipo independiente al equipo de desarrollo.

8 Diseño de casos de prueba
Un producto puede probarse siguiendo dos criterios: Conocimiento del funcionamiento del producto (Caja blanca). El conocimiento de la función específica para la que fue diseñado el producto (Caja negra).

9 Criterios de realización de pruebas
Para llevar a cabo la verificación del comportamiento de un sistema pueden servirse 2 criterios: Descendente Ascendente

10 Criterios de realización de pruebas
Prueba Descendente empieza a nivel de sistema, prueba los módulos y por ultimo las funciones que conforman. Utiliza un programa esclavo. Prueba Ascendente da inicio la verificación de funciones hasta llegar al nivel superior del sistema. Utiliza un programa conductor para cada modulo a probar.

11 Clase de pruebas Datos de prueba: Representativos (datos comunes)
Incorrectos, incompletos e incongruentes

12 Clases de pruebas

13 Diseño de casos de prueba
Prueba de Caja Negra Se realiza con el fin de asegurar que el producto es operativo. Prueba de Caja Blanca Se desarrolla con el fin de asegurar que todas las piezas del sistema tienen una operación interna que se ajusta a las especificaciones y que todos sus componentes internos se han aprobado en forma adecuada.

14 Pruebas de caja blanca Este método de casos de prueba usa los detalles procedimentales del programa. Se busca obtener casos de prueba que: Garanticen que se ejecuta por lo menos una vez todos los caminos independientes de cada módulo. Verificar las decisiones lógicas (V/F). Ejecutar las condiciones en sus límites. Ejecutar las estructuras internas de datos para asegurar su validez.

15 Pruebas de caja blanca Prueba de camino básico
Notación de grafo de flujo Complejidad ciclomática Obtención de casos de prueba Matrices de grafos Prueba de la estructura de control Prueba de condición Prueba de flujo de datos Prueba de bucles

16 Prueba del camino básico
 Es una técnica de prueba de caja blanca que nos permite obtener una medida de complejidad lógica. Con la medida de complejidad se genera un conjunto básico de caminos que se ejecutan por lo menos una vez durante la ejecución del programa.

17 Prueba del camino básico
Para representar el flujo de control de un programa se usa un grafo de flujo. Para determinar la complejidad lógica de un programa, se calcula la complejidad ciclomática que define el número de caminos independientes del conjunto básico. Un camino independiente es cualquier camino del programa que incluye nuevas instrucciones de un proceso o una nueva condición.

18 Obtención de casos de prueba
Dibujar el grafo correspondiente Determinar la complejidad. Determinar un conjunto básico de caminos linealmente independientes Preparar casos de prueba que forzarán a la ejecución de cada camino básico.

19 Métricas ´When you can measure what you are speaking about, y express it in numbers, you know something about it; but when you cannot ... your knowledge is of a meager y unsatisfactory kind.´ Lord Kelvin, 1889 ´You can‘t control what you can‘t measure......´ De Marco, 1982

20 ¿Qué es una métrica? Cualquier tipo de medida.
Ej. cms, litros, segundos, etc. Descripción de un atributo. Algunos tipos: De proyecto. Costos/plan de trabajo. Estimación. Puntos por función. Métricas de software.

21 Complejidad Es proporcional al número de errores en un segmento de código. “Entre más complejo, más susceptible a errores.” Se relaciona con el esfuerzo requerido para probar. “Entre más complejo, mayor atención para probar.”

22 Métricas de Complejidad “Complejidad Ciclomática”

23 Complejidad Ciclomática
Definición : Complejidad Ciclomática, v, es la medida de la complejidad lógica de un módulo “G” y el esfuerzo mínimo necesario para calificarlo. v es el número de rutas lineales independientes de un módulo “G”, por lo tanto es el número mínimo de rutas que deben probarse. Ventajas -Cuantifica la complejidad lógica. -Mide el esfuerzo mínimo para probar. -Guía el proceso de prueba. v(G)=10

24 Complejidad Ciclomática
Mide el número de decisiones lógicas dentro de un segmento de código (módulo). Es el número de rutas de prueba recomendado como mínimo a probar. Se utiliza durante las fases de diseño para mantener software: Fácil de entender, Fácil de probar, Fácil de modificar.

25 Ejercicio 1 Flujodiagramas Objetivos
Entender como se construye un flujodiagrama con base en el código fuente de un programa. Examinar como una herramienta de pruebas construye un flujodiagrama con base en el código fuente de un programa. McCabe IQ

26 Complejidad Ciclomática
Diagrama lógico 1,2 3 4 5 6 7 8 9 10 11 12 Sentencia; Select case case 1: case 2: case 3: Sentencia (End Case); If condición sentencia; Else nodo borde Nodos representan sentencias computables y los bordes representan la transferencia de control entre nodos.

27 Ejercicio 2 Cálculo de v(G) Objetivos
Entender como se calculan los valores de la complejidad ciclomática, utilizando los métodos formal, aristas y regiones.

28 Complejidad Ciclomática
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Cálculo de v(G): -Formal (nodos y bordes) v(G)=e-n+2 -Predicados (aristas) v(G)=p+1 -Regiones v(G)=R v(G)= =5

29 Complejidad Ciclomática
Calculo de v(G): -Formal (nodos y bordes) v(G)=e-n+2 -Predicate (aristas) v(G)=p+1 -Regiones v(G)=R v(G)= 4+1=5

30 Complejidad Ciclomática
Calculo de v(G): -Formal (nodos y bordes) v(G)=e-n+2 -Predicados (aristas) v(G)=p+1 -Regiones v(G)=R 1 2 3 4 5 v(G)= 5

31 Complejidad Ciclomática, v(G)
v(G) vs Errores 20 40 60 80 1 a 5 6 a 10 11 a 15 16 a 20 21 a 25 26 a 30 Mayor 30 Complejidad Ciclomática, v(G) Funciones Errores por función

32 Pruebas de la estructura de control
Existen tres pruebas de estructura de condición, que son: Prueba de condición, Prueba de estructura de datos y Pruebas de estructuras de control (bucles).

33 Pruebas de la estructura de control
La prueba de condición se centra en encontrar errores en condiciones lógicas en un módulo, aunque también puede detectar errores adicionales en el programa. En una condición se pueden dar los siguientes errores: Error de operador lógico Error en una variable lógica. Error en una condición simple o compuesta. Error en un operador relacional. Error en una expresión aritmética.

34 Pruebas de la estructura de control
La prueba de flujo de datos selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa. La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de condiciones. Hay cuatro tipos de estructuras de control: simples, concatenadas, anidadas y no estructuradas. De acuerdo al tipo de estructura es la prueba que se aplicará.

35 Pruebas de caja negra Métodos de prueba basados en grafos
Partición equivalente Análisis de valores límites Prueba de comparación

36 Pruebas de caja negra Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa. Con este tipo de pruebas se intenta encontrar: Funciones incorrectas o ausentes. Errores de interfaz Errorres en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicialización y terminación.

37 Pruebas de caja negra  Con la aplicación de esta técnica se obtiene un conjunto de pruebas que: Reduce el número de casos de pruebas Nos dicen algo sobre la presencia o ausencia de errores.

38 Partición equivalente
Una partición equivalente es un método de prueba de caja negra que : Divide el dominio de entrada de un programa en clases de datos. El diseño de casos de prueba para la partición equivalente se basa en la evaluación de las clases de equivalencia.

39 Análisis de valores límites
El análisis de valores límites (AVL) conduce a la elección de las pruebas que ejecuten los valores límites. Con esta técnica se complementa la partición equivalente. El  AVL  selecciona los casos de prueba con los valores extremos de una clase.

40 Prueba de comparación Esta técnica consiste en la comparacion de salidas de un mismo software pero de sus diferentes versiones. Cuando se han producido múltiples implementaciones de la misma especificación, a cada versión del  software se le proporciona como entrada los casos de prueba diseñados para la otra. Si las salidas de distintas versiones son idénticas entonces todas las implementaciones son correctas. Si la salida es diferente, se revisan las aplicaciones para determinar el defecto. Esta prueba no es infalible.

41 Estrategias de prueba del software
Prueba de unidad, Prueba de integración, Prueba de validación, Prueba del sistema.

42 Estrategias de prueba del software
Proporcionan un plano o guía para el desarrollador del software, para la organización de control de calidad y para el cliente . Es una guía que describe los pasos a llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir. Por lo tanto, cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de los casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos resultantes.

43 Etapas de un plan de pruebas
a. especificar los objetivos de las pruebas. b. determinar con precisión los criterios a seguir en su realización. c. Integrar al personal y los elementos necesarios para el desarrollo de las pruebas. d. Aplicación de la prueba o pruebas según los criterios seleccionados. e. evaluación de los resultados y consideraciones para llevar a cabo una nueva serie de pruebas.

44 Un enfoque estratégico para la prueba del software
Generalmente se proporciona una  plantilla  para la prueba con las siguientes características generales: La prueba comienza en el nivel de módulo y trabaja "hacia fuera", hacia la integración de todo el sistema basado en computadora. Se usa el enfoque “bottom-up”. En diferentes momentos se utilizarán diferentes técnicas de prueba La prueba la lleva a cabo el que desarrolla el software y (para grandes proyectos) un grupo de prueba independiente. La prueba y la depuración son actividades diferentes, pero la depuración se puede incluir en cualquier estrategia de prueba.

45 Verificación y validación
La verificación se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica. La validación se refiere a un conjunto diferente de actividades que aseguran que el software construído se ajusta a los requisitos del cliente.   La verificación y la validación comprenden un amplio rango de actividades de SQA que incluyen : Revisiones técnicas formales, Auditorias de configuración y calidad, Supervisión del rendimiento, Revisión de la base de datos, Análisis de los algoritmos, Prueba de desarrollo, Prueba de calificación, Prueba de instalación.

46 Prueba de unidad La prueba de unidad
Centra el proceso de verificación en la menor unidad del diseño del software - el módulo. Usando la descripción del diseño detallado como guía, se prueban caminos de control importantes, con el fin de descubrir errores dentro del ámbito del módulo. Está orientada a la caja blanca Puede llevarse a cabo en paralelo para múltiples módulos.

47 Consideraciones sobre la prueba de unidad
Las pruebas que se dan como parte de la prueba de unidad son: Se prueba la interfaz  del módulo .  Se examinan las estructuras de datos  locales.  Se prueban las condiciones límites .  Se ejercitan todos los caminos independientes  de la estructura de control. Y finalmente, se prueban todos los caminos de manejo de errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del módulo.

48 Prueba de integración Es una técnica sistemática para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.

49 Prueba de integración La integración incremental, El programa se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y de corregir, de esta forma es más probable que se puedan probar completamente los interfaces y se puede aplicar un enfoque de prueba sistemática. Hay estrategias de integración incremental denominadas: Integración descendente, Integración ascendente.

50 Prueba de integración A continuación se deben ensamblar o integrar los módulos para formar el paquete del software completo. La prueba de integración  se dirige a todos los aspectos asociados con el doble problema de verificación y de construcción del programa. Las técnicas que más prevalecen son las de diseño de casos de prueba de caja negra

51 Documentación de la prueba de integración
La especificación de prueba incluye un plan general para la integración del software y una descripción de las pruebas específicas. Es un resultado del proceso de ingeniería del software y forma parte de la configuración del software. El alcance de la prueba  resume las características funcionales, de rendimiento y de diseño interno específicas que van a a ser probadas. Se limita el esfuerzo de prueba, se describen los criterios de terminación de cada fase de prueba y se documentan las limitaciones del plan.

52 Documentación de la prueba de integración
El plan de prueba  describe la estrategia general para la integración. La prueba se divide en fases  y subfases  dirigidas a específicas características funcionales y del ámbito de información del software. En todas las fases de prueba se siguen los siguientes criterios con sus correspondientes pruebas: Integridad de interfaz, Validez funcional, Contenido de la información, Rendimiento.

53 Prueba de validación Tras la culminación de la prueba de la integración, el software está completamente ensamblado como un paquete, se han encontrado y corregido los errores de interfaz y puede comenzar una serie final de pruebas del software -La prueba de validación.

54 Criterios para la prueba de validación
La validación del software se consigue mediante una serie de pruebas de la caja negra que demuestran la conformidad con los requisitos. Un plan de prueba traza las pruebas que se han de llevar a cabo y un procedimiento de prueba define los casos de prueba específicos que se usarán para demostrar la conformidad con los requisitos.

55 Repaso de la configuración
Un elemento importante del proceso de validación es el repaso de la configuración. Tal repaso intenta asegurar que todos los elementos de la configuración del software se han desarrollado de forma adecuada, están catalogados y tienen el suficiente detalle para facilitar la fase de mantenimiento dentro del ciclo de vida del software.

56 Pruebas alfa y beta La prueba alfa es conducida por un cliente en el lugar de desarrollo. La prueba beta se lleva a cabo en uno o más lugares de cliente por los usuarios finales del software.

57 Prueba del sistema La prueba del sistema, realmente está constituida por una serie de pruebas diferentes cuyo propósito principal es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito distinto, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

58 Prueba de recuperación
La prueba de recuperación  es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Si la recuperación es automática hay que evaluar la correción de reinicialización, de los mecanismos de recuperación del estado del sistema, de la recuperación de datos y del rearranque. Si la recuperación requiere la intervención humana, hay que evaluar los tiempos medios de reparación para determinar si están dentro de unos límites aceptables.

59 Prueba de seguridad La prueba de seguridad  intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán.

60 Prueba de resistencia o de carga maxima
Las pruebas de resistencia  están diseñadas para enfrentar a los programas con situaciones anormales. En esencia, el sujeto que realiza la prueba de resistencia se pregunta: "¿A qué potencia puedo ponerlo a funcionar antes de que falle ?"

61 Prueba de rendimiento La prueba de rendimiento  está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proceso de prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los módulos individuales a medida que se llevan a cabo las pruebas de la caja blanca.

62 El arte de la depuración
La depuración aparece como una consecuencia de una prueba efectiva o sea, cuando un caso de prueba descubre un error, la depuración es el proceso que resulta en la eliminación del error. Aunque la depuración puede y debe ser un proceso ordendo, sigue teniendo mucho de arte.

63 El arte de la depuración
El proceso de depuración siempre tiene uno de dos resultados: (1) se encuentra la causa, se corrige y se elimina; o (2) no se encuentra la causa. En este último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un caso de prueba que ayude a validar sus sospechas y el trabajo vuelve hacia atrás a la corrección del error de una forma iterativa.

64 Bibliografia Análisis y diseño de sistemas de información (James A. Senn) Análisis y diseño de sistemas (Kendall&Kendall) Ingenieria de Software (Roger S. Pressman) Diseño de sistemas de informacion Teoria y Practica (John G. Burch)