PRUEBAS DE SISTEMAS. Hungría Berbesí UNEFA Ingeniería de Sistemas

Transcripción

1 PRUEBAS DE SISTEMAS Hungría Berbesí UNEFA Ingeniería de Sistemas

2

3 Técnicas de prueba El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de desarrollo,...). Debido a que estos errores se deben a nuestra habilidad innata de provocar errores, tenemos que incorporar una actividad que garantice la calidad del software. En este capítulo estudiaremos: Fundamentos de la prueba del software, que definen los objetivos fundamentales de la fase de prueba. Diseño de casos de prueba, que se centra en un conjunto de técnicas para que satisfagan los objetivos globales de la prueba.

4 Verificación: El proceso de evaluación de un sistema (o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase Validación: El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.

5 Pruebas :«una actividad en la cual un sistema o uno de sus (test): componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto» Caso de prueba (test case): «un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular» Defecto (defect, fault, «bug»): «un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa»

6 Equivocación (mistake) La equivocación puede ser definida como: «Una acción del ser humano que produce un resultado incorrecto.» [ Error (error) El error puede ser definido como: «La diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o teóricamente correcto.» Fallo (failure) Un fallo puede ser definido como: «La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.»

7 Defecto (defect, fault, bug) Un defecto puede ser definido como: -«Un paso, proceso o definición de dato incorrecto en un programa de computadora. El resultado de una equivocación.» -«Una variación de una característica deseada del producto.»

8 : Relación entre error, defecto y fallo.

9 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE En la etapa de prueba del software se crean una serie de casos de prueba que intentan "destruir" el software desarrollado. La prueba requiere que se descarten ideas preconcebidas sobre la "calidad o corrección" del software desarrollado.

10 1.1. Objetivos de la prueba La prueba es un 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 El objetivo es diseñar casos de prueba que, sistemáticamente, saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo. La prueba no puede asegurar la ausencia de errores; sólo puede demostrar que existen defectos en el software.

11 El proceso de prueba tiene dos entradas: Configuración del software: Incluye la especificación de requisitos del software, la especificación del diseño y el código fuente Configuración de prueba: Incluye un plan y un procedimiento de prueba Si el funcionamiento del software parece ser correcto y los errores encontrados son fáciles de corregir, podemos concluir con que: La calidad y la fiabilidad del software son aceptables, o que Las pruebas son inadecuadas para descubrir errores serios

12 Diseño de casos de prueba Se trata de diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y de tiempo. Cualquier producto de ingeniería se puede probar de dos formas: Pruebas de caja negra: Realizar pruebas de forma que se compruebe que cada función es operativa. Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operación interna se ajusta a las especificaciones, y que todos los componentes internos se han probado de forma adecuada.

13

14

15 En la prueba de la caja negra, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta. En la prueba de caja blanca se realiza un examen minucioso de los detalles procedimentales, comprobando los caminos lógicos del programa, comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos.

16 Flujo del Proceso de Prueba

17 Métodos de prueba de caja blanca Algunos de los métodos empleados en las pruebas de caja blanca son los siguientes: Prueba del camino básico es una técnica propuesta inicialmente por Tom McCabe, la cual le permite al diseñador de casos de prueba obtener 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. Los casos de prueba obtenidos del conjunto básico garantizarán que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

18 Algunos elementos y conceptos utilizados alrededor de éste método son los siguientes -Grafo de flujo o grafo del programa: representa el flujo de control lógico de un programa y se utiliza para trazar más fácilmente las caminos de éste. (Cada nodo representa una o más sentencias procedimentales y cada arista representa el flujo de control) -Complejidad ciclomática: es una métrica de software que proporciona una medición cuantitativa de la complejidad lógica de un programa. Cuando se usa en el contexto de las pruebas, el cálculo de la complejidad ciclómatica representa el número de caminos independientes del conjunto básico de un programa. Esta medida ofrece al probador de software un límite superior para el número de pruebas que debe realizar para garantizar que se ejecutan por lo menos una vez cada sentencia. -Camino independiente: cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condición.

19 De forma general, los pasos que se debe seguir para la obtención de los casos de prueba en este método, son los siguientes : 1.Emplear el diseño o el código para elaborar el grafo de flujo.2.determinar la complejidad ciclomática del grafo de flujo.3.determinar un conjunto básico de caminos linealmente independientes.4.preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico.

20 Prueba de la estructura de control dentro de éste tipo de prueba se contempla el método del camino básico mencionado anteriormente pero además existen otras pruebas asociadas que permiten ampliar la cobertura de la prueba y mejorar su calidad. Estas son:

21 Prueba de bucles Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software, por lo que tenemos que prestarles una atención especial a la hora de realizar la prueba del software. La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles. Se pueden definir cuatro tipos de bucles diferentes: Bucles simples Bucles concatenados Bucles anidados Bucles no estructurados

22 PRUEBA DE LA CAJA NEGRA Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa. Los casos de prueba de la caja negra pretenden demostrar que: Las funciones del software son operativas La entrada se acepta de forma correcta Se produce una salida correcta La integridad de la información externa se mantiene

23 Prueba de partición equivalente Este método de prueba de caja negra divide el dominio de entrada de un programa en clases de datos, a partir de las cuales deriva los casos de prueba. Cada una de estas clases de equivalencia representa a un conjunto de estados válidos o inválidos para las condiciones de entrada Identificación de las clases de equivalencia Se identifican clases de equivalencia válidas e inválidas con la siguiente tabla

24 Condiciones externas Clases de equivalencia válidas Clases de equivalencia inválidas A continuación se siguen estas directrices: Si una condición de entrada especifica un rango de valores (p.e, entre 1 y 999), se define una CEV (1 <= valor <= 999) y dos CEI (valor < 1 y valor > 999) Si una CE requiere un valor específico (p.e., el primer carácter tiene que ser una letra), se define una CEV (una letra) y una CEI (no es una letra) Si una CE especifica un conjunto de valores de entrada, se define una CEV para cada uno de los valores válidos, y una CEI (p.e., CEV para "Moto", "Coche" y "Camión", y CEI para "Bicicleta") Si una condición de entrada especifica el número de valores (p.e., una casa puede tener uno o dos propietarios), identificar una CEV y dos CEI (0 propietarios y 3 propietarios)

25 Identificación de casos de prueba Seguir estos pasos Asignar un número único a cada clase de equivalencia Escribir casos de prueba hasta que sean cubiertas todas las CEV, intentando cubrir en cada casos tantas CEV como sea posible Para cada CEI, escribir un caso de prueba, cubriendo en cada caso una CEI

26 Pruebas de unidad: La prueba de unidad se centra en el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito del módulo. La prueba de unidad hace uso intensivo de las técnicas de prueba de caja blanca.

27 Prueba de integración: El objetivo es coger los módulos probados en la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Hay dos formas de integración: Integración no incremental: Se combinan todos los módulos por anticipado y se prueba todo el programa en conjunto. Integración incremental: El programa se construye y se prueba en pequeños segmentos. En la prueba de integración el foco de atención es el diseño y la construcción de la arquitectura del software.

28 Prueba de Arquitectura y Aplicaciones La arquitectura cliente/servidor representa un importante desafío para quienes prueban el software. La naturaleza distribuida de los entornos cliente/servidor, los aspectos de desempeño relacionados con el proceso de transacción, la posible presencia de varias plataformas de hardware diferentes, la complejidad de la comunicación en red, la necesidad de servir varios clientes desde una base de datos centralizada (o, en algunos casos, distribuida) y los requisitos de coordinación impuestos al servidor se combinan para que la prueba de las arquitecturas de software cliente/servidor resulte considerablemente más difícil que la prueba de aplicaciones independientes.

29 Pruebas de funcionalidad de la aplicación: la aplicación se prueba de manera independiente. Pruebas de servidor: se prueban funciones de coordinación y manejo de datos del servidor. También se considera el desempeño del servidor (tiempo de respuesta y procesamiento de los datos). Pruebas de base de datos: se prueba la exactitud e integridad de los datos almacenados en el servidor. Se examinan las transacciones que realizaron las aplicaciones de cliente para asegurar que los datos se almacenan, actualizan y recuperan apropiadamente. También se prueba la función de archivado

30 Pruebas de transacción: se crea una serie de pruebas para asegurar que cada clase de transacciones se procesa de acuerdo con sus requisitos. Las pruebas se concentran en determinar si es correcto el procesamiento y en aspectos de desempeño. Pruebas de comunicaciones de red: con estas pruebas se verifica que la comunicación entre los nodos de la red ocurre de manera correcta y que el paso de mensajes, transacciones y el tráfico de la red relacionado se realiza sin errores. También es posible realizar pruebas de seguridad de la red como parte de estas pruebas.

31 Prueba del sistema: Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Algunas de estas pruebas son:

32 Prueba de validación: Proporciona una seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Además, valida los requerimientos establecidos comparándolos con el sistema que ha sido construido. Durante la validación se usan exclusivamente técnicas de prueba de caja negra. Prueba de recuperación: Fuerza un fallo del software y verifica que la recuperación se lleva a cabo apropiadamente. Prueba de seguridad: Verificar los mecanismos de protección. Prueba de resistencia: Enfrenta a los programas a situaciones anormales. Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecución. Prueba de instalación: Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o continuas interrupciones.

33 Pruebas de regresión: Las pruebas de regresión son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que: Los defectos identificados en la ejecución anterior de la prueba se ha corregido. Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores. La prueba de regresión puede implicar la re-ejecución de cualquier tipo de prueba. Normalmente, las pruebas de regresión se llevan a cabo durante cada iteración, ejecutando otra vez las pruebas de la iteración anterior.

34

35 Pruebas alfa y beta Cuando se construye software a medida para un cliente, se lleva a cabo una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. La mayoría de los desarrolladores de productos de software llevan a cabo un proceso denominado pruebas alfa y beta para descubrir errores que parezca que sólo el usuario final puede descubrir.

36 Pruebas de aceptación Prueba alfa: se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. Prueba beta: se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador

37 Qué vamos a hacer para encontrar y corregir errores en nuestro software?