Pruebas de Software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Transcripción

1 Pruebas de Software

2 Objetivos de las Pruebas Demostrar al desarrollador y al cliente que el software satisface los requerimientos. Descubrir defectos en el software en que el comportamiento de éste es incorrecto, no deseable o no cumple su especificación.

3 El proceso de Pruebas Pruebas de Componentes: Pruebas a componentes individuales de un programa. Generalmente encargados al desarrollador del componente Las pruebas son derivadas de la experiencia del desarrollador Pruebas del Sistema: Pruebas de componentes integrados para crear subsistemas. Responsabilidad de un grupo independiente de pruebas. Las pruebas son basadas en la especificación del sistema

4 El proceso de Pruebas Pruebas del componente Desarrollador de software Pruebas del integración Equipo de pruebas Independiente

5 El proceso de Pruebas Las pruebas no pueden demostrar que el software está libre de errores o que se comporta en todo momento como está especificado. Las pruebas solo pueden demostrar la presencia de errores, no la ausencia de ellos. Dijsktra, et al Por tanto el objetivo de las pruebas de software es convencer a los desarrolladores y a los clientes que el software es suficientemente bueno para su uso operacional.

6 Pruebas de Defectos Tiene como objeto descubrir lo defectos de un programa (En ejecución). Una prueba de defectos exitosa es aquella que provoca comportamientos extraños no planeados. Las pruebas detectan la presencia de errores no su ausencia.

7 Proceso de Pruebas de Software

8 Tećnicas de Pruebas Caja blanca o pruebas estructurales El conocimiento del diseño interno del software se usa para desarrollar los casos de Pruebas Caja negra o pruebas funcionales Los casos de prueba son diseñados basados sólo en la especificación externa del software Pruebas basadas en escenarios o casos de uso Actuar como un usuario final y crear escenarios reales para detectar errores

9 Pruebas de Caja Negra

10 Pruebas Unitarias Descripción Su propósito es encontrar errores en la lógica, datos o algoritmos en componentes o subsistemas individuales Realizado por los desarrolladores del componente Técnica de prueba: Caja blanca

11 Pruebas Unitarias Guías para generar casos de prueba Tratar de detectar errores en los algoritmos y la lógica Tratar de detectar errores en la manipulación de las estructuras de datos Tratar de detectar errores en el llamado a otros módulos Identificar todos los caminos posibles del módulo y tratar de hacer casos de prueba que los cubran Tratar de detectar errores usando datos límites

12 Pruebas de Unitarias También conocidas como pruebas de componentes Es una prueba de detección de defectos. Un componente puede ser: Funciones o métodos Clases completas. Componentes compuestos con interfaces definidas usadas para acceder a su funcionalidad.

13 Políticas de Pruebas Únicamente una revisión exhaustiva del software puede garantizar la ausencia de errores, pero esto es imposible. Las políticas de pruebas definen las partes del software a probar, ej: Todas las funcionalidades accedidas por menú deben ser probadas. Donde se realice entrada de datos, se deben realizar pruebas con entrada correcta e incorrecta.

14 Pruebas del Sistema Pruebas de Integración: El equipo de pruebas tiene acceso al código fuente, el sistema es probado como componentes integrados. Pruebas de entrega: El equipo de pruebas prueba el sistema como una caja negra. El equipo de pruebas se encarga de demostrar si el sistema funciona o no funciona Pruebas de Regresión: Repetición de pruebas después de un cambio significativo

15 Pruebas de Integración Involucra construir el sistema desde sus componentes y detectar problemas derivados de su interacción. Integración Top-Down: Se construye un esqueleto del sistema y ubican los componentes en este. Integración Botton-Up: Se integran los componentes agrupándolos de manera en la que este relacionados. Para facilitar la localización de errores estas integraciones deben realizarse de manera incremental

16 Pruebas de Integración incremental

17 Aproximaciones de Pruebas Validación arquitectural: Top-Down. Demostración del sistema: Top-Down. Pruebas de Implementación: Button-Up. Pruebas de Observación: Se utilizan ambos enfoques de integración, pero se puede requerir código extra.

18 Pruebas de Lanzamiento o liberación El proceso de probar un software antes de su lanzamiento es compartido con los clientes El principal objetivo es incrementar la confianza que tiene el cliente con el software. Por lo general se realizar por la técnicas de prueba de caja negra (El probadores no conocen como se implemento el sistema). Las pruebas están basadas en la especificación del problema

19 Pruebas por escenarios Para validar que el sistema satisface los requerimientos, la mejor aproximación basada en escenarios y se desarrollan casos de prueba a partir de estos escenarios. Un escenario se lo puede definir como una posible situación de la vida real que se puede presentar en la ejecuciòn del software. Se pueden hacer casos de pruebas para diferentes escenarios y que diferentes escenarios pueden corresponder a un mismo requerimiento.

20 Guías de Pruebas Elegir entradas que fuerzan el sistema genere todos los mensajes de error. Diseñar entradas que hacen que los bufferes de entrada se desborden. Repetir la entrada o series de entradas varias veces. Forzar a que se generen salidas inválidas. Forzar los resultados de los cálculos para que sean demasiado grande o demasiado pequeños.

21 Fuentes de Información Los casos de uso pueden ser una base para determinar casos de prueba,ya que ayudan a identificar operaciones a ser probadas. Las entradas y salidas de las operaciones pueden ser obtenidas de los diagramas de secuencia o en los listados de operaciones.

22 Pruebas de Desempeño(stress) Parte de las pruebas de liberación implican probar las propiedades emergentes como el desempeño y la disponibilidad. Las pruebas de desempeño usualmente involucran planificar un conjunto de pruebas que incrementando la carga hasta que el desempeño del sistema es inaceptable. Además también se prueba el sistema ante efecto fortuitos (apagones, desconexión de red, etc).

23 Pruebas de Desempeño(stress) Son particularmente relevantes para sistemas distribuidos basados en una red de procesadores. Estos sistemas exhiben a menudo una degradación grave cuando son sobrecargados. Existen herramientas de software que simulan la carga del servidor, el número de peticiones y de usuarios conectados.

24 Pruebas de Interfaces El objeto es detectar en las interfaces asociadas a malas asunciones sobre estas. Es importante en el D.O.O donde los objetos son definidos vía sus interfaces. Tipo de Interfaces. Interfaces de parámetros Memoria compartida. Interfaz de procedimientos. Interfaz por paso de mensajes.

25 Pruebas de Interfaces Problemas comunes en uso de interfaces: Mal Uso de la Interfaz: Un componente llama a otro componente y comete un error en la utilización de su interfaz. Son errores comunes en interfaces de parámetros, en donde los parámetros pueden ser de tipo erróneo. No compresion de la Interfaz: El componente que realiza la llamada no comprende la especificación de la interfaz. El componente invocado no se comporta como era de esperar y esto provoca un comportamiento inesperado en el componente que realiza la llamada.

26 Pruebas de Interfaces Problemas comunes en uso de interfaces: Errores temporales: Se producen en sistemas de tiempo real que utilizan una memoria compartida o una interfaz de paso de mensajes. El productor de los datos y el consumidor pueden trabajar a distintas velocidades. El consumidor puede acceder a información no actualizizada debido a que el productorde no ha actualizado la información de la Interfaz compartida.

27 Diseño de casos de prueba El objetivo es crear los casos de pruebas que permitan ver el sistema cumple con los requerimientos y además permitan la detección de defectos. Aproximaciones: Pruebas basadas en requerimientos. Pruebas de particiones. Pruebas estructurales.

28 Pruebas Basadas en Requerimientos Dado que todo requerimiento debe ser verificable, entonces todo requerimiento debe poder ser sujeto a pruebas. Se pueden escribir varias pruebas para verificar que se cumple un requerimiento Las pruebas basadas en requerimientos, toman cada requerimientos (Funcional y no funcional) y determina pruebas para cada uno de estos.

29 Pruebas de Aceptación Descripción Su propósito es verificar que el sistema satisface los requerimientos del cliente (en el sitio del cliente) Realizado por un grupo de usuarios finales Técnicas de Prueba: Caja negra basado en los requerimientos y en escenarios reales Guías para generar casos de prueba Similar a pruebas del sistema

30 Pruebas de Particiones Datos de entradas y salidas son particionados en grupo operacionalmente similares. Cada particion se conoce como una partición de equivalencia. Se selecciona elementos de cada partición de equivalencia y probar con el sistema con estos. Es una buena practica no seleccionar la media de cada partición de equivalencia, sino valores cercanos a los limites.

31 Pruebas de Particiones

32 Pruebas Estructurales También conocidas como pruebas de caja blanca. Se determinan las pruebas a partir del conocimiento de la implementación. El objetivo de este tipo de pruebas es verificar todas las lineas de código (NO todas las combinaciones de caminos). La más conocida prueba de este tipo son las pruebas de caminos. Pruebas de caja blanca, caja de cristal.

33 Pruebas de Caminos Las pruebas de caminos tratan de preparar pruebas que verifiquen cada uno de los caminos del programa al menos una vez. Se parte de un grafo que muestra todos los caminos involucrados en un fragmento de código Las lineas que involucran sentencias condicionales crearan nuevos caminos.

34 Búsqueda Binaria

35 Grafo de Caminos

36 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, , 2, 3, 4, 6, 7, 2, 11, 13, 5... La pruebas ejecutadas deberán ser derivadas de cada unos de esos caminos. Existen algunos analizadores de programas pueden identificar los caminos a verificar.

37 Automatización de Pruebas Existen herramientas que ayudan a ejecutar pruebas automáticamente Estas herramientas funcionan a partir de conjuntos de pruebas previamente definidas por el usuario. En Java existe JUnit, para la realización de pruebas unitarias y de regresión, aunque existen una gran variedad de herramientas para probar diferentes tipos de software.

38 Pruebas de Usabilidad Consiste en seleccionar a un grupo de usuarios de una aplicación y pedirles que la usen. Los diseñadores y desarrolladores evaluán la facilidad de uso que tiene la aplicación y los grados de dificultad que presenta en la interacción con el usuario. Encaminadas a evaluar el uso natural de las interfaces gráficas de usuario de una aplicación. Se utilizan técnicas como las encuestas y la opinión de expertos.

39 Lecturas Recomendadas Ingeniería de Software. Ian Sommerville. 7 th edición (Capitulo 23).