Pruebas de Unidad

Aplicar Pruebas de Unidad a un sistema existente será difícil. Si el sistema es mediano o grande, es conveniente planear sus pruebas y aplicar los cambios necesarios a través de varias versiones futuras. Las pruebas unitarias aíslan cada parte del programa y muestran que las partes individuales son correctas. A pesar de esto no descubrirán todos los errores del código, no descubren errores de integración, de rendimiento ni otros problemas que afectan a todo el sistema en su conjunto.

Las pruebas de unidad están divididas en dos grupos, en Pruebas de Caja Blanca y Pruebas de Caja Negra.

En las pruebas de Caja Blanca se observa siempre el código, las mismas se realizan para probarlo todo. Estas pruebas se aplican mediante diferentes métodos.

-Prueba de Condición: Es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa.

-Prueba de Flujo de Datos: Es un método en el que se seleccionan caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.

-Prueba de Bucles: Es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles.

-Prueba del Camino Básico: Esta permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución.

Las pruebas de Caja Blanca verifican la implementación interna de la unidad. Para cada componente se estudiará su implementación interna y se tratará de verificar su correcto comportamiento algorítmico. Se comprobarán los caminos comunes, los críticos, los menos conocidos y otros asociados con riesgos altos. Lograr un buen método con pruebas de caja blanca es un objetivo deseable pero no suficiente a todos los efectos. Un programa puede estar perfecto en todos sus términos y sin embargo no servir a la función que se pretende.

Por su parte, 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.

Las pruebas de Caja Negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (ejemplo: canales de comunicaciones, etc.). Estas pruebas verifican el comportamiento de la unidad observable externamente. Cuando el número de entradas y salidas es grande, se dividen estas en clases de equivalencias. Una clase de equivalencia es un conjunto de valores de entradas o salidas para los que se supone que un componente se comporta de forma similar.

El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables) sino en los datos que se le pasan a estas funciones. El conjunto de datos posibles suele ser muy amplio (por ejemplo, un entero).

Durante la lectura de los requisitos del sistema, se pueden encontrar una serie de valores singulares que marcan diferencias de comportamiento. Estos valores son claros candidatos a marcar clases de equivalencia: por abajo y por arriba.

Una vez identificadas las clases de equivalencia significativas en dicho módulo, se procede a coger un valor de cada clase, que no esté justamente al límite de la clase. Este valor aleatorio, sustituye a cualquier valor normal que se le pueda pasar en la ejecución real.

La experiencia muestra que un buen número de errores aparecen en torno a los puntos de cambio de clase de equivalencia. Hay una serie de valores denominados "frontera" (o valores límite) que conviene probar, además de los elegidos en el párrafo anterior. Usualmente se necesitan 2 valores por frontera, uno justo abajo y otro justo encima.

Las pruebas de caja negra convencen de que un programa hace lo que se quiere pero no de que haga (además) otras cosas menos aceptables. Al realizar pruebas funcionales lo que se pretende es ponerse en los pies del usuario, usar el sistema como él lo usaría, sin embargo el probador debe ir más allá que cualquier usuario, generalmente se requiere apoyo de los usuarios finales ya que ellos pueden aportar mucho en el desarrollo de casos de prueba complejos, enfocados básicamente al negocio, posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional.

Generalmente los usuarios realizan las pruebas con la idea de que todo debería funcionar, a diferencia del probador que tiene más bien una misión destructiva, su objetivo será encontrar alguna posible debilidad y si la llega a ubicar se esforzará porque deje de ser pequeña y posiblemente se convertirá en un gran error, cada error encontrado es un éxito.