WHITE PAPER DE AKAMAI

La guía completa para la realización

de pruebas de rendimiento de sus
aplicaciones y sitios web dedicados al retail
Tabla de contenido
Introducción a las pruebas de propiedades móviles y web del retail   ...................................... 1

¿Cuáles son los retos de rendimiento más comunes a los que se enfrentan
los retailers online?   ..................................................................................................................... 2

Introducción: Lista de comprobación de pruebas de rendimiento   .......................................... 2

¿Cuáles son los principales parámetros empresariales del retail online?   ................................. 3

¿Cuál es la rapidez adecuada?   .................................................................................................... 3

¿Quién debería formar parte de su equipo de pruebas?   ......................................................... 4

¿Qué debería analizar durante las pruebas?   ............................................................................. 5

Tipos de pruebas de rendimiento   .............................................................................................. 6

Pruebas en la fase de producción frente a pruebas en el laboratorio   .................................... 6

Pruebas en el laboratorio de rendimiento   ................................................................................ 7

Pruebas en la fase de producción (sí, es posible)   ...................................................................... 8

Pruebas de seguridad y rendimiento   ........................................................................................10

Apéndice A: Metodología de pruebas de rendimiento de Akamai   ........................................11

Apéndice B: Preguntas y respuestas sobre datos de rendimiento de CloudTest  ...................12

La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 1

Introducción a las pruebas de propiedades móviles y web

del retail
Los retailers que compiten bajo la presión del mundo del retail online se enfrentan a numerosos
retos. No solo deben ofrecer una experiencia de compra interesante y atractiva, sino que además
esa experiencia debe ser rápida y fiable.

Casi la mitad de los compradores online afirman que abandonarían una página si tardase más de
2 segundos en cargarse. En el caso de la tradicional tienda física, sustituir un establecimiento por
otro implica salir de él y correr a los brazos abiertos de la competencia. En Internet, la competencia
está solo a un par de clics.

INCREMENTAR LA VELOCIDAD DE LAS PÁGINAS ES UNA ESTRATEGIA EFICAZ PARA AUMENTAR EL

VOLUMEN DE CONVERSIONES E INGRESOS.
En Walmart.com, cada segundo de reducción del tiempo
de carga se traduce en un incremento del 2 % de la tasa

44 %
de los usuarios
de conversión. Staples.com redujo su tiempo medio de
carga en 1 segundo e incrementó su tasa de conversión
en un 10 %.

afirman que dudan LA FALTA DE DISPONIBILIDAD O VELOCIDAD DE

del éxito de las LOS SITIOS PUEDE AFECTAR A LA RETENCIÓN
transacciones
DE CLIENTES DURANTE MUCHO TIEMPO.
online lentas.
Los ingresos no son el único factor que se ve afectado
por las interrupciones y las ralentizaciones. Akamai ha
investigado el impacto de las interrupciones frente al de
las ralentizaciones en los índices de abandono de sitios de retail online. Los resultados fueron reveladores: los sitios en los
que se producían interrupciones presentaban, de media, un índice de abandono permanente del 9 %. En el caso de los
sitios lentos, el índice de abandono permanente era del 28 %.

REALIZAR PRUEBAS EN PRODUCCIÓN ES LO ÚNICO QUE GARANTIZA EL FUNCIONAMIENTO

ADECUADO DE LAS APLICACIONES ONLINE.
La realización de pruebas externas de la infraestructura de producción es ideal para la adopción de una perspectiva realista
de la capacidad y el rendimiento. (No obstante, así no se elimina la necesidad de realizar pruebas en un entorno de
laboratorio, ni sus ventajas. Es importante que exista continuidad entre ambos tipos de pruebas).
¿Cómo puede cerciorarse de que su tienda online ofrecerá una buena experiencia de compra y gestionará adecuadamente
los picos de tráfico que generan las promociones, eventos y alzas estacionales? ¿Cómo medir el éxito de su estrategia?
Esta guía se ha diseñado para proporcionarle la respuesta a preguntas como:
• ¿Cuáles son los retos de rendimiento más comunes a los que se enfrentan los retailers online?
• ¿Qué debería contener su lista de comprobación de pruebas de rendimiento?
• ¿Cuáles son los principales parámetros empresariales del retail online?
• ¿Quién debería formar parte de su equipo de pruebas?
• ¿Qué tipo de pruebas debería realizar?
• ¿Qué debería analizar durante las pruebas?
• ¿De qué elementos debería realizar pruebas en el laboratorio? ¿Por qué debería realizarlas también en la fase de
producción?

Empecemos.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 2

¿Cuáles son los retos de rendimiento más comunes a los que se

enfrentan los retailers online?
Las tiendas online se esfuerzan por equipararse a sus competidores tradicionales. Esto se debe a que los compradores
están acostumbrados a desplazarse a tiendas físicas donde pueden tocar, ver e interactuar con los productos antes de
tomar una decisión.
Internet no puede ofrecer el mismo nivel de interacción que una tienda física, pero gracias a numerosas funciones (como
vídeos, motores de recomendaciones, comentarios de los usuarios, imágenes de alta resolución que muestran los productos
desde distintos ángulos o herramientas que permiten "probarse" las prendas) los sitios web del retail ofrecen experiencias de
compra sin precedentes.
A esto hay que añadir el reto de dar difusión a las marcas online. Las hojas de estilo y las fuentes personalizadas le permiten
gestionar la presentación de su marca a su gusto, pero pueden comprometer la disponibilidad y el rendimiento de su sitio.
Establecer un equilibrio entre el rendimiento y el contenido avanzado para cumplir un objetivo de diseño determinado puede
ser todo un desafío.
Entre bambalinas, los sistemas de back-end de procesos de pago, autorización, comprobación de inventario y otras
aplicaciones también pueden suponer un reto.
Por último, la creación y el alojamiento de muchas de estas funciones (desde los comentarios de los usuarios hasta las fuentes
personalizadas, pasando por los procesos de pago) corresponden a terceros. Este contenido puede aportar funcionalidades e
información a su sitio, pero también añade una capa de complejidad y tráfico de muy difícil control.
Conocer la relevancia de este contenido es fundamental para la gestión del rendimiento general de su sitio.

Introducción: lista de comprobación de pruebas

de rendimiento
La creación de una estrategia de pruebas adecuada es esencial para que el rendimiento sea el correcto. Para empezar,
se debe conocer el modo en que los usuarios interactúan con su sitio de retail online.
Los ejemplos que se muestran a continuación son fundamentales para la definición de una estrategia de pruebas:
• Principales procesos empresariales (flujos) que siguen los visitantes del sitio
• Tiempo, de media, que los usuarios permanecen en el sitio.
• Porcentaje, de media, de usuarios que realizan compras frente a los que solo navegan.
• Índices de abandono y puntos del proceso en los que se produce.
• Media y número máximo de usuarios simultáneos por hora.
• Media y número máximo de visitas de páginas por minuto/hora.
• Media y número máximo de pedidos por minuto/hora.
• Diferencias entre patrones de tráfico de los parámetros anteriores durante eventos especiales como el Black Friday
o el Cyber Monday.
• Áreas geográficas de origen del tráfico del sitio.
• Porcentaje del tráfico procedente de dispositivos móviles, tipos de dispositivos, diferencias entre flujos de usuarios e
impacto en los parámetros anteriores.
• Si se utiliza una CDN, porcentaje de contenido procedente de la CDN.
Esta información facilita la definición de una estrategia de pruebas de rendimiento eficaz y le proporciona orientación para
diseñar y realizar pruebas.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 3

¿Cuáles son los principales parámetros empresariales del

retail online?
Los sitios de retail online emplean indicadores de rendimiento clave (KPI) específicos que facilitan el análisis del
rendimiento de los sitios:
• Pedidos por minuto: el número de pedidos que se efectúan en un periodo de tiempo determinado es un KPI clave
para los sitios de retail online. Los pedidos se traducen directamente en ingresos.

• Visitas de páginas por hora o minuto: los clientes solo efectúan pedidos si pueden usar los sitios de forma eficaz.
Es fundamental tener la seguridad de que los sitios de retail online ofrecen contenido web en todo momento para
que los usuarios realicen búsquedas, comparen e interactúen.

• Sesiones por hora: las sesiones son los sistemas o individuos que interactúan con el sitio. Es de vital importancia
garantizar que los usuarios puedan iniciar y mantener abierta una sesión durante el tiempo que necesiten para
realizar sus operaciones.

• Errores: aunque pueda resultar obvio, es fundamental realizar un seguimiento de la tasa global de errores y el tipo
de errores que aparecen. No todos los errores se producen del mismo modo.

• Tiempo de respuesta medio: conocer el tiempo medio que requiere la entrega de páginas y recursos de páginas es
relevante para identificar posibles obstáculos. También es el factor que tienen en cuenta muchos clientes a la hora de
juzgar la utilidad de un sitio de retail online.

• Tiempo de respuesta dentro del percentil 90: genera tiempos de respuesta con mayor nivel de detalle. El percentil
90 elimina el 10 % de los tiempos de respuesta más lentos. De este modo, se evitan los tiempos de espera (de unos
120 segundos de media) y se proporciona un indicador veraz de la respuesta del 90 % de usuarios.

¿Cuál es la rapidez adecuada?

Los sitios de retailers que se esfuerzan por lograr un buen rendimiento presentan tiempos de respuesta de menos de
3 segundos de media y tiempos de respuesta dentro del percentil 90 inferiores a 2,75 segundos.
Para garantizar que su sitio esté entre los mejores en términos de rendimiento, el retailer debe saber cuál es la rapidez
adecuada.
Cabe señalar que las expectativas de los usuarios varían en función del tipo de página. Por ejemplo, si los usuarios
navegan por un sitio, esperan tiempos de respuesta muy rápidos. Sin embargo, suelen esperar tiempos de respuesta algo
mayores al realizar el último paso de los procedimientos de pago.
Si un sitio de retail online alcanza sus objetivos de rendimiento durante las pruebas con un 150-200 % de los picos de
carga esperados, podrá hacer frente a eventos de marketing y periodos vacacionales con mayor seguridad.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 4

¿Quién debería formar parte de su equipo de pruebas?

Es fundamental contar con personal adecuado para la realización de pruebas.
De este modo, las pruebas son mucho más fructíferas. Cuando surgen problemas, es de vital importancia que exista un
equipo preparado para abordarlos rápidamente y tomar decisiones gracias a una inteligencia útil.
Existen diversos factores que determinan el número de profesionales que deben participar en una prueba, como el
tamaño de la empresa y la plantilla, la envergadura del sitio, la complejidad de la prueba, la externalización del desarrollo
y la implantación de aplicaciones de terceros en el sitio (si las hubiera), el empleo de un proveedor de servicios gestionados
para la infraestructura, etc.
En algunos casos, una o dos personas se encargan de todo. En otros, como la reconstrucción total de un sitio o la
realización de pruebas de un sitio popular para garantizar su buen funcionamiento en temporadas especiales, la mayoría
de tareas requieren la labor de varios profesionales, desde arquitectos hasta colaboradores particulares que se ocupan de
elementos específicos de la infraestructura.
Adoptar una estrategia supone asumir diversas responsabilidades:
• Coordinación: coordinación de las actividades de prueba con los principales interesados. Esto incluye servicios de
terceros conectados, ingeniería de aplicaciones, operaciones y proveedores, además de la implicación de responsables
empresariales y séniores.
• Comunicación: comunicación de resultados de pruebas, problemas, planes de resolución de problemas y progresos
de la estrategia general a los responsables empresariales y de ingeniería.
• Estrategia: definición de una estrategia general que incluya la creación de procesos empresariales para aplicaciones,
KPI, planes de capacidad, cobertura de supervisión y planes de pruebas individuales que se integren en el plano de
gestión del rendimiento del ciclo de vida de desarrollo de software.
• Arquitectura: aplicación de prácticas recomendadas para crear arquitecturas de infraestructuras y aplicaciones de
nuevos proyectos o destinadas a la mejora de aplicaciones existentes.
• Creación de pruebas: conversión de las definiciones de procesos empresariales en pruebas viables, creación
de cargas de trabajo de pruebas de rendimiento individuales a partir de planes de capacidad y mantenimiento
permanente de la biblioteca actual de casos de prueba.
• Realización de pruebas: realización de pruebas continuas en el laboratorio de rendimiento y el entorno de
producción con entrega de resultados.
• Análisis: revisión de los resultados de pruebas de todos los entornos y análisis del rendimiento en función de los
resultados de pruebas previas. Responsabilidad de notificar el incumplimiento de criterios de éxito definidos, el riesgo
de no alcanzar los resultados establecidos por KPI o la desviación de pruebas de actividad normal previas.
• Diagnóstico: análisis de causas de posibles cuellos de botella o problemas de rendimiento. Uso del conocimiento
de campo y de herramientas especializadas como analizadores, detectores de fugas de memoria y herramientas de
supervisión para identificar áreas problemáticas.
• Ajuste: el ajuste implica aplicar prácticas recomendadas y recomendaciones de adaptación, así como aislar partes de
la aplicación o la infraestructura que podrían optimizarse para mejorar la capacidad o el rendimiento.
• Medición: responsabilidad de analizar las actividades y su progreso en base a la estrategia general. Aplicación de las
recomendaciones de mejora de procesos para optimizar las actividades tácticas y estratégicas.

En las empresas pequeñas, estas responsabilidades pueden recaer en una persona, que con frecuencia cuenta con el
apoyo de Akamai para la creación, la adopción, la ejecución y el análisis de estrategias de pruebas.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 5

Normalmente, varias o todas las funciones se externalizan, en muchos casos para aprovechar la experiencia, centrarse en
áreas a las que no se presta suficiente atención o reducir costes.
Es frecuente que haya diversidad de individuos y funciones. Por ejemplo, contar con un gestor de proyectos, ingenieros de
rendimiento o especialistas eliminaría la necesidad de recurrir a un responsable técnico o permitiría a este dedicarse a otros
cabos sueltos del proceso. A continuación, se enumeran distintas funciones y las responsabilidades asociadas a cada una:
• Gestor de proyectos: coordinación, comunicación

• Responsable técnico: coordinación, comunicación, estrategia, arquitectura, análisis, diagnóstico, ajuste, medición

• Arquitecto: arquitectura de infraestructuras, arquitectura de aplicaciones

• Ingeniero de rendimiento: estrategia de desarrollo, arquitectura, análisis, diagnóstico, ajuste, medición

• Ingeniero de pruebas: creación, ejecución y análisis de pruebas

• Especialista: diagnóstico, optimización

¿Qué debería analizar durante las pruebas?

Saber qué agiliza o ralentiza un sitio de retail online facilita el diseño de las pruebas.
Muchos sitios de retail online son bastante complejos e integran niveles de aplicaciones y componentes diferentes.
Es importante conocer estos componentes y cómo interactúan entre sí.
Algunas áreas comunes en las que centrarse durante las pruebas son:
• Problemas de aplicaciones: no existe el código perfecto. Céntrese en problemas de sincronización, código
ineficiente, recopilación de elementos no utilizados, fugas de memoria y puntos muertos de aplicaciones.

• Rendimiento de bases de datos: esta es la clave del rendimiento. Céntrese en el bloqueo y la contención, la falta
de índices, las consultas poco eficaces, la gestión de memoria y conexiones y el crecimiento descontrolado de datos.

• Ajustes de configuración: normalmente, la configuración predeterminada no es óptima. Identifique diferencias

entre entornos y opciones de optimización y prácticas recomendadas para los distintos dispositivos de la arquitectura.

• Equilibrio de carga: utilice el hardware de forma eficiente. Identifique algoritmos no optimizados y capacidades y
funciones infrautilizadas.

• Conexión: la comunicación es vital. Asegúrese de que es posible establecer comunicaciones entre sistemas con un
mínimo de latencia, de que el firewall dispone de suficiente capacidad, de que el sistema está optimizado para redes
móviles, de que el enrutamiento DNS es correcto y de que el almacenamiento en caché de CDN está optimizado.

• Ancho de banda: ¿es suficiente? Cerciórese de que el ancho de banda sea suficiente para el tráfico. Revise el
contenido de las páginas. El contenido avanzado puede generar requisitos estrictos de ancho de banda y datos.
Compruebe que el sitio admite distintas velocidades y tipos de conexión, incluso de dispositivos móviles.

• Arquitectura: adapte los componentes al núcleo. Céntrese en niveles desequilibrados, alternativas tecnológicas
incompatibles y rutas de escalabilidad sin salida.

• Servicios de terceros: el recurso más ralentizado de su página será el que se valore para juzgar su velocidad.
Asegúrese de que los análisis, el seguimiento, los sistemas de pago, el contenido agregado, las redes sociales y las
CDN no ralenticen su sitio.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 6

Tipos de pruebas de rendimiento

Es habitual preguntarse qué tipo de pruebas se deben realizar.
Hay varias opciones: de actividad normal, de estrés, de picos de carga, de resistencia y de conmutación por error.
Para un retailer, todas tienen su utilidad.

Actividad normal
Los retailers deben establecer una referencia de rendimiento aceptable de su sitio en condiciones de "carga media".
Recomendamos extraer los resultados de los análisis de los últimos seis meses y la hora de mayor tráfico de cada día,
y utilizar dichos valores de carga como media de visualizaciones/hora y pedidos/minuto.

Estrés
Los retailers deben realizar pruebas de estrés para asegurarse de que el rendimiento de su sitio no disminuye ante una
carga pesada durante un periodo de tiempo prolongado. Es frecuente que las fugas de memoria y la recopilación errónea
de elementos no utilizados generen problemas de rendimiento que no se detectan hasta que no se realizan pruebas de
estrés. Akamai recomienda que las pruebas de estrés se realicen al 150-200 % de los picos de carga esperados.

Picos de tráfico
Las pruebas de picos de tráfico se realizan cuando se produce un aumento del número de usuarios de forma muy rápida
o casi simultánea. Las pruebas de picos de tráfico son fundamentales para los retailers. Muchos retailers experimentan
eventos que generan picos de tráfico (promociones relámpago, Black Friday, Cyber Monday, San Valentín...) que pueden
poner en peligro sus sitios. Es fundamental asegurarse de que durante estos eventos no se extravíen pedidos ni se
produzcan abandonos del sitio. Akamai recomienda que las pruebas de picos de tráfico se realicen al 200 % de los picos
de carga esperados.

Resistencia
Las pruebas de resistencia se diferencian de las de estrés por su magnitud. Mientras que las pruebas de estrés se realizan
con un volumen elevado de pedidos y visitas de páginas, durante las pruebas de resistencia se simula una carga algo
menor pero durante un periodo de tiempo más prolongado. Estas pruebas son muy útiles, ya que pueden revelar áreas
adicionales en las que el rendimiento disminuiría tras un periodo de tiempo prolongado. Existen tareas por lotes, copias de
seguridad de bases de datos y actualizaciones de caché que se pueden programar y realizar de forma periódica. Realizar
una prueba de resistencia durante varias horas puede revelar que este tipo de factores afectan al rendimiento.

Conmutación por error

La mayoría de retailers disponen de servidores de conmutación por error y recuperación ante desastres que deben actuar
en caso de fallo. ¿Se puede confiar en el hardware auxiliar ante un fallo de hardware en un momento de gran carga? La
única forma de averiguarlo es mediante una prueba de conmutación por error.
Normalmente, el objetivo de las pruebas iniciales es simplemente identificar las características de rendimiento del sitio.
Para estas pruebas, se emplean índices de crecimiento menores y más metódicos.
Una vez que se establecen estas referencias y se es consciente de los volúmenes que el sitio puede soportar, es
fundamental realizar pruebas lo más realistas posible. Esto incluye usar niveles de usuarios e índices de crecimiento
realistas. Revisar los análisis de años anteriores le ayudará a definir los niveles de crecimiento del número de usuarios.
Es fundamental que no haga trampa. No modifique los tiempos de procesamiento ni elimine elementos fundamentales
de las pruebas. Si lo hace, obtendrá resultados sesgados y estos serán menos útiles.

Pruebas de producción frente a pruebas de laboratorio

Para garantizar el éxito, necesita una estrategia de pruebas de retail online eficaz. Si desea que las pruebas se realicen
correctamente, debe contar con el equipo adecuado para implantar su estrategia. Para ello, se debe comprender por
qué son útiles las pruebas en la fase de producción y en el laboratorio de rendimiento.
Usar diversos tipos de pruebas en distintos entornos es fundamental para identificar y resolver cuellos de botella en la
arquitectura de los sitios de retail online, que suele ser bastante compleja.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 7

Creación de un plan integral en el que las pruebas de producción son un

componente esencial

Latencia entre sistemas

Configuración de red
RED Y
Ubicación de
OPERADORES Ancho de banda de red
archivos
Conflicto con otras aplicaciones en CDN
Enrutamiento DNS
Configuración del equilibrador de carga
Capacidad máxima
Errores de ampliación automática del firewall
FASE Y EQUIPO

LANZAMIENTO Superación del número máximo de sockets Servidores web no equilibrados

E IMPLANTACIÓN Plugins de terceros lentos Variabilidad de la latencia general

Ajustes de configuración por defecto Limitaciones tecnológicas

de búsquedas
Recopilación de Recursos de servidor
elementos no utilizados inadecuados

Fugas de memoria Recuentos de amenazas

DESARROLLO a bases de datos
Y PRUEBAS
Páginas Consultas poco eficaces
lentas de bases de datos

Ajuste del método

LABORATORIO DE PRUEBAS PRUEBAS PRODUCCIÓN (100 % Y MÁS)

SCALE DE
ESCALA OF PRUEBAS
TEST

La gráfica anterior muestra cómo identificar problemas específicos mediante distintos tipos de pruebas de laboratorio y en
la fase de producción para lograr un rendimiento óptimo.

Pruebas en el laboratorio de rendimiento

Realizar pruebas de laboratorio continuas permite a los equipos de ingeniería de aplicaciones evaluar la evolución del
rendimiento y facilita la identificación de fallos de rendimiento de gran repercusión antes de que afecten a la producción.
Además, el entorno de laboratorio permite realizar pruebas de rendimiento de código y cambios de configuración para
anticipar el rendimiento antes de implantar cambios en producción y fuera del ciclo de creación normal. Algunos ejemplos
serían la corrección rápida de errores de páginas o modificaciones de configuraciones aparentemente mínimas que
podrían afectar al rendimiento. Con frecuencia, este tipo de cambios se implantan sin realizar pruebas previamente
(o tras pruebas muy básicas), y posteriormente generan problemas de rendimiento.
Realizar pruebas en el laboratorio también permite provocar fallos en el sistema sin preocuparse por el impacto para los
usuarios.
Es importante saber cómo responde el sitio de retail online ante los fallos y cómo se recupera. No sería buena idea
provocar fallos en sitios de producción ya publicados.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 8

La metodología CloudTest de Akamai es una estrategia de pruebas de

rendimiento de control de calidad del software que incluye un conjunto
de procesos ligeros para garantizar la adecuación de las aplicaciones online
a periodos de máxima actividad.

Metodología CloudTest de Akamai

Estrategia Implementación Ejecución Medida

Definir Personas Definir Analizar

Integrar Procesos Diseñar Adaptar

Probar

Evaluar

Pruebas en la fase de producción (sí, es posible)

La única forma de generar verdadera confianza en un sitio es realizar pruebas en situaciones reales.
Debido al elevado número de usuarios que acceden a los sitios en un momento determinado, muy pocas empresas
pueden replicar un entorno de producción en un entorno de prueba o en un laboratorio de rendimiento. La realización
de pruebas de producción es ideal para la adopción de una perspectiva realista de la capacidad y el rendimiento. Además,
es la única forma de garantizar el funcionamiento adecuado de las aplicaciones online.
Hasta hace poco tiempo, se presuponía que las aplicaciones sometidas a pruebas en algunos servidores en un laboratorio
podrían hacer frente a volúmenes de carga exponencialmente superiores en producción. Este tipo de conclusiones siempre
van seguidas de obstáculos inesperados si no se realizan las pruebas adecuadas.

ALGUNOS HALLAZAGOS SOLO SON POSIBLES CON PRUEBAS EN PRODUCCIÓN

A continuación, se incluye una breve lista de problemas que no se detectan en pruebas de laboratorio:
• Tareas por lotes que no se realizan en el laboratorio (copias de seguridad, rotaciones de registros...) y el impacto
de otros sistemas online que afectan al rendimiento
• Problemas de rendimiento del equilibrador de carga, como ajustes de algoritmos mal configurados.
• Problemas de configuración de red como el empleo de 100 MB en lugar de 1 GB en conmutadores y problemas
de enrutamiento.
• Limitaciones de ancho de banda.
• Canal de datos no configurado como "ampliable" para gestionar picos de tráfico.
• Latencia entre sistemas dentro y fuera de burbujas de aplicaciones.
• Servidores web o servidores de aplicaciones mal configurados.
• CDN no configurada para ofrecer contenido nuevo.
• Diferencias de rendimiento pronunciadas en función del tamaño de la base de datos.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 9

RED DE DISTRIBUCIÓN DE CONTENIDO (CDN)

La infraestructura de la gran mayoría de laboratorios de pruebas no incluye una CDN. Por lo tanto, es imposible
determinar el impacto de la CDN en el rendimiento sin realizar pruebas en la fase de producción.
Cuando un retailer realiza pruebas de producción, puede evaluar en profundidad las capacidades de almacenamiento en
caché y descarga de su CDN. Esto es fundamental para conocer el rendimiento de un entorno de producción.
A la hora de preparar las pruebas de producción, es crucial que se comunique con el proveedor de CDN al inicio del
proceso para asegurarse de que cuenta con su apoyo para realizar las pruebas. (Akamai ha desarrollado una serie de
prácticas recomendadas para pruebas que incluyen recursos de CDN).
Un cliente de Akamai, ingeniero de rendimiento de un retailer valorado en miles de millones de dólares estadounidenses
con más de dos mil escaparates, considera fundamental la inclusión de una CDN en las pruebas de producción:
"Cuando realizamos pruebas de producción, normalmente habilitamos el almacenamiento en caché de Akamai. Esto
influye notablemente en las pruebas en cuanto al número de solicitudes que alcanzan el origen (sitio principal) y los
tiempos de respuesta en función de la ubicación de la que procede la página. En el laboratorio solemos recurrir menos
a Akamai. Esto significa que tenemos que incluir la CDN en nuestras pruebas de producción si queremos conocer su
verdadero rendimiento".

CONTENIDO DE TERCEROS
Muchos sitios de retail online recurren a proveedores externos para mejorar el contenido general de su sitio.
Es crucial seleccionar proveedores que ejerzan un impacto en el rendimiento antes de formular una estrategia.
Por otro lado, normalmente las pruebas no incluyen dominios como Google Analytics ni parámetros de Omniture.
Esto se hace para evitar sorpresas y que ninguna transacción falsa interrumpa el funcionamiento de su sitio o servicio.
La inclusión de proveedores externos al inicio del proceso permite garantizar su colaboración. Puede que incluso deseen
que se realicen mediciones de su servicio durante el proceso. Al fin y al cabo, también les interesa que el rendimiento de
su sitio sea bueno.

POSIBLE IMPACTO PARA CLIENTES REALES

Las pruebas de producción se pueden realizar con o sin usuarios del entorno publicado. Nota: La mayoría de clientes que
realizan pruebas de producción con Akamai CloudTest lo hacen en un entorno publicado.
Es posible, aunque no siempre viable, utilizar una página de mantenimiento o de bloqueo del acceso al sitio y esperar
a que se cierren todas las sesiones de usuario abiertas. En la práctica, este método apenas se utiliza, ya que usar una
herramienta y una metodología adecuadas permite realizar pruebas con usuarios activos en el sitio en todos los casos
salvo bajo circunstancias extremas.
En palabras de un cliente de Akamai: "El coste de no realizar pruebas es mucho mayor que el impacto potencial en los
clientes que utilizan el sitio publicado".
Si aplica el enfoque adecuado, podrá generar ingresos durante las pruebas. También es posible fragmentar parte del
entorno en directo durante periodos de poco tráfico y realizar las pruebas en un entorno secundario. Del mismo modo,
puede realizar pruebas en un centro de datos mientras se dirige a los usuarios a otro.
Normalmente, se configura una dirección IP independiente en un equilibrador de carga y se migran los servidores del
entorno publicado al entorno de prueba. En algunos casos, es necesario realizar cambios de configuración en otros
componentes compartidos. Este enfoque es más costoso porque requiere más hardware e inversiones en mantenimiento.
En cierto modo, también es menos fiable, ya que supone alejarse de la verdadera configuración de producción e impide
realizar pruebas a escala real. Sin embargo, estas pruebas son más realistas que las de laboratorio.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 10

TRES REQUISITOS PARA GARANTIZAR EL ÉXITO DE LAS PRUEBAS EN DIRECTO

1. Análisis en tiempo real

El primer requisito para realizar pruebas a gran escala con clientes en directo es disponer de una herramienta de pruebas
que incluya análisis en tiempo real. La información sobre el rendimiento de su sitio con precisión al segundo le permite
identificar rápidamente si el rendimiento es bajo o si el sitio no responde.

2. Un buen "conmutador general"

Siempre debe poder detener o abortar la carga de las pruebas de rendimiento inmediatamente. El ancho de banda, las
conexiones simultáneas, los subprocesos activos y otros elementos frecuentes volverán a la normalidad.

3. Prácticas de supervisión interna eficaces

Por último, las prácticas de supervisión interna adecuadas (preferiblemente integradas en su solución de pruebas) eliminan
la necesidad de abortar una prueba para evitar su impacto sobre los usuarios del sitio publicado. La visibilidad en tiempo
real de métricas como el uso de CPU, el uso de montones, la recopilación de elementos no utilizados y los recuentos de
conexiones en equilibradores de carga o firewalls contribuye a mantener valores adecuados durante las pruebas de rutina.

Pruebas de seguridad y rendimiento

La seguridad es uno de los aspectos en los que nadie repara hasta que genera problemas. No es habitual que el trabajo
eficaz de una empresa que protege los datos de sus clientes aparezca en los medios. De lo que sí se habla es de las
empresas que permiten que estos datos caigan en las manos equivocadas.
La seguridad de los datos es una de las mayores preocupaciones al realizar pruebas de rendimiento. Las empresas no
quieren que sus datos traspasen los firewalls.
Su solución de pruebas de rendimiento debería:
• Generar datos sintéticos con regularidad o utilizar datos de barrido en función de sus requisitos empresariales
y de seguridad
• Identificar solo parámetros HTTP/HTTPS y datos estadísticos clave para análisis, diagnóstico y generación de informes.
• Estar respaldada por una política de seguridad que garantice la protección de los datos.
Sin embargo, su solución no debería:
• Solicitar la exportación de datos o aplicaciones del firewall
• Guardar contenido de respuesta en servidores de pruebas o en la base de datos de resultados.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 11

Apéndice A: Metodología de pruebas de rendimiento de Akamai

La metodología de Akamai hace hincapié en la realización de varias pruebas en distintas ubicaciones para encontrar lo que
a menudo se considera una aguja en un pajar.

METODOLOGÍA CLOUDTEST DE AKAMAI

La metodología de pruebas de rendimiento de Akamai es una estrategia de pruebas de rendimiento de control de calidad
del software que incluye un conjunto de procesos ligeros que se integran en el ciclo de vida de desarrollo de software
para garantizar la adecuación de las aplicaciones online a periodos de máxima actividad. La metodología incluye pruebas
de aplicaciones en un entorno de laboratorio en el firewall y procesos de pruebas de la infraestructura de producción que
emplean los clientes.
Las pruebas de la nube aprovechan la eficiencia de la nube para analizar sitios y aplicaciones web. El uso de la
infraestructura y los servicios de empresas como Amazon Web Services y Rackspace permite a los clientes de Akamai
reducir el coste de las pruebas de carga y rendimiento y reflejar el tráfico real de los sitios con mayor precisión.
CloudTest es una arquitectura distribuida que también se puede implantar completamente detrás del firewall, o con una
combinación de configuraciones basadas en la nube e in situ.
Gracias a años de experiencia con pruebas en la nube, prácticas recomendadas y metodologías de pruebas de rendimiento
de gran eficacia, la metodología de Akamai amplía los enfoques tradicionales para abordar nuevos retos e identificar
oportunidades. Se incluyen los siguientes:
• Pruebas de laboratorio y de aplicaciones web en directo en la fase de producción
• Uso de la nube para realizar pruebas con niveles de tráfico normal y durante picos (con un número de usuarios que
varía de cientos a millones).
• Respuesta a la reducción de los tiempos del ciclo de desarrollo mediante la conversión de las pruebas de rendimiento
ágiles en una alternativa realista.
• Generación de cargas dispersas geográficamente para reflejar el tráfico real con mayor precisión.
• Generación de carga interna y externa en entornos de laboratorio y producción para lograr resultados óptimos en
términos de eficacia y eficiencia.
• Análisis de información sobre el rendimiento en tiempo real para agilizar la resolución de problemas.

ESTRATEGIA Y PLANIFICACIÓN
El enfoque de ingeniería de rendimiento de Akamai se basa en una estrategia general con planes de prueba individuales
asociados.
Los planes de prueba se integran en una visión general que garantiza la confianza en el buen funcionamiento de
aplicaciones de generación de ingresos clave.
El resultado es una estrategia de ingeniería de rendimiento que permanece durante toda la evolución del sitio.
Incluye varios planes de prueba centrados en objetivos individuales, como la preparación para periodos vacacionales,
modificaciones estructurales de gran alcance o lanzamientos de versiones principales de código.
Una estrategia bien definida con planes de prueba específicos garantiza la aptitud operativa a los responsables
empresariales y de ingeniería. Este enfoque ofrece un mayor volumen de información sobre el rendimiento de las
aplicaciones.
Recurrir a un proceso iterativo en los planes de prueba para alcanzar los objetivos establecidos genera un flujo de mejora
continua de las aplicaciones sometidas a pruebas.
Este proceso comienza con la definición de las pruebas y finaliza tras la obtención de información útil.
El proceso de creación de un plan de prueba empieza con la fase de definición. En esta fase se definen los flujos del sitio
de los que se van a realizar las pruebas y se establecen los parámetros que se van a supervisar y los criterios de éxito de
las pruebas. En la fase de diseño se determinan los distintos casos de usuarios y los parámetros de prueba. También se
modelan aspectos como la diversidad de usuarios que emplean diferentes componentes de la aplicación, objetivos de
usuarios virtuales y el tiempo de rampa.
Durante la fase de prueba, las pruebas se realizan finalmente y se recopilan datos para su evaluación.
La última fase es la de evaluación, que puede solaparse con la de prueba. En esta fase se proporciona inteligencia útil a
partir de los datos recopilados en la fase anterior.
La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 12

Apéndice B: Preguntas y respuestas sobre datos de rendimiento de CloudTest

¿QUÉ SON LOS DATOS DE RENDIMIENTO?

Durante las pruebas de rendimiento se emplean diversos tipos de datos de rendimiento. Estos datos se clasifican en
tres categorías principales: datos maestros, datos generados por los usuarios y datos externos. Normalmente, los datos
maestros se alojan en la base de datos del cliente y son necesarios para la gestión de la empresa (nombres de usuario,
contraseñas...). Los datos generados por los usuarios son aquellos que estos introducen en campos editables de la
aplicación (direcciones de correo electrónico nuevas, direcciones nuevas...). Los datos externos se generan al utilizar la
aplicación (números de confirmación, ID de sesión...).

¿QUÉ DATOS SE UTILIZAN DURANTE LAS PRUEBAS?

Los requisitos de datos varían en función de la aplicación y los procesos empresariales de los que se realizan las pruebas.
Por ejemplo, mientras que los datos de rendimiento pueden no ser necesarios en un sitio estático (y solo serlo el acceso al
sitio para realizar solicitudes), una aplicación más compleja puede requerir los tres tipos de datos de rendimiento.

¿QUÉ OCURRE CON LOS DATOS DE RESPUESTA QUE SE RECIBEN?

Todos los datos de respuesta relacionados con clientes se descartan de los servidores de CloudTest durante las pruebas
de carga. Solo se conservan los datos de rendimiento relacionados con estos datos de respuesta (tiempos de respuesta,
errores...). Además, como se menciona antes, los servidores de CloudTest son instancias temporales que se descartan
después de cada prueba, ya que en la base de datos de resultados solo se conservan los parámetros de rendimiento. Sin
embargo, los datos externos y de clientes se almacenan en el servidor de CloudTest durante la depuración y la creación
de scripts. Los datos utilizados para crear scripts se pueden eliminar al finalizar la creación para garantizar que no se
almacenen datos de clientes en los servidores de Akamai.

¿DURANTE CUÁNTO TIEMPO SE CONSERVAN LOS ARCHIVOS DE REGISTRO Y OTROS PARÁMETROS

QUE CONTIENEN INFORMACIÓN SOBRE DATOS?
Akamai no conserva archivos de registro ni otros parámetros con información sobre datos de clientes para la realización de
pruebas de carga. Sin embargo, como se menciona anteriormente, este tipo de datos sí se almacenan durante la creación
de scripts.

¿QUÉ DATOS SE DEVUELVEN A LOS SERVIDORES DE CLOUDTEST?

Durante las pruebas de carga solo se conservan datos externos clave, como los códigos de respuesta HTTP, las cookies,
los ID de sesión, etc. Todos los datos se devuelven a los servidores de CloudTest para su análisis y se descartan de los
servidores de Akamai por completo.

¿CUÁL ES LA DIFERENCIA ENTRE LOS DATOS SINTÉTICOS Y DE BARRIDO?

Los datos de barrido se alojan en la base de datos de un cliente y se procesan para que no incluyan datos reales de
clientes. En esencia, estos datos se crean o transforman a partir de datos reales de clientes. Los datos sintéticos se
generan de cero y constituyen una muestra precisa de la base de datos de producción del cliente.

¿CÓMO SE CREAN LOS DATOS SINTÉTICOS?

Akamai colabora estrechamente con su equipo de aplicaciones para garantizar la creación de un amplio conjunto de datos
representativos. Los datos también se crean para evaluar el proceso empresarial del que se realizan las pruebas, y pueden
ampliarse a medida que estas evolucionan.

¿QUÉ OCURRE CON LOS DATOS CUANDO FINALIZAN LAS PRUEBAS?

Tras las pruebas, los servidores de CloudTest solo analizan datos de parámetros de rendimiento relevantes para estas.
Los datos corporativos no se almacenan en los servidores de CloudTest.

¿CÓMO SE ALMACENAN LOS DATOS DE PRUEBAS EN LA NUBE?

Los datos de pruebas de Akamai se almacenan en la nube. Los resultados se alojan en servidores Linux que se
desmantelan tras las pruebas. Los servidores solo están disponibles durante las sesiones de prueba y durante el análisis
de los resultados. En la mayoría de casos, los datos de resultados se almacenan en bases de datos relacionales en EC2 en
un EBS (almacén de bloque elástico). Estos datos solo están disponibles para los empleados de Akamai.
 La guía completa para la realización de pruebas de rendimiento de sus aplicaciones y sitios web dedicados al retail 13

¿SE PUEDEN ELIMINAR LOS DATOS DE RESULTADOS DE PRUEBAS DE LA NUBE?

Sí, los resultados se pueden eliminar y suprimir de la nube si el cliente lo solicita. Tras la solicitud, los resultados no se
suprimen hasta que no se completa el informe de resultados. Los resultados se suprimen de forma permanente sin previa
realización de copias de seguridad. Tenga en cuenta que la supresión de resultados limita la posibilidad de compararlos
con resultados de pruebas previas y posteriores. La única forma de comparar resultados tras la supresión es consultar el
informe de resultados.

¿ES POSIBLE EXPORTAR DATOS DE RESULTADOS DE PRUEBAS DESDE LA NUBE PARA

ALMACENARLOS FUERA DEL SITIO?
Sí. Todos los resultados se pueden exportar en formato XML. Estos datos se pueden exportar desde la nube y migrar a una
ubicación definida por el cliente para garantizar su protección. En función de la duración de las pruebas y el volumen de
datos de rendimiento relacionados con estas, la exportación de los datos desde la nube y su migración a una ubicación
segura pueden llevar de 24 a 48 horas. También es posible suprimir los datos desde la nube.

Akamai colabora con empresas como Apple, Target, Etsy y Microsoft para facilitar la realización de
pruebas, la supervisión y la optimización de sus aplicaciones web y móviles de forma continua.

A usted también podemos ayudarle.

Empiece a utilizar CloudTest hoy mismo.

Como la plataforma de distribución en la nube más grande y respetada del mundo, Akamai ayuda a sus clientes a ofrecer las mejores y más seguras experiencias digitales,
independientemente del dispositivo, en cualquier momento y en cualquier lugar. La plataforma ampliamente distribuida de Akamai ofrece una escala inigualable, con más de
200 000 servidores repartidos por 130 países, para garantizar a sus clientes el máximo rendimiento y protección frente a las amenazas. La cartera de soluciones de rendimiento
web y móvil, seguridad en la nube, acceso empresarial y distribución de vídeo de Akamai está respaldada por un servicio de atención al cliente excepcional y una supervisión
ininterrumpida. Para descubrir por qué las principales instituciones financieras, líderes de comercio electrónico, proveedores de contenidos multimedia y de entretenimiento, y
organizaciones gubernamentales confían en Akamai, visite www.akamai.com/es/es y blogs.akamai.com/es/, o siga a @Akamai en Twitter. Puede encontrar los datos de contacto
de todas nuestras oficinas en www.akamai.com/locations. Publicado en julio de 2017.