Pruebas de Caja Negra

Estas pruebas permiten obtener un conjunto de

condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas
se ignora la estructura de control, concentrndose en los requisitos funcionales del sistema y ejercitndolos.

La prueba de Caja Negra no es una alternativa a las tcnicas de prueba de la Caja Blanca, sino un enfoque
complementario que intenta descubrir diferentes tipos de errores a los encontrados en los mtodos de la Caja
Blanca. Muchos autores consideran que estas pruebas permiten encontrar:
1. Funciones incorrectas o ausentes.
2. Errores de interfaz.
3. Errores en estructuras de datos o en accesos a las Bases de Datos externas.
4. Errores de rendimiento.
5. Errores de inicializacin y terminacin.
Para preparar los casos de pruebas hacen falta un nmero de datos que ayuden a la ejecucin de los estos
casos y que permitan que el sistema se ejecute en todas sus variantes, pueden ser datos vlidos o invlidos
para el programa segn si lo que se desea es hallar un error o probar una funcionalidad. Los datos se
escogen atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin
de verificar que el programa corra bien.
Para desarrollar la prueba de caja negra existen varias tcnicas, entre ellas estn:
1. Tcnica de la Particin de Equivalencia: esta tcnica divide el campo de entrada en clases de datos
que tienden a ejercitar determinadas funciones del software.
2. Tcnica del Anlisis de Valores Lmites: esta Tcnica prueba la habilidad del programa para manejar
datos que se encuentran en los lmites aceptables.
3. Tcnica de Grafos de Causa-Efecto: es una tcnica que permite al encargado de la prueba validar
complejos conjuntos de acciones y condiciones.
Dentro del mtodo de Caja Negra la tcnica de la Particin de Equivalencia es una de las ms efectivas pues
permite examinar los valores vlidos e invlidos de las entradas existentes en el software, 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 pruebas que
descubran clases de errores, reduciendo as en nmero de clases de prueba que hay que desarrollar.
Particin equivalente
Una particin equivalente es una tcnica de prueba de Caja Negra que divide el dominio de entrada de un
programa en clases de datos de los que se pueden derivar casos de prueba. El diseo de estos casos de
prueba para la particin equivalente se basa en la evaluacin de las clases de equivalencia.
El diseo de casos de prueba para la particin equivalente se basa en una evaluacin de las clases de
equivalencia para una condicin de entrada. Una clase de equivalencia representa un conjunto de estados
vlidos o invlidos para condiciones de entrada.
Regularmente, una condicin de entrada es un valor numrico especfico, un rango de valores, un conjunto de
valores relacionados o una condicin lgica.
Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: Si un parmetro de
entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por
encima del rango.
Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del
rango.
Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el
conjunto o fuera de l.
Si una entrada es booleana, hay 2 clases: si o no.
Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada
una de las clases.
Aplicando estas directrices se ejecutan casos de pruebas para cada elemento de datos del campo de entrada
a desarrollar. Los casos se seleccionan de forma que ejerciten el mayor nmero de atributos de cada clase de
equivalencia a la vez.
Para aplicar esta tcnica de prueba se tienen en cuenta los siguientes pasos:
Primero se deben identificar las clases de equivalencia lo cual se hace tomando
cada condicin de entrada y aplicndole las directrices antes expuestas.
Para definir las clases de equivalencia hace falta tener en cuenta un conjunto de reglas: Si una condicin de
entrada especifica un rango, entonces se confeccionan una clase de equivalencia vlida y 2 invlidas. Si una
condicin de entrada especifica la cantidad de valores, identificar una clase de equivalencia vlida y dos
invlidas. Si una condicin de entrada especifica un conjunto de valores de entrada y existen razones para
creer que el programa trata en forma diferente a cada uno de ellos, identificar una clase vlida para cada uno
de ellos y una clase invlida. Si una condicin de entrada especifica una situacin de tipo debe ser,
identificar una clase vlida y una invlida. Si existe una razn para creer que el programa no trata de forma
idntica ciertos elementos pertenecientes a una clase, dividirla en clases de equivalencia menores.
Luego de tener las clases vlidas e invlidas definidas, se procede a definir los casos de pruebas, pero
para ello antes se debe haber asignado un identificador nico a cada clase de equivalencia.
Luego entonces se pueden definir los casos teniendo en cuenta lo siguiente:
1. Escribir un nuevo caso de cubra tantas clases de equivalencia vlidas no cubiertas como sea posible
hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba.
2. Escribir un nuevo caso de prueba que cubra una y solo una clase de equivalencia invlida hasta que
todas las clases de equivalencias invlidas hayan sido cubiertas por casos de pruebas.
Con la aplicacin de esa tcnica se obtiene un conjunto de pruebas que reduce el nmero de casos de
pruebas y nos dicen algo sobre la presencia o ausencia de errores. A menudo se plantea que las pruebas a
los software nunca terminan, simplemente se transfiere del desarrollador al cliente. Cada vez que el cliente
usa el programa est llevando a cabo una prueba.
Aplicando el diseo de casos de pruebas al software en cuestin se puede conseguir una prueba ms
completa y descubrir y corregir el mayor nmero de errores antes de que comiencen las pruebas del cliente.
Procedimientos de prueba
Un procedimiento de prueba especifica como realizar uno o varios casos de prueba o parte de estos. Por
ejemplo un procedimiento de prueba puede ser una instruccin para un individuo sobre como ha de realizar un
caso de prueba manualmente, o puede ser una especificaron de cmo interaccionar manualmente con una
herramienta de automatizacin de pruebas para crear componentes ejecutables de pruebas.
El como llevar a cabo un caso de prueba puede ser especificado por un procedimiento de prueba pero es a
menudo til reutilizar un procedimiento de prueba para varios casos de prueba y reutilizar varios
procedimientos de prueba para varios casos de prueba.
Componentes de prueba
Un componente de prueba automatiza uno o varios procedimientos de prueba o parte de ellos.
Los componentes de pruebas pueden ser desarrollados utilizando lenguaje de guiones o un lenguaje de
programacin o pueden ser grabados con una herramienta de automatizacin de pruebas.
Los componentes de pruebas se utilizan para probar los componentes en el modelo de implementacin
proporcionando entradas de prueba, controlando y monitorizando la ejecucin de los componentes a probar y,
posiblemente informando de los resultados de las pruebas.
Plan de Prueba
El propsito del plan de pruebas es dejar de forma explicita el alcance, el enfoque, los recursos requeridos, el
calendario, los responsables y el manejo de riesgos de un proceso de pruebas.
Est constituido por un conjunto de pruebas. Cada prueba debe:
Dejar claro qu tipo de propiedades se quieren probar (correccin, robustez, fiabilidad, amigabilidad,...).
Dejar claro cmo se mide el resultado.
Especificar en qu consiste la prueba (hasta el ltimo detalle de cmo se ejecuta).
Definir cual es el resultado que se espera (identificacin, tolerancia,...). Cmo se decide que el resultado
es acorde con lo esperado?
Las pruebas carecen de utilidad, tanto, s no se sabe exactamente lo que se quiere probar, s no se est claro
cmo se prueba, o si el anlisis del resultado se hace a simple vista. Estas mismas ideas se suelen agrupar
diciendo que un caso de prueba consta de 3 bloques de informacin:
1. El propsito de la prueba.
2. Los pasos de ejecucin de la prueba.
3. El resultado que se espera.
Todos y cada uno de esos puntos deben quedar perfectamente documentados. El plan de pruebas seala el
enfoque, los recursos y el esquema de actividades de prueba, as como los elementos a probar, las
caractersticas, las actividades de prueba, el personal responsable y los riesgos.
Una estrategia de prueba propone movernos haca afuera en una espiral, de manera que primero se prueban
las unidades ms pequeas del diseo del software (clases o mdulos) y despus como se integran los
componentes en los cuales estn contenidas estas unidades.
RUP propone definir casos de prueba de integracin para verificar que los componentes interaccionan entre s
de forma apropiada.
A partir de un caso de uso se pueden realizar pruebas de caja negra, obtenindose varios casos de prueba
que permiten:
Verificar el resultado de la interaccin entre los actores y el sistema.
Comprobar que se satisfagan las precondiciones y poscondiciones del caso de uso.
Comprobar que se siga la secuencia de acciones especificado por el caso de uso.
Tambin se pueden realizar pruebas de caja blanca a partir de la realizacin de un caso de prueba que
permiten obtener casos de prueba en los que se verifica la integracin ante los componentes que
implementan dicho caso de uso.
Como conclusin se podra decir que se pueden definir mltiples casos de prueba de integracin para cada
caso de uso en dependencia de las condiciones de prueba que se tengan en cuenta. El formato para
describirlos podra ser:
Variante 1
1. Caso de uso: <Nombre>
2. Caso de prueba: <Nombre>
3. Entrada:<Descripcin textual de lo que ocurre en el mundo real que hace necesario ejecutar el caso
de prueba, precisando la data de entrada y los comandos a dar por el actor. Descripcin textual del
estado de la informacin almacenada>
4. Resultado:<Descripcin textual del estado en el que queda la informacin y las alertas que puedan
generarse, una vez ejecutado el caso de uso con los valores y el estado especificado en la entrada>
5. Condiciones:<Condiciones que deben cumplirse mientras se ejecuta el caso de prueba>
Variante 2
1. Caso de uso:<Nombre>
2. Rango de Valores de Entrada
3. Rango de Valores de Salida
Esta 2da variante se usa cuando hay varios casos de prueba que verifican diferentes escenarios del mismo
caso de uso.
Las pruebas del sistema se usan para probar que el sistema funciona correctamente como un todo.
Como parte de estas pruebas hay que:
Probar la instalacin del software en la plataforma del cliente.
Verificar el funcionamiento del software en diferentes configuraciones.
Realizar pruebas negativas que busquen que el sistema falle.
Realizar pruebas de tensin o estrs cuando hay competencia por los recursos.


Tcnicas de Grafos Causa - Efecto
El uso de grafos de causa - efecto es una tcnica de casos de prueba que proporciona una
concisa representacin de las condiciones lgicas y sus correspondientes acciones. La tcnica
sigue cuatro pasos:
Se listan para un mdulo las causas (condiciones de entrada) y los efectos (acciones), asignando un
identificador a cada uno de ellos.
Se desarrolla un grafo causa - efecto
Se convierte el grafo en una tabla de decisin
Se convierten las reglas de la tabla de decisin a casos de prueba
Si se ha usado una tabla de decisin como herramienta de diseo, los grafos causa - efecto ya
no son necesarios.