Las pruebas de software se clasifican por conocimiento del código (caja negra, caja blanca y gris), por nivel (unitarias, de integración, de sistema y de aceptación) y por objetivo (funcionales, no funcionales y de regresión). En caja negra se usan la partición de equivalencia y el análisis de valores límite; en caja blanca, la cobertura de sentencias, decisiones y condiciones.
El tema 19 del programa de técnico especialista de sistemas y TI trata de las pruebas del software: fundamentos, pruebas de caja negra y de caja blanca, estrategias y tipos de pruebas, y herramientas para gestionar y automatizar los tests. Es un tema con terminología muy concreta, ideal para ganar puntos si te sabes bien las definiciones. Los conceptos que siguen son los generales de la ingeniería del software, sin dependencia de una norma concreta.
Verificación y validación
Dos palabras que se confunden en los tests. La verificación comprueba que el producto se construye conforme a su especificación («¿estamos construyendo el producto correctamente?»). La validación comprueba que el producto satisface la necesidad del usuario («¿estamos construyendo el producto correcto?»). Las pruebas dinámicas ejecutan el programa; las estáticas (revisiones, inspecciones, análisis estático) analizan el código o los documentos sin ejecutarlos.
Partición de equivalencia, valores límite, tablas de decisión
Caja blanca
La estructura interna del código
Caminos, decisiones y condiciones del programa
Cobertura de sentencias, de decisiones y de condiciones; prueba del camino básico
Caja gris
Conocimiento parcial de la estructura
Mezcla de ambos enfoques
Pruebas de integración con acceso a datos internos
Un ejemplo de caja negra: valores límite
Un formulario acepta edades de 18 a 65 años. Con partición de equivalencia hay tres clases: menor de 18 (inválida), de 18 a 65 (válida) y mayor de 65 (inválida). Con análisis de valores límite se prueban los bordes de cada clase:
Valor a probar
Resultado esperado
17
Rechazado (justo por debajo del límite)
18
Aceptado (límite inferior)
65
Aceptado (límite superior)
66
Rechazado (justo por encima del límite)
Un ejemplo de caja blanca: cobertura
Si el código tiene una decisión if (a > 0 && b > 0), la cobertura de sentencias exige ejecutar cada línea al menos una vez; la cobertura de decisiones, que la expresión se evalúe una vez como verdadera y otra como falsa; y la cobertura de condiciones, que cada condición individual (a > 0 y b > 0) tome ambos valores. La cobertura de decisiones es más exigente que la de sentencias.
Por nivel de prueba
Nivel
Qué prueba
Quién suele hacerla
Unitarias
Cada componente o función por separado
Desarrolladores
Integración
La interacción entre componentes y módulos
Desarrolladores o equipo de pruebas
Sistema
El sistema completo frente a sus requisitos
Equipo de pruebas independiente
Aceptación
Si el sistema cumple lo que el cliente necesita
El usuario o cliente
Las pruebas de integración pueden hacerse de forma descendente (se empieza por los módulos de nivel superior y se simulan los inferiores con stubs), ascendente (se empieza por los inferiores y se usan drivers) o incremental. Es una pregunta clásica: stub sustituye a un módulo llamado; driver sustituye a un módulo que llama.
Por objetivo
Funcionales: comprueban qué hace el sistema.
No funcionales: rendimiento, carga, estrés, seguridad, usabilidad y accesibilidad.
De regresión: comprueban que un cambio no ha roto lo que ya funcionaba. Son las candidatas ideales a automatizar.
De humo (smoke): una comprobación rápida de que lo esencial arranca.
Carga frente a estrés. Las pruebas de carga comprueban el comportamiento con la carga esperada; las de estrés, más allá de ese límite para ver cómo y cuándo falla el sistema.
Automatización y herramientas
El programa menciona las herramientas para gestionar y automatizar pruebas. Ejemplos habituales: JUnit para pruebas unitarias en Java y Selenium para pruebas de interfaz web. Una buena práctica es la llamada pirámide de pruebas: muchas pruebas unitarias baratas, menos de integración y pocas de interfaz, que son más lentas y frágiles. La automatización encaja con la integración continua, donde cada cambio dispara el conjunto de pruebas.
Las pruebas conectan con la metodología de desarrollo: en los marcos ágiles se prueba de forma continua, como explicamos en el artículo de programación orientada a objetos y metodologías ágiles. Para el bloque de gestión del servicio, repasa ITIL v4, y para los estándares sanitarios en los que las pruebas de interoperabilidad son críticas, HL7, FHIR y DICOM.
Practica el temario de Técnico TI
Tests por tema con penalización real y simulacros de 100 preguntas.
¿Qué diferencia hay entre pruebas de caja negra y de caja blanca?
En caja negra se prueba el comportamiento sin conocer el código, a partir de la especificación. En caja blanca se conoce la estructura interna y se diseñan casos para recorrer sus caminos, decisiones y condiciones.
¿Qué es el análisis de valores límite?
Es una técnica de caja negra que prueba los valores situados en los bordes de cada clase de equivalencia, como 17, 18, 65 y 66 en un rango de edad de 18 a 65.
¿Cuáles son los niveles de prueba del software?
Unitarias, de integración, de sistema y de aceptación. Van de lo más pequeño (un componente) a lo más global (que el cliente acepte el producto).
¿Qué son las pruebas de regresión?
Son las que comprueban que un cambio en el software no ha estropeado funcionalidades que ya funcionaban. Se suelen automatizar.
💻
Practica ahora con preguntas reales de TI SERGAS
2.400+ preguntas tipo test · Tests por tema · Simulacros cronometrados · 100% gratis
🍪 Usamos cookies propias y de terceros para analizar el tráfico (Google Analytics), y recoger opiniones (Trustpilot). Puedes aceptar todas, rechazar o consultar el detalle en nuestra
Política de cookies.