Что такое тестирование масштабируемости? Учитесь на примере
Томас Гамильтон
⚡ Умное резюме
Тестирование масштабируемости измеряет поведение приложения при увеличении или уменьшении пользовательской нагрузки, объема данных или скорости транзакций, выявляя точную точку, в которой производительность перестает масштабироваться, и определяя узкое место, ответственное за это.
Что такое тестирование масштабируемости?
Тестирование масштабируемости Масштабируемость — это метод нефункционального тестирования, измеряющий производительность системы или сети при увеличении или уменьшении количества пользовательских запросов. Цель масштабируемого тестирования — убедиться, что система сможет справиться с прогнозируемым увеличением пользовательского трафика, объема данных и частоты транзакций. Оно проверяет способность системы удовлетворять растущий спрос.
Тестирование масштабируемости — это подвид тестирования масштабируемости. тестирование производительностиТаким образом, основное внимание уделяется поведению приложения при его развертывании в более крупной системе или при работе под чрезмерной нагрузкой. Программная инженерияТестирование масштабируемости измеряет точку, в которой приложение перестает масштабироваться, и выявляет причину этого.
Зачем проводить тестирование масштабируемости?
Проблемы с производительностью редко проявляются во время функционального тестирования. Они всплывают в самый загруженный торговый день года, во время запуска маркетинговой кампании или когда набор данных, незаметно росший в течение двух лет, наконец замедляет каждый запрос. Тестирование масштабируемости сначала выявляет эти ограничения в контролируемой среде. В частности, оно помогает вам:
- Определите, как масштабируется приложение по мере увеличения рабочей нагрузки и где эта кривая выравнивается.
- Определите лимит одновременного подключения пользователей к веб-приложению, прежде чем время отклика станет неприемлемым.
- Определите причины снижения производительности на стороне клиента и ухудшения пользовательского опыта при высокой нагрузке, например, замедление отрисовки экрана.
- Определите устойчивость и снижение производительности на стороне сервера, включая загрузку ЦП, утечки памяти и исчерпание пула соединений.
Проще всего представить эту зависимость в виде кривой: пропускная способность возрастает вместе с увеличением нагрузки до тех пор, пока ресурс не насытится, после чего добавление пользователей лишь удлиняет очередь.
Типы тестирования масштабируемости
Масштабируемость — это не единое свойство, поэтому план тестирования обычно охватывает более одного параметра. Четыре типа, описанные ниже, — это те, которые измеряет большинство команд, и первые два определяют структуру самой тестовой среды.
| Тип | Что такое масштабирование? | Что доказывает тест |
|---|---|---|
| Вертикальная масштабируемость (увеличение масштаба) | Добавление процессора, памяти или хранилища к одному серверу | Какую дополнительную нагрузку может поглотить одна модернизированная машина и где находится предел возможностей одноузловой системы? |
| Горизонтальная масштабируемость (масштабирование) | Дополнительные серверы, контейнеры или узлы за балансировщиком нагрузки | Увеличивается ли пропускная способность примерно пропорционально количеству добавленных узлов, или же она ограничивается общими ресурсами? |
| Функциональная масштабируемость | Новые функции, модули или сервисы | Можно ли внедрить дополнительную функциональность без ухудшения работы существующих транзакций? |
| Административная масштабируемость | Пользователи, арендаторы, команды или среды для управления | Остаются ли системы адаптации новых сотрудников, управления правами доступа и мониторинга работоспособными по мере роста организации? |
Вертикальное масштабирование проще, поскольку архитектура редко меняется, но у отдельной машины всегда есть предел производительности. Горизонтальное масштабирование устраняет этот предел и повышает отказоустойчивость за счет задержки сети, согласованности данных и накладных расходов на координацию — все это тест должен измерять, а не предполагать.
Что тестировать при тестировании масштабируемости?
Масштабируемость оценивается по результатам измерений, а не по количеству показов. Записывайте следующие атрибуты на каждом этапе загрузки, чтобы была видна тенденция, а не только итоговое значение.
| Атрибут | Что это вам говорит |
|---|---|
| Время реакции | Время между запросом пользователя и ответом системы должно оставаться неизменным по мере увеличения количества параллельных запросов. |
| Переход экрана | Как быстро одна страница или представление сменяется следующей под нагрузкой |
| Увеличить пропускную способность | Объем запросов, обрабатываемых за единицу времени; плато обозначает предел масштабируемости. |
| Измерения времени | Время сессии, время перезагрузки, время печати, время транзакции и время выполнения задачи. |
| Показатели эффективности в зависимости от количества пользователей | Как изменяется каждый показатель по мере постепенного добавления одновременно подключенных пользователей. |
| Запросить цены | Запросы в секунду, транзакции в секунду и попадания в секунду |
| Использование сети | Потребляемая пропускная способность и задержка пакетов между уровнями. |
| Использование процессора и памяти | Стоимость ресурсов на транзакцию; постоянно растущий показатель часто сигнализирует об утечке ресурсов. |
| Счетчики веб-сервера | Запросы и ответы в секунду, глубина очереди и количество отклоненных соединений. |
| Производительность под нагрузкой | Совокупное поведение после одновременного считывания всех показателей в пиковый момент. |
Стратегия тестирования масштабируемости
Стратегия тестирования масштабируемости различается в зависимости от типа тестируемого приложения. Если приложение обращается к база данныхВ качестве параметров тестирования будут учитываться размер базы данных по отношению к количеству пользователей и так далее.
Предварительные условия для тестирования масштабируемости
- Возможность распределения нагрузки — Проверьте, позволяет ли инструмент для нагрузочных испытаний создавать нагрузку с нескольких машин и управлять ею из центральной точки.
- Operating System — Проверьте, что операционные системы Агенты генерации нагрузки и главный сервер нагрузочного тестирования работают под управлением.
- процессор — Проверьте, какой тип процессора требуется для виртуального пользовательского агента и главного сервера нагрузочного тестирования.
- Память — Проверьте, сколько памяти будет достаточно для виртуального пользовательского агента и главного сервера нагрузочного тестирования.
- Тестовая среда — Проверьте, что тестовая среда достаточно точно отражает производственный процесс, чтобы результаты можно было перенести.
Как провести тестирование масштабируемости
- Определите повторяемый процесс выполнения тестов масштабируемости на протяжении всего жизненного цикла приложения.
- Определить критерии масштабируемости
- Составьте короткий список программных инструментов, необходимых для запуска нагрузочного теста.
- Установите среду тестирования и настройте оборудование, необходимое для выполнения тестов масштабируемости.
- Составьте план тестовых сценариев, а также тестов на масштабируемость.
- Создайте и проверьте скрипт виртуального пользователя.
- Создайте и проверьте сценарии нагрузочного тестирования.
- Выполните тесты
- Оцените результаты
- Сгенерируйте необходимые отчеты.
План тестирования масштабируемости
Прежде чем приступать к созданию тестов, разработайте подробный план тестирования. Это важный шаг для обеспечения соответствия тестов требованиям приложения.
Ниже приведены атрибуты для создания четко определенного План тестирования для тестирования масштабируемости.
- Шаги для сценариевВ тестовом сценарии должны быть подробно описаны шаги, определяющие точные действия, которые должен выполнить пользователь.
- Данные времени выполненияПлан тестирования должен определять все данные, необходимые во время выполнения для взаимодействия с приложением.
- Тесты, управляемые даннымиЕсли скриптам требуются изменяющиеся данные во время выполнения, необходимо понимать, какие поля нуждаются в этих данных.
Пример тестирования масштабируемости
Рассмотрим интернет-магазин, который ожидает 2,000 одновременных покупателей во время сезонной распродажи. Команда сначала согласовывает критерий соответствия: транзакция оформления заказа должна завершаться менее чем за три секунды для 95 процентов пользователей, при этом уровень ошибок должен быть ниже одного процента.
Затем в ходе теста запускается тот же скрипт просмотра-поиска-корзины-оформления заказа при количестве виртуальных пользователей 250, 500, 1,000, 1,500 и 2,000. Время отклика остается около двух секунд до 1,000 пользователей, снижается до 2.8 секунд при 1,500 и достигает девяти секунд при 2,000, при этом загрузка ЦП базы данных составляет 98 процентов. Таким образом, предел масштабируемости составляет примерно 1,500 пользователей, и узким местом является уровень базы данных, а не серверы приложений, которые команда планировала добавить.
Инструменты тестирования масштабируемости
Для масштабируемого тестирования необходим инструмент, способный одновременно генерировать нагрузку с нескольких машин и централизованно сообщать о результатах. Выбор обычно зависит от основного языка программирования команды и тестируемых протоколов.
| Инструмент | Сценарии | Наиболее подходит для |
|---|---|---|
| Apache JMeter | Планы тестирования графического интерфейса пользователя (GUI) и XML. Java основанный | Широкий охват протоколов, включая JDBC, JMS, LDAP и SOAP. |
| Графана к6 | JavaСкрипт или TypeScript | Тестирование API и микросервисов интегрировано в конвейер CI/CD. |
| Гатлинга | JavaKotlin или Scala DSL | Высокое количество виртуальных пользователей на один инжектор с подробными HTML-отчетами. |
| саранча | одноцветный Python | Python командам, которым необходимо расширить функциональность клиента за пределы HTTP. |
| LoadRunner | Скрипты, похожие на язык C, записанные в VuGen. | Крупные корпоративные сети с устаревшими и готовыми приложениями. |
Облачные средства запуска программ, такие как BlazeMeterLoadView и Gatling Enterprise используют несколько из этих движков и заслуживают внимания, если для тестирования требуются десятки тысяч виртуальных пользователей или трафик из нескольких географических регионов. Более подробный обзор этой категории доступен в руководстве по... инструменты тестирования производительности.
Проблемы и лучшие практики в тестировании масштабируемости
Результаты по масштабируемости оказались крайне неутешительными. tracВернитесь к настройке теста, а не к самому приложению. Именно эти проблемы повторяются, и именно привычки помогают их предотвратить.
Общие проблемы
- Небольшие производственные помещения — Тестовый стенд, использующий вдвое меньше оперативной памяти, сообщает о наличии узкого места, которого нет в производственной среде.
- Нереалистичные модели рабочей нагрузки — Скрипты без задержки или вариаций данных обращаются к кэшу, который реальные пользователи могли бы пропустить.
- Шумные результаты — Автоматическое масштабирование, сборка мусора и использование общего облачного оборудования приводят к расхождениям между двумя идентичными запусками.
- Тонкая наблюдаемость — Без серверных метрик медленный результат показывает, что что-то сломалось, но не что именно.
- Стоимость — Для генерации очень высокой параллельной нагрузки требуется собственный парк генераторов нагрузки, что легко может привести к недофинансированию.
лучшие практики
- Перед первым запуском необходимо согласовать критерии прохождения теста, такие как процентное значение времени отклика и верхний предел частоты ошибок.
- Постепенно увеличивайте нагрузку, следуя плану, и поддерживайте каждый уровень нагрузки достаточно долго, чтобы система стабилизировалась.
- Варьируйте тестовые данные для каждого виртуального пользователя, чтобы кэширование не искажало результаты.
- Собирайте метрики приложений, баз данных и инфраструктуры наряду с показателями на стороне клиента.
- Сохраняйте тестовые скрипты в системе контроля версий и выполняйте краткую проверку масштабируемости при каждой сборке, а затем полную проверку перед выпуском.
- Сравнивайте тенденции в разных сборках, а не оценивайте отдельный отчет изолированно.
Тестирование масштабируемости против нагрузочного тестирования
Эти два метода часто путают, потому что оба создают нагрузку. Разница заключается в вопросе, на который каждый из них отвечает: тестирование масштабируемости задает вопрос о том, насколько может расти система, в то время как нагрузочное тестирование спрашивает, справится ли оно с ожидаемой нагрузкой.
| База | Тестирование масштабируемости | испытание нагрузкой |
|---|---|---|
| Фокус | Основное внимание уделяется производительности ваших веб-сайтов, программного обеспечения, оборудования и приложений при изменении размера или объема системы для удовлетворения растущих потребностей. | Нагрузочное тестирование направлено на проверку приложения в условиях высоких нагрузок, чтобы определить, в какой момент время отклика системы начинает снижаться. |
| Схема нагрузки | Нагрузка увеличивается поэтапно, и между этапами могут добавляться ресурсы. | Нагрузка поддерживается на ожидаемом пиковом уровне в течение фиксированного периода времени. |
| Ответ на вопрос | Насколько может расшириться эта система, и что её ограничивает? | Соответствует ли эта система сегодня согласованным целям? |
| Типичный выход | Ограничение масштабируемости, узкое место и план развития мощностей. | Пройдена или не пройдена оценка по целевым показателям времени отклика и пропускной способности. |
Оба расположены под нефункциональное тестирование зонтик рядом стресс-тестирование, тестирование спайка, испытание на выносливость и объемное тестирование, а продуманная стратегия повышения производительности обычно запускает несколько таких тестов с использованием одних и тех же скриптов.
