PRUEBAS DE SOFTWARE WEB PARA VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE

VERIFICACIÓN Y VALIDACIÓN
DE SOFTWARE
UNIDAD 3
PRUEBAS
TEMA 5
PRUEBA DE APLICACIONES
WEB (PARTE 2)
PhD. Víctor Rea Sánchez.

1
Subtemas
Pruebas de navegación. 3
4
Prueba de configuración.
Prueba de seguridad.
Prueba de rendimiento.
2

Objetivo
Conocer los diferentes tipos de pruebas
para aplicaciones web y diseñar un plan de
pruebas apropiado.

Actividad de inicio
Lluvia de ideas
Mencione una prueba para aplicaciones
web.

Prueba de navegación
La labor de la prueba de navegación es:
1.- Garantizar que son funcionales todos los mecanismos que permiten al usr recorrerla
y
2.- Validar que cada unidad semántica (USN) pueda lograr la categoría de usr
apropiada.
Se clasiﬁcan en:
● Prueba de sintaxis de navegación.
● Prueba de la semántica de la navegación

Prueba de sintaxis de navegación
Vínculos de
navegación,
Redirecciones,
Motores de
búsqueda internos
Marcos y
framesets
Marcas de
páginas
(favoritos-bo
okmarks)
Mapas
de sitio

Prueba de la semántica de navegación
Una unidad semántica de
navegación (USN) se define
como “un conjunto de
estructuras de información y
navegación relacionada que
colaboran en el cumplimiento
de un subconjunto de
requerimientos de usuario
relacionados.
Cada USN se define
mediante un conjunto de
trayectorias de navegación
(llamadas “rutas de
navegación que conectan
los nodos de navegación
(por ejemplo, páginas web,
objetos de contenido o
funcionalidad).
cada USN permite a un
usuario lograr
requerimientos
específicos definidos
por uno o más casos de
uso para una categoría
de usuario.
Es necesario responder las siguientes preguntas conforme se prueba cada USN:
● ¿La USN se logra en su totalidad sin error?
● ¿Existe un mecanismo (distinto a la flecha “retroceso” del navegador) para regresar al nodo de
navegación anterior y al comienzo de la ruta de navegación?
● 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?

Prueba de configuración
Componentes
El hardware, los
sistemas operativos,
navegadores, capacidad
de almacenamiento,
velocidades de
comunicación de red y
varios otros factores en
el lado cliente son
difíciles de predecir para
cada usuario.
Configuración
La impresión que un
usuario tiene de la
webapp y la forma en la
que interactúa con ella
pueden diferir
significativamente de la
experiencia de otro
usuario si ambos
usuarios no tienen la
misma configuración..
Objetivo
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 del servidor
● En el lado del cliente

Lorem ipsum dolor sit amet at nec at
adipiscing
03
● Donec risus dolor porta venenatis
● Pharetra luctus felis
● Proin in tellus felis volutpat
adipiscing
02
adipiscing
01
Más preguntas ----->>
03
● ¿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?
● .Si se usan servidores proxy, ¿las diferencias en su
configuración se abordaron con pruebas en sitio?
Conforme se diseñan las pruebas
de configuración del lado servidor,
debe considerarse cada
componente de la configuración
del servidor.
02
● Entre las preguntas que deben plantearse y responderse durante
la prueba de configuración del lado servidor se encuentran:
● ¿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?
Los casos de prueba de
configuración se diseñan para
verificar que la configuración
servidor proyectada pueden
soportar las webapp sin error.
01
● Servidor webapp
● Servidor de base de datos
● Sistemas operativos / firewalls / etc.
Conflictos en el lado del servidor

Conflictos en el lado del cliente
Conflictos
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:
Componentes
1. Hardware: CPU, memoria, almacenamiento y dispositivos de impresión.
2. Sistemas operativos: Linux, Macintosh OS, Windows, un OS móvil.
3. Software navegador: Firefox, Safari, Internet Explorer, Opera, Chrome y
otros
Componentes
4. Componentes de interfaz de usuario: Active X, Java applets y otros.
5. Plug-ins: QuickTime, RealPlayer y muchos otros.
6. 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.
Las webapss son blanco
atractivo para hackers,
empleados descontentos,
competidores
deshonestos.
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
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
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.
Las pruebas de
rendimiento se usan para
descubrir problemas de
rendimiento que pueden
ser resultado de:
● falta de recursos
en el lado servidor.
● red con ancho de
banda inadecuada.
● capacidades de base
de datos
inadecuadas.
● capacidades de
sistema operativo
deﬁcientes o débiles.
● funcionalidad de
webapp pobremente
diseñada.

Objetivos:
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 se diseñan
para simular
situaciones de carga
del mundo real.
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?

Para desarrollar respuesta a estas preguntas:
Pruebas de
rendimiento
Prueba
de carga
Prueba de
esfuerzo

Prueba de rendimiento: prueba de carga
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
La prueba de carga también
puede usarse para valorar las
velocidades de conexión
recomendadas para los usuarios
de la webapp → P = N x T x D
Conforme avanzan las
pruebas, las permutas
de las siguientes
variables definen un
conjunto de condiciones
de prueba:
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.
Medidas: respuesta de
usuario promedio, tiempo
promedio para descargar
una unidad estandarizada
de datos y tiempo
promedio para procesar
una transacción

Prueba de rendimiento: prueba de carga
Tome como ejemplo un sitio popular de noticias deportivas. En un momento
dado, 20 000 usuarios concurrentes envían una solicitud (una transacción, T)
una vez cada 2 minutos en promedio. Cada transacción requiere que la webapp
descargue un nuevo artículo que promedia 3 Kb de longitud. Por tanto, el
rendimiento global puede calcularse como:
P = [20 000 x 0.5 x 3Kb]/60 = 500 Kbytes/s = 4 megabits por segundo
Por ende, la conexión de la red para el servidor tendría que soportar esta tasa de
datos y debería ponerse a prueba para asegurarse de que lo hace.

Prueba de rendimiento: prueba de esfuerzo
Prueba pico/rebote
En este régimen de pruebas, la
carga alcanza un pico de capacidad,
luego se baja rápidamente a
condiciones operativas normales y
después alcanza de nuevo un pico
Al rebotar la carga del sistema, es
posible determinar cuán bien el
servidor puede ordenar los recursos
para satisfacer una demanda muy
alta y entonces liberarlos cuando
reaparecen condiciones normales
¿Qué es?
La prueba de esfuerzo es
una continuación de la
prueba de carga, pero en
esta instancia las va-
riables N, T y D se
fuerzan a satisfacerse y
luego se superan los
límites operativos.
¿Cúal es la intención?
● ¿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?
● Si el sistema falla, ¿cuánto tiempo
tardará en regresar en línea?

Actividad de cierre
TALLER GRUPAL

Bibliografía
ROGER S. PRESSMAN ; TRADUCTORES VÍCTOR CAMPOS OLGUÍN, JAVIER
ENRÍQUEZ BRITO. (2010). INGENIERÍA DEL SOFTWARE UN ENFOQUE
PRÁCTICO. MÉXICO: MCGRAW-HILL

PRUEBAS DE SOFTWARE WEB PARA VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE

Más contenido relacionado

Similar a PRUEBAS DE SOFTWARE WEB PARA VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE (20)

Último (20)

PRUEBAS DE SOFTWARE WEB PARA VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE