Как провести нагрузочное тестирование правильно. Часть 1: как думать о тестировании производительности

Всем привет! Меня зовут Алексей Тиньков, я занимаюсь тестированием производительности уже 8 лет, в настоящее время я занимаюсь развитием практик тестирования производительности информационных систем в Лемана Тех. и хочу поделиться своим опытом через обучающие статьи о процессе нагрузочного тестирования (НТ), его организации, полезных практиках, типичных заблуждениях и ошибках, которых следует избегать при формировании процесса в своей компании. 

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

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

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

Итак, кому будет полезна эта серия статей?

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

• Ручным или автоматизированным тестировщикам, желающим или столкнувшимся с необходимостью освоить нагрузочное тестирование.

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

Что будет включать в себя серия статей?

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

В рамках этой серии мы поговорим на следующие темы:

• Когда и зачем нужно НТ, с чего начать процесс, главные мифы и распространенные ошибки;

• Процесс НТ от и до: место в SDLC, роли, этапы;

• Постановка целей: SLA/SLO, сбор требований, профиль нагрузки;

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

• Модель нагрузки: как построить реалистичный профиль и оформить его понятно для всех;

• Подготовка данных и окружения;

• Инструментарий и практические примеры скриптов;

• Мониторинг и наблюдаемость: что собирать и зачем;

• Анализ результатов и поиск узких мест;

• Отчетность: как писать выводы, понятные бизнесу и разработке;

• НТ в CI/CD: автоматизация и перформанс-гейты.

P. S. Сразу оговорюсь: я не считаю правильным отождествлять тестирование производительности как совокупность мер по проверке системы и нагрузочное тестирование, которое в моем представлении является лишь частью тестирования производительности. Но поскольку так сложилось, что под нагрузочным тестированием стали понимать тестирование производительности в целом, далее по тексту вы можете встретить термин «нагрузочное тестирование» вне контекста конкретного вида тестов, как обозначение процесса в целом.

Мыслим о тестировании производительности правильно

Ключевые отличия тестирования производительности от ручного и автоматизированного функционального тестирования

Корректное соблюдение функциональных требований в тестировании производительности — важное условие, но не цель проверки. Тестирование производительности отвечает не на вопрос «правильно ли работает функционал системы?», а на вопрос «как долго система способна сохранять работоспособность и соответствовать требованиям производительности?».

Тест производительности — это непрерывная работа под давлением в течение некоторого количества времени, и перед инженером стоит вопрос не «отработал ли функционал корректно?», а «когда система начнет деградировать?». При этом характер деградации может проявляться по-разному: рост latency на 95-м перцентиле, исчерпание пула соединений к базе данных, утечка памяти, накапливающаяся часами, и т. д.

Одной системной учетной записи, как правило, недостаточно

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

Тест должен учитывать модель поведения пользователя

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

В тестировании производительности все иначе. Время перехода к следующему шагу должно учитывать время размышления пользователя (think time), но сам шаг, если не предусмотрено иного (например, ожидание результата длительных синхронных операций), не дожидается готовности системы. Вместо этого он проверяет, успела ли система отреагировать на действия пользователя в установленные требованиями сроки, после того как пользователь совершил действия с присущей ему скоростью. При этом каждый шаг не блокируется бесконечно в ожидании ответа: задается явный response timeout, позволяющий четко разграничить «медленный ответ» и «ответ отсутствует».

Тренды вместо проверок корректности

Для примера возьмем абстрактный тест-кейс синхронного взаимодействия с backend тестируемой системы через REST API. Для функционального тестирования достаточно получить код ответа и его тело, чтобы оценить корректность выполнения запроса, то есть мы оцениваем реакцию системы между двумя бинарными состояниями: «корректно» или «некорректно». В тестировании производительности важно не только получить код и тело ответа, но и ответить на ряд вопросов.

• С какого момента система стала отвечать некорректно?

• Как меняется реакция системы на запросы с течением времени?

• Является ли это поведение реакцией на нагрузку или причина в функциональных ошибках? И как при этом коррелируют рост error rate и latency с утилизацией системных ресурсов компонентов системы?

• Воспроизводимо ли обнаруженное поведение при сохраняющихся условиях теста?

• Какие системные показатели мы наблюдаем на мониторинге ресурсов в момент возникновения ошибок?

Системные метрики — главный индикатор тестирования производительности

Если функциональный тест «говорит» языком assert’ов («ожидалось X, получено Y»), то нагрузочный тест говорит языком распределений и трендов: percentile latency (p50, p95, p99), throughput (RPS/TPS), error rate, saturation системных ресурсов. Именно эти показатели позволяют формулировать выводы о поведении системы под нагрузкой и сравнивать результаты между запусками вне зависимости от того, упал ли конкретный запрос с ошибкой.

На этом первая часть завершается. Мы разобрались, чем тестирование производительности принципиально отличается от привычного функционального тестирования, и почему в нем мышление «шаг за шагом» уступает место мышлению трендами и деградацией.

В следующей части поговорим о том, для чего вообще нужно тестирование производительности и каким системам оно необходимо в первую очередь — разберем это на конкретных примерах e-commerce и банковских приложений. Подписывайтесь, чтобы не пропустить!