Capítulo 1. Fundamentos de Pruebas > 1.¿Por qué son necesarias las pruebas?
La importancia económica del software
- El funcionamiento de maquinarias y equipamientos depende en gran medida, actualmente y en diferentes industrias, del software.
- No es posible imaginar grandes sistemas, en el ámbito de cualquier industria, funcionando sin software.
Calidad de software
- Cada vez más, la calidad de software se ha convertido en un factor determinante del éxito de sistemas técnicos o comerciales y productos.
Pruebas para la mejora de la calidad
- Las pruebas y revisiones aseguran la mejora de la calidad de productos de software así como de la calidad del proceso de desarrollo en sí.
Detalle
En un proyecto de desarrollo de software los errores (bugs en inglés) puede presentarse en cualquiera de las etapas del ciclo de vida del software.
Aún cuando se intente detectarlos despúes de cada fase utilizando técnicas como la inspección, algunos errores permanecen sin ser descubiertos.
Por lo tanto es muy probable que el código final contenga errores de requerimientos y diseño, adicionales a los introducidos en la codificación.
Las pruebas de software son una parte importante pero muy costosa del proceso de desarrollo de software.
Pueden llegar a representar entre el 30 y 50 % del costo total del desarrollo del software [Myers, 2004]
Sin embargo, los costos de las fallas en un software en operación pueden llegar a ser mucho mayores (catastróficos)
Algunos de los peores errores de la historia:
Se colapsa el aeropuerto de Los Angeles (2007)
Más de 17 mil personas se quedaron en tierra por un problema de software que provocó conflictos en una tarjeta de red que bloqueó toda la red informática.
El lanzamiento comercial y la producción del Airbus A380 se retrasa más un año (2006)
Diferencias entre versiones de las herramientas CAD (Computer Aided Design) usadas en las fábricas de Hamburgo y Toulouse provocaron un problema en el cableado (530km
de cables)
Sobredosis radiológica en el Instituto Nacional del Cáncer de Panama (2000)
Errores en los procedimientos y un fallo de software causan que se apliquen dosis erróneas de radiación 8 personas murieron y 20 tuvieron problemas de salud graves.
Los médicos responsables del hecho fueron acusados de asesinato.
Como pueden observar las pruebas de software tienen un rol muy importante en el aseguramiento de la calidad ya que permiten detectar los errores introducidos en las
fases previas del proyecto.
Conceptos básicos
La forma más común de organizar las actividades relacionadas al proceso de pruebas de software [Burnstein, 2003] son:
-Planeación, fija las metas y una estrategia general de pruebas
-Preparación, se describe el procedimiento general de pruebas y se generan los casos de prueba específicos
-Ejecución, incluye la observación y medición del comportamiento del producto
-Análisis, incluye verificación y análisis de resultados para determinar si se observaron fallas
-Seguimiento, si se detectaron fallas, se inicia un monitoreo para asegurar que se remueva el origen de éstas
Casos de prueba y criterios de prueba
-Generar casos de prueba efectivos que revelen la presencia de fallas es fundamental para el éxito del proceso de pruebas (etapa de preparación)
-Idealmente, se debería determinar un conjunto de casos de prueba tales que su ejecución exitosa implique que no hay errores en el software desarrollado
-Comúnmente este objetivo ideal no se puede lograr debido a las limitaciones prácticas y teóricas
-Cada caso de prueba cuesta dinero: esfuerzo para generarlo, tiempo de cómputo para ejecutarlo, esfuerzo para evaluar los resultados
-Por lo tanto, el número de casos de prueba necesarios para detectar los errores debe ser minimizado para reducir costos
Objetivo del proceso de pruebas
-Los dos objetivos principales del proceso de pruebas:
–Maximizar el número de errores detectados (cobertura)
–Reducir al mínimo el número de casos de prueba (costo)
-Como con frecuencia son contradictorios, el problema de seleccionar el conjunto de casos de prueba con el que un programa debe ser probado se vuelve una tarea muy
compleja.
Niveles de prueba
-Generalmente se comienza probando las partes más pequeñas y se continua con las más grandes
-Para el software convencional
–El módulo (componente) se prueba primero
–Se continua con la integración de módulos
-Para el software orientado a objetos
–Se prueba primero una clase (atributos, métodos, colaboración)
Pruebas Unitarias
-Se concentran en probar cada componente individualmente para asegurar que funcione de manera apropiada como unidad
-Emplean técnicas de prueba que recorren caminos específicos en la estructura de control de los componentes (pruebas estructurales)
-Herramientas
–JUnit
–TestNG (versión mejorada de JUnit)
–PHPUnit
–CPPUnit
–NUnit (.Net)
–MOQ (creación dinámica de objetos simuladores, mocks)
Pruebas de Integración
-Las pruebas de integración tienen dos objetivos principales:
–Descubrir errores asociados con las interfaces de los módulos
–Ensamblar sistemáticamente los módulos individuales para formar subsistemas y al final un sistema completo
-Principalmente se utilizan técnicas que verifican el correcto manejo de las entradas y salidas del software (pruebas funcionales)
-También pueden emplearse técnicas que recorren rutas específicas en la estructura de control del software (pruebas estructurales)
-Existen dos enfoques principales para las pruebas de integración (incremental):
–Integración descendente (componentes de funcionales)
–Integración ascendente (componentes de infraestructura, e.g. acceso a BD)
Pruebas de Integración, enfoque descendente
-El módulo principal es usado como controlador y todos sus módulos subordinados son remplazados por módulos simulados (stubs)
-Los módulos simulados se remplazan uno a la vez con los componentes reales (en profundidad) y se van probando
Pruebas de Integración, enfoque ascendente
-A diferencia del enfoque descendente, éste inicia la construcción y prueba de los módulos en los niveles más bajos de la estructura del programa
-No se requiere el uso de módulos simulados (stubs)
Pruebas de alto nivel
-Pruebas de validación, se enfocan en los requerimientos
–Pruebas de aceptación: desarrolladas por el cliente
–Pruebas alfa: realizadas por el usuario con el desarrollador como observador
–Pruebas beta: realizadas por el usuario en su entorno de trabajo (sin observadores)
-Pruebas del sistema, se enfocan en la integración del sistema (Hw, información, personas)
–Prueba de recuperación, forza el software a fallar en diferentes formas y verifica que éste se recupere adecuadamente
–Prueba de seguridad, verifica que los mecanismos de protección integrados en el sistema realmente impidan irrupciones inapropiadas
–Prueba de resistencia, ejecutan un sistema de manera que se demanden recursos en cantidades, frecuencias o volúmenes anormales
–Prueba de desempeño, prueba el desempeño del software en tiempo de ejecución dentro del contexto de un sistema integrado
Método de prueba
-Existen dos métodos básicos para diseñar casos de prueba
–De caja blanca (o estructurales)
–De caja negra (o funcionales)
Método de prueba, de caja blanca
-Verifican la correcta implementación de las unidades internas, las estructuras y sus relaciones
-Hacen énfasis en la reducción de errores internos
-Los métodos de caja blanca o estructurales permiten derivar casos de prueba que
–Garanticen que todas las rutas independientes dentro del módulo se ejecuten al menos una vez
–Ejecuten los lados verdadero y falso de todas las decisiones lógicas
–Ejecuten todos los ciclos dentro y en sus límites operacionales
–Ejerciten las estructuras de datos internas para asegurar su validez
-Algunos ejemplos de técnicas de caja blanca
–Prueba de ruta básica
—Complejidad ciclomática
–Pruebas de estructura de control
—Prueba de condición
—Prueba de flujo de datos
—Prueba de ciclos simples
—Prueba de ciclos anidados
Método de prueba, de caja negra
-Verifican el correcto manejo de funciones externas provistas o soportadas por el software
-Verifican que el comportamiento observado se apegue a las especificaciones del producto y a las expectativas del usuario
-Los casos de prueba se construyen a partir de las especificaciones del sistema
-Los métodos de caja negra o funcionales permiten derivar casos de prueba que buscan encontrar los siguientes tipos de errores:
–Funciones incorrectas o faltantes
–Errores de interfaz
–Errores en estructuras de datos o en acceso a BD externas
–Errores de comportamiento o desempeño
–Errores de inicialización o término
Método de prueba, prueba exhaustiva
-El procedimiento de prueba de caja negra más obvio es la prueba exhaustiva
-Para probar exhaustivamente este sistema con 5 componentes (parámetros) cada uno con 2 valores se requieren ejecutar 25 = 32 configuraciones diferentes (casos de
prueba)
-Para un sistema simple como el de nuestro ejemplo es posible ejecutar una prueba exhaustiva
-Sin embargo, este enfoque es impractico y no factible por que el número de casos de prueba crece muy rápidamente
-Por ejemplo para probar exhaustivamente un sistema con 5 parámetros cada uno con 10 valores se requieren ejecutar 105 = 1000000 casos de prueba
-Si se ejecuta y evalua un caso de prueba por minuto tardaríamos 694.44 días
-¿Existen otras alternativas?
Métodos de prueba, Estrategias combinatorias, pruebas de interacción
-Sí, las pruebas de interacción (ver [Grindal et al., 2005])
-Este enfoque identifica fallas que surgen de las interacciones de t (o menos) parámetros de entrada
-Para ello crea casos de prueba que incluyen al menos una vez todas las t-combinaciones entre estos parámetros y sus valores
-Los Covering arrays (CAs) son objetos combinatorios usados para representar pruebaa de interacción [Hartman, 2005]
-Permiten maximizar el número de errores detectados reduciendo al mínimo el número de casos de prueba [Kuhn et al., 2004]
Fuentes:
-ISTQB FL
-Importancia de las pruebas de software
http://www.tamps.cinvestav.mx/~ertello/swe/swTestingTecZacatecas.pdf
