3. - Ordenar las capacidades de aplicaciones web,
y herramientas que necesitamos para estas
- Seleccionar el origen de las herramientas de
desarrollo
- Considerar la categoría de la aplicación web
para la elección de herramientas y tecnología.
4. Ing. de software enfocada en lograr la
cohesión de componentes, lograr un sistema
simple de entender y mantener.
Para aplicaciones webs, se ordenan por
separado (con respectivas aplicaciones):
◦ Almacenamiento de contenido
◦ Adaptación de contenido
◦ Presentación y adaptación de la misma
◦ Estructura y navegación de contenido
◦ Funcionalidad.
5. Open Source, rápida evolución, carencia de
soporte.
Herramientas y tecnologías propietarias, con
soporte e implementación en ciclos lentos.
Tomar en cuenta si las herramientas:
◦ Permite cumplir lo deseado
◦ Calidad y extensión adecuadas
◦ Ayudara ahora y en el futuro
◦ Tiene soporte, documentación, y ayuda
◦ El costo es parte del presupuesto
6. La categoría de las aplicaciones Web define el
tipo de tecnologías a aplicar.
Inicialmente de difusión de información.
Mas compleja interacción de los
usuarios, Web
2.0(Folksonomies, Mashups, Social
networking, wikis)
Mas parecidas a las aplicaciones de escritorio.
Disminuyen las limitaciones de usuarios y
administradores.
7. Sin fin de tecnologías en
constante cambio
No intentar conocer todo, solo
enfocar a las herramientas y
tecnologías necesarias
8. Conjunto de librerías y/o componentes
usados para implementar estructuras básicas
de una aplicación, basado en lenguajes
simples.
Los frameworks complejos cubren
Mayoría basados en el modelo vista
controlador (MVC).
Permiten separar la aplicación para ser
administrada por expertos.
Seleccionado al inicio, porque influye en la
arquitectura.
9. CMS permite administrar variedad de
contenido por diversos usuarios en sistemas
basados en Web.
Presentación, estadísticas, publicación y
despliegue, seguridad, compatibilidad con
diversas aplicaciones.
Algunos permiten control de capacidades.
10. Indexación de contenido.
Avanzada búsqueda, implica configuración de
la búsqueda, de la estrategia de indexado, y
análisis de las búsquedas realizadas
anteriormente.
11. Variedad de herramientas de desarrollo
web, pero de bajo nivel
Herramientas adaptadas de
convencionales, para software, no cubren
las características especiales de las
aplicaciones Web.
12. Son pocas las orientadas específicamente
para aplicaciones Webs.
Herramientas limitadas, estructuras básicas.
Muchos sin habilidad de modelar procesos de
negocios, casos de uso o escenarios.
Herramientas de generación de
documentación y código, requieres ciertos
ajustes finales.
13. La mayoría de pruebas son de implementación,
pocas de especificación y diseño.
Categorías: Validación de:
◦ Lenguaje
◦ Navegación
◦ Rendimiento y carga
◦ Plataforma y entorno
◦ Funcionabilidad y análisis
◦ Usabilidad.
Muchas de las mismas utilizadas antes de lanzar
las aplicaciones al mercado, o para buscar
errores que se presenten.
14. Pocas herramientas que directamente
soporten los procesos de ingeniería web
(formulación, calidad, costo, etc.)
La mayoría de desarrolladores web combinan
herramientas generales para proyectos, y las
configuran para dicha tarea.
16. Herramientas para su uso, pocas para modelado
de aplicaciones web, o para el desarrollo
Separa preocupaciones y encontrar herramientas
para cada una
El origen de la herramienta que se usara
Considerar la categoría de la pagina para definir
las herramientas y tecnología que se usara.
Determinar el modelado formal, testeo, y
mantenimiento de los procesos. Una metodología
ágil y sin problemas.
17. Fuente:
Libro: Web Engineering: A Partitioner’s Approach , 6ta Edición
Autor: Roger S. Pressman y David Lowe
Cap: 15 (Testing Web Apps)
Testeo en Aplicaciones Web
Edwin O. Ramos Velásquez
Universidad Nacional Jorge Basadre Grohmann
Maestría en Ingeniería de Sistemas
18. - Dimensiones de la calidad
- Típicos errores en web
- ¿Usar estrategias en el testeo?
19. DIMENSIONES DE LA CALIDAD
La calidad de una aplicación web es consecuencia de un buen análisis y diseño de la solución.
Las complejidad de las aplicaciones así como sus componentes críticos deben ser evaluados
sin descuidar ambos aspectos.
• Contenido, Se evalúa semántica y sintácticamente. En el nivel sintáctico se evalúa La
ortografía y la gramática de los textos expuestos(errores ortográficos). En el nivel
semántico se evalúa la consistencia de la información presentada, así como el cuidado de
la relación de los objetos mostrados en pantalla(estética).
• Funcionabilidad: Cada funcionalidad es verificada, así como la respectiva existencia de
posibles inestabilidades.
• Estructura. La conformidad del soporte que la aplicación web le al contenido mostrado
• Usabilidad. Con la interfaz existente el usuario le puede dar el correcto uso a la aplicación
web?
• Navegabilidad. Toda la sintaxis y semántica de la web pueden ser usados para evitar
errores de navegación. P.e. identificación de enlaces muertos, etc.
• Rendimiento. Se verifica su correcto desempeño en las diferentes configuraciones y en las
situaciones de carga plena.
• Compatibilidad. Se verifica su funcionamiento en escenarios diferentes. Por ejemplo, en
hosts diferentes.
• Interoperabilidad. La aplicación web interactúa adecuadamente con otras aplicaciones,
como ser por ejemplo con la base de datos u otras aplicaciones?
• Seguridad. Se verifica su comportamiento ante posibles vulnerabilidades.
20. TÍPICOS ERRORES DE LAS APLICACIONES WEB
• Scripting en el lado del cliente,
• Errores en la arquitectura de capas que no puede ser fácilmente detectado, Navegación, pruebas de
rendimiento, etc.
¿ES NECESARIO EL USO DE ESTRATEGIAS DE TESTEO?
• Revisar el modelo de contenido de la aplicación web.
• Revisar el modelo de interfaz, para asegurar que todos los casos de uso han sido considerados.
• El modelo de diseño de la aplicación web es revisado para descubrir los errores de navegación.
• En la interfaz de usuario se verificar errores en la presentación y / o de navegación manual.
• Verificar los componentes funcionales por unidades.
• Navegación a través de la arquitectura.
¿Planificación en las estrategias de testeo?
Es razonable. Ocasionalmente es posible hallar más errores en las pruebas adhoc.
Planificación de la prueba ¿Cuánto es necesario?
Lo razonable. Solamente se podría justificar la minimización de pruebas de verificación en sistemas pequeños.
Objetivo de las pruebas: Detectar errores para corregirlos
22. Nivel sintáctico:
Ortografía y el buen uso del idioma
En documentos de texto e imágenes/multimedia
Nivel Semántico:
Consistencia de la información presentada
• ¿Es la información actualizada y precisa los hechos?
• ¿Está la información concisa y al grano?
• ¿Es el diseño de los objetos de contenido fácil para el usuario de entender?
• ¿Puede la información incluida en un objeto de contenido se encuentra con facilidad?
• Tener las referencias adecuadas ha proporcionado toda la información procedente de
otros fuentes?
• ¿Es la información que se presenta internamente consistente y coherente con la
información se presentan en objetos de otros contenidos?
• ¿Puede el contenido debe interpretarse como ofensiva o engañosa, o se abrir la puerta a
un litigio?
• ¿El contenido infringe los derechos de autor o marcas existentes?
• ¿El contenido contiene enlaces internos que complementan el contenido ya existente?
• ¿Son los vínculos correctos?
• ¿Tiene el estilo estético de los contenidos conflicto con el estilo estético de la interfaz?
Objetivo de las pruebas: Detectar errores en los contenidos de la aplicación web
23. En muchas aplicaciones web el contenido es dinámico. Y mucho de lo que se construye e
implementa depende del contenido de la base de datos, y la construcción de objetos se
hace en tiempo real. Por lo cual puede decirse que la BD esta estrechamente ligada a la
presentación web.
¿Que tipo de errores de contenido podrían estar relacionados con una base de datos?
Pressman menciona la no coincidencia de la información visualizada con la existente en BD
500 A1 Año Contable
A2 Agencia 2008 2009 2010 Total
300 A1 110 180 210 500
250 A3 A2 130 200 50 380
A3 80 90 80 250
250 400 500
A1 A2 A3
Extrañas divergencias entre gráficos que supuestamente presentan la misma información
Si este caso se presentare, podríamos corregir el error, ¿porque?... Pues
porque lo podemos detectar visualmente
24. Cuando la información no es mostrada en una interfaz gráfica al usuario.
Ejemplo: Cuando usted retira información del cajero automático puede visualizar
gráficamente la información:
Saldo = Saldo – Retiro 1
Lógica web
WebApp
BD
Cuando la Base de datos esta localizada en una estación remota, diferente a
la que aloja la aplicación web.
La comunicación de estación a estación es crítica, un problema de comunicación podría
afectar la coherencia de la data 2
WebApp
Data BD
Host A Host B
La aplicación Web recibe información de la BD, y la transforma para su
transmisión hacia el cliente.
3
WebApp
Data con formato Data BD
Host A Host B
25. Compatibilidad el objeto de datos con formato, con las
diferentes configuraciones del cliente
4
Cliente WebApp
Objetos con Datos
modo X Data BD
Host A Host B
Cliente Los objetos de datos con formato deberían poder
modo Y desempeñarse adecuadamente con cualquiera de las
distintas configuraciones de los clientes
Cliente
modo Z
26. En resumen, validamos:
• Información transferida en la comunicación cliente/servidor
• Ejecución de Scripts en la WebApp.
• Transferencia de información formateada
• Comunicación adecuada con el Servidor de datos
Transformación de datos WebApp
Administrador de datos
Interfaz de Usuario
Acceso a Datos
Base de Datos
28. La interfaz se verifica y valida en dos fases del desarrollo de la
aplicación:
Diseño: Comunicación, modelado y diseño propiamente dicho
Implementación: validación del comportamiento y funciones. Se
verifica la sintaxis, semántica, la facilidad de uso, etc.
Se verifica en una interfaz:
Mecanismos de interfaz: aspectos netamente de la interfaz,
funcionamiento de enlaces (navegabilidad), Ingreso de datos.
Se verifican aspectos funcionales: Funcionalidad de la interfaz,
navegabilidad de acuerdo a las especificaciones, etc.
29. Evalúa qué tan bien el diseño se hace cargo de los usuarios, ofrece una
dirección clara, ofrece retroalimentación, y mantiene la coherencia del
lenguaje y el enfoque.
Se pueden usar los modelos de diseño y/o casos de uso concebidos en el
diseño
Además, la prueba de la serie
debe incluir la selección del menú y el uso indebido enlace. La intención es
determinar si la aplicación web proporciona el manejo de errores y
recuperación eficaces.
30. Links: ¿funcionan?
Scripts del cliente: Codigo ejecutable en el lado del cliente que se encarga de ingreso de
datos (VBScript, JavaScript, html)
Forms: Los datos corresponden a los campos de datos?
Html dinámico: ¿adecuada relacion con las archivos de estilo CSS, y scripts?
Menus pop-up: ¿los menus se presentan adecuadamente?
Scripts del lado del Servidor: php, java, asp
Links de descarga
Cookies. Se almacenan y destruyen según corresponde (autenticaciones, etc.).
Mecanismos de
interfaz, ej. Carrito
de compras, etc.
Cookies de
seguridad
Ventana que graba y
destruye cookies
Ventana que lee cookies
32. Reglas generales de diseño: tipo de letra, colores, marcos, imágenes,
plantillas, etc.
Reglas individuales por interfaz (por c/u). Similar a la prueba de una unidad.
La interfaz se verifica a plenitud. Scripts, html, lógica de aplicación, etc.
Integración de interfaces. Se verifican que las interacciones o casos de usos
de cumplan
Prueba integral de la aplicación. Se verifican todos los casos de uso en los
que intervienen las interfaces.
Prueba de compatibilidad: se verifica la correcta ejecución de la WebApp en
diferentes entornos y/o navegadores web. También se verifica el adecuado
funcionamiento con las configuraciones diversas.
Index.html
Page1.php Page2.php Page3.php Page4.php Page5.php
Page6.php Page7.php Page8.php Page9.php
34. Consiste básicamente en: «Pruebas de usuarios de interfaz». Debemos determinar que
tan bien se adapta la interfaz al usuario tratamos de responder a la pregunta ¿La
interfaz puede usarse correctamente? ¿No habrán mensajes que se presten a confusión?
Medir usabilidad es básicamente medir si la WebApp cubre las necesidades del usuario
Constantine, L., “What Do Users Want? Engineering Usability in Software,”
Windows Tech Journal, December 1995, www.foruse.com. (accessed August 13, 2007).
En las pruebas de usabilidad deben participar los usuarios finales.
Se sugieren los siguientes pasos:
◦ Definir un conjunto de objetivos/metas de la evaluación
◦ Definir un conjunto de pruebas (testeos) para cada uno de los objetivos/metas
definidas previamente.
◦ Registrar (anotar) los sucesos ocurridos en la interacción de los usuarios con la
aplicación web
◦ Desarrollar los indicadores de evaluación de usabilidad para la WebApp. Reducir al
mínimo las medidas subjetivas y/o apreciaciones subjetivas.
36. La WebApp debe operar dentro de los ambientes que se diferencien entre sí.
Los diferentes parámetros de compatibilidad a consideran deberían ser: arquitectura de
ordenadores, dispositivos de pantalla, sistemas operativos, navegadores, y de la red,
resoluciones de pantalla, velocidad de conexión
Algunos navegadores, tales como Internet Explorer suelen exceder a las normas
estándar del World Wide Web Consortium (W3C).
Los navegadores, ocasionalmente producen distintos resultados a un mismo código
html.
Las pruebas de compatibilidad consiste en la verificación del mismo comportamiento
cuando varían todas esas características de los dispositivos hardware y software que
sirven de plataforma de alojamiento a las aplicaciones web.
El World Wide Web Consortium, abreviado W3C, es un consorcio internacional que produce
recomendaciones para la World Wide Web las mismas que son consideradas Estándares en Web.
37. Es el conjunto de pruebas orientadas a descubrir errores en las funciones de la WebApp.
Particiones equivalentes: el dominio de la entrada de datos se subdivide en categorías
Categoría 1 Nombre: Juan
Edad: 25 1
Lógica web
WebApp
Categoría 2 Nombre: Luis
Edad: 45
BD
Análisis de valores límites. Los formularios de datos son sometidos a valores críticos y/o extremos y se
verifica su comportamiento
Categoría 1 Nombre: A?xz4
Edad: 180 1
Lógica web
WebApp
Categoría 2 Nombre: LXT%a
Edad: 0 BD
Ruta de prueba. Si la funcionalidad es compleja, se diseñan pruebas secuenciales que permitan verificar
el cumplimiento de todos las bifurcaciones posibles de acciones de los componentes
Caso 1 Nombre: A?xz4 Page1.php Page2.php Page3.php
Edad: 180 ¿infoX? ¿infoY? ¿infoZ?
Caso 2 Nombre: LXT%a Page1.php Page2.php Page4.php
Edad: 0 ¿infoY? ¿infoZ?
¿infoX?
38. La primera fase del testeo de navegabilidad se produce en la verificación de la interfaz, donde
se verificaron links, redireccionamientos, frames, etc.
El diseño de la navegabilidad consiste básicamente en agrupar contenidos para ser explorados
(Pressman los llama Unidades de Navegación Semantica o NSU). Estas NSU son un conjunto de
rutas de navegación, agrupadas en base a la relación de la información que representan.
El equipo de desarrollo Web debe verificar:
¿Hay errores en los NSU?
¿Se accesa adecuadamente a cada Nodo de navegación (NSU)?
¿Existe un mecanismo (que no sea la flecha hacia atrás del navegador) para volver al nodo de
navegación anterior y al inicio de la ruta de navegación?
¿Existen mecanismos para la navegación dentro de un gran nodo de navegación (por
ejemplo, el ancla de enlaces junto a una página Web de longitud) funciona correctamente?
Si una función se va a ejecutar en un nodo y el usuario elige no proporcionar de
entrada, puede bloquearse el acceso al resto de la NSU?
Si una función se ejecuta en un nodo y se produce un error en el procesamiento de la
función, puede ser completado el NSU?
¿Hay alguna manera de interrumpir la navegación antes de que todos los nodos hayan sido
alcanzado, pero luego regresar al lugar donde la navegación se suspendió y proceder a partir
de ahí?
Es accesible cada nodo del mapa del sitio web
39. Se refiere a las modificaciones en los parámetros de configuración de la WebApp, en
donde, se considera los de la plataforma de alojamiento de la misma.
Aquí mencionamos algunas de las preguntas a dilucidar en esta sección:
Es la aplicación web totalmente compatible con el sistema operativo del servidor?
¿El sistema de archivos, directorios, y datos relacionados estará disponible para
correctamente cuando la aplicación web esté en funcionamiento?
¿Las medidas de seguridad del sistema (por ejemplo, firewalls, o cifrado) no interfieren
con la correcta ejecución de la Aplicación web, ni con su rendimiento?
¿Los scripts del lado del servidor se ejecutan correctamente?
40. Las pruebas de seguridad son complejas. Las consideraciones son:
Hackers: por ejemplo bloqueos de la pagina web empresarial, corrupción de la data, etc.
Empleados descontentos
Competidores deshonestos
Los puntos comúnmente considerados son:
Firewalls o cortafuegos. Es un mecanismo de hardware y software que verifica cada
paquete de datos para asegurarse que su origen es de fuentes confiables.
Autenticación. Verificación de todos los clientes y servidores que permite la
comunicación solo cuando ambas partes estén plenamente identificadas.
Autorización. Autorización de acceso al sistema en los niveles que correspondan
solamente a los debidos usuarios registrados.
Cifrado de la data. Sistemas de codificación que permiten proteger la confidencialidad
de la información.
En lo relativo a performance verificamos características tales como: velocidad de respuesta,
salidas adecuadas a fallos del sistema, etc.
41. Las pruebas de rendimiento están diseñados para simular situaciones del mundo real de
carga. A medida que el número de usuarios simultáneos aplicación web crece, o el número de
transacciones en línea aumenta, o la cantidad de datos (descarga o subida) aumenta, el
rendimiento prueba le ayudará a responder las siguientes preguntas:
¿El tiempo de respuesta del servidor degenera hasta el punto donde es notable e
inaceptable?
¿En qué momento (en términos de usuarios, transacciones, o la carga de datos) el
rendimiento ha llegado a ser inaceptable?
¿Qué componentes del sistema son responsables de la degradación del rendimiento?
¿Cuál es el tiempo medio de respuesta para los usuarios en una variedad de condiciones
de carga?
¿La degradación del rendimiento tiene un impacto en la seguridad del sistema?
¿Es la fiabilidad o exactitud de la aplicación web afectada cuando la carga del sistema
crece?
¿Qué ocurre cuando se aplican cargas mayores a las de la capacidad máxima del servidor?
¿Cuál es el impacto de los malos resultados en los ingresos de la compañía?