La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Pruebas de software.

Presentaciones similares


Presentación del tema: "©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Pruebas de software."— Transcripción de la presentación:

1 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Pruebas de software

2 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 2 Objetivos l Discutir las distinciones entre pruebas de validación y pruebas de defectos l Describir los principios del sistema y las pruebas de componentes l Describir las estrategias para generar casos de prueba de sistemas l Comprender las características esenciales de las herramientas utilizadas para la automatización de las pruebas.

3 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 3 Contenidos l Pruebas de sistema l Pruebas de componentes l Diseño de casos de prueba l Automatización de las pruebas

4 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 4 El proceso de pruebas l Pruebas de componentes Prueba de los componentes individuales del programa; Normalmente es responsabilidad del desarrollador de componentes (excepto a veces en sistemas críticos); Las pruebas se derivan de la experiencia del desarrollador. l Pruebas del sistema Prueba de grupos de componentes integrados para crear un sistema o un subsistema; La responsabilidad es de un equipo de pruebas independiente; Las pruebas se basan en la especificación de un sistema.

5 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 5 Fases de pruebas Pruebas del componente Pruebas de integración Desarrollador de software Equipo de pruebas independiente

6 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 6 Pruebas de defectos l La meta de la prueba de defectos es descubrir defectos en los programas l Una prueba de defectos con éxito es aquella que causa que el programa se comporte de una manera anómala l Las pruebas muestran la presencia no la ausencia de defectos

7 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 7 Testing process goals l Pruebas de validación Demostrar al desarrollador y el cliente del sistema que el software cumple sus requerimientos; Unas pruebas con éxito muestran que el sistema funciona como se pretendía. l Pruebas de defectos Descubrir fallos o defectos in el software donde su comportamiento es incorrecto o no se ajusta a su especificación; Una prueba con éxito es aquella que hace que el sistema no rinda de forma correcta y por tanto expone un defecto en el sistema.

8 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 8 Proceso de pruebas del software Diseñar casos de pruebas Preparar datos de prueba Ejecutar el programa con los datos de prueba Comparar resultados con los datos de prueba Casos de pruebas Datos de prueba Resultados de la prueba Informe de prueba

9 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 9 l Sólo las pruebas exhaustivas pueden demostrar que un programa está libre de defectos. Sin embargo, las pruebas exhaustivas son imposibles. l Las políticas de pruebas definen la aproximación que debe usarse al seleccionar las pruebas del sistema: Deberían ser probadas todas las funciones a las que se ha accedido a través de menú; Deberían comprobarse las combinaciones de funciones a las que se ha accedido a través del mismo menú; Donde se requiere la entrada del usuario, todas las funciones deben ser comprobadas con entradas correctas e incorrectas. Políticas de pruebas

10 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 10 Pruebas del sistema l Implica integrar componentes para crear un sistema o subsistema. l Puede implicar probar un incremento que va a entregarse al cliente. l Dos fases: Pruebas de integración- El equipo de pruebas tiene acceso al código fuente del sistema. El sistema es probado al tiempo que los componentes se integran en éste. Pruebas de entregas - El quipo de pruebas prueba el sistema completo que va a ser entregado como una «caja negra»

11 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 11 Pruebas de integración l Implica construir un sistema desde sus componentes y probarlo para encontrar problemas que pueden surgir de las interacciones de los componentes. l Integración descendente Desarrollar el esqueleto del sistema y añadir componentes. l Integración ascendente Integrar los componentes de infraestructura y después añadir componentes funcionales. l Para simplificar la localización de errores, los sistemas deberían ser integrados incrementalmente.

12 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 12 Pruebas de integración incrementales T3 T2 T1 T4 T5 A B C D T2 T1 T3 T4 A B C T1 T2 T3 A B Secuencia de prueba 1Secuencia de prueba 2Secuencia de prueba 3

13 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 13 Enfoque pruebas l Validación arquitectónica Las pruebas de integración descendentes son mejores para descubrir errores en la arquitectura del sistema. l Demostración del sistema Las pruebas de integración descendente permiten una demostración limitada en una etapa temprana en el desarrollo. l Prueba de implementación Normalmente es más fácil con pruebas de integración ascendentes. l Pruebas de observación Tiene problemas con varios enfoques. Puede requerirse código extra para observar las pruebas.

14 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 14 Pruebas de entrega l El proceso de probar la entrega de un sistema que será distribuido a los clientes l La meta principal es incrementar la confianza del proveedor en que el sistema cumplirá sus requerimientos. l La pruebas de entrega normalmente son pruebas de caja negra o funcionales Están basadas sólo en la especificación del sistema; Los probadores no tienen conocimientos de la implementación del sistema;

15 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 15 Pruebas de caja negra E e Entrada de datos de prueba SeResultados de las pruebas Sistema Entradas que provocan comportamiento anómalo Salidas que revelan la presencia de defectos

16 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 16 Pauta de pruebas l Las pautas de pruebas son pistas para ayudar al equipo de pruebas a elegir las pruebas que revelarán defectos en el sistema Escoger entradas que fuercen al sistema a generar todos los mensajes de error; Diseñar entradas que hacen que los búferes de entrada se desborden; Repetir la misma entrada o serie de entradas varias veces; Forzar a que se generen las salidas inválidas; Forzar los resultados de los cálculos para que sean demasiado grandes o demasiado pequeños.

17 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 17 Escenario de pruebas

18 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 18 Pruebas de sistemas

19 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 19 Casos de uso l Los casos de uso pueden ser la base de derivar las pruebas para un sistema. Ayudan a identificar las operaciones que van a probarse y ayuda a diseñar los casos de pruebas requeridos. l Desde un diagrama de secuencia asociado, pueden identificarse las entradas y salidas que deben crearse para las pruebas.

20 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 20 Diagrama de secuencia de recopilación de datos sobre el tiempo

21 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 21 Pruebas de rendimiento l Parte de las pruebas de entrega puede implicar probar las propiedades emergentes de un sistema, como el rendimiento y la fiabilidad. l Las pruebas de rendimiento normalmente implican planificar una serie de pruebas donde la carga se incrementa a un ritmo constante hasta que el rendimiento del sistema llega a ser inaceptable.

22 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 22 Pruebas de estrés l Ejercita el sistema por encima de su carga máxima de diseño. Estresar el sistema a veces provoca que los defectos salgan a la luz. l Estresar el sistema prueba el comportamiento de fallos. Los sistemas no deberían fallar catastróficamente. Las pruebas de estrés comprueban las pérdidas inaceptables de servicio o datos. l Estresar el sistema es particularmente importante para sistemas distribuidos que pueden exhibir una degradación severa cuando una red de trabajo se sobrecarga.

23 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 23 Pruebas de componentes l Las pruebas de componentes o pruebas de unidad son los procesos de prueba de componentes individuales aislados. l Es un proceso de prueba de defectos. l Los componentes pueden ser: funciones individuales o métodos dentro de un objeto; clases de objetos con varios atributos y métodos; Componentes compuestos con interfaces definidas utilizadas para acceder a su funcionalidad.

24 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 24 Pruebas de clases de objetos l Completar la cobertura de pruebas de una clase implica Probar todas las operaciones asociadas con un objeto; establecer e interrogar todos los atributos de los objetos; Ejercitar el objeto en todos los estados posibles. l La herencia hace que sea más difícil diseñar pruebas de clases de objetos ya que no se localiza la información que se va a probar.

25 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 25 Interfaz del objeto de la estación meteorológica identifier reportWeather () calibrate (instruments) test () startup (instruments) shutdown (instruments) WeatherStation

26 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 26 Pruebas de una estación meteorológica l Necesita definir los casos de pruebas para reportWeather, calibrate, test, startup and shutdown. l Utilizando un modelo de estado, identifica secuencias de transiciones de estado que se van a probar y las secuencias de estado que causan estas transiciones l Por ejemplo: Waiting -> Calibrating -> Testing -> Transmitting -> Waiting

27 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 27 l El objetivo es detectar fallos debidos a errores de la interfaz o suposiciones inválidas sobre las interfaces. l Es particularmente importante para el desarrollo orientado a objetos ya que los objetos se definen por sus interfaces. Pruebas de interfaces

28 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 28 Pruebas de interfaces B C Casos de pruebas A

29 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 29 Tipos de interfaz l Interfaces de parámetro Datos que pasan de un procedimiento a otro. l Interfaces de memoria compartidas Se comparte un bloque de memoria entre procesos o funciones l Interfaces procedurales Un subsistema encapsula un conjunto de procedimientos que pueden ser llamados por otros componentes. l Interfaces de paso de mensajes Los subsistemas piden servicios de otros subsistemas.

30 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 30 Errores de interfaz l Mal uso de la interfaz Un componente llama a otro componente y comete un error en la utilización de su interfaz. P.Ej.: parámetros en el orden incorrecto. l No comprensión de la interfaz El componente que realiza la llamada hace suposiciones incorrectas sobre el comportamiento del componente llamado que. l Errores temporales El objeto que llama y el llamado operan a diferentes velocidades y se accede a información no actualizada.

31 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 31 Pautas para la prueba de interfaces l Diseñar los parámetros de forma que los parámetros para un procedimiento al que se ha llamado estén en los extremos de sus rangos l Probar siempre los parámetros punteros con punteros nulos. l Diseñar pruebas que provoquen el fallo del componente. l Utilizar pruebas de estrés en los sistemas de paso de mensajes l En sistemas de memoria compartida, variar el orden en que se activan los componentes.

32 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 32 Diseño de casos de pruebas l Implica diseñar casos de pruebas (entradas y salidas) utilizadas para probar el sistema. l La meta del diseño de casos de pruebas es crear un conjunto de pruebas que sean efectivas en las pruebas de validación y defectos. l Diseñar aproximaciones: Pruebas basadas en requerimientos; Pruebas de particiones; Pruebas estructurales.

33 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 33 Requerimientos basados en pruebas l Un principio general de la ingeniería de requerimientos es que los requerimientos deberían ser estables. l Las pruebas basadas en requerimientos son técnicas de pruebas de validación donde se considera cada requerimiento y se deriva un conjunto de pruebas para ese requerimiento.

34 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 34 Requerimientos LIBSYS

35 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 35 Pruebas LIBSYS

36 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 36 Pruebas de particiones l Los datos de entrada y los resultados de salida con frecuencia se dividen en diferentes clases en las que todos los miembros de una clase están relacionados. l Cada una de estas clases es una partición de equivalencia o dominio en la que el programa se comporta de forma equivalente para cada miembro de la clase. l Deberían escogerse casos de pruebas de cada partición.

37 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 37 Particiones de equivalencia System salidas Entradas inválidas Salidas válidas Sistema

38 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 38 Particiones de equivalencia Entre y Menor que Más de Valores de entrada Entre 4 y 10Menor que 4Más de Número de valores de entrada

39 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 39 Especificación de rutina de búsqueda procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- la secuencia tiene al menos un elemento TFIRST <= TLAST Post-condition -- el elemento se encuentra y es referenciado por L ( Found and T (L) = Key) or -- el elemento no está en la secuencia ( not Found and not (exists i, TFIRST >= i <= TLAST, T (i) = Key ))

40 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 40 l Entradas que se ajustan a las precondiciones. l Entradas donde una precondición no encaja. l Entradas en las que el elemento clave es un miembro del vector. l Entradas en las que el elemento clave no es un miembro del vector. Rutina de búsqueda– particiones de entradas

41 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 41 Pautas de pruebas (secuencias) l Probar el software con secuencias que tienen un único valor. l Utilizar secuencias de diferentes tamaños en diferentes pruebas. l Derivar pruebas para que se acceda a los elementos primero, intermedio y último de la secuencia. l Probar con secuencias de longitud cero.

42 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 42 Rutina de búsqueda– particiones de entrada

43 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 43 l A veces también llamadas pruebas de caja blanca l Derivación de casos de pruebas de acuerdo a la estructura del programa. El conocimiento del programa se utiliza para identificar casos de pruebas adicionales. l El objetivo es ejercitar todas las sentencias del programa (no todas las combinaciones de caminos) Pruebas estructurales

44 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 44 Pruebas estructurales Código del componente Salidas de prueba Datos de prueba Deriva en Pruebas

45 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 45 l Precondiciones satisfechas, elemento clave en vector l Precondiciones satisfechas, elemento clave no está en vector l Precondiciones insatisfechas, elemento clave en vector. l Precondiciones insatisfechas, elemento clave no está en vector. l Vector de entrada tiene un único valor. l Vector de entrada tiene un número par de valores. l Vector que tiene un número impar de valores. Búsqueda binaria– particiones equivalentes

46 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 46 Particiones equivalentes de búsqueda binaria Punto medio Elementos < MidElementos > Mid Límites de la clase de equivalenciav

47 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 47 Búsqueda binaria– casos de pruebas

48 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 48 Prueba de caminos l El objetivo de las pruebas de caminos es asegurar que el conjunto de casos de pruebas es tal que cada camino es ejecutado a través del programa al menos una vez. l El punto de comienzo para la prueba de caminos es un gráfico de flujo del programa que muestra los nódulos que representan las decisiones del programa y arcos que representan el flujo de control. l Las sentencias con condiciones son, por lo tanto, nódulos en el gráfico de flujo.

49 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 49 Gráfico de flujo para búsqueda binaria

50 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 50 l 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 l 1, 2, 3, 4, 5, 14 l 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, … l 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, … l Los casos de pruebas deberían derivarse para que todos estos caminos se ejecuten l Puede usarse un analizador dinámico del programa para comprobar los caminos que han sido ejecutados Caminos independientes

51 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 51 Automatización de las pruebas l Probar es una fase del proceso cara. Probar bancos de trabajo proporciona cierta variedad de herramientas para reducir el tiempo necesario y los costes totales de las pruebas. l Sistemas como Junit soportan la ejecución automática de pruebas. l La mayoría de los bancos de trabajo son sistemas abiertos porque las necesidades de pruebas son específicas de la organización. l A veces es difícil integrar con un diseño cerrado y bancos de trabajo.

52 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 52 Un banco de trabajos de pruebas Analizador dinámico Programa en prueba Resultado de la prueba Predicciones de pruebas Comparador de archivos Informe de ejecución Simulador Código fuente Administrado r de pruebas Datos de prueba Oráculo Generador De datos de prueba Especificación Generador de informes Informe de los resultados de la prueba

53 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 53 Adaptación de bancos de trabajo de pruebas l Se pueden desarrollar scripts para los simuladores de interfaz del usuario y patrones para los generadores de datos de pruebas. l Las salidas de pruebas pueden tener que estar preparadas manualmente para su comparación. l Podrían desarrollarse comparadores de archivos para un propósito especial.

54 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 54 Puntos clave l Las pruebas pueden demostrar la presencia de fallos en un sistema; no puede probar que no quedan fallos. l Los desarrolladores de un componente son responsables de las pruebas del componente; Las pruebas del sistema son responsabilidad de un equipo aparte. l La integración de pruebas es comprobar los incrementos del sistema; las pruebas a entregar implican probar que un sistema que va a ser entregado a un cliente. l Utilizar la experiencia y las pautas para diseñar casos de pruebas en pruebas de defectos.

55 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 55 Puntos clave l Las pruebas de interfaz están diseñadas para descubrir defectos en las interfaces de componentes compuestos. l La partición de equivalencia es una forma de descubrir casos de pruebas : todos los casos en una partición deberían comportarse del mismo modo. l El análisis estructural depende del análisis de un programa y las pruebas de derivación del análisis. l La automatización de pruebas reduce los costes de pruebas apoyando los procesos de pruebas con varias herramientas de software


Descargar ppt "©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Pruebas de software."

Presentaciones similares


Anuncios Google