Diseño y realización de pruebas

Introducción al diseño y realización de pruebas

Cuando un equipo de desarrollo acepta el encargo de crear una aplicación informática, desea que el resultado de su trabajo sea de calidad. Esto significa que la aplicación debe responder a las necesidades del cliente y contener el menor número posible de errores.

El objetivo de la etapa de pruebas, posterior a la programación, es descubrir defectos antes de que el software sea entregado al cliente.

En esta unidad se explica cómo abordar esta importante tarea y las diferentes técnicas de diseño de casos de prueba. También se verá de qué manera un entorno de desarrollo puede asistir a los programadores en las tareas de depuración o corrección de errores encontrados durante esta fase.

Para finalizar, se describe el empleo de una herramienta de pruebas unitarias que permite realizar pruebas de manera automatizada.

Filosofía de las pruebas de software

Las pruebas constituyen una de las tareas del ciclo de vida del software y tienen como objetivo fundamental la detección de defectos cometidos inadvertidamente durante la construcción del software.

Detectar defectos no significa que los desarrolladores sean negligentes. Todos somos humanos, y los errores son inevitables. Por ello, las pruebas buscan localizar fallos antes de que los descubra el cliente.

Otro factor a considerar es la percepción psicológica: mientras que análisis, diseño y programación se consideran tareas constructivas, las pruebas pueden percibirse como destructivas. Esto puede llevar a que los desarrolladores diseñen pruebas para demostrar que el software funciona en lugar de descubrir errores. Es fundamental superar esta mentalidad.

En proyectos grandes, se suele involucrar un equipo de pruebas independiente que colabora con los desarrolladores para garantizar pruebas exhaustivas.

Además, hay dos aspectos estratégicos que considerar:

1. Estrategia de aplicación: decidir qué partes del software se someterán a prueba a medida que se desarrolla.
2. Técnicas de diseño de casos de prueba: una vez seleccionada la parte a probar, decidir cómo realizar la prueba usando la técnica apropiada.

En otras palabras, un caso de prueba indica:

• Qué datos de entrada se deben suministrar al programa.
• Qué resultados se esperan obtener.
• Cuál es el objetivo de la prueba.

Tras ejecutar la prueba, se comprueba si la salida coincide con la esperada. Si coincide, no se detectó defecto; si no coincide, se realiza la depuración, que consiste en localizar y corregir el error. Luego, se pueden realizar nuevos casos de prueba.

Pruebas en el desarrollo de Software

Estrategias de pruebas del software

Las pruebas siempre comienzan por los componentes más pequeños, es decir, se empieza probando pequeñas porciones de software y se va incrementando de manera progresiva el alcance de la prueba. Se suelen llevar a cabo cuatro tipos de pruebas secuenciales que se exponen en los siguientes subapartados.

PRUEBA DE UNIDAD

Se comienza probando o bien módulos individuales de software, en caso de que se desarrolle software convencional, o bien clases, si se trata de software orientado a objetos. En este último caso, la prueba de unidad conlleva realizar también pruebas a nivel de método, es decir, para cada método no trivial habrá que comprobar si su comportamiento es el adecuado. Es obvio pues que para probar correctamente una clase entera, es necesario realizar pruebas con cada uno de sus métodos.

Importancia de la prueba de unidad

La prueba de unidad permite localizar errores en componentes específicos antes de integrarlos en el sistema completo, garantizando un software más fiable y facilitando la depuración temprana.

PRUEBA DE INTEGRACIÓN

El objetivo de estas pruebas, que se realizan a continuación de las pruebas de unidad, es comprobar si las clases de las que consta el software funcionan correctamente cuando cooperan entre ellas con el objetivo de realizar las tareas encomendadas al programa.

Estrategias de integración

Existen dos estrategias principales para las pruebas de integración en sistemas orientados a objetos.

1. Prueba basada en hebra: integra el conjunto de clases requeridas para responder a una entrada o evento del sistema. Cada hebra se integra y prueba de manera individual.
2. Prueba basada en uso: se comienza probando las clases independientes, aquellas que usan muy pocas clases de servidor o ninguna. Después de probar estas, se examina la siguiente capa de clases dependientes, utilizadas por las primeras. Esta secuencia continúa hasta que se construye todo el sistema.

PRUEBA DEL SISTEMA

El proceso de prueba de un sistema integrado de hardware y software busca comprobar si cumple con los requisitos especificados, los cuales incluyen:

• Cumplimiento de todos los requisitos funcionales, considerando el producto software final al completo, en un entorno de sistema.
• El funcionamiento y rendimiento de las interfaces hardware, software, de usuario y de operador.
• Adecuación de la documentación de usuario.
• Ejecución y rendimiento en condiciones límite y de sobrecarga.

Tipos de pruebas del sistema

Es posible distinguir varios tipos de pruebas del sistema, cada una enfocada a un aspecto diferente de la calidad:

• Pruebas de recuperación: se fuerza al software a fallar y se verifica que la recuperación se realice de manera adecuada. Se aplican a sistemas tolerantes a fallos donde la recuperación debe ser rápida.
• Pruebas de seguridad: verifican que los mecanismos de protección del sistema protejan frente a accesos ilegales. El objetivo es evaluar cómo el sistema responde a intentos de penetración y si la dificultad de atacarlo supera los beneficios para quien lo intenta.
• Pruebas de esfuerzo: exponen al sistema a situaciones extremas para comprobar su comportamiento ante circunstancias inusuales pero posibles en la vida real, como uso máximo de memoria o búsquedas intensivas en disco.
• Pruebas de rendimiento: miden si el sistema cumple con los requisitos de tiempo de respuesta y eficiencia en situaciones concretas.
• Pruebas de despliegue: verifican que la aplicación funcione correctamente en distintas plataformas y sistemas operativos, incluyendo todas las combinaciones posibles en aplicaciones web.

PRUEBA DE VALIDACIÓN

El objetivo de la prueba de validación, también llamada prueba de aceptación, es determinar si el software es considerado válido por parte de la persona usuaria y si está preparado para su implantación en el entorno de las personas que lo vayan a usar.

Criterios de validación

La validez del software debe basarse en criterios de validación o aceptación explícitos, incluidos en la ERS (Especificación de Requisitos del Software). La ausencia de requisitos implícitos evita problemas a la hora de considerar el software listo para entrega.

Según Piattini et al. (2007), la calidad del software se puede definir como la concordancia con los requisitos explícitamente establecidos, los estándares de desarrollo fijados y los requisitos implícitos deseados por el usuario.

En este tipo de pruebas, participan activamente las personas que van a utilizar el software, ayudadas por el equipo de pruebas, ejecutando los casos necesarios. Esta es la fase final del proceso, en la que la persona usuaria da su consentimiento para su uso.

Todos estos tipos de pruebas se muestran en el modelo en V, variante del modelo en cascada.

Pruebas de validación de Software

Técnicas de diseño de casos de prueba

Las técnicas de diseño de casos de prueba son las diferentes formas en que se pueden generar casos de prueba para probar el software. Dependiendo del enfoque que se adopte, se puede aplicar uno de los dos siguientes tipos de técnicas:

• Pruebas de caja blanca o pruebas estructurales: examinan los detalles de cada módulo, para lo que se debe disponer del código fuente. A través de dicho código, se prueban los diferentes caminos, los bucles, las variables, etcétera.
• Pruebas de caja negra o pruebas funcionales: se considera al software como una caja negra que recibe una serie de entradas y proporciona una serie de salidas. El objetivo de estas pruebas es validar los requisitos funcionales.

Pruebas de caja blanca

El objetivo de las pruebas de caja blanca es crear casos de prueba que permitan revisar detalles internos del software. Así, de estas pruebas se derivan casos de prueba que:

• Garantizan que todas las rutas independientes dentro de un módulo se revisen al menos una vez.
• Revisan todas las decisiones lógicas en sus lados verdadero y falso.
• Ejecutan todos los bucles en sus fronteras y dentro de sus fronteras operativas.
• Revisan estructuras de datos internas para garantizar su validez.

Prueba del camino básico

Esta técnica permite generar una métrica de la complejidad del módulo probado llamada complejidad ciclomática de McCabe. Es un número entero que indica el número de caminos independientes que hay en el código y, en consecuencia, el número de casos de prueba necesarios para garantizar que se recorren todas las sentencias al menos una vez.

Para calcular esta métrica es necesario representar el código en un grafo de flujo siguiendo estos pasos:

1. Asignar un número único a cada sentencia o condición. Las instrucciones en secuencia pueden tratarse como un único bloque/nodo. Cada nodo se representa con un círculo.
2. Unir los nodos mediante aristas (flechas) que representan el flujo de control.

Ejemplos de representación del grafo de flujo

La complejidad ciclomática V(G) se puede calcular de tres formas:

• V(G) = Número de regiones del grafo (incluyendo la exterior).
• V(G) = A - N + 2 (Aristas - Nodos + 2).
• V(G) = NP + 1 (Nodos predicado o condiciones + 1).

Prueba de bucles

Esta técnica se centra exclusivamente en las estructuras repetitivas. Los casos de prueba varían según el tipo de bucle:

• Bucles simples: Para un máximo de n iteraciones, probar: saltar el bucle, una iteración, dos iteraciones, m iteraciones (m < n), y finalmente n-1, n y n+1 iteraciones.
• Bucles anidados: Se debe comenzar por el bucle más interno (con los demás al mínimo), probarlo como bucle simple y trabajar de dentro hacia fuera manteniendo los internos en valores típicos.
• Bucles concatenados: Si son independientes, se prueban como simples. Si son dependientes, se usa el enfoque de bucles anidados.

Prueba de flujos de datos

Selecciona caminos de acuerdo con las ubicaciones de las definiciones y usos de variables.

• DEF(I): Conjunto de variables que se definen (asignan valor) en la instrucción I.
• USO(I): Conjunto de variables cuyo valor se usa en la instrucción I.

Una definición de una variable X en I está "viva" en I' si hay un camino entre ambas que no contiene ninguna otra definición de X.

Pruebas funcionales o de caja negra

El objetivo de las pruebas de caja negra es crear casos de prueba que permitan revisar todos los requisitos funcionales de un programa. A tal efecto, existen diferentes técnicas de diseño de casos de prueba de caja negra que se exponen a continuación.

Particiones o clases de equivalencia

Por medio de esta técnica, se identifican un conjunto de clases de equivalencia o tipos de valores que se deben asignar a los datos de entrada. El primer paso es determinar las condiciones de entrada del programa, que pueden ser:

• Un valor específico.
• Un rango de valores permitido (ejemplo: entre 18 y 65).
• Un conjunto de valores permitidos (ejemplo: 18, 36 y 72).
• Una condición lógica o booleana (ejemplo: es español o no lo es).

Análisis de valores límite

Es una técnica complementaria a las clases de equivalencia. Sus diferencias principales son:

• Se seleccionan los valores que están justo en los límites de la clase.
• Se generan casos teniendo en cuenta tanto las entradas como el dominio de salida.

Reglas de generación:

Consiste en generar una lista de errores que suelen cometer quienes desarrollan aplicaciones, basándose en la experiencia y situaciones comunes. Ejemplos típicos:

• El valor 0 tanto en la entrada como en la salida.
• Listas vacías, con un solo valor o con todos los valores iguales.
• Introducción de caracteres no numéricos en campos de número.
• Interpretaciones incorrectas de la especificación por parte del programador.

Estrategia de aplicación

El proceso de prueba de una aplicación completa debe seguir este orden lógico:

Documentación de las pruebas

La documentación de las pruebas es conveniente para una buena organización de estas y para asegurar su reutilización. Se deben documentar tanto el diseño de las pruebas como el resultado o ejecución de las mismas.

Documentación del diseño de las pruebas

En cuanto a la documentación del diseño de las pruebas, es conveniente crear los siguientes documentos:

Documentación de la ejecución de las pruebas

Esta documentación es importante para la eficacia en la detección y corrección de defectos y para dejar constancia de los resultados. La ejecución toma como entrada las especificaciones de los casos y procedimientos de prueba, y debe generar dos tipos de documentos:

La ejecución de las pruebas correspondiente a cada especificación del diseño genera asimismo un informe resumen de pruebas, que incluye:

• Resumen de la evaluación de los elementos probados.
• Variaciones del software como resultado de las pruebas.
• Valoración de la cobertura de la prueba.
• Resumen de los resultados obtenidos.
• Resumen de las actividades (incluyendo consumo de recursos).

Análisis causal de los defectos

La valoración de los procesos de prueba es importante porque puede ayudar en proyectos posteriores. Por ello, es conveniente realizar un análisis causal, cuyo objetivo es proporcionar información sobre la naturaleza de los defectos encontrados.

Por cada defecto encontrado, se debería registrar la siguiente información:

Depuración (Debugging) y Pruebas de Regresión

La depuración es la tarea que hay que realizar tras una prueba exitosa, es decir, tras una prueba que detecta un fallo o, más bien, el síntoma de un defecto. En ese caso, lo que se hace es localizar el defecto en el software y corregirlo.

A veces, la localización del defecto es una tarea sencilla, pero otras veces no tanto. Para ello, resultan fundamentales las herramientas de depuración (debuggers) que proporcionan los entornos de desarrollo modernos. En ocasiones, para detectar el defecto real oculto tras un síntoma, puede ser necesario crear nuevos casos de prueba específicos.

Anatomía del Depurador en IntelliJ IDEA

Cuando activas el modo debug (usando el icono del bicho 🐞), IntelliJ abre una ventana especializada. Entender sus paneles es la diferencia entre perderse o encontrar el error rápido:

Comandos de Navegación

Para controlar el avance del programa mientras está pausado, usamos:

Pruebas Automáticas con JUnit 5

Las pruebas de unidad o unitarias son aquellas que aíslan y verifican la unidad más pequeña de código comprobable en una aplicación: la clase y sus métodos. Tradicionalmente, los estudiantes prueban su código ejecutando el método main e imprimiendo resultados por consola (System.out.println). Sin embargo, este enfoque manual presenta graves problemas en el mundo profesional:

• No son escalables: A medida que el proyecto crece a miles de clases, es imposible probar todo manualmente antes de cada entrega.
• Error humano: Dependen de que el desarrollador mire la consola y juzgue si el resultado es correcto o no.
• Efímeras: Una vez ejecutadas, no queda un registro formal de que el sistema funcionaba correctamente en ese momento.

Para solucionar esto, utilizamos JUnit 5, el marco de trabajo (framework) estándar en la industria Java. JUnit nos permite escribir código que prueba nuestro código. Estas pruebas se convierten en un activo del proyecto: una "red de seguridad" que se ejecuta en milisegundos y nos alerta inmediatamente si un cambio reciente ha roto una funcionalidad existente (Pruebas de Regresión).

El Sujeto de Prueba: Clase Cuenta

Para entender JUnit, necesitamos una clase con "reglas de negocio". Utilizaremos una clase Cuenta que simula una cuenta bancaria. Observa que los métodos ingresar y extraer tienen validaciones (if) que lanzan excepciones. Estas validaciones son precisamente lo que debemos probar.

1public class Cuenta {
2    private String numero;
3    private double saldo;
4
5    public Cuenta(String numero, double saldo) {
6        this.numero = numero;
7        this.saldo = saldo;
8    }
9
10    public void ingresarDinero(double importe) {
11        if (importe <= 0) {
12            throw new IllegalArgumentException("El importe a ingresar debe ser positivo");
13        }
14        this.saldo += importe;
15    }
16
17    public void extraerDinero(double importe) {
18        if (importe <= 0) {
19            throw new IllegalArgumentException("El importe a extraer debe ser positivo");
20        }
21        if (importe > saldo) {
22            // Protección: No permitimos números rojos.
23            // En un caso real, podríamos lanzar InsufficientFundsException
24            return; 
25        }
26        this.saldo -= importe;
27    }
28
29    public double getSaldo() { return saldo; }
30    public String getNumero() { return numero; }
31}

Ciclo de Vida del Test (Lifecycle)

Una de las reglas de oro de las pruebas unitarias es la Independencia. El resultado de la prueba A nunca debe depender de si la prueba B se ejecutó antes o después. Si la prueba A retira dinero de la cuenta, la prueba B no debería encontrarse la cuenta vacía.

Para garantizar esto, JUnit crea una nueva instancia de la clase de test para cada método de prueba. Además, nos ofrece anotaciones para controlar qué ocurre antes y después de cada ejecución.

Aserciones: Verificando la Realidad

Un test sin aserciones no sirve de nada. La aserción es la sentencia que valida si el resultado obtenido es igual al esperado. JUnit 5 proporciona la clase estática Assertions con múltiples métodos. Todos siguen la lógica: "Espero X, pero he recibido Y".

Tratamiento de Excepciones

Un error común en principiantes es pensar que si el código lanza una excepción, el test ha fallado. ¡Al contrario! Si diseñamos un sistema robusto, queremos que lance excepciones cuando alguien usa mal el sistema.

Sintaxis Avanzada con Lambdas

El método assertThrows utiliza una función lambda (() -> código) para envolver la llamada que esperamos que falle. Además, devuelve la excepción capturada para que podamos inspeccionar su mensaje.

1@Test
2@DisplayName("Ingreso negativo lanza excepción controlada")
3void testIngresoNegativo() {
4    // 1. Ejecutamos y capturamos
5    Exception excepcionCapturada = assertThrows(IllegalArgumentException.class, () -> {
6        cuenta.ingresarDinero(-500.0);
7    });
8
9    // 2. Inspeccionamos el mensaje
10    String mensajeEsperado = "El importe a ingresar debe ser positivo";
11    String mensajeReal = excepcionCapturada.getMessage();
12
13    // 3. Validamos que el mensaje sea útil para el usuario
14    assertEquals(mensajeEsperado, mensajeReal, "El mensaje de error no es el correcto");
15}

Pruebas Parametrizadas

A veces queremos probar la misma lógica con muchos valores distintos (ej: ingresar 10, 50, 100, 5000). Escribir 4 métodos `@Test` copiando y pegando código es una mala práctica (viola el principio DRY - Don't Repeat Yourself).

JUnit 5 ofrece @ParameterizedTest y @ValueSource para ejecutar el mismo test múltiples veces con diferentes argumentos.

1@ParameterizedTest
2@ValueSource(doubles = { 10.0, 50.5, 100.0, 2000.0 })
3@DisplayName("Ingresar varias cantidades válidas")
4void testVariosIngresos(double cantidad) {
5    double saldoInicial = cuenta.getSaldo();
6    cuenta.ingresarDinero(cantidad);
7    assertEquals(saldoInicial + cantidad, cuenta.getSaldo());
8}

Este único método se ejecutará 4 veces, una por cada número en @ValueSource. En la consola de IntelliJ veremos 4 checks verdes.

Análisis de Cobertura (Code Coverage)

¿Cómo sabemos si hemos probado todo? Aquí entra el Análisis de Cobertura. Es una métrica porcentual que indica cuánto código de nuestra aplicación se ha ejecutado durante los tests. IntelliJ IDEA pinta el margen izquierdo del editor (gutter) con colores semáforo.