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 da página em que deseja executar a tarefa. Deve ser formatado como tal: www.example.com. Você pode ativar um modo de entrada visualmente amigável clicando no switcher detalhado na parte superior da seção.

Verificação de SSL/Certificado

Secure Socket Layer SSL Certificate Check é um aspecto padrão dos testes HTTP(S).

As seguintes opções adicionais estão disponíveis:

  • Autoridade: verifica se uma cadeia de certificados contém um certificado raiz confiável ou não confiável.
  • Nome Comum (CN): valida que um endereço que você navega corresponde ao certificado de endereço ao qual o endereço foi assinado.
  • Data: verifica a data de validade do certificado.
  • Revogação: valida que a cadeia de confiança do certificado não contém um certificado revogado.
  • Uso: verifica uma cadeia de certificados para o uso inadequado de um certificado intermediário.
  • Lembrete de expiração em dias: um lembrete que notifica (como um erro) sobre a expiração do certificado.
  • Certificado do Cliente: nome do certificado do cliente.

Tempo limite de conclusão (em segundos)

Digite o número de segundos que a tarefa deve esperar por uma resposta da página da Web antes de encerrar a tarefa e retornar um erro. Se isso for deixado em branco, o tempo limite padrão para uma tarefa é de 120 segundos.

Tipo de solicitação

Você pode enviar uma solicitação GET ou um POST para a página da Web. A seleção de uma solicitação GET simplesmente recuperará dados do servidor web. A seleção de uma solicitação POST indica que você está incluindo um conjunto de dados para o servidor agir.

Se você definir o tipo de solicitação para POST, mas não especificar um parâmetro POST na seção de parâmetros adicionais abaixo, o valor POST será padrão de volta para GET ao salvar a tarefa.

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/";
(current.Task).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 básico de autenticação é 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 de solicitação para o servidor web.

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

Não confunda autenticação básica com outros esquemas de autenticação como autenticação portadora que envolve tokens portadores e OAuth 2.0 que usa tokens de acesso.

Leia o nome de usuário básico de autenticação e artigos de senha e APIs baseados em 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.

O cabeçalho padrão do Agente do Usuário está definido para:

Agente do Usuário: Mozilla/5.0 (compatível; 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)

No entanto, a sequência usuário-agente pode ser substituída por qualquer outra sequência. Para fazer isso, adicione um cabeçalho personalizado com o nome “usuário-agente” e o valor específico necessário.

Dados postes (put, patch)

Se um dos métodos POST, PUT ou PATCH for selecionado, você pode especificar a carga aqui. 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 http://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 http://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.