Pruebas de Software

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 especificacin.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 especificacin del sistema

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

El proceso de Pruebas
Pruebas del integracin
Equipo de pruebas Independiente

Pruebas del componente

Desarrollador de software

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 1972. 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.
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Defectos
Tiene como objeto descubrir lo defectos de un programa (En ejecucin). Una prueba de defectos exitosa es aquella que provoca comportamientos extraos no planeados. Las pruebas detectan la presencia de errores no su ausencia.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Proceso de Pruebas de Software

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Tenicas de Pruebas
Caja blanca o pruebas estructurales El conocimiento del diseo interno del software se usa para desarrollar los casos de Pruebas Caja negra o pruebas funcionales Los casos de prueba son diseados basados slo en la especificacin externa del software Pruebas basadas en escenarios o casos de uso Actuar como un usuario final y crear escenarios reales para detectar errores
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Caja Negra

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas Unitarias
Descripcin Su propsito es encontrar errores en la lgica, datos o algoritmos en componentes o subsistemas individuales Realizado por los desarrolladores del componente Tcnica de prueba: Caja blanca

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas Unitarias
Guas para generar casos de prueba Tratar de detectar errores en los algoritmos y la lgica Tratar de detectar errores en la manipulacin de datos Tratar de detectar errores en el llamado a otros mdulos Identificar todos los caminos posibles del hacer casos de prueba que los cubran mdulo y tratar de de las estructuras

Tratar de detectar errores usando datos lmites

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Unitarias
Tambin conocidas como pruebas de componentes Es una prueba de deteccin de defectos. Un componente puede ser: Funciones o mtodos Clases completas. Componentes compuestos con interfaces definidas usadas para acceder a su funcionalidad.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Polticas de Pruebas
nicamente una revisin exhaustiva del software puede garantizar la ausencia de errores, pero esto es imposible. Las polticas 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.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas del Sistema

Pruebas de Integracin: El equipo de pruebas tiene acceso al cdigo 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 Regresin: Repeticin de pruebas despus de un cambio significativo

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Integracin
Involucra construir el sistema desde sus componentes y detectar problemas derivados de su interaccin. Integracin Top-Down: Se construye un esqueleto del sistema y ubican los componentes en este. Integracin Botton-Up: Se integran los componentes agrupndolos de manera en la que este relacionados. Para facilitar la localizacin de errores estas integraciones deben realizarse de manera incremental
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Integracin incremental

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Aproximaciones de Pruebas

Validacin arquitectural: Top-Down. Demostracin del sistema: Top-Down. Pruebas de Implementacin: Button-Up. Pruebas de Observacin: Se utilizan ambos enfoques de integracin, pero se puede requerir cdigo extra.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Lanzamiento o liberacin

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 tcnicas de prueba de caja negra (El probadores no conocen como se implemento el sistema). Las pruebas estn basadas en la especificacin del problema

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas por escenarios

Para validar que el sistema satisface los requerimientos, la mejor aproximacin basada en escenarios y se desarrollan casos de prueba a partir de estos escenarios. Un escenario se lo puede definir como una posible situacin de la vida real que se puede presentar en la ejecucin del software. Se pueden hacer casos de pruebas para diferentes escenarios y que diferentes escenarios pueden corresponder a un mismo requerimiento.
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Guas de Pruebas
Elegir entradas que fuerzan el sistema genere todos los mensajes de error. Disear 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 invlidas. Forzar los resultados de los clculos para que sean demasiado grande o demasiado pequeos.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Fuentes de Informacin
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.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Desempeo(stress)
Parte de las pruebas de liberacin implican probar las propiedades emergentes como el desempeo y la disponibilidad. Las pruebas de desempeo usualmente involucran planificar un conjunto de pruebas que incrementando la carga hasta que el desempeo del sistema es inaceptable. Adems tambin se prueba el sistema ante efecto fortuitos (apagones, desconexin de red, etc).

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Desempeo(stress)
Son particularmente relevantes para sistemas distribuidos basados en una red de procesadores. Estos sistemas exhiben a menudo una degradacin grave cuando son sobrecargados. Existen herramientas de software que simulan la carga del servidor, el nmero de peticiones y de usuarios conectados.
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 va sus interfaces. Tipo de Interfaces. Interfaces de parmetros Memoria compartida. Interfaz de procedimientos. Interfaz por paso de mensajes.
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 utilizacin de su interfaz. Son errores comunes en interfaces de parmetros, en donde los parmetros pueden ser de tipo errneo. No compresion de la Interfaz: El componente que realiza la llamada no comprende la especificacin 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.
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 informacin no actualizizada debido a que el productorde no ha actualizado la informacin de la Interfaz compartida.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Diseo de casos de prueba

El objetivo es crear los casos de pruebas que permitan ver el sistema cumple con los requerimientos y adems permitan la deteccin de defectos. Aproximaciones: Pruebas basadas en requerimientos. Pruebas de particiones. Pruebas estructurales.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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.
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Aceptacin
Descripcin Su propsito es verificar que el sistema satisface los requerimientos del cliente (en el sitio del cliente) Realizado por un grupo de usuarios finales Tcnicas de Prueba: Caja negra basado en los requerimientos y en escenarios reales Guas para generar casos de prueba Similar a pruebas del sistema

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Particiones

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas Estructurales
Tambin conocidas como pruebas de caja blanca. Se determinan las pruebas a partir del conocimiento de la implementacin. El objetivo de este tipo de pruebas es verificar todas las lineas de cdigo (NO todas las combinaciones de caminos). La ms conocida prueba de este tipo son las pruebas de caminos. Pruebas de caja blanca, caja de cristal.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 cdigo Las lineas que involucran sentencias condicionales crearan nuevos caminos.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Bsqueda Binaria

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Grafo de Caminos

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

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 ...... La pruebas ejecutadas debern ser derivadas de cada unos de esos caminos. Existen algunos analizadores de programas pueden identificar los caminos a verificar.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Automatizacin de Pruebas
Existen herramientas que ayudan a ejecutar pruebas automticamente Estas herramientas funcionan a partir de conjuntos de pruebas previamente definidas por el usuario. En Java existe JUnit, para la realizacin de pruebas unitarias y de regresin, aunque existen una gran variedad de herramientas para probar diferentes tipos de software.

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Pruebas de Usabilidad
Consiste en seleccionar a un grupo de usuarios de una aplicacin y pedirles que la usen. Los diseadores y desarrolladores evalun la facilidad de uso que tiene la aplicacin y los grados de dificultad que presenta en la interaccin con el usuario. Encaminadas a evaluar el uso natural de las interfaces grficas de usuario de una aplicacin. Se utilizan tcnicas como las encuestas y la opinin de expertos.
Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008

Lecturas Recomendadas
Ingeniera de Software. Ian Sommerville. 7th edicin (Capitulo 23).

Escuela de Ingeniera de Sistemas y Computacin Desarrollo de Software II Agosto Diciembre 2008