CÓMO PROBAR APLICACIONES WEB

<<Ensayo>>

JUDITH NATALY AGUILAR BELTRAN

CORPORACIÓN UNIVERSITARIA MINUTO DE DIOS

FACULTAD DE INGENIERÍA

PRUEBAS VALIDACIÓN Y VERIFICACIÓN DE SOFTWARE

BOGOTÁ D.C.

2012

¿CUANTAS PÁGINAS HEMOS VISTO SIN ERRORES?

Actualmente las aplicaciones web o webapps1, han tenido gran acogida desde la

aparición del internet, es por ello que existen millones de webapps disponibles con

diferentes propuestas y objetivos para sus clientes.

Cuando estamos desarrollando webapps al igual que cualquier aplicación se debe

contar con un método de probar efectivo con el fin de entregar al mercado una

aplicación de calidad; de allí se pensó en una suma de actividades relacionadas

con una sola meta descubrir errores en el contenido, la función, la facilidad de uso,

la navegabilidad, el desempeño, la capacidad y la seguridad de la webapps.

Principalmente evitando que los propios usuarios sean los que llegasen a

encontrar algún error en la webapp y tomaran la decisión de abandonar el sitio

para irse a otro donde no encontraran estos errores. Estas pruebas son realizadas

por los ingenieros web y otros participantes del proyecto (gerentes, clientes,

usuarios finales) toman parte en el proceso de probar la webapp

Esta prueba cuenta con una estructura que consta de siete etapas: contenido,

interfaz, navegación, componente, configuración, desempeño y prueba de

seguridad. El resultado de esta prueba trae consigo los casos prueba para los

cuales se conserva un archivo de resultados de pruebas para uso futuro. Al igual

que algunas pruebas que hemos revisado anteriormente, primero se validan las

unidades individuales y posteriormente se cambia a pruebas que ejerciten la

webapp como un todo.

Figura 1. Prueba de contenido [1]

1 Aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor web a través de

internet o de una intranet mediante un navegador. Tomado de http://es.wikipedia.org/wiki/Webapp.

Dentro de las pruebas de contenido. “La finalidad es descubrir errores tanto

semánticos como sintácticos que afecten la precisión del contenido a la forma en

la que se presenta al usuario final” [1], por ejemplo cuando entramos al sitio web

de la empresa donde laboramos, con el fin de solicitar una referencia laboral,

digitamos el número de documento pero cuando este genera la referencia laboral,

no es clara ni los datos que muestra hacen referencia a los datos registrados en la

aplicación.

La prueba de la interfaz tiene como objetivo “descubrir errores que resulte de

mecanismos de interacción mal implementados, u omisiones, inconsistencias o

ambigüedades en la semántica de la interfaz” [1], esto es con el fin de desarrollar

una webapp agradable para el usuario, donde los vínculos, títulos, ventanas pop-

up, menús, entre otros elementos, estén adecuadamente diseñados para el

usuario final.

Figura 2. Prueba de interfaz [1]

En la prueba de navegación “los mecanismos de navegación se prueban para

garantizar que se identifican y corrigen los errores que impiden el completar un

caso de uso” [1], por ejemplo cuando un webapp es complejo, los vínculos de

navegación, bookmarks, marcos, mapas del sitio y motores de búsqueda internos,

cumplen una función prioritario dentro de la sitio, ya que si tenemos una ruta para

un caso de prueba el cual simularía un recorrido para el usuario y se llegara a

presentar problemas en alguno de estos elementos, la prueba de navegación no

cumpliría el objetivo planteado, esto se podría percibir mejor cuando nos

encontramos en la página principal de almacén y queremos regresar para ver el

anterior producto pero el vínculo que debe hacer estos no lo realiza sino que envía

al usuario a una página externa; esto significaría un usuario menos dentro del sitio

web que muy posiblemente no volverá a la misma página del almacén.

En la prueba de componentes “cada página web encapsula contenido, vínculos de

navegación y elementos de procesamiento que forman una ‘unidad’ dentro de la

arquitectura de la webapp. Se deben probar dichas unidades” [1], es decir que se

enfoca en probar la unidad como tal antes de probarla dentro de una ruta o caso

de prueba de navegación.

En la prueba de configuración “entonces se llevan a cabo pruebas para descubrir

los errores asociados con cada posible configuración” [1], dentro de esta prueba

se revisan los conflictos en el lado del servidor y cliente.

En el lado del servidor se revisan el servidor web, servidor de base de datos,

sistemas operativos, software cortafuegos, aplicaciones concurrentes, etc. En el

lado del cliente se revisan el hardware (CPU, memoria, almacenamiento y

dispositivos de impresión), sistemas operativos (Linux, Macintosh, Microsoft

Windows, un SO con base móvil), software de navegación (internet Exploret,

Mozilla/Netscape, Opera, Safari), Componentes de la interfaz del usuario (ActiveX,

applets Java), plug-ins (Quicktime, realplayer) y conectividad (cable, DSL, modem

regular, TI)

En la prueba de la seguridad “la finalidad es encontrar hoyos de seguridad” [1] es

decir desarrollar pruebas diseñadas para explorar las vulnerabilidades de la

webapps, sin embargo se deben implementar elementos de seguridad como

cortafuegos, autenticación, encriptado, autorización, etc. Con el fin de evitar

ataques de hackers y otros.

Como nos lo hace saber Dorothy y Peter Denning cuando afirman “El internet es

un lugar riesgoso para llevar a cabo negocios o almacenar activos. Hackers,

crackers, snoops, spoofers,… ladrones, vándalos, lanzadores de virus y

proveedores de programas delictivos se pasean libremente.”

La prueba de desempeño “abarca una serie de pruebas que se diseñan para

valorar el tiempo de respuesta de la WebApp y la confiabilidad conforme aumenta

la demanda en la capacidad de recursos en el lado del servidor” [1], dentro de un

servicio este tema siempre será muy importante, ya que ha ningún usuario le

gusta esperar una respuesta y más si esta no es en segundos.

Dentro de esta prueba la red donde viaja la webapp cumple una función

importante, se debe revisar si el ancho de banda de la red es apropiado, la

capacidad de base de datos, SO, funcionalidades del webapp.

Además se realiza pruebas de carga, para esta se tienen las variables:

N: el número de usuarios concurrentes.

T: el número de transacciones en línea por usuario por unidad de tiempo.

D: la carga de datos procesada por el servidor por transacción.

Y la siguiente formula:

P = N * T * D

La prueba de tensión es una continuación de la prueba de carga, pero en esta

instancia las variables N, T y D se fuerzan para alcanzar y luego superar los

límites operativos.

Cada una de los elementos que hemos mencionado anteriormente, nos hace

pensar que han sido muchas las veces que hemos encontrado alguna de estas

fallas en un sitio web que estamos visitando, sin embargo cada proveedor de sitios

web se hoy en día tiene una mayor responsabilidad a la hora de subir información

a la red, ya que la competencia cada vez es mayor y nosotros como clientes o

usuario finales estamos buscando el mejor servicios prestado, el de mejor calidad

sin importar que sea un webapp, ya que este también tiene unas condiciones que

deben seguir.

Como conclusión para los desarrolladores de webapp debemos hacer uso de las

herramientas con las que contamos, las pruebas que podemos realizar al producto

para encontrar los errores y no dejarle este trabajo al usuario sin pensar que ese

efectivamente los va a encontrar, posiblemente nos lo reportara pero no significa

que seguirá adquiriendo nuestros productos.

BIBLIOGRAFÍA

[1] Ingeniería del software, Un enfoque práctico, Sexta edición, Roger S.

Pressman, Mc Graw Hill, 2008, 769p.