Многоэтапные веб-тесты
Вы можете отслеживать записанную последовательность 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>Individual componenting>and testing>Web performance and load testing tools.
Примечание.
С ними связаны дополнительные затраты на многоэтапные веб-тесты. Дополнительные сведения см. в официальном руководстве по ценам.
Внимание
Многоэтапный веб-тест использует инфраструктуру DNS общедоступного Интернета для разрешения доменных имен тестируемых конечных точек. Если вы используете частный DNS, необходимо убедиться в том, что серверы общедоступных доменных имен могут разрешать каждое доменное имя теста. Если это невозможно, вместо них можно использовать настраиваемые тесты TrackAvailability.
Запись многоэтапного веб-теста
Предупреждение
Мы больше не рекомендуем использовать многоэтапный записыватель. Средство записи было разработано для статических HTML-страниц с основными взаимодействиями. Он не предоставляет функциональный интерфейс для современных веб-страниц.
Инструкции по созданию веб-тестов Visual Studio см. в официальной документации по Visual Studio 2019.
Отправка веб-теста
- На портале Application Insights на панели доступности выберите " Добавить классический тест". Затем в качестве номера SKU выберите многофакторную команду.
- Отправьте многоэтапный веб-тест.
- Установите значения для параметров местоположений, частоты и оповещений.
- Нажмите кнопку создания.
Частота и расположение
| Параметр | Description |
|---|---|
| Периодичность проведения тестирования | Задает частоту выполнения теста для всех тестовых расположений. При стандартной частоте в пять минут и с пятью тестовыми расположениями ваш сайт будет проверяться в среднем каждую минуту. |
| Расположения тестирования | Места, из которых наши серверы отправляют веб-запросы на ваш URL-адрес. Чтобы вы могли отличить проблемы с веб-сайтом от проблем с сетью, мы рекомендуем использовать не менее пяти расположений. Вы можете выбрать до 16 таких расположений. |
Условия успеха
| Параметр | Description |
|---|---|
| Время ожидания тестирования | Уменьшите значение этого параметра, чтобы получать оповещения о медленных откликах. Тест считается неудачной попыткой, если ответы от сайта не были получены в течение заданного периода. Если выбрать параметр Анализировать зависимые запросы, все изображения, файлы стилей, скрипты и другие зависимые ресурсы будут получены в течение этого периода. |
| HTTP-ответ | Возвращаемый код состояния, который считается успешным результатом. Код 200 указывает, что была возвращена обычная веб-страница. |
| Совпадение содержимого | Произвольная строка, например "Welcome!". Мы проверяем наличие точного совпадения (с учетом регистра) со строкой в каждом ответе. Это должна быть строка обычного текста без подстановочных знаков. Не забывайте, что при изменении содержимого страницы необходимо обновить эту строку. Поддерживаются только английские символы с совпадением содержимого. |
видны узлы
| Параметр | Description |
|---|---|
| Режим почти реального времени (предварительная версия) | Мы рекомендуем использовать оповещения практически в режиме реального времени. Настройка этого типа оповещений выполняется после создания теста доступности. |
| Пороговое значение для расположения оповещения | Мы рекомендуем как минимум 3 из 5 расположений. Оптимальное отношение между пороговым значением для оповещения расположения и числом тестовых расположений: пороговое значение для оповещения расположения = число расположений теста – 2, минимум с пятью расположениями теста. |
Настройка
Выполните следующие действия по настройке.
Подключение времени и случайных чисел к тесту
Предположим, вы тестируете средство, которое получает данные, зависящие от времени, такие как цены на акции, из внешнего канала. При записи веб-теста необходимо использовать определенное время, но задать их в качестве параметров теста и StartTime EndTime.
При выполнении теста необходимо EndTime всегда находиться в настоящее время. StartTime должно быть 15 минут до.
Подключаемый модуль времени веб-теста даты и времени предоставляет способ обработки времени параметров.
Добавьте подключаемый модуль веб-теста для каждого нужного значения параметра переменной. На панели инструментов веб-теста выберите "Добавить подключаемый модуль веб-теста".
В этом примере используется два экземпляра подключаемого модуля даты и времени. Один экземпляр предназначен для "15 минут назад", а другой — для "сейчас".
Откройте свойства каждого подключаемого модуля. Присвойте ему имя и настройте его для использования текущего времени. Для одного из них задайте значение "Добавить минуты" = -15.
В параметрах веб-теста используйте
{{plug-in name}}для ссылки на имя подключаемого модуля.
Теперь можно передать тест на портал. Он будет использовать динамические значения для каждого запуска теста.
Рассмотрите возможность входа
Если пользователи входят в приложение, вы можете протестировать страницы входа, используя несколько способов имитации входа. Выбор подхода зависит от типа безопасности в приложении.
Во всех случаях создайте учетную запись в приложении только для тестирования. По возможности ограничьте разрешения для этой тестовой учетной записи, чтобы веб-тесты не доставляли неудобств реальным пользователям.
Простое имя пользователя и пароль
Запишите веб-тест обычным образом. Сначала удалите файлы cookie.
проверка подлинности SAML
| Имя свойства | Description |
|---|---|
| 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 пытается параметризировать тест, но не правильно параметризирует маркеры.)
Устранение неполадок
Сведения об устранении неполадок см. в статье об устранении неполадок.