Las pruebas de software son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.
Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.
El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables de éste. Las pruebas de calidad presentan los siguientes objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad, facilitar información para la toma de decisiones, evitar la aparición de defectos.
Teniendo esto presente, la información que puede ser requerida es de lo más extensa que puedes imaginar. Esto hace que el proceso de testing sea completamente dependiente del entorno en el que se desarrolla.
El ambiente ideal del testing es aquel que es externo del desarrollo del software, de esta manera se logra objetividad en las pruebas.
En la actualidad, no existen las "mejores prácticas" como tal para el desarrollo de pruebas. Mientras en una situación podría funcionar una prueba, en otras sería completamente inutil.
Por esto, las actividades, técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar, deben ser seleccionadas y utilizadas de la manera más eficiente según contexto del proyecto.
PRUEBAS ESTÁTICAS.
Las pruebas estáticas son realizadas sin un código en ejecución tales como a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.
PRUEBAS DINÁMICAS.
Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación. Permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el comportamiento de la aplicación desarrollada.
PRUEBAS MANUALES Y AUTOMÁTICAS.
Cuando se dirige el desarrollo o el control de calidad de un producto software. La idea de sustituir horas de pruebas manuales por pruebas automáticas suena perfecta. Pulsar “un botón” y lanzar automáticamente las pruebas. Pero cuando se le da unas cuantas vueltas al tema, se empiezan a ver algunos problemas y aparecen las dudas.
El siguiente cuadrantes que aparecen en el libro Agile Testing, clasifica los diferentes tipos de pruebas y la estrategia recomendada para las mismas:
– Cuadrante 1. Pruebas unitarias y de componentes, que normalmente se recomienda automatizar. – Cuadrante 2. Pruebas que pueden realizarse de manera automática o manual, y que suelen ser las pruebas funcionales, simulaciones, prototipos, etc. – Cuadrante 3. Pruebas manuales, que suelen ser las de usabilidad, aceptación, de exploración y alpha/beta testing. – Cuadrante 4. Herramientas que se hacen con herramientas, como son las de rendimiento y carga.
ENFOQUE DE LAS PRUEBAS.
PRUEBAS UNITARIAS.
- Objetivo -
Se focaliza en ejecutar cada módulo (o unidad minima a ser probada, ej = una clase) lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores.
Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido.
- Descripción de la prueba -
Particionar los módulos en pruebas en unidades lógicas fáciles de probar.
Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).
Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba; por lo tanto el diseñador debe construirlos con acceso al código fuente de la unidad a probar.
Los aspectos a considerar son los siguientes: Rutinas de excepción, Rutinas de error, Manejo de parámetros, Validaciones, Valores válidos, Valores límites, Rangos, Mensajes posibles.
- Técnica -
Comparar el resultado esperado con el resultado obtenido.
Si existen errores, reportarlos.
- Criterios para completar la prueba -
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
- Consideraciones específicas -
Para la elaboración de pruebas unitarias en java se puede utillizar el JUNIT y CACTUS.
PRUEBAS DE INTEGRACIÓN.
- Objetivo -
Identificar errores introducidos por la combinación de programas probados unitariamente.
Determina cómo la base de datos de prueba será cargada.
Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente.
Verificar que las especificaciones de diseño sean alcanzadas.
Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.
Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido.
- Descripción de la prueba -
Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente.
Determina cómo la base de datos de prueba será cargada.
Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.
Decide qué acciones tomar cuando se descubren problemas.
- Técnica -
Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos.
Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se verifica que los módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.
- Criterios para completar la prueba -
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
- Consideraciones específicas -
Ninguna.
PRUEBA DE REGRESIÓN.
- Objetivo -
Determinar si los cambios recientes en una parte de la aplicación tienen efecto adverso en otras partes.
- Descripción de la prueba -
En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes.
- Técnica -
La prueba de regresión es una nueva corrida de casos de prueba previos.
Se requiere de políticas para ser creada la prueba de regresión y decidir qué casos de prueba incluir, para probar eficientemente.
La prueba de regresión es un buen candidato para automatización. Desde que estas pruebas se repiten una y otra vez, las herramientas para minimizar el esfuerzo del trabajo son útiles.
La prueba de viejas funcionalidades es más importante que la de nuevas funcionalidades.
Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos tempranamente deben ser incluidos en la prueba de regresión.
- Criterios para completar la prueba -
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
- Consideraciones específicas -
Ninguna.
PRUEBAS DE HUMO (SOMOKE TESTING O AD HOC).
- Objetivo -
Detectar los errores en realeases tempranos y de manera fácil.
Probar el sistema constantemente.
Garantizar poco esfuerzo en la integración final del sistema.
Asegurar los resultados de las pruebas unitarias.
Se reducen los riesgos y a baja calidad.
- Descripción de la prueba -
Toma éste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque “humo” o falle. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales.
Permite detectar problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo está será una forma de garantizar el buen desarrollo.
Las pruebas de humo NO SON exhaustivas, pero van de extremo a extremo de la aplicación.
- Técnica -
Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día, máximo una semana).
Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los realizados en días anteriores.
Buscar eficientemente errores.
- Criterios para completar la prueba -
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identifcaron han sido tenidos en cuenta.
- Consideraciones específicas -
Cuando se encuentre un error en el release correspondiente al periodo elegido para hacer las integraciones del sistema, se detiente el desarrollo hasta que el error es corregido.
Este tipo de pruebas es útil en la "programación extrema" (extremme programming) y de sistemas complejos.
Es útil el uso de programas de prueba automáticas que se encarguen de probar os casos de prueba ya ejecutados en realeases anteriores.
PRUEBAS DEL SISTEMA.
- Objetivo -
Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.
- Descripción de la prueba -
Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas de caja negra, ésto es, verificar el sistema (y sus procesos internos), la interacción con las aplicaciones que lo usan via GUI y analizar las salidas o resultados.
En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.
La prueba de Sistema incluye:
Prueba funcionalidad.
Prueba de Usabilidad.
Prueba de Performance.
Prueba de Documentación y Procedimientos.
Prueba de Seguridad y Controles.
Prueba de Volumen.
Prueba de Esfuerzo (Stress).
Prueba de recuperación.
Prueba de múltiples sitios.
Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de pruebas de sistema:
Humo.
Usabilidad.
Performance.
Funcionalidad.
Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados durante la prueba de sistema. No obstante, deben ser desarrollados casos de prueba adicionales para aquellos aspectos del sistema, tales como documentación, procedimientos y desempeño que no han sido probados durante la prueba unitaria y de integración.
La prueba de sistema es compleja porque intenta validar un número de características al mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema al mismo tiempo.
- Técnica -
Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que:
Los resultados esperados ocurren cuando se utiliza un dato válido.
Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido.
Cada regla de negocios es aplicada adecuadamente.
- Criterios para completar la prueba -
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
- Consideraciones específicas -
Identifique o describa aquellos aspectos (internos o externos) que impactan la implementación y ejecución de las pruebas del Sistema.
PRUEBAS DE DESEMPEÑO.
- Objetivo -
Validar el tiempo de respuesta para las transacciones o funciones de negocios bajo las siguientes dos condiciones:
Volumen normal anticipado.
Volumen máximo anticipado.
- Descripción de la prueba -
Las pruebas de desempeño miden tiempos de respuesta, índices de procesamiento de transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de desempeño es verificar y validar los requisitos de desempeño que se han especificado (en este caso, el desempeño ofrecido por el proponente).
Las pruebas de desempeño usualmente se ejecutan varias veces, utilizando en cada una, carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el sistema. Una segunda prueba debe hacerse utilizando una carga máxima.
Adicionalmente, las pruebas de desempeño pueden ser utilizadas para perfilar y refinar el desempeño del sistema como una función de condiciones tales como carga o configuraciones de hardware.
Las principales actividades son:
Comparar el desempeño del sistema actual con los requisitos,
Poner a punto el sistema para mejorar las métricas de desempeño y proyectar la capacidad futura de carga del sistema.
Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas características que afectan el desempeño son:
Errores lógicos
Procesamiento ineficiente
Diseño pobre: muchas interfases, instrucciones y entradas/salidas.
Cuellos de botella en discos, CPU ó canales de entrada/salida
Salidas del sistema
Tiempos de respuesta
Capacidad de almacenamiento
Tasa de entrada/salida de datos
Número de transacciones que pueden ser manejadas simultáneamente.
Las pruebas de desempeño utilizan las técnicas de caja blanca y caja negra.
- Técnica -
Utiliza los procedimientos de prueba desarrollados para las pruebas del modelo del negocio (Pruebas del Sistema).
Modifica archivos de datos (para incrementar el número de transacciones) o los scripts para incrementar el número de veces que ocurre cada transacción.
Los scripts deben ser ejecutados en una máquina y deben ser repetidos con múltiples clientes (virtuales o actuales). (Ver consideraciones especiales).
- Criterios para completar la prueba -
Un Usuario / Una Transaccion. Se completaron las pruebas sin ninguna falla y dentro del tiempo esperado o requerido por transacción.
Múltiples transacciones, múltiples usuarios. Se completaron las pruebas de los scripts sin ninguna falla y dentro del tiempo esperado.
- Consideraciones específicas -
Unas pruebas de desempeño integrales incluyen tener una carga en background en el servidor. Hay varios métodos que pueden ser utilizados para hacer ésto:
Transacciones dirigidas directamente al servidor, usualmente en forma de sentencias SQL.·
Creación de usuarios virtuales para simular muchos clientes (usualmente varios cientos). Se utilizan herramientas de Emulación de Terminales Remotas para obtener esta carga. Esta técnica también puede ser utilizada para cargar de tráfico la red.
Use múltiples clientes físicos, cada uno corriendo los scripts de prueba.
Las pruebas de desempeño deben ser ejecutadas en una máquina dedicada o en un tiempo dedicado. Esto permite control total y medidas precisas.
La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o proporcionalmente más grande que la diseñada.
PRUEBAS DE CARGA.
- Objetivo -
Verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios, bajo diferentes condiciones de carga.
- Descripción de la prueba -
Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga.
La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de transacciones y otros aspectos sensibles al tiempo).
- Técnica -
Usa los scripts desarrolladas para Pruebas del Negocio.
Modifica archivos de datos (para incrementar el número de transacciones o veces que cada transacción ocurre).
- Criterios para completar la prueba -
Múltiples transacciones, múltiples usuarios. Se completaron las pruebas de los scripts sin ninguna falla y dentro del tiempo esperado.
- Consideraciones específicas -
Las pruebas de carga deben ser ejecutadas en una máquina dedicada o en un tiempo dedicado. Esto permite control total y medidas precisas.
La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o proporcionalmente más grande que la diseñada.
PRUEBAS DE STRESS.
- Objetivo -
Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de stress:
Memoria baja o no disponible en el servidor.
Máximo número de clientes conectados o simulados (actuales o físicamente posibles)
Múltiples usuarios desempeñando la misma transacción con los mismos datos.
El peor caso de volumen de transacciones (ver pruebas de desempeño).
NOTAS: La meta de las pruebas de stress también es identificar y documentar las condiciones bajo las cuales el sistema FALLA.
- Descripción de la prueba -
Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Poca memoria o espacio en disco puede revelar defectos en el sistema que no son aparentes bajo condiciones normales. Otros defectos pueden resultar de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta aplicable a muchos programas, por ejemplo a un compilador o a una rutina de pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivos, de tiempo real y de control de proceso.
Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará realmente durante su utilización, muchas otras serán en verdad situaciones que nunca ocurrirán en la realidad. Esto no implica, sin embargo, que estas pruebas no sean útiles.
Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa porque es de esperar que los mismos errores puedan presentarse en situaciones reales, algo menos exigentes.
- Técnica -
Use los scripts utilizados en las pruebas de desempeño.
Para probar recursos limitados, las pruebas se deben correr en un servidor con configuración reducida (o limitada).
Para las pruebas de stress restantes, deben utilizarse múltiples clientes, ya sea corriendo los mismos scripts o scripts complementarios para producir el peor caso de volumen de transacciones.
- Criterios para completar la prueba -
Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el sistema falle. ( O si las condiciones en que el sistema falle ocurren por fuera de las condiciones especificadas).
- Consideraciones específicas -
Producir stress en la red puede requerir herramientas de red para sobrecargarla de tráfico.
El espacio en disco utilizado para el sistema debe ser reducido temporalmente para limitar el espacio disponible para el crecimiento de la Base de datos.
Sincronización de varios clientes accediendo simultáneamente los mismos registros.
