Тестирование производительности (Performance testing)

Тестирование производительности - это нефункциональный вид тестирования программного обеспечения, используемый для проверки скорости, времени отклика, стабильности, надежности, масштабируемости и использования ресурсов программного приложения при определенной рабочей нагрузке, обычно регрессионным образом, когда в приложение ежедневно или еженедельно вносятся небольшие изменения. Основная цель тестирования производительности - выявить и устранить узкие места производительности в программном приложении. Это подмножество performance engineering, также известное как «Perf Testing». Само по себе оно не призвано находить дефекты, но оно помогает в обнаружении узких мест в системе.

Обычно продолжительность теста производительности составляет 1 час (устойчивое состояние) на средней / ожидаемой нагрузке; это может варьироваться в зависимости от вашего SLA / требований.

Примечание 1: все подвиды тестирования производительности отличаются, грубо говоря, только параметрами (тип возрастания нагрузки, ее количество, длительность и т.п.) и собираемыми метриками (без которых это тестирование бессмысленно). Точкой отсчета для всех подвидов принято брать результаты Capacity testing.

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

Общие проблемы с производительностью.

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

  • Длительное время загрузки - обычно время загрузки - это начальное время, необходимое приложению для запуска. Обычно оно должно быть сведено к минимуму. Хотя некоторые приложения невозможно загрузить менее чем за минуту, время загрузки должно быть меньше нескольких секунд, если это возможно;

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

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

  • Узкие места (Bottlenecking)- это препятствия в системе, которые ухудшают общую производительность системы. Узкое место - это либо ошибки в коде, либо проблемы с оборудованием, которые вызывают снижение пропускной способности при определенных нагрузках. Узкие места обычно устраняются путем исправления плохо работающих процессов или добавления дополнительного оборудования. Некоторые общие узкие места производительности:

    • Загрузка ЦП;

    • Использование памяти;

    • Использование сети;

    • Ограничения операционной системы;

    • Использование диска;

Как проводить тестирование производительности?

  • Определите необходимую среду тестирования (testing environment): перед тем, как начать процесс тестирования, изучите детали аппаратного, программного обеспечения и сетевых конфигураций, используемых во время тестирования. Это поможет тестировщикам создавать более эффективные тесты. Это также поможет определить возможные проблемы, с которыми тестировщики могут столкнуться во время процедур тестирования производительности;

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

  • Планирование и проектирование тестов производительности: Определите, как использование может варьироваться среди конечных пользователей, и определите ключевые сценарии для тестирования всех возможных вариантов использования. Необходимо смоделировать различных конечных пользователей, спланировать данные тестирования производительности и наметить, какие метрики будут собраны;

  • Настройка тестовой среды: Подготовьте тестовую среду перед выполнением. Также подготовьте инструменты и другие ресурсы;

  • Имплементирование тест-дизайна: Создайте тесты производительности в соответствии с вашим тест-дизайном;

  • Запуск тестов: Выполнить и промониторить тесты;

  • Анализ, настройка и повторное тестирование: объединяйте, анализируйте и делитесь результатами тестирования. Затем выполните точную настройку и снова проверьте, есть ли улучшение или снижение производительности. Поскольку улучшения обычно становятся меньше с каждым повторным тестом, остановитесь, когда узкое место вызвано ЦП. Тогда вы можете рассмотреть вариант увеличения мощности процессора.

Метрики тестирования производительности (Performance Testing Metrics):

  • Использование процессора (Processor Usage): время, затрачиваемое процессором на выполнение non-idle потоков;

  • Использование памяти (Memory use): объем физической памяти, доступной процессам на компьютере;

  • Время диска (Disk time): время, в течение которого диск занят выполнением запроса на чтение или запись;

  • Время отклика (Response time): время с момента ввода пользователем запроса до получения первого символа ответа. Подробнее: раз, два;

  • Задержка (Latency): временной интервал между запросом и ответом;

  • Пропускная способность (Throughput): фактическое количество запросов (или пользователей), которое может обработать система за определенное время. В то время как время задержки говорит вам только о времени, метрика пропускной способности информирует об объеме данных, полученных и обработанных в момент времени. Важно не отделять показатели времени задержки от пропускной способности, т.к. высокий показатель времени задержки часто прямо связан с увеличением показателей метрики пропускной способности. Пропускная способность обычно измеряется в rps - (кол-во) запросов в секунду (requests per second).

  • Ширина пропускания канала (Bandwidth): максимальное число запросов (или пользователей), которое может обработать система. В отличие от пропускной способности ширина пропускания канала измеряет максимальный объем, который может обработать приложение.

  • Частные байты (Private bytes): количество байтов, выделенных процессом, которые не могут использоваться другими процессами. Они используются для измерения утечек и использования памяти;

  • Выделенная память (Committed memory) - объем используемой виртуальной памяти;

  • Страниц памяти в секунду (Memory pages/second) - количество страниц, записываемых на диск или считываемых с диска для устранения аппаратных ошибок страниц. Сбои аппаратной страницы - это когда код не из текущего рабочего набора вызывается из другого места и извлекается с диска;

  • Ошибок страниц в секунду (Page faults/second) - общая скорость, с которой страницы ошибок обрабатываются процессором. Это происходит, когда процессу требуется код из-за пределов своего рабочего набора;

  • Число прерываний процессора в секунду (CPU interrupts per second): это среднее количество аппаратных прерываний, которые процессор принимает и обрабатывает каждую секунду;

  • Длина дисковой очереди (Disk queue length): среднее количество запросов на чтение и запись, поставленных в очередь для выбранного диска в течение интервала выборки;

  • Длина сетевой выходной очереди (Network output queue length): длина очереди выходных пакетов в пакетах. Значение больше двух означает, что необходимо убрать задержку и возникновение узких мест;

  • Всего сетевых байтов в секунду (Network bytes total per second): скорость, с которой байты отправляются и принимаются интерфейсом, включая символы кадрирования;

  • Количество пулов соединений (Amount of connection pooling): количество запросов пользователей, которые удовлетворяются объединенными соединениями. Чем больше запросов будет выполнено подключениями в пуле, тем выше будет производительность;

  • Максимальное количество активных сессий (Maximum active sessions): максимальное количество сессий, которые могут быть активны одновременно;

  • Коэффициент хитов (Hit ratios): это связано с количеством операторов SQL, которые обрабатываются кэшированными данными вместо дорогостоящих операций ввода-вывода. Это хорошее начало для решения проблем, связанных с узкими местами;

  • Хитов в секунду (Hits per second): количество хитов веб-сервера в течение каждой секунды нагрузочного теста;

  • Сегмент отката (Rollback segment): объем данных, который можно откатить в любой момент времени;

  • Блокировки баз данных (Database locks) - блокировки таблиц и баз данных необходимо отслеживать и тщательно настраивать;

  • Максимальное время ожидания (Top waits) - отслеживаются, чтобы определить, какое время ожидания можно сократить при работе с тем, насколько быстро данные извлекаются из памяти;

  • Количество потоков (Thread counts): состояние приложения можно измерить по количеству потоков, которые работают и в настоящее время активны;

  • Сборка мусора (Garbage collection): это связано с возвратом неиспользуемой памяти обратно в систему. Сборку мусора необходимо отслеживать на предмет эффективности;

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

Тестирование производительности клиентской части и серверной, в чем разница?

Оценка скорости работы клиентской и серверной частей веб-приложения осуществляется двумя разными видами тестирования: для Frontend применяется тестирование клиентской части, или Client-Side testing, а для Back-end - тестирование серверной части.

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

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

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

Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.

Тестирование серверной части направлено на анализ выполнения запросов и получения соответствующего ответа от Back-end.

Цели данного вида тестирования:

  • Измерить время отклика самых важных бизнес-транзакций;

  • Определить предельный уровень допустимой нагрузки;

  • Выявить «узкие» места в производительности системы;

  • Составить рекомендации по улучшению производительности;

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

Примеры проверок:

  • Время отклика не превышает 4 секунды при одновременном доступе к сайту 1000 пользователей;

  • Время отклика приложения под нагрузкой находится в допустимом диапазоне при медленном сетевом подключении;

  • Проверьте максимальное количество пользователей, с которыми приложение может справиться, прежде чем оно выйдет из строя;

  • Проверить время выполнения базы данных при одновременном чтении / записи 500 записей;

  • Проверьте использование ЦП и памяти приложением и сервером базы данных в условиях пиковой нагрузки;

  • Проверьте время отклика приложения в условиях низкой, нормальной, средней и высокой нагрузки;

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

Источники:

Доп. материал:

PreviousНефункциональное тестирование (Non-Functional testing)NextТестирование емкости (Capacity testing)

Last updated