PRUEBA DE APLICACIONESWEBExiste una urgencia que siempre impregna un proyecto web. Los participantes (intranquilos por la competencia de otras webapps, presionados por las demandas del cliente y preocu- pados porque perderán la ventana de mercado) fuerzan para poner la webapp en línea.

C ONCEPTOS DE PRUEBAS PARA APLICACIONES WEB

Probar es el proceso de ejecución del software con la intención de encontrar (errores.

Puesto que los sistemas y las aplicaciones basadas en web residen en una red e interactúan con muchos sistemas operativos, navegadores, protocolos de comunicaciones y aplicaciones “de cuarto trasero” diferentes, la búsqueda de errores representa un reto significativo.

Dimensiones de calidad El contenido. La función La estructura La usabilidad La navegabilidad El rendimiento La compatibilidad La interoperabilidad . La seguridad

Errores dentro de un entorno de webapp 1. Puesto que muchos tipos de pruebas de webapps descubren problemas

que se evidencian primero en el lado del cliente (es decir, mediante una interfaz implantada en un navegador específico o en un dispositivo de comunicación personal), con frecuencia se ve un síntoma del error, no el error en sí.

2. Puesto que una webapp se implanta en algunas configuraciones distintas y dentro de di- ferentes entornos, puede ser difícil o imposible reproducir un error afuera del entorno en el que originalmente se encontró.

3. Aunque algunos errores son resultado de diseño incorrecto o codificación HTML (u otro lenguaje de programación) impropia, muchos errores pueden rastrearse en la configu- ración de la webapp.

4. Dado que las webapps residen dentro de una arquitectura cliente-servidor, los errores pueden ser difíciles de rastrear a través de tres capas arquitectónicas: el cliente, el servi- dor o la red en sí.

5. Algunos errores se deben al entorno operativo estático (es decir, a la configuración espe- cífica donde se realiza la prueba), mientras que otros son atribuibles al entorno opera- tivo dinámico (es decir, a la carga de recurso instantánea o a errores relacionados con el tiempo).

Estrategia de las pruebas 1. El modelo de contenido para la webapp a se revisa a fin de descubrir errores. 2. El modelo de interfaz se examina para garantizar que todos los casos de uso pueden alojarse. 3. El modelo de diseño para la webapp se revisa para descubrir errores de navegación. 4. La interfaz de usuario se prueba para descubrir errores en la mecánica de presentación y/o

navegación. 5. Los componentes funcionales se someten a prueba de unidad. 6. Se prueba la navegación a lo largo de toda la arquitectura. 7. La webapp se implanta en varias configuraciones de entorno diferentes y se prueba para asegurar

la compatibilidad con cada configuración. 8. Las pruebas de seguridad se realizan con la intención de explotar las vulnerabilidades en la

webapp o dentro de su entorno. 9. Se realizan pruebas de rendimiento. 10. La webapp se prueba con una población controlada y monitoreada de usuarios finales; los

resultados de su interacción con el sistema se evalúan para detectar errores de con- tenido y de navegación, preocupaciones de usabilidad y compatibilidad, y seguridad, confiabilidad y rendimiento de la webapp.

PRUEBA DE CONTENIDO La prueba se enfoca en la información presentada dentro de cada objeto de con- tenido. El

revisor debe responder las siguientes preguntas: ¿La información realmente es precisa? ¿La información es concisa y puntual? ¿La plantilla del objeto de contenido es fácil de comprender para el usuario? ¿La información incrustada dentro de un objeto de contenido puede encontrarse con facilidad? ¿Se proporcionaron referencias adecuadas para toda la información derivada de otras fuentes? ¿La información presentada es consistente internamente y con la información presen- tada en

otros objetos de contenido? ¿El contenido es ofensivo, confuso o abre la puerta a demandas? ¿El contenido infringe derechos de autor o nombres comerciales existentes? ¿El contenido incluye vínculos internos que complementan el contenido existente? ¿Los vínculos

son correctos? ¿El estilo estético del contenido entra en conflicto con el estilo estético de la interfaz?

PRUEBA DE INTER FAZ DE USUARIO

Vínculos Formularios. Guión en el lado cliente. HTML dinámico. Ventanas pop-up. Guiones CGI. Contenido de streaming Cookies. Mecanismos de interfaz específicos de aplicación.

PRUEBA EN EL NIVEL DE COMPONENTE

Partición de equivalencia. Análisis de valor de frontera. Prueba de rutas.

PRUEBA DE NAVEGACIÓN

Vínculos de navegación Redirecciones Marcas de página Marcos y framesets Mapas de sitio Motores de búsqueda internos

PRUEBA DE CONFIGURACIÓN

Conflictos en el lado servidorEn el lado servidor, los casos de prueba de configuración se diseñan para verificar que la confi- guración servidor proyectada [es decir, servidor webapp, servidor de base de datos, sistemas operativos, software de firewall (cortafuegos), aplicaciones concurrentes] pueden soportar la webapp sin error. En esencia, la webapp se instaló dentro del entorno del lado servidor y se probó para asegurar que opera sin error

PRUEBA DE CONFIGURACIÓN

Conflictos en el lado clienteEn el lado cliente, las pruebas de configuración se enfocan con más peso en la compatibilidad de la webapp con las configuraciones que contienen una o más permutas de los siguientes componentes:

• Hardware: CPU, memoria, almacenamiento y dispositivos de impresión• Sistemas operativos: Linux, Macintosh OS, Microsoft Windows, un OS móvil• Software navegador: Firefox, Safari, Internet Explorer, Opera, Chrome y otros• Componentes de interfaz de usuario: Active X, Java applets y otros• Plug-ins: QuickTime, RealPlayer y muchos otros• Conectividad: cable, DSL, módem regular, T1, WiFi

P RUEBA DE SEGURIDAD

En el lado servidor, las vulnerabilidades incluyen ataques de negación de servicio y guiones maliciosos que pueden pasar hacia el lado cliente o usarse para deshabilitar operaciones del servidor. Además, puede accederse sin autorización a las bases de datos en el lado servidor (robo de datos).

Para proteger contra éstas vulnerabilidades, se implanta uno o más de los siguientes elementos de seguridad :

• Firewall • Autenticación • Encriptado • Autorización

PRUEBA DE RENDIMIENTO

Prueba de carga La intención de la prueba de carga es determinar cómo responderán

las webapps y su entorno del lado servidor a varias condiciones de carga. Conforme avanzan las pruebas, las permutas de las siguientes variables definen un conjunto de condiciones de prueba:

N, número de usuarios concurrentes

T, número de transacciones en línea por unidad de tiempo

D, carga de datos procesados por el servidor en cada transacción

PRUEBA DE RENDIMIENTO

Prueba de esfuerzo La prueba de esfuerzo es una continuación de la prueba de

carga, pero en esta instancia las variables N, T y D se fuerzan a satisfacerse y luego se superan los límites operativos

GRACIAS