P R E S E N T A D O P O R :

L A Y N E K E R A R M A N D O G U T I É R R E Z C A Ñ A S

PRUEBAS DEL SOFTWARE

Prueba de software

La prueba es un conjunto de actividades que se planean con anticipación y serealizan de manera sistemática. Por tanto, se debe definir una plantilla paralas pruebas del software.

Las pruebas que hace el equipo de software debe ser muy efectivas porquecon esto se eliminan todos los errores existes para garantizar la calidad delsoftware donde es dirigido por el desarrollador y aplicada en diferentesmomentos.

Verificación y validación de las pruebas

Verificación es el conjunto de actividades que aseguran que elsoftware implemente correctamente una función específica.

Validación es un conjunto diferente de actividades que aseguranque el software construido corresponde con los requisitos del

cliente.

Prueba Unitaria

Se focaliza en ejecutar cada módulo (o unidad minima a serprobada, ej = una clase) lo que provee un mejor modo demanejar la integración de las unidades en componentesmayores.

Busca asegurar que el código funciona de acuerdo con lasespecificaciones y que el módulo lógico es válido.

Prueba de Integración

Describe cómo verificar que las interfaces entre las componentes desoftware 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 lascomponentes al siguiente.

Decide qué acciones tomar cuando se descubren problemas.

Prueba de Regresión

Determinar si los cambios recientes en una parte de la aplicación tienenefecto adverso en otras partes.

En esta prueba se vuelve a probar el sistema a la luz de los cambiosrealizados durante el debugging (depuración), mantenimiento odesarrollo de la nueva versión del sistema buscando efectos adversos enotras partes.

Pruebas de Humo

Toma éste nombre debido a que su objetivo es probar el sistemaconstantemente buscando que saque “humo” o falle. En algunosproyectos este tipo de prueba va junto con las pruebas funcionales.Permite detectar problemas que por lo regular no son detectados en laspruebas normales. Algunas veces, si las Pruebas ocurren tarde en elciclo de desarrollo está será una forma de garantizar el buen desarrollo.

Las pruebas de humo no son exhaustivas, pero van de extremo aextremo de la aplicación.

Pruebas del Sistema

Las pruebas del sistema deben enfocarse enrequisitos que puedan ser tomadosdirectamente de casos de uso y reglas yfunciones de negocios. El objetivo de estaspruebas es verificar el ingreso, procesamientoy recuperación apropiado de datos, y laimplementación apropiada de las reglas denegocios. Este tipo de pruebas se basan entécnicas de caja negra, esto es, verificar elsistema (y sus procesos internos).

En esta prueba se determina qué pruebas deSistema (usabilidad, volumen, desempeño,etc.) asegurarán que la aplicación alcanzarásus objetivos de negocio.

Pruebas de Desempeño

Las pruebas de desempeño miden tiempos de respuesta, índices deprocesamiento de transacciones y otros requisitos sensibles al tiempo.El objetivo de las pruebas de desempeño es verificar y validar losrequisitos de desempeño que se han especificado (en este caso, eldesempeño ofrecido por el proponente).

Pruebas de Carga

Las pruebas de carga miden la capacidad del sistema para continuarfuncionando apropiadamente bajo diferentes condiciones de carga.

La meta de las pruebas de carga es determinar y asegurar que elsistema funciona apropiadamente aún más allá de la carga de trabajomáxima esperada. Adicionalmente, las pruebas de carga evalúan lascaracterísticas de desempeño (tiempos de respuesta, tasas detransacciones y otros aspectos sensibles al tiempo).

Pruebas de Stress

Verificar que el sistema funciona apropiadamente y sinerrores, 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).

NOTA: La meta de las pruebas de stress también es identificar y documentar las condiciones bajo las cuales el sistema FALLA.

Pruebas de Volumen

Verificar que la aplicación funciona adecuadamentebajo los siguientes escenarios de volumen:

Máximo (actual o físicamente posible) número de clientes conectados (o simulados), todos ejecutando la misma función (peor caso de desempeño) por un período extendido.

Máximo tamaño de base de datos (actual o escalado) y múltiples consultas ejecutadas simultáneamente.

Prueba de Múltiples Sitios

Realizar casos de prueba que verifiquen mínimo lo siguiente:

Consistencia de las opciones de configuración para el sistema a través de los sitios.

Empaquetamiento del sistema para múltiples instalaciones.

Sincronización de datos entre sitios.

Comunicación de datos entre sistemas en diferentes sitios.

Rompimiento de funciones de sistema a través de los sitios.

Consistencia de controles y seguridad a través de los sitios

Pruebas de Seguridad y Control de Acceso

Nivel de seguridad de la aplicación: Verifica que un actor solopueda acceder a las funciones y datos que su usuario tiene permitido.

Nivel de Seguridad del Sistema: Verificar que solo los actores conacceso al sistema y a la aplicación están habilitados para accederla.

Las pruebas de seguridad y control de acceso se centran en dos áreasclaves de seguridad:

Seguridad del sistema, incluyendo acceso a datos o Funciones denegocios.

Seguridad del sistema, incluyendo ingresos y accesos remotos alsistema.

Pruebas de GUI

Verifica lo siguiente: La navegación a través de los objetos de la prueba reflejan las

funcionalidades del negocio y requisitos, se realiza una navegación ventana por ventana, usando los modos de acceso (tabuladores, movimientos del mouse, teclas rápidas, etc.).

Los objetos de la ventana y características, tales como menús, medidas, posiciones, estados y focos se verifican conforme a los estándares.

Pruebas de Configuración

Estas pruebas verifican la operación del sistema endiferentes configuraciones de hardware y software. En lamayoría de los ambientes de producción, lasespecificaciones para las estaciones de trabajo, equipos dered y servidores pueden variar. Las estaciones pueden tenerdiferentes versiones de software instaladas (SistemasOperativos, Drivers, etc) y en cualquier momento, puedenllegar a utilizarse diferentes combinaciones.

Prueba de Aceptación

La prueba de aceptación es ejecutada antes de que la aplicación sea instalada dentro de un ambiente de producción. La prueba de aceptación es generalmente desarrollada y ejecutada por el cliente o un especialista de la aplicación y es conducida a determinar como el sistema satisface sus criterios de aceptación validando los requisitos que han sido levantados para el desarrollo, incluyendo a documentación y procesos de negocio.

Prueba de Instalación

Verificar y validar que el sistema se instala apropiadamente en cadacliente, bajo las siguientes condiciones:

Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el sistema.

Actualizar máquinas previamente instaladas con el sistema.

Instalar versiones viejas en máquinas previamente instaladas con el sistema.

Pruebas Funcionales

Las pruebas Funcionales deben enfocarse en los requisitos funcionales, las pruebas pueden estar basadas directamente en los Casos de Uso (o funciones de negocio), y las reglas del negocio. Las metas de estas pruebas son:

Verificar la apropiada aceptación de datos,

Verificar el procesamiento y recuperación y la implementación adecuada de las reglas del negocio.

Prueba de Usabilidad

Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las áreas de diseño que hacen al sistema de difícil uso para el usuario.

La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema desde el punto de vista del usuario.

Pruebas Alfa

Prueba de aceptación para detectar errores en el sistema bajo un ambiente controlado.

La verificación involucra la ejecución de partes o todo del sistema en ambientes simulados, con el fin de encontrar errores.

La retroalimentación de esta fase produce cambios en el software para resolver los errores y fallas que se descubren.

Pruebas Beta

Prueba de aceptación donde La validación (o pruebas beta) involucra el uso del software en un ambiente real.

Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un ambiente real. Usan el sistema en sus actividades cotidianas, procesan transacciones y producen salidas normales del sistema.

Las transacciones y personas que usan el sistema son reales y trabajan en su área de trabajo real.

El desarrollador no esta presente.

Los usuarios están advertidos de que están usando un sistema que puede fallar.

Los usuarios realizan pruebas a su antojo realizando uso de la aplicación.