En la ingeniería de software este tipo de prueba se utiliza para evaluar las partes esenciales de un sistema, sobre todo en aquellas empresas que fabrican su propio software o que en sus funciones requieren la integración de múltiples aplicaciones.

Cobertura de sentencias: Verifica que todas las líneas de código hayan sido ejecutadas al menos una vez durante las pruebas.

Cobertura de ramas: Evalúa si se han probado todas las rutas posibles dentro de las estructuras de control.

Cobertura de bucles: Asegura que los ciclos hayan sido ejecutados en sus distintas configuraciones (nunca, una vez, múltiples veces).

2. Optimización del Rendimiento

Identificación de cuellos de botella en funciones o bloques de código específicos.

Verificación de la eficiencia en el manejo de recursos (memoria, procesamiento).

3. Validación de Lógica Interna

Detección de errores en cálculos, algoritmos o implementaciones.

Asegura que las funciones y módulos cumplen con los requisitos de diseño.

4. Pruebas de Seguridad Interna

Identifica vulnerabilidades como desbordamientos de buffer, manejo incorrecto de excepciones, o exposición de datos sensibles.

Evalúa la robustez del sistema ante escenarios no previstos.

5. Análisis de Integración

Verifica cómo interactúan los diferentes módulos o componentes del sistema.

Detecta problemas en las interfaces internas, como fallos en el intercambio de datos.

6. Depuración y Mantenimiento

Facilita la localización precisa de errores o defectos, gracias a la visibilidad total del código.

Simplifica las actualizaciones o mejoras al sistema.

2. Cobertura de ramas

3. Cobertura de condiciones

4. Cobertura de bucles

5. Cobertura de caminos

6. Manejo de excepciones y errores

7. Interacciones entre módulos internos

8. Cobertura de datos

9. Complejidad ciclomática

10. Validación de algoritmos

La prueba de caja negra, también conocida como prueba funcional, es una técnica de prueba en la que los evaluadores verifican la funcionalidad del software sin conocer su estructura interna. En lugar de centrarse en el código, los evaluadores se concentran en las entradas y salidas del sistema.

El objetivo principal de la prueba de caja negra es verificar que el software funcione según lo especificado en los requisitos. Esto incluye probar todas las funcionalidades, verificar los límites y casos extremos, y asegurarse de que el sistema maneje adecuadamente los errores.

Descripción: Asegurarse de que todas las especificaciones y expectativas del cliente estén cubiertas.

Pruebas de interfaz

Descripción: Evaluar cómo los componentes del sistema interactúan entre sí a través de sus interfaces.

Validación de entradas y salidas

Descripción: Probar diferentes combinaciones de entradas válidas, inválidas y límites para confirmar que el sistema responde de manera adecuada.

Pruebas de rendimiento

Descripción: Evaluar cómo el sistema maneja volúmenes altos de datos o solicitudes bajo condiciones de carga.

Pruebas de usabilidad

Descripción: Asegurar que el sistema sea fácil de usar y entender desde la perspectiva del usuario final.

Validación de casos límite

Descripción: Comprobar cómo el sistema maneja valores extremos o situaciones inusuales.

Pruebas de compatibilidad

Descripción: Garantizar que el sistema funcione correctamente en diferentes entornos o plataformas.

Pruebas de regresión

Descripción: Confirmar que los cambios realizados en el sistema no afecten funciones previamente implementadas.

Pruebas de seguridad

Descripción: Validar que el sistema sea resistente frente a entradas maliciosas o ataques externos.

Descripción: Dividir las entradas del sistema en clases o grupos equivalentes, donde todos los datos de una clase se tratan de manera similar.

Análisis de valores límite

Descripción: Probar los límites extremos de las entradas permitidas, ya que estos suelen ser puntos donde ocurren errores.

Pruebas basadas en tablas de decisión

Descripción: Utilizar una tabla que relacione condiciones con acciones esperadas para validar combinaciones de entradas.

Pruebas de casos de uso

Descripción: Diseñar casos de prueba basados en los escenarios descritos en los casos de uso del sistema.

Pruebas de transición de estados

Descripción: Evaluar cómo responde el sistema al pasar de un estado a otro, especialmente en sistemas que dependen de eventos o interacciones secuenciales.

Pruebas de gráficos de causa-efecto

Descripción: Modelar relaciones entre condiciones (causas) y sus efectos en el sistema, probando las combinaciones posibles.

Pruebas de compatibilidad

Descripción: Validar que el sistema funcione correctamente en diferentes entornos, plataformas o dispositivos.

Pruebas de regresión funcional

Descripción: Confirmar que nuevas actualizaciones o modificaciones no afecten funcionalidades ya existentes.

Pruebas de respuesta esperada

Descripción: Comparar las salidas del sistema con los resultados esperados basados en los requisitos funcionales.