Pruebas de caja negra y caja blanca

CAJA NEGRA 

Las pruebas caja negra son las pruebas que se realizan en el sistema cuando  se quiere probar la funcionalidad del producto, que cumpla con los requisitos pedidos, además de minimizar los Bugs y garantizar la calidad sin tener en cuenta la estructura interna del código.

Se debe de tener en cuenta encontrar errores como:

-Funciones incorrectas o faltantes

-Errores de interfaz

-Errores en las estructuras de datos o en el acceso a bases de datos externas

-Errores de comportamiento y rendimiento

-Errores de inicialización y terminación

Se tiene en cuenta:

¿Cómo se prueba la validez funcional?

• ¿Cómo se prueban el comportamiento y el rendimiento del sistema?

• ¿Qué clases de entrada harán buenos casos de prueba?

• ¿El sistema es particularmente sensible a ciertos valores de entrada?

• ¿Cómo se aíslan las fronteras de una clase de datos?

• ¿Qué tasas y volumen de datos puede tolerar el sistema?

• ¿Qué efecto tendrán sobre la operación del sistema algunas combinaciones específicas

de datos?

Métodos:

Métodos de prueba basados en gráficos

El primer paso en la prueba de caja negra es entender los objetos5 que se modelan en software

y las relaciones que conectan a dichos objetos. Una vez logrado esto, el siguiente paso es definir

una serie de pruebas que verifiquen “que todos los objetos tengan la relación mutua esperada

Partición de equivalencia

La partición de equivalencia es un método de prueba de caja negra que

divide el dominio de entrada de un programa en clases de datos de los

que pueden derivarse casos de prueba.

Análisis de valor de frontera

Un mayor número de errores ocurre en las fronteras del dominio de entrada y no en el “centro”.

Por esta razón es que el análisis de valor de frontera (BVA, del inglés boundary value analysis) se

desarrolló como una técnica de prueba. El análisis de valor de frontera conduce a una selección

de casos de prueba que revisan los valores de frontera.

 Prueba de arreglo ortogonal

Existen muchas aplicaciones en las cuales el dominio de entrada es relativamente limitado, es decir, el número de parámetros de entrada es pequeño y los valores que cada uno de los parámetros puede tomar están claramente acotados

La prueba basada en modelo (PBM) 

Es una técnica de prueba de caja negra que usa la información contenida en el modelo de requerimientos como la base para la generación de casos de prueba. En muchos casos, la técnica de prueba basada en modelo usa diagramas de estado UML, un elemento del modelo de comportamiento

Prueba de arquitecturas cliente-servidor

La naturaleza distribuida de los entornos cliente-servidor, los conflictos de rendimiento asociados con el procesamiento de transacciones, la potencial presencia de algunas plataformas de hardware diferentes, las complejidades de la comunicación en red, la necesidad de atender a múltiples clientes desde una base de datos centralizada (o en algunos casos, distribuida) y los requerimientos de coordinación impuestos al servidor se combinan para realizar las pruebas de las arquitecturas cliente-servidor y el software que reside dentro de ellas es considerablemente más difícil que las aplicaciones independientes

Prueba para sistemas de tiempo real

La naturaleza asíncrona, dependiente del tiempo de muchas aplicaciones de tiempo real, agrega

un nuevo y potencialmente difícil elemento a la mezcla de pruebas: el tiempo. El diseñador de

casos de prueba no sólo debe considerar los casos de prueba convencionales, sino también la

manipulación de eventos (es decir, el procesamiento de interrupciones), la temporización de los

datos y el paralelismo de las tareas (procesos) que manejan los datos.

PRUEBAS CAJA BLANCA

Estas pruebas están ligadas a la estructura, diseño y lógica del código fuente, aunque igualmente se presentan con la finalidad de asegurarse que el producto cumpla con los requerimientos y que no hayan inconsistencias en el diseño, estructura y lógica del proyecto.

Se tiene en cuenta:

1) garanticen que todas las rutas independientes dentro de un módulo se revisaron al menos una vez. 

2) revisen todas las decisiones lógicas en sus lados verdadero y falso.

3) ejecuten todos los bucles en sus fronteras y dentro de sus fronteras operativas.

4) revisen estructuras de datos internas para garantizar su validez.

Métodos:

El método de ruta básica 

Permite al diseñador de casos de prueba, derivar una medida de complejidad lógica de un diseño de procedimiento y usar esta.

Prueba de condición

Es un método de diseño de casos de prueba que revisa las condiciones lógicas contenidas en un módulo de programa. Una condición simple es una variable booleana o una expresión relacional, posiblemente precedida de un operador NOT (¬). Una expresión relacional toma la forma.

Prueba de flujo de datos 

Selecciona rutas de prueba de un programa de acuerdo con las ubicaciones de las definiciones y con el uso de variables en el programa. Para ilustrar el enfoque de prueba de flujo de datos, suponga que a cada enunciado en un programa se le asigna un número de enunciado único y que cada función no modifica sus parámetros o variables globales

La prueba de bucle 

Es una técnica de prueba de caja blanca que se enfoca exclusivamente en la validez de los constructos bucle. Pueden definirse cuatro clases diferentes de bucles simples, concatenados, anidados y no estructurados.