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 cul 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 hacia 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.