Pruebas de caja negra

Pruebas de Caja Negra

Concepto: La prueba de Caja Negra se centra principalmente en los requisitos funcionales del software.

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, concentrándose en los requisitos funcionales del sistema y ejercitándolos.

La prueba de Caja Negra no es una alternativa a las técnicas de prueba de la Caja Blanca, sino un enfoque complementario que intenta descubrir diferentes tipos de errores a los encontrados en los métodos 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 inicialización y terminación.

Para preparar los casos de pruebas hacen falta un número de datos que ayuden a la ejecución de los estos casos y que permitan que el sistema se ejecute en todas sus variantes, pueden ser datos válidos o inválidos para el programa según 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 técnicas, entre ellas están:

1. Técnica de la Partición de Equivalencia: esta técnica divide el campo de entrada en clases de datos que tienden a ejercitar determinadas funciones del software.
2. Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del programa para manejar datos que se encuentran en los límites aceptables.
3. Técnica de Grafos de Causa-Efecto: es una técnica que permite al encargado de la prueba validar complejos conjuntos de acciones y condiciones.

Dentro del método de Caja Negra la técnica de la Partición de Equivalencia es una de las más efectivas pues permite examinar los valores válidos e inválidos de las entradas existentes en el software, descubre de forma inmediata una clase de errores que, de otro modo, requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de pruebas que descubran clases de errores, reduciendo así en número de clases de prueba que hay que desarrollar.

Partición equivalente

Una partición equivalente es una técnica 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 diseño de estos casos de prueba para la partición equivalente se basa en la evaluación de las clases de equivalencia.

El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada.

Regularmente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica.

Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: Si un parámetro 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 número de atributos de cada clase de equivalencia a la vez.

Para aplicar esta técnica de prueba se tienen en cuenta los siguientes pasos:

• Primero se deben identificar las clases de equivalencia lo cual se hace tomando

cada condición de entrada y aplicándole las directrices antes expuestas.

Para definir las clases de equivalencia hace falta tener en cuenta un conjunto de reglas: Si una condición de entrada especifica un rango, entonces se confeccionan una clase de equivalencia válida y 2 inválidas. Si una condición de entrada especifica la cantidad de valores, identificar una clase de equivalencia válida y dos inválidas. Si una condición 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 válida para cada uno de ellos y una clase inválida. Si una condición de entrada especifica una situación de tipo “debe ser”, identificar una clase válida y una inválida. Si existe una razón para creer que el programa no trata de forma idéntica ciertos elementos pertenecientes a una clase, dividirla en clases de equivalencia menores.

• Luego de tener las clases válidas e inválidas 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 válidas 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 inválida hasta que todas las clases de equivalencias inválidas hayan sido cubiertas por casos de pruebas.

Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número 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 diseño de casos de pruebas al software en cuestión se puede conseguir una prueba más completa y descubrir y corregir el mayor número 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 instrucción para un individuo sobre como ha de realizar un caso de prueba manualmente, o puede ser una especificaron de cómo interaccionar manualmente con una herramienta de automatización 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 programación o pueden ser grabados con una herramienta de automatización de pruebas.

Los componentes de pruebas se utilizan para probar los componentes en el modelo de implementación proporcionando entradas de prueba, controlando y monitorizando la ejecución de los componentes a probar y, posiblemente informando de los resultados de las pruebas.

Plan de Prueba

El propósito 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 (corrección, robustez, fiabilidad, amigabilidad,...).
• Dejar claro cómo se mide el resultado.
• Especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta).
• Definir cual es el resultado que se espera (identificación, tolerancia,...). ¿Cómo 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 cómo se prueba, o si el análisis del resultado se hace a simple vista. Estas mismas ideas se suelen agrupar diciendo que un caso de prueba consta de 3 bloques de información:

1. El propósito de la prueba.
2. Los pasos de ejecución de la prueba.
3. El resultado que se espera.

Todos y cada uno de esos puntos deben quedar perfectamente documentados. El plan de pruebas señala el enfoque, los recursos y el esquema de actividades de prueba, así como los elementos a probar, las características, las actividades de prueba, el personal responsable y los riesgos.

Una estrategia de prueba propone movernos hacía afuera en una espiral, de manera que primero se prueban las unidades más pequeñas del diseño del software (clases o módulos) y después como se integran los componentes en los cuales están contenidas estas unidades.

RUP propone definir casos de prueba de integración 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, obteniéndose varios casos de prueba que permiten:

• Verificar el resultado de la interacción 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.

También se pueden realizar pruebas de caja blanca a partir de la realización de un caso de prueba que permiten obtener casos de prueba en los que se verifica la integración ante los componentes que implementan dicho caso de uso.

Como conclusión se podría decir que se pueden definir múltiples casos de prueba de integración para cada caso de uso en dependencia de las condiciones de prueba que se tengan en cuenta. El formato para describirlos podría ser:

• Variante 1

1. Caso de uso: <Nombre>
2. Caso de prueba: <Nombre>
3. Entrada:<Descripción 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. Descripción textual del estado de la información almacenada>
4. Resultado:<Descripción textual del estado en el que queda la información 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 instalación 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 tensión o estrés cuando hay competencia por los recursos.

Defecto

Un defecto es una anomalía del sistema, como por ejemplo un síntoma de una fallo software o un problema descubierto en una revisión. Un defecto puede ser utilizado para localizar cualquier cosa que los desarrolladores necesitan registrar como síntoma de un problema en el sistema que ellos necesitan controlar y resolver.

Evaluación de prueba

Una evaluación de prueba es una evaluación de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba, la cobertura del código y el estado de los defectos.

Fuentes

Pruebas de software: Caja Negra
Realizando pruebas de caja negra
Las pruebas de caja negra
Ejecución de pruebas de caja negra

Enlaces externos

• http://html.rincondelvago.com/metodos-de-prueba-caja-de-pandora.html Pruebas de caja negra o caja de pandora en RINCONDELVAGO.COM
• http://www.angelfire.com/empire2/ivansanes/bywbox.htm Diseño de casos de prueba en ANGELFIRE.COM
• http://info_system.galeon.com/grupo8.html Método de Prueba de Caja Negra en INFO_SYSTEM.GALEON.COM
• http://testingfuncional.wordpress.com/2011/03/12/%C2%BFtesting-funcional-o-pruebas-de-caja-negra/ Prueba funcional o Prueba de Caja Negra en TESTINGFUNCIONAL.WORDPRESS.COM
• http://es.scribd.com/doc/27668112/1-Pruebas-de-Caja-Negra-y-De Pruebas de caja negra y de interfaz de usuario en ES.SCRIBD.COM
• http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node27.html Enfoque funcional o Prueba de Caja Negra en GEMINI.UDISTRITAL.EDU.CO