Métodos y tipos de pruebas
Este artículo es una explicación de conceptos sobre métodos de prueba y su clasificación, incluyendo preguntas de examen y etiquetas.
En resumen
¿Quién prueba? – Persona (manual) vs. máquina (automatizado), desarrollador vs. usuario.
¿Qué se prueba? – Unitario (componente), integración, sistema (E2E).
¿Cómo se prueba? – Abajo‑arriba/arriba‑abajo, estático/dinámico, caja negra/caja blanca, exploratorio.
¿Cuándo se prueba? – Antes/después, aceptación.
¿Por qué se prueba? – Regresión, carga/rendimiento, smoke.
Descripción técnica comprimida
¿Quién prueba?
- Desarrollador: unitarios, integración, contrato, análisis estático, TDD
- QA/Tester: pruebas de sistema, E2E, pruebas exploratorias, aceptación
- Máquina: regresión automatizada, pruebas de carga, pipelines CI
¿Qué se prueba?
- Prueba unitaria: clase/función aislada
- Prueba de integración: colaboración entre componentes (BD, red)
- Prueba de sistema/E2E: flujo completo del usuario a través de UI e infraestructura
¿Cómo se prueba?
- Abajo‑arriba: primero unidades pequeñas, luego integración
- Arriba‑abajo: primero stubs, luego componentes reales
- Estático: análisis de código sin ejecución (lint, escaneo de seguridad)
- Dinámico: se ejecuta el código (unitarias, integración, E2E)
- Caja negra: solo a través de interfaces, sin conocimiento de la estructura interna
- Caja blanca: conocimiento de la estructura interna, cobertura de ramas/caminos
- Exploratorio: pruebas basadas en experiencia, sin script
Cuándo y por qué
- Antes (fase de desarrollo): TDD, unitarias, análisis estático
- Después: pruebas de sistema, aceptación, regresión
- Regresión: asegurar que los cambios no rompan nada
- Carga/estrés: verificar el comportamiento bajo pico de carga
- Smoke: verificación rápida de que las funciones principales funcionan tras el despliegue
Puntos clave para examen
- Clasificación de pruebas (quién, qué, cómo, cuándo, por qué) diferenciar claramente
- Unitarias vs. integración vs. E2E delimitación clara
- Caja negra vs. caja blanca aplicar con ejemplos
- Dobles de prueba: stubs vs. mocks
- Características de buenas pruebas unitarias (correctas, aisladas, rápidas, significativas, mantenibles)
- Determinación de casos de prueba: clases de equivalencia, análisis de valores límite, cobertura de ramas/caminos
- Proceso de prueba: selección, criterios, datos, protocolo, evaluación
- TDD: ciclo rojo‑verde‑refactor
- Regresión, carga, smoke como tipos de prueba típicos
Componentes principales
- Clasificación de pruebas (quién, qué, cómo, cuándo, por qué)
- Niveles de prueba (unitaria, integración, sistema)
- Enfoques de prueba (abajo‑arriba, arriba‑abajo, caja negra, caja blanca)
- Dobles de prueba (stub, mock, fake, spy)
- Determinación de casos de prueba (clases de equivalencia, valores límite, cobertura)
- Automatización de pruebas (frameworks, CI, reportes)
- Gestión de datos de prueba (fixtures, factories, seed)
- Proceso de prueba (planificación, ejecución, evaluación, protocolo)
- Aseguramiento de calidad (revisiones, auditorías, métricas)
- Herramientas (frameworks de prueba, librerías de mock, CI/CD)
Ejemplo práctico (procesamiento de pedidos)
Unitaria (caja blanca):
- Clase: ServicioDescuento
- Método: calcularDescuento(cliente, articulo)
- Caso de prueba: cliente nuevo, artículo estándar → esperado 0 %
- Cobertura: todas las ramas (tipo de cliente, tipo de artículo)
Integración (caja negra):
- Componentes: servicio → repositorio → BD
- Prueba: guardar/leer un pedido con contenedor de BD real
- Criterio: datos persistidos = datos esperados
E2E (arriba‑abajo):
- Flujo: navegador → portal → API → BD → message broker
- Escenario: realizar pedido, simular pago
- Expectativa: confirmación visible, entrada en BD, evento
Regresión (automatizada):
- Antes: pedido con 5 artículos, 10 % descuento → 110 €
- Después: mismo escenario → debe seguir siendo 110 €
Prueba de carga:
- Perfil de carga: 500 usuarios simultáneamente, 10 s
- Criterio: percentil 95 tiempo de respuesta <300 ms, sin errores
Smoke:
- Después del despliegue: login, buscar artículos, agregar al carrito
- Criterio: las 3 acciones exitosas
Ventajas y desventajas
Ventajas
- Cobertura sistemática de riesgos
- Detección temprana de errores (unitarias/TDD)
- Calidad comprobable (pruebas de regresión)
- Menores costos de fallos (pruebas de carga)
Desventajas
- Esfuerzo de mantenimiento de pruebas
- Pruebas inestables cuando hay dependencias poco claras
- Enfoque en “números” en lugar de valor sin objetivos claros
Preguntas típicas de examen (con respuesta breve)
- ¿Caja negra vs. caja blanca? Caja negra: solo a través de interfaces; caja blanca: conocimiento de la estructura interna.
- ¿Unitaria vs. integración? Unitaria: aislada; integración: colaboración real entre componentes.
- ¿Qué es TDD? Desarrollo dirigido por pruebas: rojo (prueba falla) → verde (prueba pasa) → refactor.
- ¿Características de buenas pruebas unitarias? Correctas, aisladas, rápidas, significativas, mantenibles, simples de ejecutar.
- ¿Métodos de determinación de casos de prueba? Clases de equivalencia, análisis de valores límite, cobertura de ramas/caminos.