Тест нагрузки HTTP (S) генерирует одновременные запросы на один URL. Он проверяет целевой URL на надлежащее содержание, ошибки и сломанные ссылки. Он поддерживает запросы POST и GET, файлы cookie, представления форм, пользовательские заготовки, защищенные паролем сайты (основная авторизация HTTP/HTTPS, а также механизмы авторизации файлов cookie/script) и пороговые значения тайм-аута. Тест нагрузки HTTP (S) поддерживает протоколы IPv4 и IPv6.

Параметры запроса HTTP (S) можно преобразовать в параметры контекста, чтобы передать значения, например, полученные из ответа другого запроса в тестовом устройстве нагрузки. Можно настроить параметры контекста для URL-адреса, заголовников, содержимого запросов (для методов Post, Put, Patch), а также скриптов подготовки и поста. Для получения подробной информации узнайте, как использовать параметры контекста в запросах HTTP (S).

Url

Введите URL-адрес, который вы хотите протестировать. Адрес должен быть сформирован именно так, как вы бы использовать его в браузере, таких как http://www.example.com. Вы должны включить http:// или https:// в начале адреса. Вы можете включить любые параметры GET в конце URL-адреса.

Порог проверки времени (в секундах)

Введите количество секунд, в течение которого задача должна ждать ответа с веб-страницы, прежде чем закончить задачу и вернуть ошибку. Если это оставлено пустым, тайм-аут по умолчанию для задачи составляет 120 секунд.

Тип запроса

Вы можете отправить запрос GET или POST на веб-страницу. Выбор запроса GET будет просто получать данные с веб-сервера. Выбор запроса POST указывает на то, что вы включая набор данных для сервера.

Если вы установите тип запроса в POST, но не укажете параметр POST в разделе дополнительных параметров ниже, значение POST вернется к GET при сохранении задачи.

URL перенаправляет

Если опция Follow Redirects настроена на Yes,система будет следовать по пути URL-адреса, который отправляется с ответом 301, и рассматривать каждое перенаправление как отдельный запрос HTTP. Это позволяет следовать полной цепочке перенаправления (все ссылки, через которые перенаправляется запрос) в результатах теста, включая время отклика как для первоначального URL, так и для последующих ответов.

Мы рекомендуем оставить опцию Follow Redirects активированной, если вам нужно протестировать не только начальный URL, но и все URL-адреса в цепочке. Например, может быть полезно выполнить проверку сертификата SSL для каждого URL-адреса в цепочке перенаправления.

В тех случаях, когда вы хотите протестировать только первоначальный URL, отключите опцию Follow Redirects.

Обратите внимание, что лимит перенаправления по умолчанию установлен на уровне 10 перенаправлений. Если вы хотите, чтобы система выполнила определенное количество перенаправлений (менее 10), вы можете указать количество URL-адресов, которые вы хотите протестировать в цепочке перенаправления в поле Prepare Script:

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

Где N – это количество перенаправлений, за которые мы хотим следовать. Чтобы не перенаправлять, просто установите количество перенаправлений до 0.

Проверка содержимого

Ключевые слова проверки содержимого используются для обеспечения загрузки ожидаемого содержимого на веб-страницу. В полях ключевых слов можно указать одно или несколько слов или фраз, которые вы хотите искать в содержимом веб-страницы. Если ожидаемые ключевые слова не найдены, задача вернет ошибку.

Вы можете ввести несколько строк в поля ключевых слов. Значения, которые вы вводите, могут быть разделены логическими выражениями следующим образом:

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

где:
– начало выражения ключевых слов;
– конец выражения ключевых слов;
() – группирование кронштейнов;
Вопрос – логический AND;
| – логический OR;
! – логически НЕ;
“строка” – ключевое слово.

Успешное выражение ключевого слова должно включать в себя стартовые и конечные скобки следующим образом:

{["keyword"]}

Базовая аутентификация

Схема базовой аутентификации используется для доступа пользователей к контенту на некоторых веб-сайтах. После предоставления учетных данных будет передан вместе с заголовком запроса на веб-сервер.

  • Имя пользователя: содержит имя пользователя для базовой проверки подлинности доступа HTTP/S или дайджест.
  • Пароль пользователя: содержит пароль для базовой проверки подлинности доступа HTTP/S или дайджест.

Не путайте Basic Authentication с другими схемами аутентификации, такими как Проверка подлинности на предъявителя, которая включает токены на предъявителя, и OAuth 2.0, которая использует токены доступа.

Для получения дополнительной информации читайте статьи об основных api-пользователях аутентификации и паролях и мониторинге API на основе OAuth 2.0.

Заголовки

Опция позволяет добавлять любые дополнительные пользовательские заготовки. Например, можно определить тип MIME данных, отправленных вместе с запросом в заголовке Content-Type:

Content-Type: text/html

Если заголовок Content-Type не указан для запроса, запрос будет отправлен с приложением типа содержимого по умолчанию/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.

Параметры DNS

Функция DNS Options позволяет пользователям выбирать, как запросы сервера доменных имен (DNS) проводятся во время выполнения задачи мониторинга. В разделе Пользовательские узлы DNS укажите пользовательские сопоставления IP-адресов с именами узлов. Это может быть полезно для нагрузочного тестирования ваших веб-сайтов во время миграции. Таким образом, вы можете протестировать свой сайт на новом сервере, в то время как все ваши пользователи продолжают использовать его на знакомом IP-адресе.

Примеры:

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

Обратите внимание, что этот параметр не поддерживается локальными агентами LoadView. Подробные рекомендации по настройке пользовательских узлов DNS для агента на месте см. в статье Настройка пользовательских узлов DNS для нагрузочного тестирования с помощью агента на месте нашей базы знаний.

Почтовые (Put, Патч) Данные

Если был выбран один из методов POST, PUT или PATCH, вы можете указать полезную нагрузку здесь. Содержимое в органе запроса HTTP может быть отправлено в виде “сырых” данных (JSON, XML и т.д.) или статического сбора именных значений (Форм-данные).

Для работы с коллекцией именных значений можно включить подробный режим ввода с помощью подробного коммутатора в верхней части раздела и предоставить имена параметров запроса и значения в соответствующем поле.

Для отправки “сырых” данных вместе с запросом, например, объекта JSON, введите полезную нагрузку JSON в поле ввода. Вы также можете динамически изменить тело запроса. Например, если вам необходимо отправить текущую дату и время в рамках запроса POST или передать текущий идентификатор сеанса в полезной нагрузке JSON удаленному серверу. Dotcom-Monitor позволяет динамически изменять полезную нагрузку запроса HTTP с помощью синтаксиса Razor и масок данных.

  • пример. Динамический орган JSON для запросов на пост HTTP

    Чтобы лучше понять, как работает тело Dynamic JSON в запросе HTTP, давайте рассмотрим следующий пример. Предположим, что нам нужно отправить заказ на веб-сайте, и транзакция представления включает в себя три основных шага, выполненных последовательно:

    1. Входа
    2. регистрация
    3. Подача заказа

    Чтобы настроить тест с последовательно выполненными шагами, нам необходимо создать три задачи HTTP в рамках одного устройства мониторинга (или нагрузить тест, если проводится тестирование нагрузки).

    Допустим, нам нужно отправить текущее время и уникальный GUID в JSON с запросом HTTP, чтобы проверить с приложением. Кроме того, чтобы отправить заказ, идентификатор сеанса пользователя, созданный при входе в систему, и приложение требует времени заказа.

    Для реализации этого теста сначала необходимо настроить запрос входа с основными параметрами аутентификации на веб-сервер веб-приложения. Далее нам нужно настроить запрос HTTP, чтобы передать фактическое время регистрации и уникальный GUID вместе с телом JSON. В этом примере мы введите следующую строку, используя синтаксис Razor в теле JSON:

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

    В @Model «Параметр < Имя» > в выражении Razor упоминается необходимое имя параметра контекста.

    Мы должны объявить параметры контекста и указать, как данные о почте должны обрабатываться в поле Подготовка сценария:

    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

    Результат запроса HTTP будет выглядеть так:

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

    На следующем этапе нам необходимо настроить запрос HTTP для отправки заказа. Для этого мы перебудем текущее время заказа и идентификатор сеанса, а также идентификационный номер модели элемента в органе JSON в целевую конечную точку. Смотрите орган JSON для этого запроса ниже:

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

    Чтобы передать значение текущей переменной идентификатора сеанса, нам нужно извлечь ее со страницы входа, называемой на первом этапе входа, используя метод View State. Он может быть закодирован в сценарии подготовки. Кроме того, чтобы имитировать время мысли реального пользователя, мы завеем переменную времени заказа с трехминутным смещением. Таким образом, поле Prepare Script будет содержать следующие строки:

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

    Полученный запрос HTTP будет выглядеть так же, как:

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

Чтобы узнать, как настроить запрос HTTP с динамически изменяющейся полезной нагрузкой, узнайте, как динамически изменить полезную нагрузку в запросе HTTP.

Подготовка сценария и почтового сценария

Поля могут содержать код C, который может быть использован для конкретных POST, GET, URL данных или для проверки или публикации пользовательских заголовников. Для получения более подробной информации об использовании обратитесь в техническую поддержку в статье Using Prepare Script and Post Script.

После создания тестового устройства нагрузки вам будет предложено настроить сценарий тестирования нагрузки.