Mtodos de prueba de caja negra

Algunos de los mtodos empleados en las pruebas de caja negra son los siguientes:

Mtodos de prueba basados en grafos [Pressman] 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: 1. Se crea un grafo de objetos importantes y sus relaciones. 2. Se disea una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir errores. Beizer describe un nmero de modelados para 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 inventariodisponibilidad-bsqueda y es seguido por cliente-factura-informacinentrada). 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.

Un grfico de causa-efecto es un lenguaje formal al cual se traduce una especificacin. El grfico es realmente un circuito de lgica digital (una red combinatoria de lgica), pero en vez de la notacin estndar de la electrnica, se utiliza una notacin algo ms simple. No hay necesitad de tener conocimiento de electrnica con excepcin de una comprensin de la lgica boleana (entendiendo los operadores de la lgica y, o, y no).

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: 1. 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). 2. 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. Anlisis de valores lmite: los errores tienden a darse ms en los lmites del campo de entrada que en el centro. Por ello, se ha desarrollado el anlisis de valores lmites (AVL) como tcnica de prueba. El anlisis de valores lmite lleva a una eleccin de casos de prueba que ejerciten los valores lmite. El anlisis de valores lmite es una tcnica de diseo de casos de prueba que completa a la particin equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la eleccin de casos de prueba en los extremos de la clase. En lugar de centrarse solamente en las condiciones de entrada, el AVL obtiene casos de prueba tambin para el campo de salida.[Pressman] Condiciones sublmite. Las condiciones limite normales son las ms obvias de descubrir. Estas son definidas en la especificacin o son evidentes al momento de utilizar el software. Algunos limites, sin embargo , son internos al software, no son necesariamente aparentes al usuario final pero an as deben ser probadas por el probador. Estas son conocidas como condiciones sublmites o condiciones lmite internas. Una condicin sublmite comn es la tabla de caracteres ASCII, por ejemplo, si se est evaluando una caja de texto que acepta solamente los caracteres AZ y az, se debe incluir los valores en la particin invlida justo debajo de y encima de esos caracteres de la tabla ASCII, [", y {.

Prueba de la tabla ortogonal [Pressman]: hay aplicaciones donde el nmero de parmetros de entrada es pequeo y los valores de cada uno de los parmetros est claramente delimitado. Cuando estos nmeros son muy pequeos (por ejemplo, 3 parmetros de entrada tomando 3 valores diferentes), es posible considerar cada permutacin de entrada y comprobar exhaustivamente el proceso del dominio de entrada. En cualquier caso, cuando el nmero de valores de entrada crece y el nmero de valores diferentes para cada elemento de dato se incrementa, la prueba exhaustiva se hace impracticable. La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio de entrada es relativamente pequeo pero demasiado grande para posibilitar pruebas exhaustivas. El mtodo de prueba de la tabla ortogonal es particularmente til al encontrar errores asociados con fallos localizados -una categora de error asociada con defectos de la lgica dentro de un componente software-.

La prueba de tabla ortogonal permite proporcionar una buena cobertura de pruebas con bastantes menos casos de prueba que en la estrategia exhaustiva.