Una prueba de carga HTTP(S) genera solicitudes simultáneas a una sola dirección URL. Comprueba la dirección URL de destino en busca de contenido adecuado, errores y vínculos rotos. Es compatible con solicitudes POST y GET, cookies, envíos de formularios, encabezados personalizados, sitios protegidos por contraseña (autorización básica HTTP/HTTPS, así como mecanismos de autorización de cookies/script) y umbrales de tiempo de espera. La prueba de carga HTTP(S) admite protocolos IPv4 e IPv6.

Puede convertir parámetros de solicitud HTTP(S) en parámetros de contexto para pasar valores, por ejemplo, recuperados de una respuesta de otra solicitud dentro del dispositivo de prueba de carga. Puede configurar parámetros de contexto para la dirección URL, encabezados, contenido de solicitud (para métodos Post, Put, Patch) y los scripts prepare y post. Para obtener más información, consulte Cómo utilizar parámetros de contexto en solicitudes HTTP(S).

Url

Introduzca la dirección URL que desea probar. La dirección debe formarse exactamente como se usaría en un navegador, como http://www.example.com. Debe incluir la http:// o https:// al principio de la dirección. Puede incluir cualquier parámetro GET al final de su URL.

Umbral de validación de tiempo (en segundos)

Escriba el número de segundos que la tarea debe esperar para obtener una respuesta de la página web antes de finalizar la tarea y devolver un error. Si esto se deja en blanco, el tiempo de espera predeterminado para una tarea es de 120 segundos.

Tipo de solicitud

Puede enviar una solicitud GET o POST a la página web. Al seleccionar una solicitud GET, simplemente se recuperarán datos del servidor web. La selección de una solicitud POST indica que está incluyendo un conjunto de datos para que el servidor actúe.

Si establece el tipo de solicitud en POST pero no especifica un parámetro POST en la sección de parámetros adicionales siguiente, el valor POST volverá a GET al guardar la tarea.

Redirecciones de URL

Si la opción Seguir redirecciones se establece en Sí, el sistema seguirá la ruta de acceso de la dirección URL que se envía con la respuesta 301 y considerará cada redirección como una solicitud HTTP independiente. Le permite seguir la cadena de redirección completa (todos los vínculos a los que se redirige la solicitud) en los resultados de la prueba, incluidos los tiempos de respuesta tanto para la DIRECCIÓN URL inicial como para las respuestas posteriores.

Le recomendamos que deje activada la opción Seguir redirecciones si necesita probar no solo la DIRECCIÓN URL inicial, sino todas las direcciones URL de la cadena. Por ejemplo, puede ser útil realizar una comprobación de certificado SSL para cada DIRECCIÓN URL en una cadena de redirección.

En los casos en los que desee probar solo una DIRECCIÓN URL inicial, deshabilite la opción Seguir redirecciones.

Tenga en cuenta que un límite de redirección predeterminado se establece en 10 redirecciones. Si desea que el sistema ejecute un número determinado de redirecciones (menos de 10), puede especificar el número de DIRECCIONES URL que desea probar en la cadena de redirección en el campo Preparar script:

string url;
url = "http://wtatour.com/";
(current.Task).TaskMaxRedirectAttempts = N;

Donde N es el número de ubicaciones de redirección que queremos seguir. Para no seguir ninguna redirección, simplemente establezca el número de ubicaciones de redirección en 0.

Validación de contenido

Las palabras clave de validación de contenido se usan para asegurarse de que el contenido esperado se cargó en una página web. En los campos Palabra clave, puede especificar una o varias palabras o frases que desee buscar en el contenido de la página web. Si no se encuentran las palabras clave esperadas, la tarea devolverá un error.

Puede introducir varias cadenas en los campos de palabras clave. Los valores introducidos pueden estar separados por expresiones lógicas de la siguiente manera:

{[("keyword1"&"keyword2")|!"keyword3"]}

Dónde:
• – inicio de la expresión de palabra clave;
] – fin de la expresión de palabra clave;
() – grupos de corchetes;
& – y lógico;
| – OR lógico;
! – NO lógico;
“string” – una palabra clave.

Una expresión de palabra clave correcta debe incluir los corchetes inicial y final de la siguiente manera:

{["keyword"]}

Autenticación básica

El esquema de autenticación básica s utilizado para permitir a los usuarios acceder al contenido en algunos sitios web. Una vez proporcionadas las credenciales de inicio de sesión se pasarán junto con el encabezado de solicitud al servidor web.

  • Nombre de usuario: contiene un nombre de usuario para la autenticación de acceso básico o de resumen HTTP/S.
  • Contraseña de usuario: contiene una contraseña para la autenticación de acceso básico o de resumen HTTP/S.

No confunda la autenticación básica con otros esquemas de autenticación como autenticación portadora que implica tokens portadores y OAuth 2.0 que usa tokens de acceso.

Lea los artículos sobre el nombre de usuario y la contraseña de autenticación básica y las API basadas en OAuth 2.0 para obtener más información.

Encabezados

La opción permite agregar encabezados personalizados adicionales. Por ejemplo, puede definir el tipo MIME de los datos enviados junto con la solicitud en el encabezado Content-Type:

Content-Type: text/html

Si no se especifica el encabezado Content-Type para la solicitud, la solicitud se enviará con el tipo de contenido predeterminado application/x-www-form-urlencoded.

The default User-Agent header is set to:

User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) DMBrowser/2.1 (SV)

However, the user-agent string can be replaced with any other string. To do this, add a custom header with the name “user-agent” and the specific value needed.

Opciones de DNS

La característica Opciones de DNS permite a los usuarios elegir cómo se llevan a cabo las solicitudes de servidor de nombres de dominio (DNS) durante una tarea de supervisión. En la sección Hosts DNS personalizados , especifique asignaciones personalizadas de direcciones IP a nombres de host. Puede ser útil realizar pruebas de carga de sus sitios web durante una migración. Por lo tanto, puede probar su sitio web en un nuevo servidor mientras todos sus usuarios continúan usándolo en una dirección IP familiar.

Ejemplos:

192.168.107.246 example.com user.example.com userauth.example.com tools.example.com
192.168.107.246 example.com
192.168.107.246 user.example.com
192.168.107.246 userauth.example.com

Tenga en cuenta que la opción no es compatible con los agentes in situ de LoadView. Para obtener instrucciones detalladas sobre cómo configurar hosts DNS personalizados para el agente in situ, visite el artículo Cómo configurar hosts DNS personalizados para pruebas de carga con el agente in situ de nuestra base de conocimientos.

Datos de publicación (put, parche)

Si se ha seleccionado uno de los métodos POST, PUT o PATCH, puede especificar la carga útil aquí. El contenido dentro del cuerpo de la solicitud HTTP se puede enviar como datos “sin procesar” (JSON, XML, etc.) o colección estática nombre-valor (Datos de formulario).

Para trabajar con una colección nombre-valor, puede activar el modo de entrada detallado mediante el conmutador Detallado en la parte superior de la sección y proporcionar nombres y valores de parámetros de solicitud en el campo correspondiente.

Para enviar datos “sin procesar” junto con la solicitud, como un objeto JSON, escriba la carga JSON en el campo de entrada. También puede cambiar dinámicamente el cuerpo de la solicitud. Por ejemplo, si necesita enviar la fecha y hora actuales como parte de la solicitud POST o pasar el ID de sesión actual en carga JSON a un servidor remoto. Dotcom-Monitor permite cambiar dinámicamente la carga de solicitudes HTTP mediante la sintaxis y las máscaras de datos de Razor.

  • ejemplo. Cuerpo JSON dinámico para solicitudes de publicación HTTP

    Para comprender mejor cómo funciona el cuerpo JSON dinámico en la solicitud HTTP, echemos un vistazo al ejemplo siguiente. Supongamos que necesitamos enviar una orden en un sitio web y la transacción de envío incluye tres pasos básicos ejecutados secuencialmente:

    1. Iniciar sesión
    2. check-in
    3. Presentación de pedidos

    Para configurar una prueba con estos pasos ejecutados secuencialmente, necesitamos crear tres tareas HTTP dentro de un dispositivo de supervisión (o prueba de carga, si se están realizando pruebas de carga).

    Supongamos que necesitamos enviar la hora actual y un GUID único en el JSON con la solicitud HTTP para registrarnos con la aplicación. Además, para enviar un pedido, una identificación de sesión de usuario generada al iniciar sesión y un tiempo de pedido es requerido por la aplicación.

    Para implementar esta prueba, primero necesitamos configurar una solicitud de inicio de sesión con parámetros básicos de autenticación para el servidor web de aplicaciones web. A continuación, necesitamos configurar una solicitud HTTP para pasar la hora de registro real y el GUID único junto con un cuerpo JSON. En este ejemplo, escribiremos la siguiente cadena mediante la sintaxis razor en el cuerpo JSON:

    { "CheckInTime": "@Model["CurrentTime"]", "GenGuid": "@Model["Guid"]" }

    Donde @Model[” < Nombre del parámetro > “] hace referencia a un nombre de parámetro de contexto necesario en la expresión Razor.

    Debemos declarar los parámetros de contexto y especificar cómo se deben procesar los datos de publicación en el campo Preparar script:

    context.Guid = Guid.NewGuid().ToString(); // uniq random string
context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\Thh:mm:ss") + ".0Z"; // get current time in UTC
ProcessPostDataByRazor(currentTask); // the call to process the Post Data content with the Razor engine

    El resultado de la solicitud HTTP tendrá un aspecto similar al siguiente:

    03:15:23
POST http://www.dotcom-monitor.com/CheckIn
{ "CheckInTime": "2021-03-30T08:15:22.0Z", "GenGuid": "5c5e3d23-66fd-49d0-bd57-62c516aea7e7" }

    En el paso siguiente, necesitamos configurar la solicitud HTTP para enviar un pedido. Para ello, pasaremos el id. Consulte el cuerpo JSON de esta solicitud a continuación:

    { "OrderTime": "@Model["OrderTime"]",   "VIEWSTATE": "@Model["Session"]",  "ModelID": "2128506" }

    Para pasar un valor de la variable de ID de sesión actual, necesitamos recuperarlo de la página de inicio de sesión, llamada en el primer paso de inicio de sesión, mediante el método View State. Se puede codificar en el script prepare. Además, para simular el tiempo de pensar de un usuario real, estableceremos la variable de tiempo de pedido con un desplazamiento de tres minutos. Por lo tanto, el campo Preparar script contendrá las siguientes cadenas:

    context.OrderTime = DateTime.Now.AddMinutes(3).ToUniversalTime().ToString("yyyy-MM-dd\Thh:mm:ss") + ".0Z"; // order time + 3 min
context.Session = (Tasks["Login"] as Http).body["//INPUT[@ID='__VIEWSTATE']", "VALUE"]; // track state value from Login page 
ProcessPostDataByRazor(currentTask);

    La solicitud HTTP resultante tendrá un aspecto similar al siguiente:

    03:15:45
POST http://www.dotcom-monitor.com/Order
{ "OrderTime": "2021-03-30T08:18:45.0Z", "VIEWSTATE": "<Server Generated ViewState>", "ModelID": "2128506" }

Para obtener información sobre cómo configurar una solicitud HTTP con una carga dinámicamente cambiante, consulte Cómo cambiar dinámicamente la carga útil en la solicitud HTTP.

Preparar guión y secuencia de comandos de publicación

Los campos pueden contener código de C#, que se puede usar para datos POST, GET, URL específicos o para validar o publicar encabezados personalizados. Consulte el artículo Uso del script y el script de publicación o póngase en contacto con el soporte técnico para obtener más detalles sobre el uso.

Una vez creado el dispositivo de prueba de carga, se le pedirá que configure el escenario de prueba de carga.