Многошаговые веб-тесты

Вы можете отслеживать записанную последовательность URL-адресов и взаимодействий с веб-сайтом с помощью многошаговых веб-тестов. Эта статья поможет вам создать многошаговый веб-тест с помощью Visual Studio Enterprise.

Важно!

Многошаговые веб-тесты являются устаревшими. Мы рекомендуем использовать TrackAvailability () для отправки пользовательских тестов доступности вместо многошаговых веб-тестов. С помощью TrackAvailability() и настраиваемых тестов доступности можно выполнять тесты на любом требуемом вычислительном узле и использовать C# для простого создания новых тестов.

Примечание

Облако Azure для государственных организацийне поддерживает многошаговые веб-тесты.

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

Альтернатива многошаговому веб-тесту

Многошаговые веб-тесты зависят от файлов веб-тестов в Visual Studio. Как было объявлено ранее, Visual Studio 2019 станет последней версией с поддержкой веб-тестов. При этом важно отметить следующее. Несмотря на отсутствие новых возможностей, предоставляемые возможности веб-тестов будут доступными в Visual Studio 2019 в течение всего жизненного цикла поддержки этого продукта.

Рекомендуется использовать TrackAvailability для отправки настраиваемых тестов доступности вместо многошаговых веб-тестов. Это долгосрочное решение, поддерживаемое для сценариев тестирования с несколькими запросами или тестирования проверки подлинности. С помощью TrackAvailability() и настраиваемых тестов доступности можно выполнять тесты на любом требуемом вычислительном узле и использовать C# для простого создания новых тестов.

Предварительные требования

  • Visual Studio 2017 Enterprise или более новая версия.
  • Средства Visual Studio для тестирования производительности веб-сайтов и нагрузочного тестирования.

Чтобы найти эти обязательные средства тестирования, сделайте следующее: запуск Visual Studio Installerотдельных компонентовотладка и тестированиесредств веб-тестирования производительности и нагрузочных тестов.

Screenshot of the Visual Studio installer UI with Individual components selected with a checkbox next to the item for Web performance and load testing tools

Примечание

Многошаговые веб-тесты влекут определенные дополнительные затраты. Дополнительные сведения об этом см. в официальном справочнике по ценам.

Запись многошагового веб-теста

Предупреждение

Мы не рекомендуем использовать средство записи многошаговых веб-тестов. Оно было разработано для статических страниц HTML с простыми взаимодействиями и не предоставляет возможностей для работы с современными веб-страницами.

Рекомендации по созданию веб-тестов в Visual Studio см. в официальной документации по Visual Studio 2019.

Отправка веб-теста

  1. На портале Application Insights в области "Доступность" выберите Добавить классический тест, затем выберите Многошаговый в качестве SKU.
  2. Отправьте многошаговый веб-тест.
  3. Установите значения для параметров местоположений, частоты и оповещений.
  4. Нажмите кнопку создания.

Периодичность & расположения

Параметр Объяснение
Периодичность проведения тестирования Задает частоту выполнения теста для всех тестовых расположений. При стандартной частоте в пять минут и с пятью тестовыми расположениями ваш сайт будет проверяться в среднем каждую минуту.
Расположения тестирования Определяет места, из которых наши серверы отправляют веб-запросы на указанный URL-адрес. Чтобы вы могли различать проблемы с веб-сайтом и сетью, мы рекомендуем использовать не менее пяти расположений. Вы можете выбрать до 16 таких расположений.

Критерии успешного завершения

Параметр Объяснение
Время ожидания тестирования Уменьшите значение этого параметра, чтобы получать оповещения о медленных откликах. Тест считается неудачной попыткой, если ответы от сайта не были получены в течение заданного периода. Если выбрать параметр Анализировать зависимые запросы, все изображения, файлы стилей, скрипты и другие зависимые ресурсы будут получены в течение этого периода.
HTTP-ответ Возвращаемый код состояния, который считается успешным результатом. Код 200 указывает на возврат нормальной веб-страницы.
Совпадение содержимого Строка, например "Добро пожаловать!" Мы проверяем, что в каждом ответе выполняется точное совпадение с учетом регистра. Это должна быть строка обычного текста без подстановочных знаков. Не забывайте, что если контент страницы изменяется, необходимо обновить эту строку. В совпадении содержимого поддерживаются только символы английского алфавита

видны узлы

Параметр Объяснение
Почти в реальном времени (предварительная версия) Мы рекомендуем использовать оповещения "Почти в реальном времени". Настройка этого типа оповещений выполняется после создания теста доступности.
Пороговое значение для расположения оповещения Мы рекомендуем как минимум 3 из 5 расположений. Оптимальное отношение между пороговым значением расположения предупреждений и числом расположений тестов — это пороговое значение расположения предупрежденийдля расположений тестов — 2, со значением не менее пяти расположений тестирования.

Конфигурация

Включение значения времени и случайных чисел в тесты

Предположим, что вы тестируете инструмент, который получает зависящие от времени данные (например, запасы) от внешнего источника. При записи веб-теста необходимо использовать определенные значения времени, но они должны быть заданы как параметры теста StartTime и EndTime.

My awesome stock app screenshot

При запуске теста параметру EndTime следует всегда присваивать текущее время, а параметру StartTime – время за 15 минут до текущего.

Подключаемый модуль даты и времени позволяет указывать время в качестве параметров.

  1. Добавьте подключаемые модули веб-теста для всех необходимых значений переменных параметров. На панели инструментов веб-теста выберите Добавить подключаемый модуль веб-теста.

    Add Web Test Plug-in

    В этом примере используется два экземпляра подключаемого модуля даты и времени. Для первого экземпляра будет задано время за 15 минут до текущего, а для второго — текущее время.

  2. Откройте свойства каждого подключаемого модуля. Присвойте ему имя и настройте его для использования текущего времени. Для одного из экземпляров задайте для параметра "Добавление минут" значение "-15".

    Context Parameters

  3. В параметрах веб-теста используйте {{имя подключаемого модуля}} для ссылки на имя подключаемого модуля.

    StartTime

Теперь можно передать тест на портал. Он будет использовать динамические значения при каждом тестировании.

Работа с входом

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

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

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

Проверка подлинности SAML.

Имя свойства Описание
URI аудитории URI аудитории для токена SAML. Это URI службы контроля доступа (ACS), в который включаются пространство имен и имя узла ACS.
Пароль сертификата Это пароль для сертификата клиента, который предоставляет доступ к внедренному закрытому ключу.
Сертификат клиента Это сертификат клиента с закрытым ключом, который закодирован как строка Base64.
Идентификатор имени Идентификатор имени для токена.
Не позднее Срок действия токена. Значение по умолчанию равно 5 минутам.
До Срок действия токена, созданного ранее (на случай отклонений во времени). Отрицательное значение; по умолчанию — 5 минут.
Имя целевого параметра контекста Имя параметра контекста, в который будет записано сформированное утверждение.

Секрет клиента. Если в приложении предусмотрен маршрут входа с использованием секрета клиента, используйте этот маршрут. Azure Active Directory (AAD) — это пример службы, в которой доступен вход в систему с использованием секрета клиента. В AAD секрет клиента — это ключ приложения.

Ниже приведен пример веб-теста веб-приложения Azure с использованием ключа приложения.

Sample screenshot

Получите токен из Azure AD с помощью секрета клиента (AppKey). Извлеките токен носителя из ответа. Вызовите интерфейс API, используя токен носителя в заголовке авторизации. Убедитесь, что веб-тест является клиентом, т. е. имеет собственное приложение в AAD, и используйте соответствующие значения clientId и appkey. У тестируемой службы также есть собственное приложение в AAD: универсальный код ресурса URI appID этого приложения содержится в веб-тесте в поле resource.

Открытая проверка подлинности

Пример открытой проверки подлинности — это вход с помощью учетной записи Майкрософт или Google. Многие приложения, использующие OAuth, предоставляют альтернативный вариант с использованием секрета клиента, поэтому сначала стоит попробовать эту возможность.

Если в вашем тесте должен выполняться вход с использованием OAuth, общий порядок действий таков:

Проверьте трафик между веб-браузером, сайтом проверки подлинности и приложением при помощи Fiddler или аналогичного средства. Выполните вход несколько раз с разных компьютеров или из разных браузеров либо через большие промежутки времени (чтобы истек срок действия маркеров). Сравнивая различные сеансы, определите маркер, возвращаемый с сайта проверки подлинности, который затем передается на сервер приложения после входа. Запишите веб-тест с помощью Visual Studio. Параметризуйте маркеры, задав параметр при возврате маркера из структуры проверки подлинности и использовав его в запросе к сайту. (Visual Studio попытается параметризовать тест, но не сможет правильно параметризовать маркеры).

Устранение неполадок

См. инструкции по устранению неполадок.

Дальнейшие действия