О Нагрузочном Тестирование

Курс молодого бойца НТ

Данная статья написана с целью просвещения, формирования абстрактной и первичной картины о НТ

После этапов аналитики и разработки, начинается этап тестирования продукта. Один из таких подэтапов в тестировании продукта – Нагрузочное Тестирование (НТ).

Если мы будем говорить о производительности системы, то нам понадобится такое понятие как tps (transaction per second), транзакция в секунду. Т.е. например если начать раз в секунду нажимать на этой странице F5, то конкретно этим действием будет создана нагрузка в 1 запрос в секунду, т.е. 1 tps. Если попросить друга делать тоже самое то это уже 2 tps. Поздравляю, вы только, что провели тестирование производительности системы на 2 tps. Встречается также понятие bps. bps – это бизнес операция в секунду. В одну бизнес операцию может входить несколько транзакций. Но это уже детали.

Итак, производительность системы замеряется в способности обработать определенное количество операций за единицу времени и при условии, что времена отклика системы, % ошибочных транзакций и утилизация аппаратных ресурсов (CPU, RAM, HDD и т.д) находятся в пределах нормы нефункциональных требований к системе.

Но сперва немного про другое. НТ начинается с осознания того, что оно необходимо. Откуда приходит это осознание? Система масштабируется, т.е. растет, а значит растет и трафик, т.е. количество запросов в секунду. Пользователи сегодня не любят ждать, практически у каждого человека есть доступ в интернет и каждый из них хочет быстрого и стабильного ответа на свой запрос. Вместе с запросами растут объемы данных и необходимость предоставить пользователям постоянный доступ к сервису, максимальную отказоустойчивость, сохранность данных при сбоях и быстрое восстановление системы. И как только это будет достигнуто понадобятся новые сервисы, новые пользователи, новые мощности. Глобальная цифровизация.

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

Какие задачи решает НТ?

Выявление дефектов производительности

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

Отказоустойчивость системы

Подбор оптимальных настроек и конфигураций системы

Прогнозирование показателей системы при масштабируемости

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

Требования к НТ

Объект тестирования
Первое с чем нужно разобраться. Что мы тестируем? Тут вариантов тысячи и в каждом из них я бы советовал есть слона по частям, т.е. заняться декомпозицией. Для начала просто нарисовать схему стенда и межсервисного взаимодействия. Хорошо если такая схема есть в аналитике, но как показывает практика лучше самому разобраться и нарисовать свою.
Стенд НТ
Он может быть или ещё не быть. Чем ближе характеристики стенда к ПРОМу (промышленная эксплуатация), тем лучше. Вот только в плане конфигураций железа, а не данных. На тестовых стендах используются тестовые данные. т.е данные, которые прошли процедуры обезличивания и обработки до состояния тестовых данных.
План НТ
главное, что всех объединяет. Обычно основывается на методике нагрузочного тестирования (МНТ), если не знаешь, что это, спроси у старшего товарища. Если не знает и старший товарищ, то возможно у нас проблемы. В плане прописывается, все, что необходимо для НТ. Во-первых, это памятка и пошаговая инструкция на случай амнезии или если сотрудника собьет грузовик. Во-вторых, договор между НТ и стороной, которая принимает отчет. Штука сугубо индивидуальная, но для примера вот пункты:

Объект тестирования
т.е. то о чем говорил выше, своё понимание и схему прикладываем в план, чтобы договориться (понять, что сам всё понял правильно и остальные понимают как и ты) о том, что же мы тестируем.
1
Конфигурации стенда НТ
Описание стенда, что за железо, конфигурации и ПО. Если требуется, то сравнение стенда НТ и ПРОМ.
2
Список тестов
- Какие тесты будут проходить,
- Какие цели преследует проведение каждого теста
- Как конкретно тест будет проходить
- На что следует обратить внимание, критерии успешности и не успешности
3
Профиль нагрузки
Какую нагрузку и куда подаем. Тестируемая система может быть как уже в ПРОМе, так и еще нет. Если еще нет, то предоставляется аналитический бизнес прогноз, что по данному сервису планируется в ПРОМе, т.е. исполнение таких запросов с такой-то интенсивностью. Если сервис уже в ПРОМе, то хотелось бы сказать, что аналитики предоставляют данные для НТ, но это не везде и не всегда так. Слухи подсказывают, что бывает по-разному. Если не повезло с аналитиками, то:
1. Запрашиваем статистику за максимально долгий период (год).
2. Изучаем почасовую статистику, т.е. сколько и каких операций выполнялось каждый час в течение года.
3. Находим пиковый день, в нем пиковый час (когда больше всего выполнялось операций).
4. Из того, что получилось берем 70-80% наиболее интенсивных операций.
Обычно к поступившим требованиям добавляется для НТ ещё + 15-20%, но например, в моих проектах сразу пишутся требования с плюсом для НТ. Чтобы было удобно и читабельно я использую для каждого вида нагрузки отдельную таблицу. Для удобства в таблицу с рестовыми сервисами добавляю столбец времен ответов. Чтобы сразу человек видел, что по сервису такому-то, даем столько тпс и ожидаем, что времена ответов будут не более стольких.
PS: Как сказал один мудрец НТ: «Пиши отчет так, будто читать его будет ребенок и надо, чтобы он всё понял».
4
Подготовка к тестированию
Что требуется дополнительно, т.е. кроме самой поставки, сделать для проведения валидного НТ.
1. Заполненность таблиц определенным количеством и\или качеством данных.
2. Заглушки, т.е. то, что эмулирует взаимодействие с системой, которая не относится к тестируемому сервису, но взаимодействие с ней необходимо для проведения НТ. Например, на каком-то этапе наш сервис запрашивает у сторонней системы какие-то данные. Возможности интеграции нет или же принято решение, что это не является важным для проведения НТ. Тогда пишется сервис, который получает запрос и осуществляет ответ, аналогичный ответу смежной системы, или же не такой же, но тот, который удовлетворяет критериям НТ. Кроме самого тела ответа эмулируется и время задержки ответа.
3. Пулы данных для скриптов нагрузки. Поскольку мы создаем запросы к тестируемому сервису, которые должны быть, как можно больше приближены к реальным пользовательским запросам, то используются пулы данных. Какие-то данные генерируются, а какие-то должны соответствовать данным, которыми оперирует сервис, например данным хранящимся на БД. Поэтому собирается ТЗ на генерацию данных и прописывается в этом пункте или же в случае сложных генераций добавляется приложением к плану НТ.
5

Конечно же, можно не писать никаких планов НТ. И так на встречах обсуждается всё это и мусолится постоянно. Можно, конечно, я иногда так делал. Но поверьте, вы никогда не забудете это чувство, когда сдаете отчет и тут начинаются вопросы, которых вы точно не ожидали. «Почему данные такие кривые?», «Почему тут какие-то заглушки, когда нужна интеграция?», «Почему мягкое не теплое, когда нужно было круглое?». С последним, я наверное, перегнул, но иногда мне кажется, некоторые спрашивают именно это.

И дело таких поворотов не всегда в невнимательности, забывчивости или искажениях восприятия. Иногда дело в том, что что-то пошло не так, профакапили все сроки или упали в ПРОМе. В общем, вдруг, надо объяснить то, что объяснять не хочется и как-то так, чтобы точно не подумали, что дело в нас. И тут всегда есть куда переложить ответственность, например, на команду НТ. «С нашим сервисом, всё в порядке, это всё ваша заглушка», «Это всё рандом ваш не рандомит» – это топчик моих любимых фраз, которые я часто слышу. Чтобы не возникало даже желания так делать, прописывается план НТ. А вторым шагом, в общей переписке, в почте, обсуждается план НТ с лицами причастными и ответственными за приём (валидацию, согласование) отчета НТ. После обсуждения обязательно получить от них согласование плана НТ.

Как говорится: «Лучше знать и не применять, чем не применять по незнанию».

Мониторинг
Все должно мониториться. Мониторинг это процесс сбора, агрегации и визуализации информации, по сути это инструмент добычи информации, которая и является основой для заключения по отчету НТ. Как настроен мониторинг, таков и результат НТ. Если процесс НТ только налаживается, то нужно понять, что необходимо видеть тестируемому для проведения НТ, что и как именно хочет видеть принимающая сторона. После зафиксировать в МНТ. МНТ на мой взгляд это как конституция, массивный большой документ о нормах , правилах и культуре проведения НТ, который согласован с стороной принимающей результаты НТ. План НТ это же локальный акт, который ссылается на МНТ, дополняет и разъясняет определенные нюансы в конкретном тестирование.
Тесты
Что касается тестов, их можно разделить на две основные категории:
1. Деструктивное тестирование – когда воспроизводится сценарий оказывающий негативное воздействие на объект тестирования. т.е. тест умышленно и подконтрольно подразумевающий сбой и дестабилизацию системы.
2. Регрессионное тестирование – преследует в основном две цели:
- проверить, что привнесенные изменения не повлияли на функционал который не менялся.
- проверка функционирования системы в течение продолжительного времени.
Все тесты соответственно будут выполняться под нагрузкой.

Про регресс особо сказать нечего, обычно это 12 – 24 ч., везде немного, по разному. Всё, что мы настроили должно не развалиться на дистанции и не показать тенденций и признаков деградации системы. Обычно, самое явное, что тут можно найти это утечки памяти или тенденции стремления к ним.

Деградация системы - это:
- изменение времен отклика сервиса
- увеличение % ошибок транзакций
- повышение утилизации аппаратных ресурсов(CPU, RAM, HDD и т.д)
В каждой системе уровень допустимой деградации свой.

С деструктами всё намного интересней. Начнем с тестов отказов. Тут следует взять схему объекта тестирования, которую нарисовали и понеслось.
- Если стенд в 2N резерве, отлично, не просто так, значит отказ до 1N.
- CRUD? БД обязательно откажет.
- МКУ? О, да, они любят падать.
- Кафка? Обязательно надо отключить.
В общем, делим слона на кусочки и начинаем есть. Конечно же походы в сторонние системы, заменяем на заглушки, роняем их и заставляем оооооочень медленно отвечать. Но во всём должно быть семя рациональности. И помним закон Мёрфи: «Если, что-то может произойти, то оно обязательно когда-нибудь произойдет».
Если для сервиса это первый раз, то ломать надо полностью. Все остальные разы, если доработка не привнесла изменений в эту область, то можно это не трогать. Например, доработка влияет только на CRUD, который кладет в кафку сообщение, которое вычитывает другой приклад, что-то там делает и кладёт в другую кафку. У нас есть в зоне риска доработки взаимодействие круда с БД и с кафкой. Всё остальное ломать деструктами не нужно, если нет явной необходимости или острого желания на то лиц принимающих решение о НТ.

Еще один вид деструкта о котором можно говорить отдельно это «поиск максимума» или «поиск максимальной производительности». Т.е. мы берем какую-то нагрузку, которую точно система держит, например 25% от профиля нагрузки. Выходим на оптимальные показатели и далее ступенями постепенно начинаем повышать нагрузку. Ступень обычно 15 – 30%. Эталонная длительность ступени час, но обычно на деле 15-30 минут. Всё зависит от хорошего понимания тестируемой системы, и опыт сын ошибок трудных.

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

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

У меня всегда есть мысль в голове, точнее принцип, вот когда ляжет ПРОМ и деньги потекут рекой, но не к нам, а от нас. Тогда будет заведен инцидент, комиссия, расследование. Обязательно откроют отчет и будут детально изучать. Не приведет ли этот отчет в ходе следственных мероприятий ко мне? Шучу, конечно же, такое вряд ли случится, но мне кажется мысль эта хорошая для самодисциплины. На практике были случаи, когда отчет НТ явно давал понять, что в данном случае к команде НТ вопросов нет.

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

Это всё, что хотелось бы изложить в рамках КМБ для НТ. Но, чтобы с этим всем разобраться и разложить по полочкам нужна практика и только практика. Присоединяйся к интеграции.