PRUEBAS CAJA BLANCA

1. Prueba del camino bsico Permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba obtenidos del conjunto bsico garantizarn que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. Algunos elementos y conceptos utilizados alrededor de ste mtodo son los siguientes: -Grafo de flujo o grafo del programa: representa el flujo de control lgico de un programa y se utiliza para trazar ms fcilmente los caminos de ste. (Cada nodo representa una o ms sentencias procedimentales y cada arista representa el flujo de control). -Complejidad ciclomtica: es una mtrica de software que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Cuando se usa en el contexto de las pruebas, el clculo de la complejidad ciclmatica representa el nmero de caminos independientes del conjunto bsico de un programa. Esta medida ofrece al probador de software un lmite superior para el nmero de pruebas que debe realizar para garantizar que se ejecutan por lo menos una vez cada sentencia. -Camino independiente: cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condicin. De forma general, los pasos que se debe seguir para la obtencin de los casos de prueba en este mtodo, son los siguientes: 1. Emplear el diseo o el cdigo para elaborar el grafo de flujo. 2. Determinar la complejidad ciclomtica del grafo de flujo. 3. Determinar un conjunto bsico de caminos linealmente independientes. 4. Preparar los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico.

2. Prueba de la estructura de control Dentro de ste tipo de prueba se contempla el mtodo del camino bsico mencionado anteriormente pero adems existen otras pruebas asociadas que permiten ampliar la cobertura de la prueba y mejorar su calidad. Estas son: Prueba de condicin: es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. Algunos conceptos empleados alrededor de esta prueba son los siguientes: -Condicin simple: es una variable lgica o una expresin relacional (E1 < operador - relacional > E2). -Condicin compuesta: est formada por dos o ms condiciones simples, operadores lgicos y parntesis. En general los tipos de errores que se buscan en una prueba de condicin, son los siguientes: -Error en operador lgico (existencia de operadores lgicos incorrectos, desaparecidos, sobrantes). -Error en variable lgica. -Error en parntesis lgico. -Error en operador relacional. -Error en expresin aritmtica.

PRUEBAS CAJA NEGRA

1. Mtodos de prueba basados en grafos En este mtodo se debe entender los objetos (objetos de datos, objetos de programa tales como mdulos o colecciones de sentencias del lenguaje de programacin) que se modelan en el software y las relaciones que conectan a estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas. En este mtodo: Se crea un grafo de objetos importantes y sus relaciones. Se disea una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir errores.

Pruebas de comportamiento que pueden hacer uso de los grafos: Modelado del flujo de transaccin. Los nodos representan los pasos de alguna transaccin (por ejemplo, los pasos necesarios para una reserva en una lnea area usando un servicio en lnea), y los enlaces representan las conexiones lgicas entre los pasos (por ejemplo, vuelo.informacin.entrada es seguida de validacin /disponibilidad.procesamiento). Modelado de estado finito. Los nodos representan diferentes estados del software observables por el usuario (por ejemplo, cada una de las pantallas que aparecen cuando un telefonista coge una peticin por telfono), y los enlaces representan las transiciones que ocurren para moverse de estado a estado (por ejemplo, peticin-informacin se verifica durante inventario-disponibilidad-bsqueda y es seguido por cliente-factura-informacin-entrada). Modelado de flujo de datos. Los nodos objetos de datos y los enlaces son las transformaciones que ocurren para convertir un objeto de datos en otro. Modelado de planificacin. Los nodos son objetos de programa y los enlaces son las conexiones secuenciales entre esos objetos. Los pesos de enlace se usan para especificar los tiempos de ejecucin requeridos al ejecutarse el programa. Grfica Causa-efecto. La grfica Causa-efecto, representa una ayuda grfica en seleccionar, de una manera sistemtica, un gran conjunto de casos de prueba. Tiene un efecto secundario beneficioso en precisar estados incompletos y ambigedades en la especificacin.

2. Particin equivalente Pressman presenta la particin equivalente como un mtodo de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores que, de otro modo, requeriran la ejecucin de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar. Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos para condiciones de entrada. Tpicamente, una condicin de entrada es un valor numrico especfico, un rango de valores, un conjunto de valores relacionados o una condicin lgica. El objetivo de particin equivalente es reducir el posible conjunto de casos de prueba en uno ms pequeo, un conjunto manejable que evale bien el software. Se toma un riesgo porque se escoge no probar todo. As que se necesita tener mucho cuidado al escoger las clases. La particin equivalente es subjetiva. Dos probadores quienes prueban un programa complejo pueden llegar a diferentes conjuntos de particiones. En el diseo de casos de prueba para particin equivalente se procede en dos pasos: a. Se identifican las clases de equivalencia: Las clases de equivalencia son identificadas tomando cada condicin de entrada (generalmente una oracin o una frase en la especificacin) y repartindola en dos o ms grupos. Es de notar que dos tipos de clases de equivalencia estn identificados: las clases de equivalencia vlidas representan entradas vlidas al programa, y las clases de equivalencia invlidas que representan el resto de los estados posibles de la condicin (es decir, valores errneos de la entrada). b. Se define los casos de prueba: El segundo paso es el uso de las clases de equivalencia para identificar los casos de prueba. El proceso es como sigue: se asigna un nmero nico a cada clase de equivalencia. Hasta que todas las clases de equivalencia vlidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia vlida. Y por ltimo hasta que los casos de prueba hallan cubierto todas las clases de equivalencia invlidas, se escribe un caso de la prueba que cubra una, y solamente una, de las clases de equivalencia invlidas descubiertas.