Caja Negra y Blanca

7
CAJA NEGRA Y CAJA BLANCA Caja negra Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro. Caja blanca En estas pruebas estamos siempre observando el código, que las pruebas se dedican a ejecutar con ánimo de "probarlo todo". Esta noción de prueba total se formaliza en lo que se llama "cobertura" y no es sino una medida porcentual de cuánto código hemos cubierto. Métodos de prueba Basados en grafos En este método se debe entender los objetos (Objetos de datos, objetos de programa tales como módulos o colecciones de sentencias del lenguaje de programación) 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. • Modelado del flujo de transacción. Los nodos representan los pasos de alguna transacción (por ejemplo, los pasos necesarios para una reserva en una línea aérea usando un servicio en línea), y los enlaces representan las conexiones lógicas entre los pasos: Por ejemplo, vuelo. Información. Entrada es seguida de validación/disponibilidad. Procesamiento).

Transcript of Caja Negra y Blanca

Page 1: Caja Negra y Blanca

CAJA NEGRA Y CAJA BLANCA

Caja negraLas pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.

Caja blancaEn estas pruebas estamos siempre observando el código, que las pruebas se dedican a ejecutar con ánimo de "probarlo todo". Esta noción de prueba total se formaliza en lo que se llama "cobertura" y no es sino una medida porcentual de cuánto código hemos cubierto.

Métodos de prueba

Basados en grafosEn este método se debe entender los objetos (Objetos de datos, objetos de programa tales como módulos o colecciones de sentencias del lenguaje de programación) 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.

• Modelado del flujo de transacción. Los nodos representan los pasos de alguna transacción (por ejemplo, los pasos necesarios para una reserva en una línea aérea usando un servicio en línea), y los enlaces representan las conexiones lógicas entre los pasos:

Por ejemplo, vuelo. Información.Entrada es seguida de validación/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 petición por teléfono).

• 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 planificación. 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 ejecución requeridos al ejecutarse el programa.

• Gráfica Causa-efecto. La gráfica Causa-efecto representa una ayuda gráfica en seleccionar, de una manera sistemática, un gran conjunto de casos de prueba. Tiene un efecto secundario beneficioso en precisar estados incompletos y ambigüedades en la especificación. Un gráfico de causa-efecto es un lenguaje formal al cual se traduce una especificación.

Page 2: Caja Negra y Blanca

El gráfico es realmente un circuito de lógica digital (una red combinatoria de lógica), pero en vez de la notación estándar de la electrónica, se utiliza una notación algo más simple.

Partición Equivalente

Se identifican las clases de equivalencia. Las clases de equivalencia son identificadas tomando cada condición de entrada (generalmente una oración o una frase en la especificación) y repartiéndola en dos o más grupos. 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 número único a cada clase de equivalencia. Hasta que todas las clases de equivalencia válidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia válida.

Análisis de valores límite

Los errores tienden a darse más en los límites del campo de entrada que en el centro. Por ello, se ha desarrollado el análisis de valores límites (AVL) como técnica de prueba. El análisis de valores límite lleva a una elección de casos de prueba que ejerciten los valores límite. El análisis de valores límite es una técnica de diseño de casos de prueba que completa a la partición equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la elección de casos de prueba en los extremos de la clase.

Prueba de la tabla ortogonal

Hay aplicaciones donde el número de parámetros de entrada es pequeño y los valores de cada uno de los parámetros está claramente delimitado. Cuando estos números son muy pequeños (por ejemplo, 3 parámetros de entrada tomando 3 valores diferentes). La prueba de tabla ortogonal permite proporcionar una buena cobertura de pruebas con bastantes menos casos de prueba que en la estrategia exhaustiva.

Adivinando el error

Dado un programa particular, se conjetura, por la intuición y la experiencia, ciertos tipos probables de errores y entonces se escriben casos de prueba para exponer esos errores. Es difícil dar un procedimiento para esta técnica puesto que es en gran parte un proceso intuitivo y ad hoc. La idea básica es enumerar una lista de errores posibles o de situaciones propensas a error y después escribir los casos de prueba basados en la lista. Por ejemplo, la presencia del valor 0 en la entrada de un programa es una situación con tendencia a error.

Page 3: Caja Negra y Blanca

Ejemplo:

En el caso de automatizar un proceso dentro del sistema de inventarios, es necesario que el administrador conozca los procesos inherentes al sistema, sus entradas y salidas, así como estos procesos transforman las entradas en salidas. Además las funciones de cada persona que participa en el sistema. Por ejemplo conocer el detalle el método de costeo de inventario que se utiliza, si se establecen o no alarmas con existencias, etc.

Un contador debe conocer el funcionamiento interno contable que lleva la empresa para dar referencia para donde van las entradas y las salidas, además cada departamento de la empresa participa en el programa. El contador debe Vanalizar los procesos internos del sistema que transformarán las entradas y las salidas, y verifica lo que transforma las entradas en salidas.

Page 4: Caja Negra y Blanca

EJEMPLOS GRAFICADOS

CAJA NEGRA DE ALGORITMOS

En la Caja Negra de algoritmos son imperceptibles para el usuario, es decir, están ocultos y, por tanto, el usuario no puede saber cómo funciona internamente el proceso. Estos algoritmos son muy comunes en los buscadores. Cabe aclarar que este tipo de algoritmos pueden entenderse si se trabaja estudiando sus características de entrada y de salida.

CAJA NEGRA CON CAJA DE MERMELADAS

Page 5: Caja Negra y Blanca

CAJA NEGRA DE SISTEMA DIGESTIVO

CAJA NEGRA DE RETROALIMENTACION

La retroalimentación se produce cuando las salidas del sistema o la influencia de las salidas de los sistemas en el contexto, vuelven a ingresar al sistema como recursos o información.La retroalimentación permite el control de un sistema y que el mismo tome medidas de corrección en base a la información retroalimentada.

CAJA NEGRA DE MATERIA