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

Вы можете отслеживать записанную последовательность 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>Индивидуальные компоненты>Отладка и тестирование>Средства веб-тестирования производительности и нагрузочного тестирования.

Снимок экрана: пользовательский интерфейс установщика Visual Studio с выбранными отдельными компонентами с флажком рядом с элементом для средств веб-тестирования производительности и нагрузочного тестирования.

Примечание

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

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

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

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

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

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

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

Частота и расположение

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

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

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

видны узлы

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

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

Выполните следующие действия по настройке.

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

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

Снимок экрана: стандартное приложение.

При выполнении теста необходимо EndTime всегда находиться в настоящем времени. StartTime должно быть за 15 минут до.

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

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

    Снимок экрана: добавление подключаемого модуля веб-теста.

    В этом примере используется два экземпляра подключаемого модуля даты и времени. Один экземпляр для "15 минут назад", а другой для "сейчас".

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

    Снимок экрана: параметры контекста.

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

    Снимок экрана: Время начала.

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

Рассмотрите возможность входа

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

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

Простое имя пользователя и пароль

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

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

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

Секрет клиента

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

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

Снимок экрана: пример.

  1. Получите маркер из Azure AD с помощью секрета клиента (ключа приложения).
  2. Извлеките токен носителя из ответа.
  3. ВызовИТЕ API, используя маркер носителя в заголовке авторизации.
  4. Убедитесь, что веб-тест является фактическим клиентом. Это значит, что у него есть собственное приложение в Azure AD. Используйте идентификатор клиента и ключ приложения. Тестируемая служба также имеет собственное приложение в Azure AD. URI идентификатора приложения отражается в веб-тесте в поле ресурса.

Открыть проверку подлинности

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

Если тест должен выполнить вход с помощью OAuth, общий подход:

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

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

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

Следующие шаги