Please enable JavaScript.
Coggle requires JavaScript to display documents.
PRUEBAS DE APLICACIONES WEB (PRUEBA DE RENDIMIENTO (Prueba de carga…
PRUEBAS DE APLICACIONES WEB
Conjunto de actividades relacionadas con una sola meta.
Descubrir errores en el contenido, función, utilidad, navegabilidad, rendimiento, capacidad y seguridad de esa aplicación.
PRUEBA DE CONTENIDO
Combina revisiones con generación de casos de prueba ejecutables.
Las revisiones se aplican para descubrir errores semánticos en el contenido.
Las pruebas ejecutables se usan para descubrir errores de contenido que puedan rastrearse para derivar contenido que se impulse por los datos adquiridos de una o más bases de datos.
Objetivos
Descubrir errores sintácticos en documentos de texto, representaciones gráficas y otros medios.
Para lograrlo, pueden usarse correctores automáticos de vocabulario y gramática.
Descubrir errores semánticos en cualquier objeto de contenido que se presente conforme ocurre la navegación.
¿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 presentada 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?
Encontrar errores en la organización o estructura del contenido que se presenta al usuario final.
Durante esta prueba, la estructura y organización de la arquitectura de contenido se prueba.
Para garantizar que el contenido requerido se presente al usuario final en el orden y relaciones adecuados.
Prueba de base de datos
Pasos
1) Consulta a una gran base de datos de fondos.
2) Extracción de datos relevantes de la base de datos.
3) Organización de los datos extraídos como un objeto de contenido.
4) Transmisión de este objeto de contenido al entorno del cliente para su despliegue
Garantizan
Información válida entre el cliente y el servidor desde la capa interfaz.
La webapp procesa los guiones de manera correcta y extrae o formatea adecuadamente los datos del usuario.
Los datos del usuario pasan correctamente a una función de transformación de datos del lado servidor que formatea consultas adecuadas.
Las consultas pasan a una capa de gestión de datos que se comunica con las rutinas de acceso a la base de datos.
PRUEBA DE INTERFAZ DE USUARIO
Estrategias
Descubrir errores relacionados con mecanismos de interfaz específicos.
Descubrir errores en la forma como la interfaz implanta la semántica de navegación, la funcionalidad de la webapp o el despliegue de contenido
Prueba de mecanismos de interfaz
Consideraciones de prueba.
Vínculos.
Cada vínculo de navegación se prueba para garantizar que se alcanza el objetivo de contenido o función apropiados.
Se construye una lista de todos los vínculos asociados con la plantilla de interfaz y se ejecuta cada uno individualmente.
Se ejecutan los vínculos dentro de cada objeto de contenido para descubrir URL o vínculos defectuosos.
Los vínculos con webapps externas deben probarse en su precisión y evaluarse para determinar el riesgo.
Formularios
Las pruebas en un nivel macroscópico se realizan para asegurarse de que
Las etiquetas identifican los campos dentro del formulario y los campos obligatorios se identifican visualmente para el usuario.
El servidor recibe toda la información contenida dentro del formulario y ningún dato se pierde en la transmisión entre cliente y servidor.
Se usan valores por defecto adecuados cuando el usuario no selecciona de un menú desplegable o conjunto de botones
Las funciones del navegador no corrompe la entrada de datos en un formulario
Los guiones que realizan la comprobación de errores en los datos ingresados funcionan de manera adecuada y proporcionan mensajes de error significativos.
Las pruebas en un nivel más dirigido garantizan
Los campos del formulario tienen ancho y tipos de datos adecuados.
El formulario establece salvaguardas adecuadas que prohíben que el usuario ingrese cadenas de texto más largas que cierto máximo predefinido.
Todas las opciones adecuadas para menús desplegables se especifican y ordenan en forma significativa para el usuario final.
Las características de “autollenado” del navegador no conducen a errores en la entrada de datos.
Cualquier tecla inicia el movimiento adecuado entre los campos del formulario
Guión en el lado del cliente
Se realizan para descubrir cualquier error en el procesamiento conforme se ejecuta el guión.
Se debe asegurar de que los estándares [de webapps] de la compañía proporcione el lenguaje y versión preferidos del lenguaje de guión que se va a usar para la escritura de guiones en el lado cliente.
HTML dinámico
Cada página web que contenga HTML dinámico se ejecuta para asegurar que el despliegue es correcto.
Prueba de compatibilidad para asegurarse que funciona adecuadamente en las configuraciones de entorno que soportan la webapp.
Guiones CGI
Se realizan con énfasis sobre la integridad de los datos y del procesamiento del guión.
Contenido de Streaming
Se debe demostrar que los datos están actualizados, se despliegan de manera adecuada y que pueden suspenderse sin error y reanudarse sin dificultad.
Cookies
Se requieren pruebas tanto del lado servidor como del lado cliente.
Deben garantizar que una cookie se construyó adecuadamente y que se transmitió de manera adecuada al lado cliente.
Determinan si la webapp liga adecuadamente las cookies existentes a una solicitud específica (enviada al servidor).
Mecanismos de interfaz específicos de aplicación
Lista de comprobación para la funcionalidad.
Prueba de frontera del número mínimo y máximo de artículos que pueden colocarse en el carro de compras.
Prueba de una solicitud de “salida” para un carro de compras vacío.
Prueba para determinar si una compra vacía el contenido del carro.
Prueba para determinar la persistencia del contenido del carro de compras
Prueba para determinar si la webapp puede recordar el contenido del carro de compras en alguna fecha futura.
Prueba de borrado adecuado de un artículo del carro de compras.
Ventanas pop-up garantizan
La aparición instantánea tiene el tamaño y posición adecuadas.
La aparición no cubre la ventana de la webapp original.
El diseño estético de la aparición es consistente con el diseño estético de la interfaz.
Las barras de desplazamiento y otros mecanismos de control anexados a la ventana de aparición se ubican y funcionan de manera adecuada.
Prueba de la semántica de la interfaz
Evalúa cuán bien cuida el diseño a los usuarios, ofrece instrucciones claras, entrega retroalimentación y mantiene consistencia de lenguaje y enfoque
Descubre errores que evitarán que un usuario logre el objetivo asociado con el caso de uso.
mantener una lista de comprobación para asegurar que cada objeto del menú se ejercitó al menos una vez y que se utilizó cada
vínculo incrustado dentro de un objeto de contenido.
Pruebas de usabilidad
Evalúa el grado en el cual los usuarios pueden interactuar efectivamente con la webapp y el grado en el que la webapp guía las acciones del usuario.
Proporciona retroalimentación significativa y refuerza un enfoque de interacción consistente
Pasos
Definir un conjunto de categorías de prueba de usabilidad e identificar las metas de cada una.
categorias
Interactividad: ¿Los mecanismos de interacción son fáciles de entender y usar?
Plantilla: ¿Los mecanismos de navegación, contenido y funciones se colocan de forma que el usuario pueda encontrarlos rápidamente?
Legibilidad: ¿El texto está bien escrito y es comprensible? ¿Las representaciones gráficas se entienden con facilidad?
Estética: ¿La plantilla, color, fuente y características relacionadas facilitan el uso? ¿Los usuarios “se sienten cómodos” con la apariencia y el sentimiento de la webapp?
Características de despliegue: ¿La webapp usa de manera óptima el tamaño y la resolución de la pantalla?
Sensibilidad temporal: ¿Las características, funciones y contenido importantes pueden usarse o adquirir en forma oportuna?
Personalización: ¿La webapp se adapta a las necesidades específicas de diferentes categorías de usuario o de usuarios individuales?
Accesibilidad: ¿La webapp es accesible a personas que tienen discapacidades?
2.Diseñar pruebas que permitirán la evaluación de cada meta.
Seleccionar a los participantes que realicen las pruebas.
Instrumentar la interacción de los participantes con la webapp mientras se lleva a cabo la prueba.
Desarrollar un mecanismo para valorar la usabilidad de la webapp
Pruebas de compatibilidad
Definir un conjunto de configuraciones de cómputo, y sus variantes, que “se encuentran comúnmente” en el lado cliente
Pruebas de validación de compatibilidad, adaptadas de pruebas de interfaz existentes, de navegación, de rendimiento y de seguridad.
PRUEBA EN EL NIVEL DE COMPONENTE
Se enfoca en un conjunto de pruebas que intentan descubrir errores en funciones de las webapps
Métodos de diseño de caso de prueba
Partición de equivalencia:
El dominio de entrada de la función se divide en categorías o clases de entrada a partir de las cuales se derivan casos de prueba.
El formulario de entrada se valora para determinar cuáles clases de datos son relevantes para la función.
Los casos de prueba para cada clase de entrada se derivan y ejecutan, mientras que otras clases de entrada se mantienen constantes.
Análisis de valor de frontera:
Los datos de los formularios se prueban en sus fronteras
Prueba de rutas
Si la complejidad lógica de la función es alta, puede usarse para garantizar que se ejercitó cada ruta independiente en el programa
PRUEBA DE NAVEGACIÓN
Garantizar que son funcionales todos los mecanismos que permiten al usuario de la webapp recorrerla.
Validar que cada unidad semántica de navegación (USN) pueda lograr la categoría de usuario apropiada.
Prueba de sintaxis de navegación
Mecanismos.
Vínculos de navegación
Cada vínculo debe ser probado para asegurarse de que se alcanza el contenido o funcionalidad adecuados cuando se elige el vínculo.
Incluyen vínculos internos, externos y anclas dentro de una página web específica.
Redirecciones
Entran en juego cuando un usuario solicita una URL inexistente o cuando selecciona un vínculo cuyo contenido se removió o cuyo nombre cambió.
Se despliega un mensaje para el usuario y la navegación se redirige hacia otra página.
Los redireccionamientos deben probarse al solicitar vínculos internos incorrectos o URL externas y valorarse cómo manejan estas solicitudes.
Marcas de página
Debe probarse para garantizar la extracción de un título de página significativo conforme se crea la marca.
Marcos y framesets
Deben probarse para que tengan el contenido correcto, la plantilla y tamaño adecuados, rendimiento de descargas y compatibilidad de navegador.
Mapas de sitio
Cada entrada del mapa de sitio debe probarse para garantizar que los vínculos llevan al usuario al contenido o funcionalidad adecuados
Motores de búsqueda internos
Valida la precisión y completitud de la búsqueda, las propiedades de manejo de error del motor de búsqueda y las características de búsqueda avanzadas
Prueba de la semántica de navegación
Preguntas conforme se prueba cada unidad semántica de navegación(USN)
¿La USN se logra en su totalidad sin error?
¿Todo nodo de navegación se alcanza dentro del contexto de las rutas de navegación definidas por la USN?
Si la USN puede lograrse usando más de una ruta de navegación, ¿se probó cada ruta relevante?
Si la interfaz de usuario proporciona una guía para auxiliar en la navegación, ¿las instrucciones son correctas y comprensibles conforme avanza la navegación?
¿Existe un mecanismo para regresar al nodo de navegación anterior y al comienzo de la ruta de navegación?
¿Los mecanismos de navegación dentro de un gran nodo de navegación funcionan de manera adecuada?
Si una función debe ejecutarse en un nodo y el usuario elige no proporcionar entrada, ¿el resto de la USN puede completarse?
Si una función se ejecuta en un nodo y ocurre un error en el procesamiento de la función, ¿la USN puede completarse?
¿Existe alguna forma para descontinuar la navegación antes de que todos los nodos se hayan alcanzado, pero luego regresar a donde se descontinuó la navegación y avanzar desde ahí?
¿Todo nodo es alcanzable desde el mapa de sitio? ¿Los nombres de nodo son significativos para los usuarios finales?
Si un nodo dentro de una USN se alcanza desde alguna fuente externa, ¿es posible avanzar hacia el nodo siguiente en la ruta de navegación? ¿Es posible regresar al nodo anterior en la ruta de navegación?
¿El usuario entiende su ubicación dentro de la arquitectura de contenido conforme se ejecuta la USN?
PRUEBA DE CONFIGURACIÓN
Probar un conjunto de probables configuraciones en los lados cliente y servidor para garantizar que la experiencia del usuario será la misma en todos ellos y que aislará los errores que puedan ser específicos de una configuración particular.
Conflictos en el lado servidor.
Preguntas que deben plantearse y responderse durante la prueba
¿La webapp es completamente compatible con el servidor OS?
¿Los archivos de sistema, directorios y datos de sistema relacionados se crean correctamente cuando la webapp es operativa?
¿Las medidas de seguridad del sistema permiten a la webapp ejecutarse y atender a los usuarios sin interferencia o degradación del rendimiento?
¿La webapp se probó con la configuración de servidor distribuido que se eligió?
¿La webapp se integró adecuadamente con el software de base de datos? ¿La webapp es sensible a diferentes versiones del software de base de datos?
¿Los guiones de la webapp en el lado servidor se ejecutan adecuadamente?
¿Los errores del administrador del sistema se examinaron en sus efectos sobre las operaciones de la webapp?
Si se usan servidores proxy, ¿las diferencias en su configuración se abordaron con pruebas en sitio?
Conflictos en el lado cliente
Pruebas de configuración de componentes como:
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.
PRUEBA DE SEGURIDAD
Se diseñan para sondear las vulnerabilidades del entorno lado cliente, las comunicaciones de red que ocurren conforme los datos pasan de cliente a servidor y viceversa, y el entorno del lado servidor
Elementos de seguridad
Firewall: mecanismo de filtrado, que es una combinación de hardware y software que examina cada paquete de información entrante para asegurarse de que proviene de una fuente legítima y que bloquea cualquier dato sospechoso.
Autenticación: mecanismo de verificación que valida la identidad de todos los clientes y servidores, y permite que la comunicación ocurra solamente cuando ambos lados se verifican.
Encriptado: mecanismo de codificación que protege los datos sensibles al modificarlos de forma que hace imposible leerlos por quienes tienen intenciones maliciosas. El encriptado se fortalece usando certificados digitales que permiten al cliente verificar el destino al que se transmiten los datos.
Autorización: mecanismo de filtrado que permite el acceso al entorno cliente o servidor sólo a aquellos individuos con códigos de autorización apropiados.
PRUEBA DE RENDIMIENTO
Se usan para descubrir problemas como:
Falta de recursos en el lado servidor, red con ancho de banda inadecuada, capacidades de base de datos inadecuadas,etc.
Comprende cómo responde el sistema conforme aumenta la carga
Recopilar mediciones que conducirán a modificaciones de diseño para mejorar el rendimiento.
Objetivos
Responde preguntas como
¿El tiempo de respuesta del servidor se degrada a un punto donde es apreciable e inaceptable?
¿En qué punto (en términos de usuarios, transacciones o carga de datos) el rendimiento se vuelve inaceptable?
¿Qué componentes del sistema son responsables de la degradación del rendimiento?
¿Cuál es el tiempo de respuesta promedio para los usuarios bajo diversas condiciones de carga?
¿La degradación del rendimiento tiene impacto sobre la seguridad del sistema?
¿La confiabilidad o precisión de la webapp resulta afectada conforme crece la carga sobre el sistema?
¿Qué sucede cuando se aplican cargas que son mayores que la capacidad máxima del servidor?
¿La degradación del rendimiento tiene impacto sobre los ingresos de la compañía?
Prueba de carga
Determina cómo responderán las webapps y su entorno del lado servidor a varias condiciones de carga
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
Puede usarse para valorar las velocidades de conexión recomendadas para los usuarios de la webapp.
Fórmula
P= N x T x D
Prueba de esfuerzo
Responde preguntas como
¿El sistema se degrada “suavemente” o el servidor se apaga conforme la capacidad se supera?
¿El software servidor genera mensajes “servidor no disponible”? De manera más general, ¿los usuarios están conscientes de que no pueden llegar al servidor?
¿El servidor pone en cola los recursos solicitados y vacía la cola una vez que disminuye la demanda de capacidad?
¿Las transacciones se pierden conforme la capacidad se excede?
¿La integridad de los datos resulta afectada conforme la capacidad se excede?
¿Qué valores de N, T y D fuerzan el fallo del entorno servidor? ¿Cómo se manifiesta la falla? ¿Se envían notificaciones automáticas al personal de apoyo técnico en el sitio servidor?
Si el sistema falla, ¿cuánto tiempo tardará en regresar en línea?
¿Ciertas funciones de la webapp quedan descontinuadas conforme la capacidad alcanza el nivel de 80 o 90 por ciento?