Tcnicas de prueba del software

Fundamentos de las pruebas del software

Facilidad de Prueba

Operatividad

Observabilidad

Controlabilidad

Consiste en la facilidad con la que se puede probar el software

Cuanto mejor funcione, ms eficiente se puede probar

Lo que se ve es lo que se prueba

Si mejor se puede controla el software, se optimizar y automatizar mejor.

El sistema tiene pocos errores

Cdigo fuente accesible

Formatos de entradas y resultados, consistentes y estructurados.

Un resultado incorrecto se identifica fcilmente.

Fundamentos de las pruebas del software

Capacidad de descomposicin Simplicidad Estabilidad Facilidad de comprensin
Si se tiene mas informacin, las pruebas sern ms inteligentes.

Controlando el mbito de las pruebas, se pueden aislar ms rpidamente los problemas.

Cuanto menos se tenga que probar, se realizar ms rapidamente.

Menos cambios, menos interrupciones a las pruebas.

Simplicidad: Los mdulos de software se pueden probar independientemente.

La documentacin tcnica est:

Funcional, estructural, cdigo.

Organizada, especfica y detallada.

Fundamentos de las pruebas del software

Caractersticas de una buena prueba

Una buena prueba tiene una alta probabilidad de encontrar un fallo. Para alcanzar este objetivo el responsable de la prueba debe entender el software y desarrollar una imagen mental de cmo podra fallar. Una prueba no es redundante. No hay razn para realizar una prueba que tenga el mismo propsito que otra pues el tiempo y recursos destinados para la misma es limitado. Una prueba debe ser la mejor de su clase. Debe usarse la prueba que tenga la mayor probabilidad de descubrir un tipo completo de errores. Una prueba no debe ser ni muy simple ni demasiado compleja.

Pruebas de caja negra

Si se conoce la funcin especfica para la que se diseo el producto, se aplican pruebas, que demuestren que cada funcin es plenamente operacional, mientras se buscan errores de cada funcin, a este tipo de enfoque se denomina como prueba de caja negra. El componente se ve como una Caja Negra cuyo comportamiento slo puede ser determinado estudiando sus entradas y las salidas obtenidas a partir de ellas

Pruebas de caja blanca

Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un mdulo. As como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del mdulo, las de caja blanca estn dirigidas a las funciones internas. Entre las tcnicas usadas se encuentran:
Prueba de la ruta bsica Prueba de la estructura de control

Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un mdulo concreto, para luego realizar las de caja negra sobre varios subsistemas.

Pruebas de caja blanca

Al emplear este tipo de pruebas el ingeniero de software podr derivar casos de prueba que:

Garanticen que todas las rutas dentro del mdulo se han ejercitado al menos una vez.

Ejerciten lados verdaderos y falso de todas las decisiones lgicas.

Ejecuten todos los bucles en sus lmites y dentro de sus lmites operacionales

Ejerciten estructuras de datos internos asegurando validez.

Mtodos de pruebas orientadas a objetos.

El objetivo general de este tipo de pruebas es encontrar el nmero mximo de pruebas con una cantidad mnima de esfuerzo. Basada en fallas: Tipo de pruebas, que tiene por objetivo disear pruebas con una alta probabilidad de descubrir posibles fallas. Casos de prueba y jerarqua de clases: La herencia no obvia entre clases y subclases y superclases.

Mtodos de pruebas orientadas a objetos.

Basadas en escenarios:
Sucede con especificaciones incorrectas o con interacciones entre subsistemas. Se concentra en lo que hace el usuario no el producto. Esto significa capturar tareas mediante casos de uso, que el usuario tiene que realizar y luego aplicarlas.

Diseo de caso de prueba de Interclase

El diseo de casos de prueba se torna ms complicado cuando comienza la integracin del sistema Orientado a Objetos. Es en esta etapa cuando deben comenzar las pruebas de las colaboraciones entre clases. La prueba de colaboracin entre clases se lleva a cabo al aplicar mtodos aleatorios y de participacin, adems de pruebas basadas en el escenario y de comportamiento.

Diseo de caso de prueba de Interclase

Pruebas de clases mltiples
Secuencia de pasos para generar casos de prueba aleatorios para mltiples clases: Para cada clase cliente, utilice la lista de operaciones de clase, para generar una serie de secuencias de pruebas al azar. Para cada mensaje que se genere, determine la clase colaboradora y la operacin correspondiente en el objeto servidor Para cada operacin en el objeto servidor (invocada por mensajes enviados por el objeto cliente), determinar los mensajes que transmite Para cada uno de los mensajes, determine el siguiente nivel de operaciones que son invocadas, e incorpore stas a la secuencia de pruebas.

Diseo de caso de prueba de Interclase

Pruebas de clases mltiples

Diseo de caso de prueba de Interclase

Pruebas derivadas de modelos de comportamiento
El diagrama de transicin de estados para una clase puede usarse para ayudar a derivar una secuencia de pruebas, que ejercitarn el comportamiento dinmico de la clase. Las pruebas a disearse deben alcanzar una cobertura de todos los estados.

Pruebas de entornos especializados: Arquitecturas y Aplicaciones

Pruebas de interfaces grficas de usuario
Las pruebas de interfaz de usuario verifican la interaccin del usuario con el software. El objetivo de las pruebas de la interfaz de usuario es asegurar que dicha interfaz proporciona al usuario el acceso y la navegacin apropiados a travs de las funcionalidades del elemento objetivo de la prueba.

Pruebas de entornos especializados Pruebas de arquitectura cliente/servidor

Este tipo de prueba se presentan en tres niveles:
Se prueba toda la arquitectura cliente/servidor, incluida la operacin y desempeo de la red.

Aplicaciones de cliente individuales se prueban en una modalidad desconectada; la operacin del servidor y red no se toman en cuenta

El software de cliente y aplicaciones asociadas del servidor se prueban en conjunto

Pruebas de entornos especializados Pruebas de arquitectura cliente/servidor

Pruebas de funcionalidad de la aplicacin
Pruebas de servidor

Pruebas de base de datos

La aplicacin se prueba de manera independiente.

Se prueban las funciones de coordinacin y manejo de datos del servidor, adems se considera el desempeo del servidor.

Se prueba la exactitud e integridad de los datos almacenados en el servidor.

Pruebas de entornos especializados Pruebas de arquitectura cliente/servidor

Pruebas de comunicaciones de red

Pruebas de transaccin

Se verifica que la comunicacin entre los nodos de la red ocurre de manera correcta.

Adems el paso de mensajes, transacciones y trfico de red se realiza sin errores.

Se crea una serie de pruebas para asegurar que cada clase de transacciones se procesa, de acuerdo con sus requisitos.

Pruebas de la documentacin y las funciones de ayuda

Tiene como propsito probar la documentacin de usuario, incluyendo el manual de ste y la documentacin de mantenimiento y servicio. Esta prueba se aborda en dos fases: Revisin e inspeccin: Se examina la claridad editorial del documento. Prueba en vivo: Se emplea la documentacin junto con el programa real.

Pruebas de sistemas de tiempo real

El diseador del caso de prueba, no slo debe considerar los casos de prueba convencionales, sino tambin el manejo de eventos (procesamiento de interrupciones) Estrategia de 4 pasos:

Prueba de tareas

Pruebas de comportamiento

Prueba intertareas

Prueba del sistema

El primer paso de la prueba de sistemas de tiempo real consiste en probar cada tarea independiente mente

Utilizando modelos del sistema creados con herramientas CASE, es posible simular el comportamiento del sistema en tiempo real y examinar su comportamiento como consecuencia de eventos externos.

Se prueban tareas asincrnicas de las que se sabe que se comunican entre s, para determinar errores de sincronizacin.

Se prueba las tareas que se comunican por medio de cola de mensajes o almacn de datos.

El software y el hardware estn integrados, por lo que se lleva a cabo una serie de pruebas completas del sistema para intentar descubrir errores en la interfaz software / hardware.

Patrones de prueba
Se usan como mecanismos para describir los bloques de construccin del software. Se repiten a medida que se construyen diferentes aplicaciones o que se realizan diferentes proyectos. Los patrones de prueba describen bloques de construccin o situaciones frecuentes y que los responsables de probar el software pueden reutilizar al afrontar la prueba de algn sistema nuevo o revisado.

Tipos de Patrones
Interfaz de prueba separada Prueba de escenario
Describe la manera de crear una interfaz de prueba que permita describir pruebas especficas en clases que slo son visibles internamente para un componente.

Describe una tcnica para ejercitar el software desde el punto de vista del usuario. Una falla en este nivel indica que el software no satisface los requisitos de un usuario visible.

Tipos de Patrones

Testigo Par

Patrn orientados a procesos, describe una tcnica anloga a la programacin par, en la cual dos responsables de una pruebas trabajan de manera conjunta para disear y ejecutar una serie de pruebas aplicables a actividades de prueba de unidad, integracin o validacin.

SHODAN.- En este proyecto es posible y recomendable aplicar pruebas basadas en escenarios y pruebas basadas en fallas, las cuales sean en una casi total incidencia de caja blanca, ya que lo ms importante en este sistema son los algoritmos de medicin de rendimiento del alumno en su disciplina. Un tipo especfico de prueba orientada a objetos que se usara en este proyecto, ser el de integracin que se divide en:
Resultado inesperado Operacin incorrecta Mensaje inesperado Invocacin incorrecta

Todo esto definir el comportamiento del software, aplicando estas pruebas a las funciones y operaciones del sistema.