Pruebas de software para GSI: caja blanca, caja negra y niveles de prueba

Las pruebas de software son uno de esos apartados que parecen «de sentido común» hasta que llega una pregunta tipo test sobre complejidad ciclomática o valores límite. Este contenido pertenece al tema 7 del Bloque III (Desarrollo de sistemas) del temario de GSI: «Pruebas. Planificación y documentación. Utilización de datos de prueba. Pruebas de software, hardware, procedimientos y datos». Aquí nos centramos en un punto muy concreto y muy preguntado: las técnicas de caja blanca y caja negra y los niveles de prueba, con ejemplos resueltos.

Para qué sirven las pruebas (y qué no pueden demostrar)

Probar es ejecutar el software con la intención de encontrar defectos, no de demostrar que funciona. Es una idea clásica que conviene tener clara para el examen: una batería de pruebas que pasa sin errores no garantiza la ausencia de defectos, solo que no se han encontrado con esos casos. Por eso una prueba «buena» es la que tiene una probabilidad alta de descubrir un error todavía no detectado.

Tres conceptos que se confunden a menudo:

Error (equivocación): la acción humana incorrecta, por ejemplo, programar mal una condición.
Defecto (fallo en el código): la imperfección que queda en el producto como resultado de ese error.
Fallo (avería): el comportamiento incorrecto observable cuando se ejecuta el código defectuoso.

Otra pareja clásica: verificación responde a «¿estamos construyendo el producto correctamente?» (conforme a la especificación) y validación a «¿estamos construyendo el producto correcto?» (lo que el usuario necesita).

Caja blanca y caja negra: la diferencia clave

La pregunta que distingue ambos enfoques es sencilla: ¿miro el código para diseñar los casos de prueba?

Aspecto	Caja blanca (estructural)	Caja negra (funcional)
Base para diseñar casos	Estructura interna del código	Especificación: entradas y salidas esperadas
Qué busca	Recorrer caminos, decisiones y bucles	Funciones incorrectas o ausentes, errores de interfaz
Técnicas típicas	Cobertura de sentencias, de decisiones y de condiciones; camino básico; bucles	Particiones de equivalencia, valores límite, tablas de decisión, transición de estados
Quién la suele aplicar	Desarrollador (pruebas unitarias)	Equipo de pruebas y usuarios (sistema, aceptación)
Limitación	No detecta funciones que faltan	No garantiza recorrer todo el código

No son excluyentes: se complementan. Lo habitual es usar caja blanca en los niveles bajos (componentes) y caja negra a medida que se sube hacia el sistema completo. A la combinación de ambas se le suele llamar caja gris.

Técnicas de caja blanca

Criterios de cobertura

Cobertura de sentencias: cada instrucción se ejecuta al menos una vez. Es el criterio más débil.
Cobertura de decisiones (ramas): cada decisión toma al menos una vez el valor verdadero y otra el falso. Implica la cobertura de sentencias.
Cobertura de condiciones: cada condición simple dentro de una decisión compuesta toma ambos valores.
Decisión/condición: combina las dos anteriores.

Camino básico y complejidad ciclomática

La técnica del camino básico, propuesta por McCabe, representa el código como un grafo de flujo y calcula la complejidad ciclomática V(G), que indica el número de caminos independientes y, por tanto, el número mínimo de casos de prueba necesarios para recorrerlos. Hay tres formas equivalentes de calcularla:

V(G) = A − N + 2, siendo A el número de aristas y N el de nodos del grafo.
V(G) = P + 1, siendo P el número de nodos predicado (decisiones simples).
V(G) = número de regiones del grafo plano (contando la región exterior).

Ejemplo. Una función de cálculo de una tasa contiene un if que comprueba si el solicitante está exento, un if/else que aplica una bonificación y un while que recorre los conceptos de la liquidación. Hay tres decisiones simples, así que V(G) = 3 + 1 = 4: necesitamos al menos cuatro casos de prueba para cubrir los caminos independientes. Ojo con las condiciones compuestas: if (a && b) cuenta como dos nodos predicado, porque en el grafo se descompone en dos decisiones.

Técnicas de caja negra con un ejemplo resuelto

Supón un formulario de inscripción en un curso de formación que acepta edades entre 18 y 65 años, ambos incluidos.

Particiones (clases) de equivalencia

Se divide el dominio de entrada en clases cuyos valores el programa debería tratar igual, y se elige un representante de cada una:

Clase válida: 18 ≤ edad ≤ 65 (representante: 40).
Clase no válida: edad < 18 (representante: 10).
Clase no válida: edad > 65 (representante: 80).
Clase no válida: valor no numérico (representante: «abc»).

Regla práctica: los casos válidos pueden agruparse para cubrir varias clases válidas a la vez, pero cada clase no válida se prueba en un caso separado, para que un error no enmascare a otro.

Análisis de valores límite

Los defectos se concentran en los bordes (un < donde debía ir <=). Por eso se prueban los valores justo en el límite y a cada lado: 17, 18, 65 y 66 (y, en la versión ampliada, también 19 y 64). Esta técnica complementa a las particiones: en lugar de un representante cualquiera, se eligen los extremos de cada clase.

Otras técnicas que debes reconocer

Tablas de decisión: útiles cuando el resultado depende de combinaciones de condiciones (por ejemplo, exento sí/no y bonificado sí/no).
Transición de estados: para sistemas cuyo comportamiento depende del estado (un expediente en borrador, presentado, resuelto).
Conjetura de errores: basada en la experiencia del probador (campos vacíos, ceros, caracteres especiales).

Niveles de prueba: de la unidad a la aceptación

Nivel	Qué se prueba	Enfoque habitual	Responsable típico
Unitarias	Cada componente o módulo aislado	Caja blanca, con stubs y drivers	Desarrollador
Integración	Interfaces e interacción entre módulos	Incremental: descendente, ascendente o mixta	Equipo de desarrollo
Sistema	El sistema completo frente a los requisitos, incluidos los no funcionales	Caja negra: rendimiento, seguridad, volumen, usabilidad	Equipo de pruebas
Implantación	El sistema en el entorno de operación	Caja negra en el entorno real	Equipo de implantación y sistemas
Aceptación	Que el sistema satisface las necesidades del usuario	Caja negra, con criterios pactados	Usuarios

En Métrica v3, la metodología de referencia en la Administración española, las pruebas unitarias, de integración y de sistema se realizan en el proceso de Construcción del Sistema de Información (CSI), mientras que las de implantación y aceptación pertenecen al proceso de Implantación y Aceptación del Sistema (IAS).

Integración descendente y ascendente: stubs y drivers

Descendente (top-down): se empieza por el módulo principal y los módulos inferiores que aún no existen se sustituyen por stubs (resguardos) que simulan su respuesta.
Ascendente (bottom-up): se empieza por los módulos de más bajo nivel y se usan drivers (conductores) que los invocan simulando al módulo superior.
Big bang: se integra todo a la vez. Es la opción menos recomendable, porque localizar el origen de un fallo resulta difícil.

Truco para no confundirlos: el stub está «debajo» (lo llaman) y el driver está «encima» (llama).

Pruebas de regresión

No son un nivel, sino un tipo de prueba transversal: tras cualquier cambio (corrección, mejora o mantenimiento) se vuelven a ejecutar pruebas ya superadas para comprobar que no se ha roto nada que antes funcionaba. Son las candidatas naturales a la automatización dentro de la integración continua.

Planificación, documentación y datos de prueba

El temario también pide planificación y documentación. La serie de normas ISO/IEC/IEEE 29119 es la referencia internacional en pruebas de software: su parte 1 recoge conceptos y definiciones, la parte 2 los procesos de prueba, la parte 3 la documentación (plan de pruebas, especificación de casos, informes) y la parte 4 las técnicas de diseño de pruebas. Sustituyó a normas anteriores como IEEE 829 en el ámbito de la documentación.

Sobre los datos de prueba, lo importante en la Administración es no usar datos personales reales sin protección: lo correcto es emplear datos sintéticos o datos reales previamente anonimizados o seudonimizados, en un entorno separado del de producción.

Pregunta tipo test de ejemplo

En una estrategia de integración ascendente (bottom-up), los módulos auxiliares que simulan la llamada desde el módulo de nivel superior se denominan:

Stubs o resguardos.
Drivers o conductores.
Mocks de aceptación.
Oráculos de prueba.

Respuesta correcta: B. En la integración ascendente se prueban primero los módulos de bajo nivel, que necesitan a alguien que los invoque: ese papel lo hacen los drivers. Los stubs (A) se usan en la integración descendente para sustituir a módulos inferiores aún no desarrollados. Un oráculo (D) es el mecanismo que determina cuál es el resultado esperado de una prueba, y «mocks de aceptación» (C) no es un término de la clasificación.

Resumen para repasar

Probar es intentar encontrar defectos; las pruebas no demuestran su ausencia.
Caja blanca = diseño a partir del código; caja negra = diseño a partir de la especificación.
V(G) = A − N + 2 = decisiones + 1 = regiones, y marca el mínimo de casos para el camino básico.
Particiones de equivalencia: un caso por cada clase no válida. Valores límite: prueba el borde y sus vecinos.
Niveles: unitarias → integración → sistema → implantación → aceptación. En Métrica v3, las tres primeras en CSI y las dos últimas en IAS.
Descendente usa stubs; ascendente usa drivers. La regresión se repite tras cada cambio.
ISO/IEC/IEEE 29119 es la serie de normas de pruebas de software; nada de datos personales reales sin anonimizar.

Practica este tema con tests y flashcards

Leer esto una vez ayuda; recordarlo el día del examen exige practicarlo. En PreparaGSI tienes tests con explicación, flashcards con repetición espaciada y audios de todo el temario, incluido el tema de pruebas del Bloque III. Regístrate gratis y empieza a repasar hoy mismo.