Pruebas de software

1. Pruebas de software

2. Objetivos • Discutir las distinciones entre pruebas de validación y pruebas de defectos • Describir los principios del sistema y las pruebas de componentes • Describir las estrategias para generar casos de prueba de sistemas • Comprender las características esenciales de las herramientas utilizadas para la automatización de las pruebas.

3. Contenidos • Pruebas de sistema • Pruebas de componentes • Diseño de casos de prueba • Automatización de las pruebas

4. El proceso de pruebas • 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. • 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. Fases de pruebas Pruebas del componente Pruebas de integración Equipo de pruebas independiente Desarrollador de software

6. Pruebas de defectos • La meta de la prueba de defectos es descubrir defectos en los programas • Una prueba de defectos con éxito es aquella que causa que el programa se comporte de una manera anómala • Las pruebas muestran la presencia no la ausencia de defectos

7. Testing process goals • 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. • 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. Proceso de pruebas del software Datos de prueba Casos de pruebas Resultados de la prueba Informe de prueba Ejecutar el programa con los datos de prueba Diseñar casos de pruebas Preparar datos de prueba Comparar resultados con los datos de prueba

9. Políticas de pruebas • Sólo las pruebas exhaustivas pueden demostrar que un programa está libre de defectos. Sin embargo, las pruebas exhaustivas son imposibles. • 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.

10. Pruebas del sistema • Implica integrar componentes para crear un sistema o subsistema. • Puede implicar probar un incremento que va a entregarse al cliente. • 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. Pruebas de integración • Implica construir un sistema desde sus componentes y probarlo para encontrar problemas que pueden surgir de las interacciones de los componentes. • Integración descendente • Desarrollar el esqueleto del sistema y añadir componentes. • Integración ascendente • Integrar los componentes de infraestructura y después añadir componentes funcionales. • Para simplificar la localización de errores, los sistemas deberían ser integrados incrementalmente.

12. Pruebas de integración incrementales A T1 T1 A T1 T2 A B T2 T2 T3 B T3 B C T3 T4 C T4 D T5 Secuencia de prueba 1 Secuencia de prueba 2 Secuencia de prueba 3

13. Enfoque pruebas • Validación arquitectónica • Las pruebas de integración descendentes son mejores para descubrir errores en la arquitectura del sistema. • Demostración del sistema • Las pruebas de integración descendente permiten una demostración limitada en una etapa temprana en el desarrollo. • Prueba de implementación • Normalmente es más fácil con pruebas de integración ascendentes. • Pruebas de observación • Tiene problemas con varios enfoques. Puede requerirse código extra para observar las pruebas.

14. Pruebas de entrega • El proceso de probar la entrega de un sistema que será distribuido a los clientes • La meta principal es incrementar la confianza del proveedor en que el sistema cumplirá sus requerimientos. • 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. Pruebas de caja negra Entradas que provocan comportamiento anómalo Entrada de datos de prueba E e Sistema Salidas que revelan la presencia de defectos Resultados de las pruebas Se

16. Pauta de pruebas • 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. Escenario de pruebas

18. Pruebas de sistemas

19. Casos de uso • 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. • Desde un diagrama de secuencia asociado, pueden identificarse las entradas y salidas que deben crearse para las pruebas.

20. Diagrama de secuencia de recopilación de datos sobre el tiempo

21. Pruebas de rendimiento • Parte de las pruebas de entrega puede implicar probar las propiedades emergentes de un sistema, como el rendimiento y la fiabilidad. • 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. Pruebas de estrés • 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. • 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. • Estresar el sistema es particularmente importante para sistemas distribuidos que pueden exhibir una degradación severa cuando una red de trabajo se sobrecarga.

23. Pruebas de componentes • Las pruebas de componentes o pruebas de unidad son los procesos de prueba de componentes individuales aislados. • Es un proceso de prueba de defectos. • 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. Pruebas de clases de objetos • 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. • 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. Interfaz del objeto de la estación meteorológica W eatherStation identifier repor tW eather () calibrate (instruments) test () star tup (instruments) shutdown (instruments)

26. Pruebas de una estación meteorológica • Necesita definir los casos de pruebas para reportWeather, calibrate, test, startup and shutdown. • 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 • Por ejemplo: • Waiting -> Calibrating -> Testing -> Transmitting -> Waiting

27. Pruebas de interfaces • El objetivo es detectar fallos debidos a errores de la interfaz o suposiciones inválidas sobre las interfaces. • Es particularmente importante para el desarrollo orientado a objetos ya que los objetos se definen por sus interfaces.

28. Pruebas de interfaces Casos de pruebas A B C

29. Tipos de interfaz • Interfaces de parámetro • Datos que pasan de un procedimiento a otro. • Interfaces de memoria compartidas • Se comparte un bloque de memoria entre procesos o funciones • Interfaces procedurales • Un subsistema encapsula un conjunto de procedimientos que pueden ser llamados por otros componentes. • Interfaces de paso de mensajes • Los subsistemas piden servicios de otros subsistemas.

30. Errores de interfaz • 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. • No comprensión de la interfaz • El componente que realiza la llamada hace suposiciones incorrectas sobre el comportamiento del componente llamado que. • Errores temporales • El objeto que llama y el llamado operan a diferentes velocidades y se accede a información no actualizada.

31. Pautas para la prueba de interfaces • 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 • Probar siempre los parámetros punteros con punteros nulos. • Diseñar pruebas que provoquen el fallo del componente. • Utilizar pruebas de estrés en los sistemas de paso de mensajes • En sistemas de memoria compartida, variar el orden en que se activan los componentes.

32. Diseño de casos de pruebas • Implica diseñar casos de pruebas (entradas y salidas) utilizadas para probar el sistema. • 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. • Diseñar aproximaciones: • Pruebas basadas en requerimientos; • Pruebas de particiones; • Pruebas estructurales.

33. Requerimientos basados en pruebas • Un principio general de la ingeniería de requerimientos es que los requerimientos deberían ser estables. • 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. Requerimientos LIBSYS

35. Pruebas LIBSYS

36. Pruebas de particiones • 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. • 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. • Deberían escogerse casos de pruebas de cada partición.

37. Particiones de equivalencia Entradas inválidas Salidas válidas S ystem Sistema salidas

38. Particiones de equivalencia 3 1 1 4 7 1 0 Menor que 4 Entre 4 y 10 Más de 10 Número de valores de entrada 9999 1 00000 1 0000 5 0000 99999 Menor que 10.000 Entre Más de99999 10000 y 99999 Valores de entrada

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 T’FIRST <= T’LAST 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, T’FIRST >= i <= T’LAST, T (i) = Key ))

40. Rutina de búsqueda– particiones de entradas • Entradas que se ajustan a las precondiciones. • Entradas donde una precondición no encaja. • Entradas en las que el elemento clave es un miembro del vector. • Entradas en las que el elemento clave no es un miembro del vector.

41. Pautas de pruebas (secuencias) • Probar el software con secuencias que tienen un único valor. • Utilizar secuencias de diferentes tamaños en diferentes pruebas. • Derivar pruebas para que se acceda a los elementos primero, intermedio y último de la secuencia. • Probar con secuencias de longitud cero.

42. Rutina de búsqueda– particiones de entrada

43. Pruebas estructurales • A veces también llamadas pruebas de caja blanca • 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. • El objetivo es ejercitar todas las sentencias del programa (no todas las combinaciones de caminos)

44. Pruebas estructurales Datos de prueba Pruebas Deriva en Código del componente Salidas de prueba

45. Búsqueda binaria– particiones equivalentes • Precondiciones satisfechas, elemento clave en vector • Precondiciones satisfechas, elemento clave no está en vector • Precondiciones insatisfechas, elemento clave en vector. • Precondiciones insatisfechas, elemento clave no está en vector. • Vector de entrada tiene un único valor. • Vector de entrada tiene un número par de valores. • Vector que tiene un número impar de valores.

46. Particiones equivalentes de búsqueda binaria Límites de la clase de equivalencia v Elementos < Mid Elementos > Mid Punto medio

47. Búsqueda binaria– casos de pruebas

48. Prueba de caminos • 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. • 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. • Las sentencias con condiciones son, por lo tanto, nódulos en el gráfico de flujo.

49. Gráfico de flujo para búsqueda binaria

50. Caminos independientes • 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 • 1, 2, 3, 4, 5, 14 • 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, … • 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, … • Los casos de pruebas deberían derivarse para que todos estos caminos se ejecuten • Puede usarse un analizador dinámico del programa para comprobar los caminos que han sido ejecutados