13 Jun
Objetivos Fundamentales de las Pruebas de Software
El proceso de pruebas de software persigue dos objetivos distintos y complementarios:
- Demostrar al desarrollador y al cliente que el software cumple con los requisitos establecidos.
- Descubrir vicios o defectos en el software que puedan manifestar un comportamiento incorrecto, indeseable o que no se ajuste a sus especificaciones.
El primer objetivo conduce a la prueba de validación, en la que se espera que el sistema funcione correctamente en un conjunto determinado de casos de prueba que reflejen el uso previsto del sistema. El segundo objetivo, por su parte, lleva a la prueba de defectos, donde los casos de prueba están diseñados específicamente para exponer fallas.
Es crucial entender que las pruebas no pueden demostrar que el software está completamente libre de defectos o que se comportará como se especifica en todas las circunstancias. Siempre existe la posibilidad de que una prueba posterior descubra problemas adicionales en el sistema.
Estrategias y Políticas de Pruebas
Las estrategias de prueba pueden basarse en la experiencia de uso del sistema y centrarse en la verificación de las características del sistema en funcionamiento. Por ejemplo:
- Todas las funciones del sistema accesibles a través de los menús deben ser probadas.
- Las combinaciones de funciones (por ejemplo, el formato de texto) accesibles a través de los mismos menús deben ser probadas.
- Todas las funciones deben ser probadas con entradas correctas e incorrectas en los puntos de entrada del usuario.
Tipos de Pruebas en Ingeniería de Software
Pruebas de Sistema
Las pruebas de sistema consisten en la integración de dos o más componentes que implementan las funciones o características del sistema, y la posterior prueba de este sistema integrado. Para la mayoría de los sistemas complejos, existen dos fases principales en las pruebas de sistema:
Pruebas de Integración
En esta fase, el equipo de pruebas debe tener acceso al código fuente del sistema. Cuando se descubre un problema, el equipo de integración intenta encontrar el origen del problema e identificar los componentes que deben ser depurados.
Propósito: El proceso de integración del sistema implica la construcción de un sistema a partir de sus componentes y la prueba del sistema resultante para identificar problemas que surgen de las interacciones entre dichos componentes.
Pruebas de Liberación (Release Testing)
En esta fase, se prueba una versión del sistema que podría ser entregada a los usuarios. Aquí, el equipo se enfoca en validar que el sistema cumple con los requisitos y en asegurar su fiabilidad.
Objetivo: Es el proceso de prueba de la versión del sistema que será distribuida a los clientes. El objetivo principal es aumentar la confianza de los proveedores en que el sistema cumple con los requisitos.
Pruebas de Rendimiento
Una vez que el sistema ha sido completamente integrado, puede ser probado en relación con propiedades emergentes como el rendimiento y la fiabilidad.
Pruebas de Componentes (Pruebas Unitarias)
A veces denominadas pruebas unitarias, este proceso consiste en probar los componentes individuales del sistema. Se trata de un proceso de pruebas de defectos, y por lo tanto, su objetivo es exponer los defectos dentro de estos componentes. Hay diferentes tipos de componentes que pueden ser probados en esta etapa:
- Las distintas funciones o métodos de un objeto.
- Las clases de objetos con varios atributos y métodos.
- Componentes compuestos que agrupan diferentes objetos o funciones. Estos componentes tienen una interfaz compuesta definida que se utiliza para acceder a su funcionalidad.
Pruebas de Interfaz
La prueba de interfaz es de particular importancia en el desarrollo orientado a objetos y basado en componentes. Los objetos y componentes se definen por sus interfaces y pueden ser reutilizados en combinación con otros componentes en distintos sistemas. Existen diferentes tipos de interfaces:
- Interfaces de Parámetros: Son interfaces a través de las cuales se pasan datos o, a veces, referencias a funciones de un componente a otro.
- Interfaces de Memoria Compartida: Son interfaces donde un segmento de memoria es compartido entre los componentes.
- Interfaces de Procedimientos: Son interfaces en las que un componente está formado por un conjunto de procedimientos que pueden ser invocados por otros componentes.
- Interfaces de Paso de Mensajes: Son interfaces donde un componente solicita un servicio de otro componente, pasándole un mensaje.
Tipos Comunes de Errores de Interfaz
Los errores de interfaz son uno de los fallos más comunes en los sistemas complejos. Incluyen:
- Mal Uso de la Interfaz: Un componente invoca a otro componente y comete un error al utilizar su interfaz.
- Malentendido de la Interfaz: Un componente que invoca a otro ignora la especificación de la interfaz del componente llamado y hace suposiciones incorrectas sobre su comportamiento.
- Errores de Sincronización: Estos errores ocurren en sistemas de tiempo real que utilizan interfaces de memoria compartida o paso de mensajes.
Pautas Generales para las Pruebas de Interfaces
Algunas pautas generales para las pruebas de interfaces son las siguientes:
- Examinar el código a probar y listar explícitamente cada llamada a componentes externos.
- Se deben verificar siempre los punteros de interfaz de cooperación para asegurar que no se transmitan punteros nulos a través de la interfaz.
- Diseñar pruebas que provoquen fallos en el componente cuando se le llama a través de una interfaz de procedimiento.
- Utilizar pruebas de estrés en sistemas de paso de mensajes.
- Cuando varios componentes interactúan a través de memoria compartida, diseñar pruebas que varíen el orden en que estos componentes se activan.
Diseño de Casos de Prueba
El diseño de casos de prueba es una parte fundamental de las pruebas de componentes y sistemas, donde se definen los casos (entradas y salidas esperadas) que pondrán a prueba el sistema. Existen varios enfoques que se pueden utilizar para diseñar casos de prueba:
- Pruebas Basadas en Requisitos: Los casos de prueba están diseñados para verificar los requisitos del sistema.
- Pruebas de Particiones (Equivalencia): Se identifican particiones en las entradas y salidas, y las pruebas se diseñan para que el sistema procese entradas de todas las particiones y genere salidas en todas las particiones.
- Pruebas Estructurales (Caja Blanca): Se utiliza el conocimiento de la estructura interna del programa para diseñar pruebas que ejerciten todas sus partes.
Cobertura de Caminos (Path Testing)
Es una estrategia para las pruebas estructurales cuyo objetivo es ejercitar todos los caminos de ejecución independientes de un componente o un programa. Si cada camino es gestionado de forma independiente, todas las sentencias de los componentes habrán sido ejecutadas al menos una vez.
Automatización de Pruebas
La fase de pruebas es, a menudo, la más intensiva en tiempo y mano de obra del proceso de desarrollo de software. Por lo tanto, las herramientas de prueba se encuentran entre las primeras herramientas de software en ser desarrolladas. Un banco de trabajo de pruebas de software es un conjunto integrado de herramientas para apoyar el proceso de prueba. Ejemplos de algunas herramientas de pruebas incluidas en un banco de trabajo de prueba son:
- Gestor de Pruebas: Administra la ejecución del programa de pruebas. El gestor de pruebas realiza un seguimiento de los datos de prueba, los resultados esperados y los recursos de los programas de prueba.
- Generador de Datos: Genera datos de prueba para el programa bajo prueba.
- Oráculo de Prueba: Genera pronósticos de los resultados esperados.
- Comparador de Archivos: Compara los resultados del programa bajo prueba con los resultados de pruebas anteriores e informa las diferencias entre ellos.
- Generador de Informes: Proporciona recursos para la identificación y elaboración de informes de resultados de la prueba.
- Análisis Dinámico: Añade código al programa para contar el número de veces que se ejecuta cada sentencia. Después de la prueba, se genera un perfil de ejecución para mostrar con qué frecuencia se ha ejecutado cada instrucción del programa.
- Simulador: Se pueden proporcionar diferentes tipos de simuladores. Los simuladores emulan la máquina destino en la que se ejecutará el programa.
Puntos Clave sobre Pruebas de Software
- Las pruebas solo pueden demostrar la presencia de errores en un programa; no pueden demostrar la ausencia de fallas restantes.
- Las pruebas de componentes son responsabilidad del desarrollador de los componentes. Otro equipo de pruebas suele realizar las pruebas de sistema.
- Las pruebas de integración son la actividad inicial de las pruebas de sistema, donde los componentes integrados se prueban para detectar defectos. Las pruebas de liberación se centran en las versiones de prueba para el cliente y en verificar que el sistema cumple los requisitos para ser liberado.
- Al probar sistemas, se debe intentar «romper» el sistema utilizando la experiencia y las directrices para elegir tipos de casos de prueba eficaces que permitan encontrar defectos, similar a lo que ocurre en otros sistemas.
- Las pruebas de interfaz intentan descubrir defectos en las interfaces de los componentes compuestos. Los defectos de interfaz pueden surgir debido a errores en la lectura de la especificación, malinterpretación de la especificación o suposiciones inválidas sobre el tiempo de ejecución.
- La partición de equivalencia es una forma de derivar casos de prueba. Depende del descubrimiento de las particiones de los conjuntos de entrada y salida y del ejercicio del programa con valores de estas particiones. A menudo, el valor más probable para llevar a cabo una prueba exitosa es un valor umbral de la partición.
- Las pruebas estructurales se basan en el análisis de un programa para determinar sus caminos y utilizar este análisis para ayudar en la selección de casos de prueba.
- La automatización reduce los costos de las pruebas al apoyar el proceso con una variedad de herramientas de software.
Deja un comentario