Многоэтапные веб-тесты
Вы можете отслеживать записанную последовательность 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>Индивидуальные компоненты>Отладка и тестирование>Средств веб-тестирования производительности и нагрузочного тестирования.
Примечание
С многошаговыми веб-тестами связаны дополнительные затраты. Дополнительные сведения см. в официальном руководстве по ценам.
Запись многоэтапного веб-теста
Предупреждение
Больше не рекомендуется использовать многошаговую запись. Средство записи было разработано для статических HTML-страниц с базовыми взаимодействиями. Он не обеспечивает функциональный интерфейс для современных веб-страниц.
Инструкции по созданию веб-тестов Visual Studio см. в официальной документации по Visual Studio 2019.
Отправка веб-теста
- На портале Application Insights в области Доступность выберите Добавить классический тест. Затем выберите Многошаговыйномер SKU.
- Отправьте многоэтапный веб-тест.
- Установите значения для параметров местоположений, частоты и оповещений.
- Нажмите кнопку создания.
Частота и расположение
| Параметр | Описание |
|---|---|
| параметр "Периодичность проверки" | Задает частоту выполнения теста для всех тестовых расположений. При стандартной частоте в пять минут и с пятью тестовыми расположениями ваш сайт будет проверяться в среднем каждую минуту. |
| Расположения тестирования | Места, из которых наши серверы отправляют веб-запросы на ваш URL-адрес. Чтобы вы могли отличить проблемы с веб-сайтом от проблем с сетью, мы рекомендуем использовать не менее пяти расположений. Вы можете выбрать до 16 таких расположений. |
Критерии успешного завершения
| Параметр | Описание |
|---|---|
| Время ожидания тестирования | Уменьшите значение этого параметра, чтобы получать оповещения о медленных откликах. Тест считается неудачной попыткой, если ответы от сайта не были получены в течение заданного периода. Если выбрать параметр Анализировать зависимые запросы, все изображения, файлы стилей, скрипты и другие зависимые ресурсы будут получены в течение этого периода. |
| Ответ HTTP | Возвращаемый код состояния, который считается успешным результатом. Код 200 указывает, что была возвращена обычная веб-страница. |
| совпадение содержимого | Произвольная строка, например "Welcome!". Мы проверяем наличие точного совпадения (с учетом регистра) со строкой в каждом ответе. Это должна быть строка обычного текста без подстановочных знаков. Не забывайте, что при изменении содержимого страницы необходимо обновить эту строку. Совпадение содержимого поддерживается только для символов на английском языке. |
видны узлы
| Параметр | Описание |
|---|---|
| Режим почти реального времени (предварительная версия) | Мы рекомендуем использовать оповещения практически в реальном времени. Настройка этого типа оповещений выполняется после создания теста доступности. |
| Порог генерации для местоположения | Мы рекомендуем как минимум 3 из 5 расположений. Оптимальная связь между пороговым значением расположения оповещений и количеством тестовых расположений — пороговое = значение расположения оповещений — 2, при этом не менее пяти расположений тестирования. |
Конфигурация
Выполните следующие действия по настройке.
Подключение времени и случайных чисел к тесту
Предположим, вы тестируете средство, которое получает зависящие от времени данные, такие как цены на акции, из внешнего веб-канала. При записи веб-теста необходимо использовать определенное время, но вы задали его в качестве параметров теста и StartTimeEndTime.
При выполнении теста вы хотите EndTime всегда быть в настоящее время. StartTime должно быть за 15 минут до.
Подключаемый модуль веб-теста даты и времени предоставляет способ обработки времени параметров.
Добавьте подключаемый модуль веб-теста для каждого значения параметра переменной. На панели инструментов веб-теста выберите Добавить подключаемый модуль веб-теста.
В этом примере используется два экземпляра подключаемого модуля даты и времени. Один экземпляр — для "15 минут назад", а другой — для "сейчас".
Откройте свойства каждого подключаемого модуля. Присвойте ему имя и настройте его для использования текущего времени. Для одного из них установите параметр Добавить минуты = -15.
В параметрах веб-теста используйте
{{plug-in name}}для ссылки на имя подключаемого модуля.
Теперь можно передать тест на портал. Он будет использовать динамические значения при каждом запуске теста.
Рассмотрите возможность входа
Если пользователи входят в приложение, вы можете протестировать страницы входа, используя несколько способов имитации входа. Выбор подхода зависит от типа безопасности в приложении.
Во всех случаях создайте учетную запись в приложении только для тестирования. По возможности ограничьте разрешения для этой тестовой учетной записи, чтобы веб-тесты не доставляли неудобств реальным пользователям.
Простое имя пользователя и пароль
Запишите веб-тест обычным образом. Сначала удалите файлы cookie.
Проверка подлинности SAML
| Имя свойства | Описание |
|---|---|
| URI аудитории | URI аудитории для токена SAML. Этот URI предназначен для службы контроль доступа, включая контроль доступа пространство имен и имя узла. |
| Пароль сертификата | Пароль для сертификата клиента, который предоставит доступ к встроенному закрытому ключу. |
| Сертификат клиента | Значение сертификата клиента с закрытым ключом в формате Base64. |
| Идентификатор имени | Идентификатор имени для маркера. |
| Не после | Срок действия токена. Значение по умолчанию равно 5 минутам. |
| Не ранее | Срок действия токена, созданного ранее (на случай отклонений во времени). Отрицательное значение; по умолчанию — 5 минут. |
| Имя параметра целевого контекста | Имя параметра контекста, в который будет записано сформированное утверждение. |
Секрет клиента
Если в приложении предусмотрен маршрут входа с использованием секрета клиента, используйте этот маршрут. Azure Active Directory (Azure AD) — это пример службы, которая предоставляет секретный вход клиента. В Azure AD секрет клиента является ключом приложения.
Ниже приведен пример веб-теста веб-приложения Azure с использованием ключа приложения.
- Получите маркер из Azure AD с помощью секрета клиента (ключа приложения).
- Извлеките токен носителя из ответа.
- ВызовИТЕ API, используя маркер носителя в заголовке авторизации.
- Убедитесь, что веб-тест является фактическим клиентом. Это значит, что у него есть собственное приложение в Azure AD. Используйте идентификатор клиента и ключ приложения. Тестируемая служба также имеет собственное приложение в Azure AD. URI идентификатора приложения отражается в веб-тесте в поле ресурса.
Открыть проверку подлинности
Примером открытой проверки подлинности является вход с помощью учетной записи Майкрософт или Google. Многие приложения, использующие OAuth, предоставляют альтернативный вариант с использованием секрета клиента, поэтому сначала стоит попробовать эту возможность.
Если тест должен выполнить вход с помощью OAuth, общий подход:
- Проверьте трафик между веб-браузером, сайтом проверки подлинности и приложением при помощи Fiddler или аналогичного средства.
- Выполните вход несколько раз с разных компьютеров или из разных браузеров либо через большие промежутки времени (чтобы истек срок действия маркеров).
- Сравнивая различные сеансы, определите маркер, переданный обратно с сайта проверки подлинности, который затем передается на сервер приложений после входа.
- Запись веб-теста с помощью Visual Studio.
- Параметризация маркеров. Задайте параметр, когда маркер возвращается из средства проверки подлинности, и используйте его в запросе к сайту. (Visual Studio пытается параметризовать тест, но не правильно параметризует маркеры.)
Устранение неполадок
Справку по устранению неполадок см. в специальной статье по устранению неполадок .