Медленная загрузка или неотвека на веб-страницы оказывают непосредственное влияние на финансовые поступления. Крайне важно убедиться, что вы настроили тесты производительности с правильной симуляцией нагрузки. Если не сделать правильно, это может иметь катастрофические последствия. Разочарованные пользователи, скорее всего, отказаться от того, что они делали, а не вернуться. Даже если вы и ваша команда решили эту проблему, скорее всего, слишком поздно. Они, вероятно, уже нашли альтернативное решение. И как только они есть, вряд ли они будут переключаться обратно.
Мало того, что вы должны беспокоиться о потерянных доходов, но и другие факторы, такие как доверие потребителей, целостность бренда и т.д., вероятно, более пагубным для бизнеса. Чем дольше длится вопрос, тем труднее восстановить доверие потребителей. Мало того, отдача от инвестиций, которые вы сделали в свой продукт, команды и организации будет занять больше времени, чтобы понять, если вообще. Таким образом, тестирование производительности (и мониторинг) стало фундаментальной и важной частью цепочки разработки программного обеспечения и приложений. Потребность в решении, которое может правильно и точно выполнять тесты производительности вплотную к опыту пользователя, всегда всегда востребована.
Платформы тестирования производительности предоставляют широкий спектр методов моделирования нагрузки, таких как HTTP/S, безготье и реальное тестирование на основе браузера. В этой статье мы наметим основные аспекты каждого из них, а затем матрицу сравнения, которую можно использовать для выбора соответствующего подхода к моделированию.
Моделирование нагрузки на основе HTTP
В первые дни нашей цифровой эры, http-тестирование было очень популярным. С появлением технологии многофункциональных веб-клиентов этот подход становится все более устаревшим (и тестирование производительности с помощью таких инструментов, как JMeter , также немного устарело). Типичный тест-драйвер на базе HTTP выполняет запросы на обслуживание и анализирует ответы. Современные web 2.0 приложения состоят из многих клиентских скриптов, которые полностью игнорируются и не измеряются в этом типе тестового исполнения. Из-за нехватки клиентских сгенерированных сгенерированных см.
Из-за их запроса и характера, основанного на ответах, накладные расходы на машину для впрыска нагрузки очень низки. Типичный тестовый сервер нагрузки может имитировать до 800 одновременных сеансов. Сложные случаи использования на основе протокола могут быть трудно реализовать. Инженеру по производительности необходимо иметь дело с файлами cookie, данными сеансов и другими динамическими параметрами. В зависимости от технологии тестируемой системы некоторые имена веб-форм часто изменяются после развертывания новой версии, что приводит к сбою сценария на основе HTTP.
Пример сценария ниже демонстрирует очень технический характер этих скриптов. Если технический атрибут приложения изменяется, необходимо переписать весь скрипт, что легче сказать, чем сделать.
//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;
dclform
CONTINUE001:
“имя” :” “Джек”,
“Новое имя-кнопка” : “Продолжить”;
SEARCH001:
“поиск” :” “загрузка”;
В конце концов, сценарии уровня протокола хороши для тестирования на уровне компонентов в средах непрерывной интеграции и, благодаря их малой занимаемой площади на машинах впрыска нагрузки, являются идеальной настройкой для стресс-тестов.
Безготовая моделирование нагрузки на основе браузера
С ростом технологий Web 2.0 испытательный бизнес столкнулся с серьезными проблемами. Богатые браузерные приложения больше не могут быть протестированы или смоделированы на уровне протокола из-за отсутствия логики на стороне клиента во время воспроизведения скрипта. Поэтому было представлено несколько безголёрных браузеров, таких как HtmlUnit, PhantomJS или SlimerJS. Они часто построены на вершине WebKit, двигатель за Chrome и Safari.
Безготовные браузеры имеют все преимущества реальных браузеров, и они работают быстрее без тяжелого графического интерфейса. Многие платформы автоматизации тестирования и тестирования производительности используют безготовые браузеры, поскольку они позволяют реалистичное моделирование пользователей.
Некоторые провайдеры построили свои собственные безготовые браузерные двигатели, но имеют запустить в эксплуатацию ловушки, потому что они должны идти в ногу с новыми версиями браузера. В этой ситуации настоятельно рекомендуется использовать любые свободно доступные безголовые комплекты браузера, потому что существует широкое сообщество, которое работает над улучшениями.
Моделирование визуализации со стороны клиента не бесплатно. Типичный сервер впрыска нагрузки может имитировать до восьми одновременных сеансов безготового браузера.
Реализация и настройка тестовых скриптов не слишком сложны. Если у вас есть базовые навыки разработчика, вы сможете создавать простые скрипты. Не все безголюкие браузеры предоставляют функции визуального воспроизведения и без визуального воспроизведения, отладка скрипта, и анализ ошибок может стать очень сложным.
В примере ниже выполняется простой запрос на пост. Для настройки таких тестовых сценариев вам понадобятся навыки программирования на Java.
//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=42';
page.open (сервер, ‘пост’, данные, функция (статус)
если (статус! – “успех”)
консоль.log (‘Не удается разместить!’);
– еще один
консоль.log (page.content);
}
phantom.exit();
});
С учетом этого, безготовные браузеры путь, если у вас есть навыки программирования, и вы используете решение, которое позволяет визуального воспроизведения сценария.
Реальное моделирование нагрузки на основе браузера
Web 2.0 приложения полны JavaScript, Flash, AJAX, CSS и т.д. Без полного браузера невозможно измерить фактическое время ответа на все приложение или веб-страницу. Реальное тестирование производительности на основе браузера позволяет проверить функциональность и скорость сайта , воспринимаемые конечным пользователем, что, как мы обсуждали выше, действительно имеет значение.
Типичное реальное решение для тестирования производительности браузера собирает время загрузки изображений, JavaScript, CSS и многое другое. Часто они обеспечивают водопад диаграммы, которые визуализируют время загрузки этих компонентов.
След реального браузера на основе браузера немного выше. Поскольку безголистное моделирование браузера не дает 100-процентного реалистичного времени отклика, справедливо сказать, что реальным моделированием на основе браузера должен быть предпочтительный метод тестирования.
Реализация и обслуживание тестовых скриптов легко, потому что действия пользователя непосредственно отражены, а визуальный повтор упрощает отладку. В примере сценария ниже браузер открывает URL-адрес, вставляет пароль пользователя и нажимает кнопку входа.
//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);
перейти на сайт входа
BrowserNavigate (“https://demo.com/TestSite/LoginForm.html”);
установить аутентификацию для безопасного сайта
BrowserSetText (“//INPUT@name’пользователь”, “Пользователь1”);
BrowserSetPassword (“//INPUT@name’pwd'”, “Password1”);
логин
BrowserClick (“//INPUT @value”‘Login'”, BUTTON_Left);
конец TMain;
В конце концов, реальное моделирование браузера полезно для реалистичных тестов на нагрузку. Однако не используйте его для стресс-тестирования, так как след на сервере впрыска нагрузки слишком высок.
Различные типы нагрузок и тестов производительности
Тесты скорости компонентов
В последние годы методы разработки программного обеспечения двигались в гибком направлении. Короткие спринты релиза имеют важное значение. Разработчики и инженеры-испытатели автоматизируют проверку качества и производительности. Как правило, они реализуют тесты производительности на основе служб (а иногда и тесты API) на уровне протокола или имитируют реальные проверки производительности на основе браузера для сравнения сквозного времени отклика с согласованными границами производительности.
Цели испытаний скорости компонентов:
- Проверка и повторение поведения входных/выходных данных.
- Автоматизированный интерфейс и все-таки проверки производительности.
- Сравнение времени отклика с согласованными пороговыми значениями.
Нагрузочных тестов
Загрузка тестирует идеальную настройку, когда дело доходит до проверки нефункциональных требований. Одна из причин заключается в том, что время отклика может быть проверено в воспроизводимых условиях. Другое дело, что эти тесты позволяют проверить пороговые значения времени отклика. Реалистичное измерение времени отклика имеет важное значение в сценариях тестирования нагрузки. Поэтому инженеры-испытатели используют безготовное или реальное моделирование пользователей на основе браузера для своих настроек тестирования нагрузки.
Цели нагрузочных испытаний:
- Воспроизводимая нагрузка моделирования.
- Проверка пороговых значений времени отклика.
- Выявление узких мест в условиях производственной нагрузки.
- Создание реалистичных сценариев тестирования.
Стресс-тестирование
Если необходимо доказать надежность приложения в условиях пиковой нагрузки, запустите стресс-тест, чтобы определить точку разрыва системы.
Цели стресс-тестирования:
- Докажите масштабируемость и стабильность в пиковых условиях движения.
- Наблюдайте, как система выходит из строя и возвращается в Интернет.
- Воспроизводство не важно.
Сравнение
Очевидно, что есть веские причины и ситуации для протокола, безготье, и реальные браузер на основе моделирования пользователей. В приведенной ниже матрице приведены некоторые рекомендации относительно того, когда выбрать соответствующий подход к тестированию.
| критерии | HTTP | Безготовный браузер | Реальный браузер |
| Моделирование пользователя | (1) Нет клиенто-стороны рендеринга | (2) Некоторые элементы, со стороны клиента, моделируются | (3) Моделирование реальных пользователей |
| Реализация сценария и настройка | (1) Трудно, когда веб-сайты являются сложными | (2) Навыки разработчика, необходимые для создания надежных скриптов | (3) Простые скрипты, легко настроить |
| Повтор сценария | (1) Требуется анализ низкого уровня | (2) В зависимости от используемого двигателя возможно визуальное воспроизведение | (3) Вы видите, что вы получаете |
| Обслуживание скрипта | (1) Необходимы навыки программирования | (2) Ошибки в не отрисованные разделы сложно решить | (3) Легко, потому что вы видите сбои во время воспроизведения |
| Поддержка нескольких браузеров | (1) Некоторые инструменты эмулируют веб-браузеры, но это несопоставимо | (2) Да, но некоторые элементы часто отсутствуют | (2) Некоторые поддерживают другие версии и различные браузеры |
| След на машине впрыска нагрузки | (3) Низкий, до 800 сеансов на сервер | (2) Средний, до 8 сеансов на сервер | (1) Высокий, до 6 сеансов на сервер |
| Рекомендуется для DevOps | (2) Зависит от фактического сценария тестирования | (1) Нет, часто сложные скрипты | (3) Да, проста в использовании и реалистичные цифры |
| Рекомендуется для нагрузочных тестов | (1) Нет, обработка на стороне клиента пропущена | (2) Да, лучше, чем моделирование HTTP | (3) Да, реалистичное моделирование пользователя |
| Рекомендуется для стресс-тестов | (3) Да, потому что есть низкие накладные расходы на машину генератора нагрузки | (2) Нет, накладные расходы на машину генератора нагрузки слишком высока | (1) Нет, самые высокие накладные расходы на машину генератора нагрузки |
| издержки | (3) Низкий | (2) Средний | (1) Высокий |
| Общий балл | 17 | 19 | 24 |
Надеемся, что эта статья о моделировании нагрузки и типах тестирования производительности дала вам некоторое дополнительное представление о ваших тестах производительности. Если у вас есть какие-либо вопросы о выполнении нагрузочных и стресс-тестов или о решении LoadView в целом, свяжитесь с нашей командой или запишитесь на демонстрацию с одним из наших инженеров по производительности.