Introducción a las Pruebas de Software
Es fundamental realizar pruebas exhaustivas para verificar que el software es correcto y cumple con los objetivos establecidos, dado que los errores humanos son comunes en el proceso de desarrollo. Las pruebas buscan identificar fallos relacionados con la codificación, las especificaciones y el diseño. Durante esta fase, se llevan a cabo tareas de verificación y validación, y se crean casos de prueba, que son documentos que especifican los valores de entrada, la salida esperada y las condiciones previas para la ejecución de una prueba.
Recomendaciones Clave para Pruebas Efectivas
- Cada prueba debe definir los resultados esperados.
- Un programador debe evitar probar su propio software para asegurar objetividad.
- Revisar meticulosamente los resultados de cada prueba.
- Incluir datos de entrada tanto válidos como no válidos e inesperados.
- Comprobar si el software hace lo que debe y, crucialmente, lo que no debe.
Flujo de Trabajo para las Pruebas de Software
- Generar un plan de pruebas.
- Diseñar las pruebas a partir del plan.
- Generar los casos de prueba.
- Definir los procedimientos de la prueba.
- Ejecutar las pruebas.
- Evaluar los resultados.
- Evaluar los posibles errores y generar un informe.
- Depurar y analizar los errores detectados.
Deficiencias Comunes en el Desarrollo de Software
Es importante distinguir entre los diferentes tipos de problemas que pueden surgir:
- Error: Es la equivocación cometida por el programador durante el desarrollo.
- Defecto: Es la manifestación de un error que se encuentra presente en el software.
- Fallo: Ocurre cuando el sistema no se comporta como debería debido a un defecto.
Técnicas Fundamentales para Casos de Prueba
Las pruebas de software verifican y validan un producto antes de su puesta en marcha. Una prueba es una actividad ejecutada en un sistema bajo circunstancias previamente especificadas para observar, registrar y evaluar los resultados.
Tipos de Pruebas por Técnica
- Pruebas de Caja Blanca: Se basan en el examen minucioso de los detalles procedimentales del código de la aplicación. Requieren conocimiento de la estructura interna del software.
- Pruebas de Caja Negra: No es necesario conocer la estructura interna del software. Su objetivo es validar que el software es operativo. Se utilizan para identificar:
- Funcionalidades incorrectas o ausentes.
- Errores de interfaz.
- Errores en estructuras de datos.
- Errores de rendimiento.
- Errores de inicialización o finalización.
- Pruebas de Regresión: Comprueban que los cambios realizados en la aplicación no introduzcan un comportamiento no deseado o errores adicionales. Se llevan a cabo cada vez que se realiza una modificación en el sistema para asegurar que no se produzcan efectos negativos.
Estrategia de Pruebas de Software
Un producto se prueba y valida de forma progresiva hasta alcanzar la validación completa del sistema.
Fases de la Estrategia de Pruebas
Prueba de Unidad:
Se prueba la unidad más pequeña del software con el objetivo de eliminar errores en la lógica interna. Se emplean tanto técnicas de caja blanca como de caja negra.
Prueba de Integración:
Se observa cómo interactúan los módulos entre sí. Existen dos enfoques fundamentales:
- Integración No Incremental: Se prueban todos los módulos juntos y combinados.
- Integración Incremental: El programa se va construyendo y probando poco a poco, añadiendo módulos progresivamente.
Pruebas de Validación:
Comprueban que el software funciona de acuerdo con los requisitos del cliente. A menudo se realizan como pruebas de caja negra:
- Prueba Alfa: El cliente prueba el software en el entorno del desarrollador, y este anota los fallos o errores detectados.
- Prueba Beta: La realizan usuarios reales en su propio entorno, quienes registran los fallos detectados para informar al desarrollador.
Prueba de Sistema:
Verifica que todos los elementos encajan de forma adecuada y que se alcanzan la funcionalidad y el rendimiento total del sistema. Incluye:
- Prueba de Recuperación: Se fuerza un fallo en el software para garantizar que es capaz de recuperarse correctamente.
- Prueba de Seguridad: Se evalúa el sistema desde el punto de vista de la ciberseguridad, buscando vulnerabilidades.
- Prueba de Resistencia: Evalúa el comportamiento del software ante situaciones que demandan una gran cantidad de recursos o estrés.
Documentación Esencial en el Proceso de Pruebas
Durante el proceso de pruebas, es crucial generar varios documentos:
Plan de Pruebas:
Describe el alcance, el enfoque, los recursos y el calendario de las pruebas. Identifica los elementos a probar, las tareas, el personal involucrado y los riesgos asociados.
Especificaciones de Prueba:
Compuestas por tres documentos principales:
Especificación del Diseño de la Prueba:
Identifica los requisitos, los casos de prueba y los procedimientos necesarios para llevar a cabo las pruebas.
Especificaciones de los Casos de Prueba:
Documenta los valores de entrada, las condiciones y los resultados previstos para cada caso de prueba.
Especificación de los Procedimientos de Prueba:
Detalla los pasos para ejecutar las pruebas. Además, se generan otros informes importantes:
- Informe que identifica los elementos que están siendo probados.
- Registro de las pruebas ejecutadas.
- Informe de incidentes de la prueba (errores o defectos encontrados).
- Informe resumen de las actividades de prueba.
Pruebas de Código: Métodos y Técnicas
Las pruebas de código consisten en la ejecución de un programa con el objetivo de detectar errores. Para ello:
- Se define un conjunto de entradas y condiciones de ejecución.
- Se observan y registran los resultados obtenidos.
- Se comparan con los resultados esperados.
1. Prueba del Camino Básico (Caja Blanca)
Permite medir la complejidad lógica de un programa y definir un conjunto básico de caminos de ejecución, asegurando que cada sentencia del código se ejecuta al menos una vez.
Complejidad Ciclomática:
Determina el número de pruebas necesarias y el riesgo asociado:
- 1-10: Programa simple, bajo riesgo.
- 11-20: Programa moderadamente complejo, riesgo medio.
- 21-50: Programa complejo, alto riesgo.
- +50: Programa no testable, riesgo muy alto.
Pasos para Realizar la Prueba del Camino Básico:
- Dibujar el grafo de flujo:
- Los nodos representan una o varias sentencias.
- Los nodos predicado contienen condiciones (bifurcaciones).
- Las aristas conectan los nodos.
- Las regiones son áreas delimitadas por aristas y nodos.
- Calcular la Complejidad Ciclomática (V(G)) con una de estas fórmulas:
- V(G) = Número de regiones
- V(G) = Número de aristas – Número de nodos + 2
- V(G) = Número de nodos predicado + 1
- Determinar los caminos independientes, donde cada camino introduce nuevas sentencias de código.
- Diseñar los casos de prueba asegurando que se cubren todas las condiciones de los nodos predicado.
2. Partición en Clases de Equivalencia (Caja Negra)
Este método de caja negra divide los valores de entrada en clases equivalentes para reducir el número de pruebas necesarias.
Reglas para Definir Clases de Equivalencia:
- Rango de valores: 1 clase válida, 2 clases no válidas.
- Valor específico: 1 clase válida, 2 clases no válidas.
- Miembro de un conjunto: 1 clase válida, 1 clase no válida.
- Condiciones lógicas: 1 clase válida, 1 clase no válida.