Introducción

Cuando intentamos encontrar errores en el software que se ha desarrollado, podemos hacerlo de dos maneras:

1. Comprobar que los elementos del software encajan correctamente y que los procedimientos internos cumplen las especificaciones. Estas pruebas se llaman pruebas de la caja blanca y se centran en la estructura de control del programa. Tratan de buscar errores en los caminos independientes de cada módulo, los bucles, las estructuras internas de datos y las decisiones lógicas.

1. Pruebas del camino básico: estas pruebas utilizan el grafo de flujo para calcular la complejidad lógica de un programa, que nos dará el número de caminos linealmente independientes en la estructura de control del programa. En segundo lugar, se diseñan casos de prueba que obliguen a la ejecución de cada uno de estos caminos del programa.
2. Pruebas de condiciones: con éstas se trata de encontrar errores en las condiciones simples y compuestas del programa. Los tipos de errores que se pueden hallar dependen del elemento de la condición que sea incorrecto: el operador lógico, el paréntesis lógico, el operador racional o la expresión aritmética.
3. Pruebas de flujo de datos: éstas seleccionan caminos de prueba para un programa buscando la ubicación de las definiciones y los usos de las variables de dicho programa.
4. Prueba de bucles: estas pruebas se centran en la validez de las construcciones de los bucles, elementos importantes de cada algoritmo del programa. Para cada tipo de bucle (simple, anidado, concatenado y no estructurado), se aplica un tipo de prueba diferente; en el caso de los bucles no estructurados, lo mejor es rediseñarlos.

2. Comprobar que las funciones que se ejecutan en el software son operativas y sirven para conseguir la función para la que se las requiere. Este tipo de pruebas se denominan pruebas de la caja negra, y confirman que el software responde bien en las entradas, tanto válidas como no válidas; que las salidas son correctas, que las funciones son operativas, que el programa se comporta de acuerdo con las especificaciones y que no corrompe otros programas o datos del software. Los errores que intenta encontrar son: funciones incorrectas o ausentes, estructuras de datos incorrectos, errores en el acceso a bases de datos externas, errores en la interfaz, errores de rendimiento, errores de inicio y finalización.

Se trata de construir casos de pruebas que nos permitan saber si existe algún problema con ciertos valores de entrada, sobre todo con los valores límite, qué volúmenes y niveles de datos tolerará el software y qué efecto tendrán determinadas combinaciones específicas de datos sobre el software.

Hay que distinguir entre datos de prueba (entradas que se formulan para probar el software) y casos de prueba (que contienen especificaciones de entrada y salida). Nos encontramos con diferentes formas de construir casos de prueba, que mostramos a continuación:

1. Partición de equivalencia: consiste en determinar qué clases de entradas tienen propiedades comunes, para que, de esta manera, podamos detectar errores genéricos. Las clases se disponen en función de las condiciones de entrada.
2. Análisis de valores límite: técnica que se centra en los valores límite de las entradas. Cada tipo de condición de entrada tiene unos valores límite: si se trata de un rango de valores entre x e y, éstos son los valores límite; si es un número de valores, los valores límite son el máximo y el mínimo. También son valores límite los que se obtienen de los extremos de un rango de salida, y el máximo y mínimo de un número de valores de salida.
3. Técnicas de gráficos de causa-efecto: esta técnica trata de diseñar casos que permitan probar todas las combinaciones de causas (condiciones de entrada) que provocan un efecto (acciones).