Want to create interactive content? It’s easy in Genially!

Get started free

Prueba de aplicaciones Web

Ulises López Montano

Created on October 31, 2021

Start designing with a free template

Discover more than 1500 professional designs like these:

Corporate Christmas Presentation

Business Results Presentation

Meeting Plan Presentation

Customer Service Manual

Business vision deck

Economic Presentation

Tech Presentation Mobile

Transcript

Prueba de aplicaciones Web

Las pruebas no deben esperar hasta que el proyecto finalice. Comience a probar antes de escribir una línea de código. Pruebe constante y efectivamente, y desarrollará un sitio web mucho más duradero

01

CONCEPTOS DE PRUEBAS PARA APLICACIONES WEB

¿Qué es? La prueba de una webapp es una colección de actividades relacionadas con una sola meta: descubrir errores en el contenido, función, utilidad, navegabilidad, rendimiento, capacidad y seguridad de esa aplicación. Para lograr esto, se aplica una estrategia de prueba que abarca tanto revisiones como pruebas ejecutables.

Dimensiones de calidad

¿Cómo se valora la calidad dentro del contexto de una webapp y su entorno?

  • El contenido se evalúa tanto en el nivel sintáctico como en el semántico. En el primero, se valora vocabulario, puntuación y gramática para documentos basados en texto. En el segundo, se valora la corrección (de la información presentada), la consistencia (a través de todo el objeto de contenido y de los objetos relacionados) y la falta de ambigüedad.

¿Cómo se valora la calidad dentro del contexto de una webapp y su entorno?

  • La función se prueba para descubrir errores que indican falta de conformidad con los requerimientos del cliente. Cada función de la webapp se valora en su corrección, inestabilidad y conformidad general con estándares de implantación adecuados (por ejemplo, estándares de lenguaje Java o AJAX).
  • La estructura se valora para garantizar que entrega adecuadamente el contenido y la función de la aplicación, que es extensible y que puede soportarse conforme se agregue nuevo contenido o funcionalidad.
  • La usabilidad se prueba para asegurar que la interfaz soporta a cada categoría de usuario y que puede aprender y aplicar toda la sintaxis y semántica de navegación requerida.
  • El rendimiento se prueba bajo condiciones operativas, configuraciones y cargas diferentes a fin de asegurar que el sistema responde a la interacción con el usuario y que maneja la carga extrema sin degradación operativa inaceptable.

Errores dentro de un entorno de webapp

¿Qué hace que los errores encontrados durante la ejecución de una webapp sean un poco diferentes a los que se encuentran para el software convencional?

  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 diferentes entornos, puede ser difícil o imposible reproducir un error afuera del entorno en el que originalmente se encontró.
  3. 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 servidor o la red en sí.
  1. El modelo de contenido para la webapp 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.
  1. Las pruebas de seguridad se realizan con la intención de explotar las vulnerabilidades en la en la webapp o dentro de su entorno.
  2. Se realizan pruebas de rendimiento.

Estrategia de las pruebas

El plan de prueba identifica el conjunto de tareas de pruebas, los productos de trabajo que se van a desarrollar y la forma en la que deben evaluarse, registrarse y reutilizarse los resultados.

Planificación de pruebas

El proceso de prueba de webapps comienza con pruebas que ejercitan la funcionalidad del contenido y la interfaz que son inmediatamente visibles para el usuario final. Conforme avanza la prueba, se ejercitan aspectos de la arquitectura del diseño y de la navegación. Finalmente, la atención se centra en las pruebas que examinan las capacidades tecnológicas que no siempre son aparentes para los usuarios finales: los temas de infraestructura e instalación/ implantación de la webapp.

U N PANORAMA DEL\PROCESO DE PRUEBA

PRUEBA DE CONTENIDO

La prueba de contenido combina tanto revisiones como generación de casos de prueba ejecutables. Las revisiones se aplican para descubrir errores semánticos en el contenidoLa prueba de contenido combina tanto revisiones como 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 a fin de derivar dinámicamente contenido que se impulse por los datos adquiridos de una o más bases de datos.

PRUEBA DE CONTENIDO

Prueba de base de datos

Objetivos de la prueba de contenido

Las webapps modernas hacen mucho más que presentar objetos de contenido estáticos. En muchos dominios de aplicación, la webapp tiene interfaz con sofisticados sistemas de gestión de base de datos y construyen objetos de contenido dinámico que se crean en tiempo real, usando los datos adquiridos desde una base de datos.

Los objetivos de la prueba de contenido son:

  1. Descubrir errores sintácticos en el contenido.
  2. Descubrir errores semánticos y
  3. Encontrar errores estructurales.

Los objetivos de la prueba de contenido son: 1) descubrir errores sintácticos en el contenido, 2) descubrir errores semánticos y 3) encontrar errores estructurales.

Lorem ipsum dolor sit amet

PRUEBA DE INTERFAZ DE USUARIO

Cuando un usuario interactúa con una webapp, la interacción ocurre a través de uno o más mecanismos de interfaz.

  • Vínculos
  • Formularios

Prueba de mecanismos de interfaz

Estrategia de prueba de interfaz

La prueba de interfaz ejercita los mecanismos de interacción y valida los aspectos estéticos de la interfaz de usuario. La estrategia global para la prueba de interfaz es: 1) descubrir errores relacionados con mecanismos de interfaz específicos (por ejemplo, en la ejecución adecuada de un vínculo de menú o en la forma como entran los datos en un formulario) y 2) 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.

Lorem ipsum dolor sit amet

PRUEBA DE INTERFAZ DE USUARIO

Pruebas de usabilidad

Prueba de la semántica de la interfaz

La prueba de usabilidad es similar a la de semántica de interfaz porque también 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.

Una vez que cada mecanismo de interfaz ha sido sometido a prueba de “unidad”, la atención de la prueba de interfaz cambia hacia una consideración de la semántica de la interfaz. Esta prueba “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” Una vez que cada mecanismo de interfaz ha sido sometido a prueba de “unidad”, la atención de la prueba de interfaz cambia hacia una consideración de la semántica de la interfaz. Esta prueba “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” .

Lorem ipsum dolor sit amet

PRUEBA DE INTERFAZ DE USUARIO

Pruebas de compatibilidad

Las webapps se ejecutan dentro de varios entornos en el lado cliente. El objetivo de la prueba de compatibilidad es descubrir errores asociados con un entorno específico (por ejemplo, navegador).

Lorem ipsum dolor sit amet

PRUEBA EN EL NIVEL DE COMPONENTE

La prueba en el nivel de componente, también llamada prueba de función, se enfoca en un conjunto de pruebas que intentan descubrir errores en funciones de las webapps. Cada función de una webapp es un componente de software (implantado en uno de varios lenguajes de programación o lenguajes de guiones) y puede probarse usando técnicas de caja negra (y en algunos casos de caja blanca)

Lorem ipsum dolor sit amet

PRUEBA DE NAVEGACIÓN

Un usuario viaja a través de una webapp en forma muy parecida a como un visitante camina a través de una tienda o de un museo. Existen muchas rutas que pueden tomarse, muchas paradas que pueden realizarse, muchas cosas que aprender y mirar, actividades por iniciar y decisiones por tomar. Este proceso de navegación es predecible porque cada visitante tiene un conjunto de objetivos cuando llega. Al mismo tiempo, el proceso de navegación puede ser impredecible porque el visitante, influido por algo que ve o aprende, puede elegir una ruta o iniciar una acción que no es usual conforme el objetivo original.Un usuario viaja a través de una webapp en forma muy parecida a como un visitante camina a través de una tienda o de un museo. Existen muchas rutas que pueden tomarse, muchas paradas que pueden realizarse, muchas cosas que aprender y mirar, actividades por iniciar y decisiones por tomar. Este proceso de navegación es predecible porque cada visitante tiene un conjunto de objetivos cuando llega. Al mismo tiempo, el proceso de navegación puede ser impredecible porque el visitante, influido por algo que ve o aprende, puede elegir una ruta o iniciar una acción que no es usual conforme el objetivo original.

La labor de la prueba de navegación es 1) garantizar que son funcionales todos los mecanismos que permiten al usuario de la webapp recorrerla y 2) validar que cada unidad semántica de navegación (USN) pueda lograr la categoría de usuario apropiada.

PRUEBA EN EL NIVEL DE COMPONENTE

Prueba de sintaxis de navegación

La primera fase de la prueba de navegación en realidad comienza durante la prueba de interfaz. Los mecanismos de navegación se prueban para asegurarse de que cada interfaz realiza la función que se le ha encargado.La primera fase de la prueba de navegación en realidad comienza durante la prueba de interfaz. Los mecanismos de navegación se prueban para asegurarse de que cada interfaz realiza la función que se le ha encargado.

Lorem ipsum dolor sit amet

PRUEBA EN EL NIVEL DE

Prueba de sintaxis de navegación

La primera fase de la prueba de navegación en realidad comienza durante la prueba de interfaz. Los mecanismos de navegación se prueban para asegurarse de que cada interfaz realiza la función que se le ha encargado.La primera fase de la prueba de navegación en realidad comienza durante la prueba de interfaz. Los mecanismos de navegación se prueban para asegurarse de que cada interfaz realiza la función que se le ha encargado.

COMPONENTE

Splaine y Jaskiel sugieren que debe probarse cada uno de los siguientes mecanismos de navegación:

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

PRUEBA DE CONFIGURACIÓN

Conflictos en el lado servidor

En el lado servidor, los casos de prueba de configuración se diseñan para verificar que la configuració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 cliente

  • 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

En 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 componentesEn 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

PRUEBA DE SEGURIDAD

Las pruebas 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. Cada uno de estos dominios puede atacarse, y es tarea del examinador de seguridad descubrir las debilidades que puedan explotar quienes tengan intención de hacerlo.

Conflictos en el lado cliente

La seguridad de la webapp es un tema complejo que debe comprenderse por completo antes de que pueda lograrse una prueba de seguridad efectiva. Las webapps y los entornos en los lados cliente y servidor donde se albergan representan un blanco atractivo para hackers externos, empleados descontentos, competidores deshonestos y para quien quiera robar información sensible, modificar contenido maliciosamente, degradar el rendimiento, deshabilitar la funcionalidad o avergonzar a una persona, organización o negocio.

PRUEBA DE RENDIMIENTO

Nada es más frustrante que una webapp que tarda minutos en cargar contenido cuando sitios de la competencia descargan contenido similar en segundos. Nada es más exasperante queNada es más frustrante que una webapp que tarda minutos en cargar contenido cuando sitios de la competencia descargan contenido similar en segundos. Nada es más exasperante que intentar ingresar a una webapp y recibir un mensaje de “servidor ocupado”, con la sugerencia de que se intente de nuevo más tarde. Nada es más desconcertante que una webapp que responde instantáneamente en algunas situaciones y luego en otras parece caer en un estado de espera infinita. Estos eventos suceden en la web todos los días y todos ellos se relacionan con el rendimiento.

PRUEBA DE RENDIMIENTO

Objetivos de la prueba de rendimiento

Las pruebas de rendimiento se diseñan para simular situaciones de carga del mundo real. Conforme aumenta el número de usuarios simultáneos de la webapp o el número de transacciones en línea o la cantidad de datos (descargados o subidos), las pruebas de rendimiento ayudarán a responder las siguientes preguntas:

  • ¿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?

PRUEBA DE RENDIMIENTO

El objetivo de la prueba de esfuerzo es comprender de mejor manera como falla un sistema a medida que es forzado más allá de sus límites operacionales.

Prueba de carga

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. La intención de estas pruebas es responder a cada una de las siguientes preguntas:

  • ¿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?

pecífica de N, T y D. La prueba de carga también puede usarse para valorar las velocidades de conexión recomendadas para los usuarios de la webapp. El rendimiento global, P, se calcula de la forma siguiente: P=N*T*D

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. La intenciónde estas pruebas es responder a cada una de las siguientes preguntas: • ¿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?

¡GRACIAS!