Director Técnico en Escuela Politécnica Superior. Universidad de Alicante
17 de May de 2017•0 recomendaciones•738 vistas
1 de 16
Pruebas del servicio web
17 de May de 2017•0 recomendaciones•738 vistas
Descargar para leer sin conexión
Denunciar
Tecnología
Presentación tema 4 de la asignatura "Servidores web" del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web. sobre pruebas a servicios web
3. SW pruebas
Destinadas a descubrir problemas por
●
Falta de recursos: red (ancho de
banda), sistemas (hw o sw) o apps
(diseño,...)
●
Confictos HW o SW (que conduzcan a
degradación del rendimiento)
Objetivos:
●
Conocer cómo se comporta el servicio
conforme aumenta la carga
●
Recopilar información para mejorar el
rendimiento
introducción
4. SW pruebas
¿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?
Objetivos
5. SW pruebas
¿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?
Objetivos
6. SW pruebas
¿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?
Objetivos
7. SW pruebas
Determinar cómo responderá la webapp
y su backend en condiciones variables de
carga. Variables importantes:
●
N, número de usuarios concurrentes
●
T, número de transacciones en línea
por unidad de tiempo
●
D, carga de datos procesados en cada
transacción
●
R, respuesta promedio
●
Tm, tiempo promedio para procesar
una transacción
●
Dm, tiempo promedio para descargar
una unidad estandarizada de datos
Prueba de carga
8. SW pruebas
Determinar si una disminución abrupta
en el rendimiento puede rastrearse en
una combinación específica de N, T y D.
El rendimiento global, P, se calculará:
P= NxTxD
Ejemplo: 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
Prueba de carga
9. SW pruebas
●
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.
●
¿El sistema se degrada “suavemente” o
el servidor se apaga conforme la
capacidad se supera?
●
¿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 recuperarse?
Prueba de esfuerzo
10. SW pruebas
●
¿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?
●
A una variación de las pruebas de
esfuerzo en ocasiones se le conoce como
prueba pico/rebote (spike/bounce)
Prueba de esfuerzo
11. SW pruebas
●
¿La webapp es completamente
compatible con el backend?
•¿Las medidas de seguridad del sistema
(por ejemplo, firewalls o cifrado) permiten
a la webapp ejecutarse y atender a los
usuarios sin interferencia o degradación
del rendimiento?
●
¿La webapp se integró adecuadamente
con el software de base de datos?
Prueba de configuración
12. SW pruebas
●
sondear las vulnerabilidades y
debilidades, tanto en el lado del cliente
como en el backend
●
¿Los datos comunicados entre el cliente
y el servidor son vulnerables al spoofing?
●
¿DoS?
●
¿Accesos? ¿A la base de datos?
●
…
●
Las pruebas de seguridad deben
diseñarse para sondear cada una de
estas tecnologías de seguridad con la
intención de descubrir agujeros
Prueba de seguridad
13. SW pruebas
●
Instalación: apt-get install apache2-utils
●
Uso:
ab -n 100 -c 10 http://miservidor/
n: conexiones
c: concurrencia
●
¿Qué nos proporciona?
.- tiempo de servicio
.- cantidad de datos que se transmiten
.- tiempo empleado en conectar con el
servidor, de procesamiento de la petición
.- % peticiones servidas en cierto
tiempo
ab
14. SW pruebas
●
Instalación: apt-get install apache2-utils
●
Uso:
ab -n 100 -c 10 http://miservidor/
n: conexiones
c: concurrencia
●
¿Qué nos proporciona?
.- tiempo de servicio
.- cantidad de datos que se transmiten
.- tiempo empleado en conectar con el
servidor, de procesamiento de la petición
.- % peticiones servidas en cierto
tiempo
ab
15. SW pruebas
●
Instalación: apt-get install siege
●
Uso:
siege -t 60s -c 100 -b -q http://miservidor/
t: tiempo de duración de la prueba
c: conexiones concurrentes
b: obliga a no tener ningún retraso entre cada usuario simulado
(modo benchmark)
q: elimina la salida
●
¿Qué nos proporciona?
●
Transactions: 7718 hits
●
Availability: 100.00 %
●
Elapsed time: 59.83 secs
●
Data transferred: 0.32 MB
●
Response time: 0.77 secs
●
Transaction rate: 129.00 trans/sec
●
Throughput: 0.01 MB/sec velocidad transporte de datos→
●
Concurrency: 98.97
●
Successful transactions: 7718
●
Failed transactions: 0
●
Longest transaction: 2.74
●
Shortest transaction: 0.02
siege