Tecnicas de Pruebas Ingeniera del Software

Facilitador: Ing. Hctor Molina Participante: Bastardo Luis

1m+3m
Trimestre.IX

Ciudad bolivar,27 de Mayo del 2013

Objetivos de las pruebas

La prueba es el proceso de ejecucin de un programa con la intencin 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.

Nos quitan la idea que, normalmente, tenemos de que una prueba tiene xito si no descubre errores.. Nuestro objetivo es disear pruebas que sistemticamente saquen a la luz diferentes clases de errores, hacindolo con la menor cantidad de tiempo y de esfuerzo.

Tecnicas de Pruebas Niveles de Pruebas

Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Las pruebas de unidad es un proceso para probar los subprogramas, las subrutinas, los procedimientos individuales o las clases en un programa. Es mejor probar primero los bloques desarrollados ms pequeos del programa, que inicialmente probar el software en su totalidad.

Pruebas de Unidad

Tecnicas de Pruebas
Pruebas de Unidad
Qu se necesita para disear el caso deprueba?
La especificacin para el mdulo y el cdigo fuente del mdulo. La especificacin define tpicamente los parmetros de entrada y de salida del mdulo y su funcin.

Son orientadas en gran parte a caja blanca

CONSIDEARACIONES SOBRE LA PRUEBA DE UNIDAD

Interfaz

Se prueba para verificar que la informacin fluye apropiadamente hacia dentro y hacia fuera del mdulo

Estructura de datos locales Rutas de ejecucin

Asegurarse que los datos temporales mantienen la integridad durante todos los pasos de la ejecucin del algoritmo

Se recorren todos los caminos independientes para probar que todas las instrucciones se hayan ejecutado al menos una vez

CONSIDEARACIONES SOBRE LA PRUEBA DE UNIDAD

Condiciones lmite Rutas de manejo de errores

Asegurar que el mdulo opera apropiadamente en los lmites establecidos para restringir el procesamiento.

Se prueban todos los caminos que involucran a los errores .

PRUEBA DE UNIDAD

Verifica el componente o mdulo de software

Se toma como gua la descripcin del diseo al nivel de componentes

Se concentran en la lgica de procesamiento interno y en las estructuras de datos dentro de los lmites de un componente.

Limita la complejidad de las pruebas.

Tecnicas de Pruebas

Pruebas de Integracin

El objetivo de las pruebas de integracin es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactan correctamente a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes.

Tecnicas de Pruebas

PRUEBAS DE INTEGRACION: La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es tomar los mdulos probados en unidad y estructurar un programa que est de acuerdo con el que dicta el diseo. Los tipos de prueba de integracin son:

Integracin descendente: es una estrategia de integracin incremental a la construccin de la estructura de programas, en el cual se integran los mdulos movindose en direccin hacia abajo por la jerarqua comenzando por el control principal (Programa principal).
-

-Integracin ascendente: es donde la construccin del diseo empieza desde los mdulos ms bajos hacia arriba (mdulo principal).

Tecnicas de Pruebas

Pruebas de Integracin
Estrategias Prueba Top-Down
El primer componente que se desarrolla y prueba es el primero de la jerarqua (A). Los componentes de nivel ms bajo se sustituyen por componentes auxiliares para simular a los componentes invocados.

Ventaja: una de las ventajas de aplicar esta estrategia es que las interfaces entre los distintos componentes se prueban en una fase temprana y con frecuencia.

Tecnicas de Pruebas

Pruebas de Integracin
Estrategias Prueba Bottom-up

En este caso se crean primero los componentes de ms bajo nivel (E, F) y se crean componentes conductores para simular a los componentes que los llaman.

A continuacin se desarrollan los componentes de ms alto nivel (B, C, D) y se prueban. Por ltimo dichos componentes se combinan con el que los llama (A).

Ventaja: este tipo de enfoque permite un desarrollo ms en paralelo que el enfoque de arriba abajo, pero presenta mayores dificultades a la hora de planificar y de gestionar.

Tecnicas de Pruebas

Pruebas de Integracin
Estrategias Estrategias combinadas.

A menudo es til aplicar las estrategias anteriores conjuntamente.

De este modo, se desarrollan partes del sistema con un enfoque "top-down", mientras que los componentes ms crticos en el nivel ms bajo se desarrollan siguiendo un enfoque "bottom-up".

En este caso es necesaria una planificacin cuidadosa y coordinada de modo que los componentes individuales se encuentren en el centro.

Tecnicas de Pruebas

Tipos de defectos
Segn Centro de Investigaciones de IBM
Descripcion

Tipo

Dcoumentacion Sintaxis Construir Paquetes Asignacion Interfaz Chequeo

Comentarios Mensajes Ortografia, puntuacion, erratas , formato de las instrucciones Gestion de cambios, librerias, control de version Declaracion, nombres duplicados, ambitos Llamadas a procedimientos y referencias, E/S, formatos de usuario Mensajes de error, chequeos inadecuados

Datos Funcion

Estructura, Contenido Lgica, punteros, bucles, recursion, computacion, defectos de la funcion

Tecnicas de Pruebas

Tipos de defectos
Segn Centro de Investigaciones de IBM

Tipo Sistema Sintaxis Entorno

Descripcion Configuracion, temporizacion, memoria Ortografia, puntuacion, erratas , formato de las instrucciones Diseo, compilacion, pruebas y otros problemas que soporta el sistema

PRUEBAS DEL SISTEMA

Se prueba el sistema de cmputo profundamente

Las pruebas trabajan para verificar que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas

Adelantarse a los posibles problemas de interfaz

TIPOS DE PRUEBA DEL SISTEMA

Pruebas de recuperacin
Es una prueba que obliga al software a fallar de varias maneras y a verificar que la recuperacin se realice apropiadamente. Si la recuperacin es automtica debe evaluarse que sean correctos la re inicializacin, mecanismos de respaldo del sistema, recuperacin de datos Si la recuperacin es manual, se debe evaluar el tiempo medio de reparacin para determinar si se encuentra dentro de lmites aceptables

TIPOS DE PRUEBA DEL SISTEMA

Comprueba que los mecanismos de proteccin integrados en el sistema realimente lo protejan de irrupciones inapropiadas Pruebas de seguridad El papel del diseador del sistema es que el costo de la irrupcin sea mayor que el valor de la informacin que habr de obtenerse

Ejecuta el sistema de tal manera que requiera una cantidad, una frecuencia o un volumen anormal de recursos

Pruebas de resistencia

Se trata de sobrecargar el sistema

Pruebas de sensibilidad

Tratan de descubrir combinaciones de datos dentro de las clases de entrada vlidas que causen inestabilidad o procesamiento inadecuado

TIPOS DE PRUEBA DEL SISTEMA

Est diseada para probar el desempeo del software en tiempo de ejecucin dentro del contexto de un sistema integrado

Prueba de desempeo
Se requiere instrumentacin externa para medir el desempeo del sistema
Se aplica en todos los niveles de prueba, desde prueba de unidad

Pruebas de Sistema y de Aceptacin

Pruebas de Aceptacin

Son aquellas pruebas que realiza el usuario/cliente con el objeto de comprobar si el sistema es aceptable para l.

Estas pruebas son del mismo tipo que las mencionadas anteriormente, pero son determinadas por el usuario, en lugar de serlo por el equipo de desarrollo.

Un tipo especial de estas pruebas es el de la ejecucin en paralelo con el viejo sistema (legado), para comparar los resultados producidos por ambas ejecuciones.

Se chequea fundamentalmente: correctitud, robustez, performance y documentacin.

Tipos de Pruebas
Pruebas de Caja Blanca (Estructural)
Es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba.

Tecnicas de Pruebas
Pruebas de Caja Blanca (Estructural) Con este mtodo se puede obtener casos de prueba que:

Garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo. Ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa. Ejecuten todos los bucles en sus lmites y con sus lmites operacionales. Ejerciten las estructuras internas de datos para asegurar su validez

Tecnicas de Pruebas

Pruebas de Caja Blanca (Estructural)

Formas de realizar las pruebas

Pruebas Estticas:Es el proceso que cuidadosamente y metdicamente revisa el diseo del software, la arquitectura o el cdigo para encontrar defectos sin necesidad de ejecutar el cdigo. Esto algunas veces se refiere a un anlisis estructural.

Pruebas Dinmicas: en estas pruebas se revisa dentro de la caja, se examina el cdigo y se observa ste mientras se ejecuta. La prueba de caja blanca dinmica, en resumidas palabras, utiliza la informacin que se obtiene al observar que hace el cdigo, como trabaja, para as determinar que probar, que no probar y como aproximarse a las pruebas.

Tecnicas de Pruebas

Pruebas de Caja Blanca (Estructural)

Metodos de prueba

Prueba del camino basico: Se obtiene una medidad de la complejidad logica del diseo procedimental con esto se define un conjunto de caminos basicos de ejecucion

Prueba de la estructura de control

Prueba de condicion: Simples o compuestos Prueba del flujo de datos: Definiciones y usos de variables Prueba de bucles: bucles simples, anidados, concatenados y no estructurados

Tecnicas de Pruebas
Pruebas de Caja Negra (Funcional)

Las pruebas de caja negra se centran en los requisitos funcionales del software. Es decir, permite obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa.

Tecnicas de Pruebas

Pruebas de Caja Negra (Funcional)

Intentan encontrar errores de las siguientes categoras:
Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin.

Tecnicas de Pruebas

Pruebas de Caja Negra (Funcional)

Formas de realizar las pruebas:
Pruebas estticas, probando la especificacin: la especificacin es un documento, no es el programa ejecutndose; esto es lo que se considera esttico. Entonces se puede tomar el documento, hacer las pruebas estticas de caja negra y examinar cuidadosamente esta para encontrar errores. Pruebas dinmicas: es probar el software sin tener un conocimiento de los detalles del cdigo fuente. Es dinmica porque el programa se est ejecutando mientras se est probando. Y es caja negra porque se prueba sin tener un conocimiento exacto de como trabaja. Se ingresan entradas, se reciben salidas, y se comprueban resultados.

Tecnicas de Pruebas

Pruebas de Caja Negra (Funcional)

Metodos de Prueba Basado en grafos: flujos de transicion, estados finitos, flujo de datos, planificacion, causa-efecto Particion equivalente: divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Analisis de valores limites: los errores tienden a darse ms en los lmites del campo de entrada que en el centro Prueba de tabla ortogonal: es posible considerar cada permutacin de entrada y comprobar exhaustivamente el proceso del dominio de entrada. Adivinando el error: dado un programa particular, se conjetura, por la intuicin y la experiencia, ciertos tipos probables de errores y entonces se escriben casos de prueba para exponer esos errores

Pruebas Funcionales

Se denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen por objetivo probar que los sistemas desarrollados, cumplan con las funciones especficas para los cuales han sido creados, es comn que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a produccin.

A este tipo de pruebas se les denomina tambin pruebas de comportamiento o pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su atencin a como se generan las respuestas del sistema, bsicamente el enfoque de este tipo de prueba se basa en el anlisis de los datos de entrada y en los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas.

Dentro del campo de estudio de la Ingeniera de Software, se sugieren diversas metodologas de prueba que pueden incorporarse el ciclo de vida de un proyecto de desarrollo computacional. De acuerdo con Pressman, las pruebas funcionales pueden realizare en base a 2 enfoques principales [PRR98]:

Prueba de caja blanca Prueba de caja negra

Pruebas funcionales
Objetivo: Se asegura la trabajo apropiado de los requisitos funcionales, incluyendo la navegacin, entrada de datos, procesamiento y obtencin de resultados. Metas de estas pruebas son: Verificar el procesamiento, recuperacin e implementacin adecuada de las reglas del negocio. Verificar la apropiada aceptacin de datos. Enfoque: Los requisitos funcionales (Casos de Uso) y las reglas del negocio.

Tcnica: Caja Negra

Se ejecuta cada caso de uso, flujo de caso de uso, o funcin , usando datos vlidos e invlidos, para verificar lo siguiente:
Que los resultados esperados ocurran cuando se usen datos vlidos. Que sean desplegados los mensajes a propiados de error y precaucin cuando se usan datos invlido

Que se aplique apropiadamente cada regla de negocio.

Pruebas no Funcionales
Para entender este tipo de pruebas es bueno tener claro que son las pruebas funcionales, estas pruebas se encargan verificar que una funcionalidad en especfico, es decir un conjunto de entradas son aplicadas a un mdulo y segn las salidas que este de se verifica si funciona correctamente o no. Si bien este tipo de pruebas son necesarias, no son las nicas y no muestran el comportamiento real de la aplicacin bajo condiciones de produccin. Por tal motivo se hace necesario realizar las pruebas no funcionales, estas se encargan de ver el comportamiento de la aplicacin bajo situaciones similares a las de produccin.

Que pruebas no funcionales existen?

En una aplicacin podemos evaluar los siguientes aspectos:

Manejo de memoria Confiabilidad Usabilidad Mantenibilidad Configurabilidad Rendimiento (Estrs) Seguridad Portabilidad Recuperacin Recuperacin a desastres Interoperabilidad Compatibilidad
Instalabilidad

Pruebas de Interfaz
Existen diferentes tipos de interfaces entre los componentes del programa y, consecuente- mente, distintos tipos de errores de interfaces que pueden producirse: Interfaces de parmetros. Son interfaces en las que los datos, o algunas veces refe- rencias a funciones, se pasan de un componente a otro en forma de parmetros.

Interfaces de memoria compartida. Son interfaces en las que un bloque de memoria se comparte entre los componentes. Los datos se colocan en la memoria por un sub- sistema y son recuperados desde aqu por otros subsistemas.
Interfaces procedwales. Son interfaces en las que un componente encapsula un con- junto de procedimientos que pueden ser llamados por otros componentes. Los objetos y los componentes reutilizables tienen esta forma de interfaz. 4. Interfaces de paso de mensajes.

Pruebas de Interfaz
Los errores de interfaces son una de las formas ms comunes de error en sistemas com- plejos (Lutz, 1993). Estos errores se clasifican en tres clases:

Mal uso de la interfaz. Un componente llama a otro componente y comete un error en la utilizacin de su interfaz. Este tipo de errores es particularmente comn con interfaces de parmetros en donde los parmetros pueden ser de tipo errneo, pueden pasarse en el orden equivocado o puede pasarse un nmero errneo de parmetros.

No comprensin de la interfaz. El componente que realiza la llamada no comprende la especificacin de la interfaz del componente al que llama, y hace suposiciones sobre el comportamiento del componente invocado. El componente invocado no se comporta como era de esperar y esto provoca un comportamiento inesperado en el componente que hace la llamada. Por ejemplo, puede llamarse a una rutina de bsqueda binaria con un vector no ordenado para realizar la bsqueda. En este caso, la bsqueda podra fallar.

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 de dichos datos pueden operar a diferentes velocidades

Patrones de diseo basados en pruebas

Siguiendo la tcnica de los patrones de diseo, Robert V. Binder define la siguiente plantilla de patrones de diseo de pruebas

Nombre: una palabra o frase que identifica el patrn y sugiere su enfoque general.

Objetivo: Qu problema de diseo de pruebas resuelve este patrn? Cul es la estrategia de pruebas? Dar una descripcin muy breve. Contexto: Bajo qu circunstancias se aplica este patrn? A qu clase de entidades software? A qu alcance? Esta seccin se corresponde con las de motivacin y aplicabilidad de los patrones de diseo. Modelo de fallos: Qu clase de defectos busca este patrn? El fallo debe alcanzarse a partir de los datos de entrada de la prueba y el estado del sistema, debe producir resultados incorrectos y ha de ser propagado a la salida de tal forma que sea observable por la persona que realiza la prueba. Estrategia: esta seccin aclara como se ha de generar e implementar la coleccin de casos de prueba. Tiene cuatro subsecciones obligatorias: Modelo de Pruebas: define una representacin de las responsabilidades y/o implementacin que son el punto central del diseo de pruebas.

Patrones de diseo basados en pruebas

Procedimiento de prueba: define un algoritmo, tcnica o heurstica por la que se generan los casos de prueba del modelo.

Comprobacin: define el algoritmo, la tcnica o heurstica por la cual los resultados actuales de un caso de prueba se evalan como paso / no paso. Automatizacin: discute los enfoques automticos para la generacin de casos de prueba, ejecucin de pruebas y evaluacin de la ejecucin de las pruebas. Se suele mostrar con ejemplos. Criterio de entrada: lista de precondiciones para una prueba efectiva y eficiente con este patrn. Una implementacin no ha de ser probada hasta que no est lista para ser probada. Criterio de salida: criterio objetivo que ha de alcanzarse para dar por completa la prueba con este patrn. Por ejemplo, cobertura de sentencias a nivel de mtodo.

Consecuencias: prerrequisitos generales, costos, beneficios, riesgos y consideraciones en el uso de este patrn. Usos conocidos: cules son los usos conocidos de este patrn de diseo? Cules son los usos conocidos de los modelos de prueba y estrategias incorporadas en este patrn?Cul es la eficiencia y la efectividad de este patrn o estrategias similares establecidas por estudios empricos? Patrones relacionados: patrones de diseo similares o complementarios.

Herramientas

Hay herramientas que generan casos de prueba en forma inteligente, de alguna manera eligiendo un nmero relativamente limitado de casos de prueba.

Las herramientas pueden probar los casos (generan cdigo para el test driver).

Las herramientas computan cobertura de cdigo e incluso cobertura de caminos.

Para sistemas embebidos de comunicaciones (como radios de dos vas), las herramientas se comunican con un modelo ejecutable de otros sistemas con los que se interacta.

Muchas gracias