Всем привет! Это вторая часть серии статей о нагрузочном тестировании. Если вы еще не читали первую часть — там мы разбирались, как правильно думать о тестировании производительности и чем оно принципиально отличается от функционального тестирования, — рекомендую начать с нее. В этой части поговорим о том, для чего вообще нужно тестирование производительности, — разберем сценарии, общие для любых систем (рост числа пользователей, длительная работа, рост объема данных, изменение архитектуры и бизнес-процессов), а также рассмотрим специфику на конкретных примерах 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 и банковских приложений.
В следующей, третьей части поговорим о самых распространенных мифах о нагрузочном тестировании и разберем ошибки, которые встречаются в проектах слишком часто. Подписывайтесь, чтобы не пропустить!
