Pruebas de Software: Tipos, Estrategias y Herramientas Clave

Pruebas de Software: Fundamentos y Objetivos

Las pruebas de software constituyen el proceso de ejecutar un programa con el objetivo principal de identificar errores antes de su entrega al usuario final. Este proceso es crucial para garantizar la calidad y fiabilidad del software.

Objetivos de las Pruebas

• Detectar defectos en el software.
• Una prueba se considera exitosa si revela la presencia de un defecto.
• Una prueba falla si existen defectos, pero no son identificados.

Verificación y Validación

• Pruebas de Verificación: Determinan si el software cumple con las especificaciones de diseño establecidas.
• Pruebas de Validación: Evalúan si el software satisface los requisitos definidos durante el análisis, es decir, si cumple con las necesidades del usuario.

Características de las Pruebas Efectivas

Las pruebas de software efectivas se caracterizan por los siguientes atributos:

• Operabilidad: El software debe operar de manera limpia y sin fallos inesperados durante las pruebas.
• Observabilidad: Los resultados de cada caso de prueba deben ser claramente observables y medibles.
• Controlabilidad: Las pruebas deben ser automatizables y optimizadas en la medida de lo posible.
• Descomposición: Las pruebas deben ser dirigidas y enfocadas en componentes específicos.
• Simplicidad: Se debe reducir la complejidad lógica y arquitectónica para simplificar las pruebas.
• Estabilidad: Aunque se requieren cambios durante las pruebas, estos deben ser gestionados y controlados.
• Comprensibilidad: El diseño del software debe ser comprensible para facilitar el proceso de prueba.

Las pruebas revelan errores, el cumplimiento de los requerimientos, el desempeño del software y proporcionan una indicación general de la calidad.

Responsables de las Pruebas

• Desarrollador: Posee un profundo entendimiento del sistema, pero puede ser condescendiente. Su enfoque principal es el "entregable".
• Probador Independiente: También debe comprender el sistema, pero su objetivo principal es identificar fallas y asegurar la calidad del producto.

Pruebas de Caja Blanca

Las pruebas de caja blanca, también conocidas como pruebas de caja transparente (clear box), se caracterizan por tener acceso al código fuente del software que se está probando.

Objetivo Principal

Asegurar que todas las sentencias y condiciones del código se ejecuten al menos una vez.

Tipos de Pruebas de Caja Blanca

• Pruebas de cubrimiento
• Pruebas de condiciones
• Pruebas de bucles

Justificación de las Pruebas de Caja Blanca

• Los caminos básicos del código a menudo se consideran de baja probabilidad de ejecución, pero pueden contener errores.
• Los errores tipográficos son aleatorios y pueden ocurrir en cualquier parte del código.
• Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de ejecución de un camino del programa.

Se utilizan para encontrar errores de tipo: bucles, lógicos y estructuras internas de datos.

Herramientas para Pruebas de Caja Blanca

• Notación de Grafo de Flujo: Representa el flujo de control lógico mediante una notación visual. Cada instrucción estructurada tiene su correspondiente símbolo en el grafo.
• Complejidad Ciclomática: Es una métrica que proporciona una medida cuantitativa de la complejidad lógica de un programa. En el contexto del camino básico, define el número de caminos independientes y proporciona un límite para las pruebas que deben realizarse. Un camino independiente introduce al menos una nueva sentencia o condición. Un nodo predicado es aquel del que emergen dos o más aristas.
• Matrices de Grafos: Se utilizan para obtener el grafo de flujo y determinar un conjunto de caminos básicos. Es una matriz cuadrada cuyo tamaño (filas y columnas) es igual al número de nodos del grafo de flujo, y las entradas representan las aristas entre los nodos.

Pruebas de Cubrimiento

• Buscan ejecutar cada sentencia al menos una vez.
• Requieren varios casos de prueba.
• Se determinan los posibles caminos independientes.
• Cada condición debe cumplirse en un caso y no cumplirse en otro. Generalmente, se necesitan tantos casos como condiciones, más uno (número ciclomático).
• Puede ser imposible cubrir el 100% debido a código que nunca se ejecuta (condiciones imposibles). Ejemplo: detección y notificación de errores internos en un código sin errores.

Pruebas de Bucles

• Se buscan números de repeticiones especiales.
• Bucles Simples: Repetir cero, una y dos veces. Repetir un número medio (típico) de veces. Repetir el máximo - 1, el máximo y ¡el máximo + 1!
• Bucles Anidados: Repetir un número medio (típico) de veces los bucles internos, el mínimo los externos, y variar las repeticiones del bucle intermedio ensayado.
• Ensayar con cada nivel de anidamiento.

Pruebas de Caja Negra

Las pruebas de caja negra (black box) se enfocan en la interfaz del software, sin tener conocimiento de su estructura interna. Se busca ejercitar cada elemento de la interfaz.

• Se centran en los requerimientos funcionales del software.
• Permiten obtener un conjunto de condiciones de entrada que ejerciten completamente los requisitos funcionales.
• No son una alternativa a las pruebas de caja blanca, sino un complemento.

Pruebas de Clase de Equivalencia: Representan un rango de valores para la técnica de análisis.

Estrategias de Prueba del Software

• Pruebas de Unidades: Se enfocan en probar componentes individuales del software de forma aislada.
• Pruebas de Integración: Verifican la interacción entre diferentes componentes o módulos del sistema.
• Pruebas de Regresión: Se realizan después de realizar cambios en el software (correcciones o mejoras) para asegurar que no se hayan introducido nuevos errores.
• Pruebas de Validación: Determinan si el software cumple con los requisitos del usuario y si es apto para su uso.