Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Cree un escenario de prueba

La creación de un escenario de prueba implica cuatro pasos principales: configurar los ajustes generales, definir el escenario, configurar los patrones de tráfico y revisar la configuración.

Paso 1: Configuración general

Configure los parámetros básicos de la prueba de carga, incluidos el nombre de la prueba, la descripción y las opciones de configuración generales.

Identificación de la prueba

Opciones de programación

Configure cuándo debe ejecutarse la prueba:

Programación del flujo de

Al programar una prueba, se produce el siguiente flujo de trabajo:

Datos en directo

Seleccione la casilla Incluir datos en tiempo real para ver las métricas en tiempo real mientras se ejecuta la prueba. Cuando está habilitada, puedes supervisar:

La función de datos en tiempo real proporciona gráficos en tiempo real con datos agregados en intervalos de un segundo. Para obtener más información, consulte Monitorización con datos en tiempo real.

Paso 2: Configuración del escenario

Defina el escenario de prueba específico y seleccione su marco de prueba preferido.

Selección del tipo de prueba

Elija el tipo de prueba de carga que desea realizar:

Modo Traffic Shape

Elija qué lado controla la carga que genera la prueba. El modo que selecciones cambia los campos que muestra la consola en el paso 3: Forma del tráfico.

Native requiere cargar un script, por lo que no puedes seleccionarlo si eliges el tipo de prueba Simple HTTP Endpoint. Para obtener las definiciones completas y la orientación sobre qué modo elegir, consulta los modos de configuración del tráfico.

Configuración del punto final HTTP

Cuando se selecciona «Punto de enlace HTTP simple», la solución genera un plan de pruebas de JMeter a partir de su configuración y lo ejecuta con el binario Apache JMeter incluido. Configure estas opciones:

Pruebe los scripts del marco

Cuando utilices JMeter, k6 o Locust, sube tu archivo de script de prueba o un archivo.zip que contenga tu script de prueba y los archivos complementarios.

En el caso de JMeter, puedes incluir complementos personalizados en una /plugins carpeta dentro de tu archivo .zip.

En el caso de Locust, se debe asignar un nombre a un script de prueba dentro de un archivo.zip. locustfile.py Para instalar paquetes de Python de terceros en el contenedor durante la ejecución, incluye un requirements.txt archivo en el archivo y, si lo desea, un packages subdirectorio de archivos de rueda para instalarlos sin acceso a Internet. Para obtener más información, consulte las pruebas de Locust.

Duración de seguridad (modo nativo)

Al seleccionar el modo nativo, la consola muestra un campo de duración de seguridad junto con la carga del script. El valor predeterminado es de 4 horas y el máximo de 24 horas.

En el modo nativo, la duración de seguridad finaliza una prueba que se ejecuta durante más tiempo del previsto, ya que el script decide cuándo finaliza la ejecución. Se trata de una guardia, no de un cronograma. Si la prueba sigue ejecutándose cuando transcurre el tiempo, la solución detiene el marco de prueba. Conserva los resultados de la parte que se ejecutó y registra la ejecución como completada en lugar de fallida. Establézcala por encima de la ejecución más larga que espera que necesite el script.

Paso 3: Forma del tráfico

Configure cómo se distribuirá el tráfico durante la prueba, incluida la compatibilidad multirregional.

Modos de configuración del tráfico

La solución ofrece dos modos de configuración del tráfico: estándar y nativo. Se diferencian en el lado que controla la carga: la solución o el script que subes. El modo se selecciona en el paso 2: Configuración del escenario, y este determina cuál de los campos siguientes se aplica.

Estándar

El modo estándar permite a la solución controlar la carga. Tú estableces la cantidad de tareas de Fargate por región, los usuarios virtuales simultáneos por tarea, el período de aceleración y la duración de la espera. La solución ejecuta la prueba a través del marco de automatización de Taurus, que traduce esos valores en los propios controles de carga del marco subyacente. Taurus tiene prioridad sobre cualquier carga que declare su script, por lo que un bloque de opciones de k6, un grupo de hilos de Locust LoadTestShape o JMeter se reescribe o se ignora. Los usuarios virtuales de una región son el recuento de tareas multiplicado por la concurrencia de cada tarea, y la forma es la misma independientemente del marco que elijas. Así es como se ejecutaban todas las pruebas antes de la versión 4.3.0, por lo que los escenarios creados anteriormente siguen comportándose exactamente como lo hacían y no necesitan cambios.

Elija Estándar cuando la forma de carga no esté incluida en el script o se defina desde la consola, la CLI o un agente. Standard es el único modo que permite establecer un recuento exacto de usuarios virtuales y cambiar la forma de aumento y retención sin tocar el script. Solo el estándar admite el tipo de punto final HTTP simple, en el que la solución genera el plan de pruebas automáticamente. Usos típicos: comprobar la capacidad de 500 a 5000 usuarios virtuales, realizar una regresión nocturna para retener a 1000 usuarios durante diez minutos o cualquier comparación que necesite una rampa idéntica. Su límite es la expresividad. Todo lo que Taurus no pueda representar no está disponible aquí, incluidos varios escenarios ponderados, umbrales por etapa y ejecutores con tasas de llegada.

Nativo

El modo nativo permite al script controlar la carga. La solución ejecuta el archivo que cargó en la propia línea de comandos del marco:jmeter -n -t,k6 run, olocust --headless. No detecta ningún indicador de carga, por lo que su script es la única autoridad sobre el tráfico que genera y la solución nunca lo reescribe. Quedan dos controles: el número de tareas de Fargate que se deben iniciar por región y el tiempo de seguridad obligatorio de hasta 24 horas. La duración de la seguridad es para evitar que se produzca un guion que nunca finaliza, no para establecer un cronograma. Si una prueba sigue ejecutándose una vez transcurrido el tiempo, la solución detiene el marco, recopila los resultados de la parte que se ejecutó y registra la ejecución como completada en lugar de fallida. Cada tarea se ejecuta como un proceso marco independiente sin coordinación entre las tareas, por lo que una región genera una copia completa de la carga declarada del script para cada tarea. Por ejemplo, un script k6 que contiene 200 usuarios virtuales, se ejecuta en cinco tareas y sitúa a 1000 usuarios virtuales en el objetivo. Por lo tanto, el recuento de tareas es el único control de carga que ofrece Native, y se mueve en múltiplos enteros de lo que declara el script. Cambiar la rampa, el tiempo de espera o el propio recuento de usuarios virtuales implica editar el script.

Elija Nativo cuando desee ejecutar un script exactamente como se escribió. Un script que ya se ejecuta localmente o en CI se ejecuta sin cambios en la solución, que es la razón principal por la que opta por Native. Native conserva todo lo que el marco puede expresar: k6 escenarios, etapas y umbrales; LoadTestShape clases de Locust y conjuntos de tareas ponderados; temporizadores y grupos de subprocesos de JMeter. Elígelo cuando la forma de la carga forme parte de lo que significa la prueba, y reproducirlo fielmente es más importante que guiarlo desde fuera. Usos típicos: reutilizar un script k6 de una canalización sin volver a escribirlo, crear un perfil en el que se produce un pico y luego se recupera o escenarios ponderados que un solo número de simultaneidad no puede expresar. Al ejecutar el marco tal como se creó, se derivan dos restricciones. Native requiere cargar un script, por lo que Simple HTTP Endpoint no está disponible. Los scripts de Locust no se deben configurarprocesses, ya que la solución solo cuenta las solicitudes cuando Locust se ejecuta como un solo proceso.

Elección de un modo

Multi-Region configuración de tráfico

Seleccione una o más regiones de AWS para distribuir la prueba de carga geográficamente. Para cada región seleccionada, configure:

Determine la cantidad de usuarios

La cantidad de usuarios que puede admitir un contenedor para una prueba se puede determinar aumentando gradualmente la cantidad de usuarios y supervisando el rendimiento en Amazon CloudWatch. Cuando observe que el rendimiento de la CPU y la memoria se acerca a sus límites, habrá alcanzado el número máximo de usuarios que un contenedor puede admitir para esa prueba en su configuración predeterminada (2 vCPU y 4 GB de memoria).

Esta calibración establece el valor de concurrencia, por lo que se aplica al modo estándar. Los límites de contenedor que establece también se aplican al modo nativo. Ahí aumentas o disminuyes la carga que declara tu script, en lugar de establecer el campo de concurrencia.

Proceso de calibración

Puede empezar a determinar los límites de usuarios simultáneos para su prueba mediante el siguiente ejemplo:

Repita los pasos 1 a 3 si la prueba no superó los límites de recursos. Si lo desea, puede aumentar los recursos del contenedor para permitir un mayor número de usuarios simultáneos. Sin embargo, esto se traduce en un costo más alto. Para obtener más información, consulte la Guía para desarrolladores.

Para obtener más información sobre la calibración de los usuarios por motor, consulte Calibrar una prueba de Taurus en la BlazeMeter documentación.

Tabla de tareas disponibles

La tabla de tareas disponibles muestra la disponibilidad de recursos para cada región seleccionada:

Para aumentar la cantidad de tareas o CPU virtuales disponibles por tarea, consulta la Guía para desarrolladores.

Duración de la prueba

Defina cuánto tiempo durará la prueba de carga. La consola muestra esta sección solo en modo Estándar. En el modo nativo, el script determina durante cuánto tiempo se ejecutará la prueba, dependiendo del tiempo de seguridad establecido en el paso 2: Configuración del escenario.

Paso 4: Revisar y crear

Revise todas las configuraciones antes de crear el escenario de prueba. Verificar:

Tras revisarlo, elija Crear para guardar el escenario de prueba.

Administración de escenarios de prueba

Tras crear un escenario de prueba, puede: