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

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

Для чего нужно тестирование производительности?

Нагрузочное тестирование (load testing) по определению — это метод проверки работы программного обеспечения под ожидаемой или пиковой нагрузкой для оценки производительности, стабильности и масштабируемости системы.
Но для чего оно нужно?

Тестирование производительности, или нагрузочное тестирование, позволяет ответить на вопрос: «Что будет с системой, когда с ней начнут работать реальные потребители?»

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

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

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

Независимо от специфики

Неважно, к какому домену можно отнести вашу систему. Как правило, тестирование производительности должно определить, как система справляется со своими задачами при указанных ниже сценариях эксплуатации.

Рост числа пользователей системы

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

Длительная непрерывная работа системы

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

Рост объема обрабатываемых данных

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

Изменение архитектуры системы

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

Изменение обрабатываемых бизнес-процессов

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

Capacity Planning

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

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

Е-commerce-системы

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

Что важно проверить при работе с e-commerce-системами?

Способность системы работать под пиковыми нагрузками

Например, во время распродажи и других high-season-событий.

Поиск и фильтрация

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

Оформление заказов, работа корзины и другие сценарии работы системы

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

Банковские приложения

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

Утренние пики

В будни период с 9:00 до 11:00, как правило, является пиковым для банковских систем по операциям авторизации и входа в приложение банковскими работниками. Тестирование производительности позволяет убедиться, что операторы системы не испытывают трудностей с авторизацией в системе и могут беспрепятственно выполнять свои рабочие задачи.

День зарплаты

В дни выплаты заработной платы зарплатным клиентам банка от предприятий (чаще всего это происходит 1 и 15, 5 и 20, 10 и 25 числа месяца) банковская система должна обеспечить гарантированную доставку перевода в установленные платежным агентом сроки. Проблемы с работой переводов могут приводить к юридическим последствиям и негативному опыту участников деловых взаимоотношений, что чревато репутационными и материальными потерями.

Регуляторные требования

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

Конкурентное обновление счетов

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

Интеграции с внешними системами

Тестирование производительности — это не только диагностика текущих проблем, но и инструмент стратегического планирования. Банковские системы взаимодействуют с SWIFT, АБС, бюро кредитных историй. Тестирование производительности позволяет определить характер поведения системы при возникновении недоступности или деградации быстродействия внешних систем. Необходимо убедиться, что проблемы на стороне внешних систем не приводят к деградации производительности или недоступности тестируемой системы.

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

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