Um teste de carga HTTP(S) gera solicitações simultâneas a uma única URL. Ele verifica a URL de destino para obter conteúdo adequado, erros e links quebrados. Ele suporta solicitações POST e GET, cookies, envios de formulários, cabeçalhos personalizados, sites protegidos por senha (autorização básica HTTP/HTTPS, bem como mecanismos de autorização de cookies/script) e limites de tempo limite. O teste de carga HTTP(S) suporta protocolos IPv4 e IPv6.

Você pode converter parâmetros de solicitação HTTP(S) em Parâmetros de Contexto para passar em valores, por exemplo, recuperados de uma resposta de outra solicitação dentro do dispositivo de teste de carga. Você pode configurar parâmetros de contexto para a URL, cabeçalhos, solicitar conteúdo (para métodos Post, Put, Patch) e os scripts de preparação e postagem. Para obter detalhes, consulte Como usar parâmetros de contexto em solicitações HTTP(S).

URL

Digite a URL que deseja testar. O endereço deve ser formado exatamente como você usaria em um navegador, como http://www.example.com. Você deve incluir o http:// ou https:// no início do endereço. Você pode incluir quaisquer parâmetros GET no final da sua URL.

Limite de validação de tempo (em segundos)

Insira o número de segundos que o sistema deve aguardar uma resposta do recurso de destino antes de retornar um erro. Se isso for deixado em branco, o tempo limite padrão é de 120 segundos.

Tipo de solicitação

No campo Tipo de Solicitação , você pode selecionar um dos métodos HTTP mais usados para enviar solicitações de monitoramento para uma página da Web. Se você precisar enviar uma carga com solicitações HTTP, forneça-a no campo correspondente (consulte o capítulo Corpo da solicitação para obter detalhes). A carga útil pode ser especificada e enviada com todos os tipos de solicitações, exceto Rastreamento (RFC2616).

Redirecionamentos de URL

Se a opção Seguir redirecionamentos for definida como Sim,o sistema seguirá o caminho da URL enviada com a resposta 301 e considerará cada redirecionamento como uma solicitação HTTP separada. Ele permite que você siga a cadeia de redirecionamento completo (todos os links que a solicitação é redirecionada) nos resultados do teste, incluindo tempos de resposta tanto para a URL inicial quanto para respostas subsequentes.

Recomendamos que você deixe a opção Seguir redirecionamentos ativado se você precisar testar não apenas a URL inicial, mas todos os URLs da cadeia. Por exemplo, pode ser útil realizar uma verificação de certificado SSL para cada URL em uma cadeia de redirecionamento.

Nos casos em que você deseja testar apenas uma URL inicial, desabilitar a opção Seguir redirecionamentos.

Observe que um limite de redirecionamento padrão é definido em 10 redirecionamentos. Se você quiser que o sistema execute um determinado número de redirecionamentos (menos de 10), você pode especificar o número de URLs que deseja testar em sua cadeia de redirecionamento no campo Preparar script:

string url;
url = "http://wtatour.com/";
currentTask.TaskMaxRedirectAttempts = N;

Onde N é o número de locais de redirecionamento que queremos seguir. Para não seguir os redirecionamentos, basta definir o número de locais de redirecionamento para 0.

Validação de conteúdo

As palavras-chave de validação de conteúdo são usadas para garantir que o conteúdo esperado seja carregado em uma página da Web. Nos campos de palavras-chave, você pode especificar uma ou mais palavras ou frases que deseja pesquisar no conteúdo da página da Web. Se as palavras-chave esperadas não forem encontradas, a tarefa retornará um erro.

Você pode inserir várias strings nos campos de palavras-chave. Os valores que você digita podem ser separados por expressões lógicas da seguinte forma:

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

onde:
{[ – início de expressão de palavras-chave;
]} – final de expressão de palavra-chave;
() – suportes de agrupamento;
& – lógico E;
| – OR lógico;
! – lógico NÃO;
“string” – uma palavra-chave.

Uma expressão de palavras-chave bem sucedida deve incluir os suportes de início e fim da seguinte forma:

{["keyword"]}

Autenticação Básica

O esquema de Autenticação Básica é usado para permitir que os usuários acessem conteúdo em alguns sites. Uma vez fornecidas, as credenciais de login serão passadas junto com o cabeçalho da solicitação para o servidor Web.

  • Nome de usuário: contém um nome de usuário para autenticação de acesso HTTP/S básico ou resumido.
  • Senha de usuário: contém uma senha para autenticação de acesso HTTP/S básico ou resumido.

Não confunda a Autenticação Básica com outros esquemas de autenticação, como a Autenticação ao Portador, que envolve tokens de portador, e o OAuth 2.0, que usa tokens de acesso.

Leia os artigos sobre Nome de usuário e senha de autenticação básica e APIs baseadas em monitoramento OAuth 2.0 para obter mais informações.

Cabeçalhos

A opção permite adicionar quaisquer cabeçalhos personalizados adicionais. Por exemplo, você pode definir o tipo MIME dos dados enviados juntamente com a solicitação no cabeçalho Tipo de conteúdo:

Content-Type: text/html

Se o cabeçalho tipo conteúdo não for especificado para a solicitação, a solicitação será enviada com o aplicativo de tipo de conteúdo padrão/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.

Opções de DNS

O recurso Opções de DNS permite que os usuários escolham como as solicitações de servidor de nomes de domínio (DNS) são conduzidas durante uma tarefa de monitoramento. Na seção Hosts DNS personalizados , especifique mapeamentos personalizados de endereços IP para nomes de host. Pode ser útil carregar o teste de seus sites durante uma migração. Assim, você pode testar seu site em um novo servidor enquanto todos os seus usuários continuam a usá-lo em um endereço IP familiar.

Exemplos:

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

Observe que a opção não é suportada pelos agentes locais do LoadView. Para encontrar diretrizes detalhadas sobre como configurar hosts DNS personalizados para o Agente no local, visite o artigo Como configurar hosts DNS personalizados para teste de carga com o agente no local da nossa Base de Dados de Conhecimento.

Dados postes (put, patch)

O Dotcom-Monitor permite que você envie cargas úteis em solicitações HTTP(S) (exceto solicitações de rastreamento). O conteúdo dentro do órgão de solicitação HTTP pode ser enviado como dados “brutos” (JSON, XML, etc.) ou coleta de valor de nome estático (Dados de Formulário).

Para trabalhar com uma coleção de valor de nome, você pode ativar o modo de entrada detalhado usando o switcher detalhado na parte superior da seção e fornecer nomes e valores de parâmetros de solicitação no campo correspondente.

Para enviar dados “brutos” juntamente com a solicitação, como um objeto JSON, digite sua carga JSON no campo de entrada. Você também pode alterar dinamicamente o corpo de solicitação. Por exemplo, se você precisar enviar a data e a hora atuais como parte da sua solicitação POST ou passar o ID de sessão atual na carga JSON para um servidor remoto. O Dotcom-Monitor permite alterar dinamicamente a carga de solicitação HTTP usando a sintaxe razor e máscaras de dados.

  • exemplo. Corpo JSON Dinâmico para Solicitações de Postes HTTP

    Para entender melhor como o corpo dynamic JSON funciona na solicitação HTTP, vamos dar uma olhada no exemplo a seguir. Suponha que precisamos enviar um pedido em um site e a transação de submissão inclui três etapas básicas executadas sequencialmente:

    1. login
    2. Check-in
    3. Submissão de pedidos

    Para configurar um teste com essas etapas executadas sequencialmente, precisamos criar três tarefas HTTP dentro de um dispositivo de monitoramento (ou teste de carga, se o teste de carga estiver ocorrendo).

    Vamos supor que precisamos enviar o tempo atual e um GUID exclusivo no JSON com a solicitação HTTP para fazer check-in com o aplicativo. Além disso, para enviar um pedido, um ID de sessão do usuário gerado no login e um tempo de pedido é exigido pelo aplicativo.

    Para implementar este teste, primeiro precisamos configurar uma solicitação de login com parâmetros básicos de autenticação para o servidor web do aplicativo web. Em seguida, precisamos configurar uma solicitação HTTP para passar o tempo real de check-in e GUID exclusivo, juntamente com um corpo JSON. Para este exemplo, entraremos na seguinte sequência usando a sintaxe razor no corpo JSON:

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

    Onde @Model[” < Nome do parâmetro > “] faz referência a um nome de parâmetro de contexto necessário na expressão Razor.

    Devemos declarar os parâmetros de contexto e especificar como os Post Data devem ser processados no 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

    A solicitação HTTP de resultado será semelhante a esta:

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

    Na próxima etapa, precisamos configurar a solicitação HTTP para enviar um pedido. Para isso, passaremos o tempo atual da ordem e o ID da sessão, juntamente com o número de identificação do modelo do item, no corpo JSON até o ponto final do alvo. Consulte o órgão JSON para este pedido abaixo:

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

    Para passar um valor da variável ID de sessão atual, precisamos recuperá-la da página de login, chamada na primeira etapa de login, usando o método Exibir Estado. Pode ser codificado no script de preparação. Além disso, para simular o tempo de pensar de um usuário real, definiremos a variável de tempo de pedido com um deslocamento de três minutos. Portanto, o campo Preparar script conterá as seguintes strings:

    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);

    A solicitação HTTP resultante será semelhante a esta:

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

Para saber como configurar uma solicitação HTTP com uma carga útil que muda dinamicamente, consulte Como alterar dinamicamente a carga útil na solicitação HTTP.

Prepare script e poste script

Os campos podem conter código C#, que pode ser usado para dados post, GET, URL específicos ou para validar ou publicar cabeçalhos personalizados. Consulte o artigo “Use Prepare Script and Post Script” ou entre em contato com suporte técnico para obter mais detalhes sobre o uso.

Uma vez criado o dispositivo de teste de carga, você será solicitado a configurar o cenário de teste de carga.