Как использовать устройства и цели

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

Мониторинг HTTP/S проверяет сертификаты безопасности, полномочия по проверке сертификатов и проверку на истечение срока действия. Он также может быть настроен для отправки напоминаний, когда приближается срок действия сертификата.

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

Настройка запроса

Url

Введите URL страницы, на которую вы хотите выполнить задачу. Она должна быть отформатирована как таковая: www.example.com. Вы можете включить визуально дружественный режим ввода, нажав на подробный переключатель в верхней части раздела.

Проверка SSL/сертификата

Проверка сертификата Secure Socket Layer SSL является стандартным аспектом тестов HTTP (S).

Доступны следующие дополнительные опции:

  • Власть: проверяет, содержит ли цепочка сертификатов корневой сертификат, которому доверяют или не доверяют.
  • Общее имя (CN): подтверждает, что адрес, по который вы переходите, соответствует сертификату адреса, на который был подписан адрес.
  • Дата: проверяет срок действия сертификата.
  • Отзыв: подтверждает, что цепочка доверия сертификата не содержит отозванного сертификата.
  • Использование: проверяет цепочку сертификатов на ненадлежащее использование промежуточного сертификата.
  • Напоминание об истечении срока действия в днях: напоминание, уведомляемое (как ошибка) об истечении срока действия сертификата.
  • Сертификат клиента: имя сертификата клиента.

Смотрите также: Целевое имя хозяина или IP-адрес.

Тайм-аут завершения (в секундах)

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

Заголовок пользователя-агента по умолчанию установлен на:

Пользователь-агент: Mozilla/5.0 (совместим; 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)

Тем не менее, строка пользователя-агента может быть заменена на любую другую строку. Для этого добавьте пользовательский заголовок с именем “пользователь-агент” и необходимым конкретным значением.

Данные POST (PUT, PATCH)

Если был выбран один из методов 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.

Параметры DNS

Функция DNS Options позволяет пользователям выбирать, как запросы сервера доменных имен (DNS) проводятся во время выполнения задачи мониторинга.

Чтобы указать режим разрешения имен хостов в разделе Режим решения 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

Смотрите также: Параметры режима DNS.

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

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