No Image

Что такое нагрузочное тестирование

СОДЕРЖАНИЕ
0 просмотров
22 января 2020

Раздел: Автоматизация > Нагрузочное тестирование

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

Теперь давайте ответим на вопрос: "Что же такое нагрузочное тестирование?", и постараемся более подробно описать процесс проведения нагрузочного тестирования.

Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) – это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

Начиная работу в области нагрузочного тестирования, следует четко понимать, что это не просто запись и прогон (Record and Playback) скриптов, а более сложный процесс:

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

Далее предлагаю вам пункт за пунктом углубиться в тестирование производительности:

Также рекомендуем почитать статьи специалистов по нагрузочному тестированию:

Конечно, прочитать все это – не достаточно, чтобы сказать: "Я стал знатоком или экспертом в области тестирования производительности", для этого вам понадобится не один год и не один проект. От себя мы можем только пожелать вам удачи на этом нелегком пути. Если же у вас появятся вопросы, вы можете смело обратиться к нам. Специалисты группы ПроТестинг могут провести консультации по тестированию и обеспечению качества программного обеспечения

Авторы раздела: Андрей Широбоков, Алексей Булат
Блог автора: Нагрузочное тестирование ПО

Предложение от 8host.com

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

За последние несколько лет в сфере оптимизации производительности было разработано много передовых методов и технологий. Многие из этих методов предназначены для уменьшения размера загружаемых веб-страниц, оптимизации JavaScript и ограничения количества отдельных запросов HTTP.

Данная статья расскажет об основных понятиях и открытых инструментах для оптимизации производительности. С ее помощью вы сможете выяснить, как быстро ваш сервер отвечает на запросы пользователей, и разработать индивидуальный план.

Основные понятия

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

  • Задержка – это показатель того, насколько быстро сервер реагирует на запросы клиента. Обычно измеряется в миллисекундах (мс). Задержка также часто называется временем отклика. Чем ниже этот показатель, тем быстрее сервер обрабатывает запрос. Задержка измеряется на стороне клиента с момента отправки запроса до получения ответа. В этот показатель включены затраты сетевых ресурсов.
  • Пропускная способность – это количество запросов, которые сервер может обрабатывать в течение определенного промежутка времени. Обычно этот показатель измеряется в запросах в секунду.
  • Процентиль – это способ группировки результатов по проценту от всего набора данных.

Основы нагрузочного тестирования

Нагрузочное тестирование – это технология измерения производительности сервера, которая заключается в отправке имитируемого HTTP-трафика на сервер. Это позволяет найти ответы на такие вопросы:

  • Достаточно ли у сервера ресурсов (памяти, CPU и т. п.), чтобы обработать ожидаемый трафик?
  • Достаточно ли быстро реагирует сервер, чтобы обеспечить хороший пользовательский опыт?
  • Эффективно ли работает приложение?
  • Нужно ли серверу вертикальное или горизонтальное масштабирование?
  • Есть ли особо ресурсозатратные страницы или вызовы API?

Нагрузочное тестирование выполняется путем запуска специального программного обеспечения на одном компьютере (или в кластере машин). Это ПО генерирует большое количество запросов и отправляет их на веб-сервер на втором компьютере (или в другой инфраструктуре). Существует много таких инструментов, позже мы рассмотрим некоторые их них. На данный момент сосредоточимся на общих терминах, которые будут актуальны независимо от того, какое средство для нагрузочного тестирования вы выберете. Обычное программное обеспечение для нагрузочного тестирования используется для определения максимального количества запросов в секунду, которое может обрабатывать сервер. Для этого на сервер отправляется как можно большее количество запросов; затем нужно проверить, сколько из них сервер смог обработать успешно.

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

Общая тенденция такова: чем выше нагрузка (чем больше запросов в секунду), тем выше задержка. Чтобы получить более реальную картину о задержке сервера при заданной нагрузке, нужно будет протестировать его несколько раз с разным количеством запросов. Не все приложения для тестирования нагрузки способны на это, но немного позже мы ознакомимся с wrk2 (это средство командной строки для тестирования нагрузки, которое может выполнить эту функцию).

Как определить разумный показатель задержки?

Время загрузки веб-сайта в диапазоне 2-5 секунд – обычное дело, но часть времени, связанная с задержкой веб-сервера, обычно составляет около 50-200 миллисекунд. Идеальный показатель задержки индивидуален для каждого сайта. Он зависит от большого количества факторов (аудитории, рынка, целей сайта, наличия пользовательского интерфейса или API и т. д.). Имейте в виду: большинство исследований показывают, что в производительности учитывается каждый маленький бит скорости, и даже совсем незаметные улучшения приводят к улучшению результатов в целом.

Читайте также:  Филипс ксениум w8510 характеристики

Планирование нагрузочного тестирования

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

1: Мониторинг ресурсов

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

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

Если у вас уже есть система мониторинга типа Prometheus, Graphite или CollectD, вы сможете собрать все необходимые данные.

Читайте также:

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

Для мониторинга доступной памяти используйте команду free. В комбинации с командой watch данные будут обновляться каждые 2 секунды.

Флаг -h выводит числа в удобочитаемом формате.

total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
-/+ buffers/cache: 39M 450M
Swap: 0B 0B 0B

Выделенное число в выводе представляет свободную память после вычитания буфера и кэша. Новые версии free выводят другие результаты:

. total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M 260M
Swap: 0B 0B 0B

Новый столбец available вычисляется по-разному, но обычно представляет одну и ту же метрику: текущий объем доступной памяти для приложений.

Для мониторинга использования CPU в командной строке есть утилита mpstat, которая выводит количество свободных ресурсов CPU. По умолчанию утилита mpstat не установлена в Ubuntu. Вы можете установить ее с помощью следующей команды:

sudo apt-get install sysstat

При запуске mpstat нужно задать интервал обновления данных в секундах:

Она выведет строку заголовков, а затем строку статистики, и будет обновляться каждые две секунды:

Linux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

Столбец %idle показывает, какой процент ресурсов ЦП не используется. Загрузка процессора часто разделяется на разные категории (user CPU и system CPU).

2: Определение максимальной скорости отклика

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

Конкурентность – это показатель, который отображает количество параллельных подключений, которое может обрабатывать сервер. Значение по умолчанию 100 подходит в большинстве случаев, но вы можете выбрать индивидуальное значение. Для этого нужно проверить MaxClients, MaxThreads сервера и другие подобные параметры.

Также вам нужно будет выбрать URL-адрес для тестирования. Если ваше программное обеспечение может обрабатывать только один URL за один раз, стоит выполнить несколько тестов для разных URL-адресов, так как требования к обработке могут сильно различаться в зависимости от страницы. Например, требования к загрузке домашней страницы сайта и страницы продукта разные.

Некоторое программное обеспечение для нагрузочного тестирования позволяет сразу указать несколько URL-адресов, которые нужно проверить. Это позволяет более точно имитировать реальный трафик. Если у вас есть данные об использовании сайта (из аналитического программного обеспечения или логов сервера), вы можете применить эти данные в тестировании.

Отобрав URL-адреса, запустите тестирование. Убедитесь, что программное обеспечение очень быстро отправляет запросы. Если программное обеспечение разрешает выбрать скорость запроса, выберите значение, которое почти наверняка будет слишком высоким для вашего сервера. Если программное позволяет установить задержку между запросами, уменьшите это значение до нуля.

Использование ресурсов процессора и памяти будет увеличиваться. Свободные ресурсы процессора могут достигать 0%, и клиент может получить ошибку соединения. Это нормально, поскольку сервер работает на пределе возможностей.

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

Затем нужно повторить тестирование, чтобы получить дополнительную информацию о том, как работает сервер на пределе ресурсов.

3: Определение максимальной пропускной способности

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

Здесь можно обратиться к инструменту wrk2, который позволяет указывать точное количество запросов в секунду.

Возьмите максимальную скорость запросов, которую вы определили на предыдущем этапе, и разделите ее на 2. Запустите еще один тест с новыми данными и обратите внимание на время ответа. Находится ли показатель в приемлемом диапазоне?

Если да, увеличьте значение до максимума и повторите тестирование, пока задержка не достигнет максимального значения, которое вы считаете приемлемым. Это и будет фактическая максимальная скорость ответа, которую может обрабатывать ваш сервер.

Инструменты для нагрузочного тестирования

Существует множество программных пакетов с открытым исходным кодом для нагрузочного тестирования серверов. Кроме того, существует множество платных сервисов, которые умеют автоматически создавать графики и отчеты на основе данных, полученных в ходе тестирования. Эти сервисы отлично подходят крупным сайтам, которым необходимо генерировать высокую нагрузку для тестирования большой инфраструктуры.

Читайте также:  Телевизор lg подключение к интернету через кабель

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

Инструмент ab

ab (или ApacheBench) – это простой однопоточный инструмент командной строки для тестирования HTTP-серверов. Изначально он разрабатывался как часть HTTP-сервера Apache, но его можно использовать для тестирования любого HTTP- или HTTPS-сервера.

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

Базовый вызов команды ab выглядит следующим образом:

ab -n 1000 -c 100 http://example.com/

Флаг –n задает количество запросов. Флаг –с задает конкурентность. Затем нужно указать URL, который нужно протестировать. Вывод (выдержка из которого приведена ниже) указывает количество запросов в секунду, время запроса и список процентилей времени ответа:

. . .
Requests per second: 734.76 [#/sec] (mean)

Time per request: 136.098 [ms] (mean)
Time per request: 1.361 [ms] (mean, across all concurrent requests)
Transfer rate: 60645.11 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)
50% 133

66% 135

75% 137

80% 139

90% 145

95% 149

98% 150

99% 151

100% 189 (longest request)

JMeter

JMeter – это мощное и многофункциональное приложение для нагрузочного и функционального тестирования от Apache Software Foundation. Функциональное тестирование – это проверка вывода приложения.

JMeter предлагает графический интерфейс Java для настройки тестовых планов.

Планы тестирования можно записать с помощью прокси-сервера JMeter и обычного браузера. Это позволяет вам использовать в тестах трафик, который более точно имитирует реальную работу сервера.

JMeter может выводить информацию о процентилях в отчетах HTML и других форматах.

Siege

Siege – еще один инструмент командной строки для нагрузочного тестирования. Он похож на ab, но имеет несколько дополнительных функций. Siege – многопоточный инструмент, что обеспечивает относительно высокую пропускную способность. Он также позволяет указать сразу несколько URL-адресов для нагрузочного тестирования. Базовый вызов выглядит так:

siege -c 100 -t 30s http://example.com/

Флаг –с указывает конкурентность. Флаг -t определяет продолжительность тестирования (в данном случае – 30 секунд). Siege выводит среднее время отклика и скорость запроса:

. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Response time: 0.01 secs

Transaction rate: 197.15 trans/sec
Throughput: 4.59 MB/sec
Concurrency: 2.23
. . .

Siege не предоставляет процентилей для статистики задержек.

Locust

Locust – это инструмент для нагрузочного тестирования на основе Python, который предоставляет веб-интерфейс для мониторинга результатов в реальном времени.

Сценарии тестирования Locust пишутся с помощью кода Python, что предоставляет дополнительные преимущества тем, кто хорошо знаком с этим языком программирования.

Locust также можно запускать в распределенном режиме: вы можете запустить кластер из серверов Locust, который будет создавать высокую нагрузку вашего сервера. Это позволяет выполнить качественное нагрузочное тестирование целой инфраструктуры веб-серверов.

Locust может предоставить подробную статистику в CSV-файлах, которые можно загрузить.

Инструмент wrk2

wrk2 – это многопоточный инструмент командной строки для нагрузочного тестирования, способный производить нагрузку с заданной частотой запросов. Он может предоставлять подробную статистику задержек и поддерживает сценарии на языке программирования Lua.

wrk2 вызывается командой wrk:

wrk -t4 -c100 -d30s -R100 –latency http://example.com/

Параметр -t определяет количество потоков (в данном случае их 4, здесь нужно использовать количество процессорных ядер вашего сервера). Параметр -c указывает количество одновременных запросов (здесь 100). Флаг –d определяет продолжительность тестирования (30 секунд). Флаг –R указывает частоту запросов в секунду (100). Подробный вывод задержки предоставит флаг —latency.

. . .
Latency Distribution (HdrHistogram – Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .

Заключение

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

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

Что пишут в блогах

Совсем скоро под бой курантов и праздничный фейерверк закончится этот плодотворный и запоминающийся для нас год (но об этом позже ;).

В этом видео показан пример построения проекта по автоматизации тестирования на Java

Заходите в наш Slack. " >QAGuild live #19: Чемпионат по автоматизации тестирования на Java

  • В моей школе есть практическое задание — выбрать для своего сайта любой исследовательский тур и применить. 20 минут поисследовать и написать результаты.
    Тур домоседа: как за 20 минут найти 4 бага
  • Онлайн-тренинги

    Конференции

    Что пишут в блогах (EN)

    Разделы портала

    Про инструменты

    Как спроектировать нагрузочный тест
    13.08.2019 00:00

    Автор: Кристин Джеквони (Kristin Jackvony)
    Оригинал статьи
    Перевод: Ольга Алифанова

    Сегодня мы поговорим о нагрузочном тестировании. Нагрузочное тестирование – это способы измерения надежности и скорости вашего приложения во времена повышенного спроса на него. Это может означать тест-сценарии при приемлемой, разумной нагрузке, или же это могут быть тесты на экстремальный стресс, чтобы выяснить пределы возможностей приложения.

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

    Поэтому, прежде чем приступать, важно ответить на следующие вопросы:

    • Какие сценарии будут тестироваться?
    • Каково ожидаемое поведение в этих сценариях?

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

    Держа это в уме, вы ожидаете вот какого поведения:

    • Страницы сайта должны загружаться за не более чем две секунды под обычной субботней утренней нагрузкой.
    • Сайт должен быть способен обрабатывать пятьсот заказов в час – это поможет справиться с загруженным сезоном дня святого Валентина.
    • Сайт должен выдерживать десять тысяч посетителей в час – такое количество ожидается сразу после эфира ТВ-шоу.

    Следующий шаг – выяснить, какое тест-окружение будет использоваться. Конечно, тестирование в продакшене – это наиболее реалистичное окружение, но нагрузочное тестирование в этих условиях – плохая идея, если результатом станет падение сайта. Следующий наиболее реалистичный вариант – это тест-окружение, которое точно отражает реальное окружение в смысле количества используемых серверов и размера базы данных бэкэнда. Идеальная ситуация – когда тест-окружение используется только для нагрузочного тестирования, но это не всегда возможно; вам может понадобиться делиться этим окружением с другими тестировщиками, и тогда вам надо знать, какие тесты они запускают, и как это может на вас повлиять. Они, в свою очередь, должны знать, когда проводятся ваши нагрузочные тесты, и не удивляться повышенному времени отклика.

    Как только тест-окружение подготовлено, можно провести ряд простых тестов, чтобы определиться с базовыми значениями метрик. Тут можно использовать стратегии, упомянутые в статье "Введение в тестирование производительности" и выяснить, как долго грузятся страницы, и каково типичное время ответа ваших API-эндпойнтов. Знание этих чисел поможет вам определить, какой эффект окажет нагрузка.

    Теперь настало время проектировать тесты. Здесь можно пользоваться различными стратегиями:

    • Можно тестировать индивидуальные компоненты – например, загрузку страницы или единичный запрос к API.
    • Можно тестировать целые пользовательские сценарии – просмотр сайта, добавление товара в корзину, оформление заказа.

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

    Для каждого теста нужно определиться:

    • Сколько пользователей будет единовременно взаимодействовать с приложением?
    • Будут ли они добавляться единовременно, или постепенно, каждые несколько секунд?
    • Будут ли они выполнять одно действие и останавливаться, или же они будут непрерывно повторять его в течение теста?
    • Как долго продлится тест?

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

    Перед прогоном теста убедитесь, что шаги возвращают ошибки, если не получают ожидаемого результата. Когда я только начинала работать в нагрузочном тестировании, я прогнала несколько тестов с сотнями запросов, прежде чем обнаружила, что все мои запросы возвращали пустоту. Они возвращались со статусом 200, поэтому я и не заметила, что что-то пошло не так! Убедитесь, что ваши шаги убеждаются, что приложение работает именно так, как задумано.

    Когда шаги созданы, тест-параметры (количество пользователей, частота их добавления и продолжительность теста) заданы, а вы убедились, что валидация результата в порядке, наступает время прогона! Пока тест запущен, следите за временем ответов и загрузкой процессора. Если пойдут ошибки или всплески загрузки CPU, можно остановить тест и отметить, при какой нагрузке это произошло.

    Неважно, надо ли вам остановить тест раньше времени, или он успешно завершен – понадобится несколько прогонов, чтобы убедиться, что результаты соответствуют друг другу. В конце тестирования вы сможете ответить на вопрос, выдержит ли ваше приложение пятьсот заказов в час. Если все заказы прошли без ошибок, а время ответа было приемлемым, то ответ "да". Если вы столкнулись с ошибками, или время ответа увеличилось до нескольких секунд, то ответ "нет". Если ответ "нет", то собранными данными стоит поделиться с разработчиками, чтобы показать, при каком количестве пользователей система начала медленнее работать.

    Нагрузочное тестирование – это не то, чем стоит заниматься просто ради того, чтобы поставить галочку "этот тип тестирования покрыт". Потратив время на размышления, какие сценарии нужно замерять, какого поведения вы ожидаете, как именно можно протестировать это поведение, и как анализировать результаты, вы убедитесь, что нагрузочное тестирование – продуктивная и информативная деятельность.

    Комментировать
    0 просмотров
    Комментариев нет, будьте первым кто его оставит

    Это интересно
    Adblock detector