Автор: Ким Нап (Kim Knup)
Оригинал статьи
Перевод: Ольга Алифанова

3 года назад я рассказывала о своем опыте тестирования производительности в Songkick, и, честно говоря, я любила эту дисциплину. Она сочетает две моих любимых вещи – поведение пользователей и поведение системы в различных условиях. Было просто потрясающе – включаешь распродажу билетов на артиста и наблюдаешь, как по-разному используют систему разные поклонники. Они отличаются не только используемыми устройствами и браузерами, но и тем, что они делают. Они постоянно обновляют страницу, возвращаются вперед и снова переходят назад. Кому-то достаточно одного билета, а кто-то всегда берет несколько.

Обожаю сочетать данные о поведении реальных пользователей с их действиями и моделировать на этом основании различные тесты производительности.

COVID-19 был прямо-таки создан для того, чтобы я снова об этом задумалась, так как:

1. Я больше не путешествую, поэтому у меня больше времени (правда, я ездила недалеко).
2. Наши пользователи больше пользуются нашей системой из-за различных причин.
3. Я временно сменила команду, что дало мне больше свободного времени на размышления.

В моей команде мы особо не занимаемся тестированием производительности – как минимум, у нас нет реальной стратегии (в течение нескольких недель это была моя задача с ретроспективы – создать такую стратегию). У нас есть внешние команды, умеющие этим заниматься, и их задача – тестировать все системы совместно.

Меня восхищает то, что тестирование производительности позволяет вам забраться приложению под кожу. Вам нужны инструменты мониторинга и аналитики, чтобы посмотреть, что происходит, а затем вы рассматриваете все уровни вашей архитектуры. Я не технарь, поэтому это потрясает меня, и я каждый раз узнаю что-то новое. У меня нет в запасе реальных историй, но я решила описать четыре типа тестирования производительности, с которыми я имела дело и о которых делала доклад в 2017 году.

Типы тестирования производительности

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

Те, о которых я хочу поговорить, перечислены ниже (спасибо Марку Томлинсону за графики).

• Нагрузочное тестирование
• Стресс-тестирование
• Продолжительное тестирование/тестирование выносливости
• Пиковое тестирование

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

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

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

Говоря о создании нагрузки, мы имеем в виду количество пользователей, одновременно пользующихся системой, и поведение транзакций.

Нагрузочное тестирование используется для уточнения и определения:

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

Стресс-тестирование

Цель: постепенно, непрерывно повышать нагрузку на систему, пока она не выдаст ошибку или отказ (например, повышать количество виртуальных пользователей, пока система не упадет).

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

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

Прогоняя стресс-тест, вы можете узнать о:

• Пределах системы
• Том, как именно она отказывает
• Том, насколько адекватна стратегия переключения при отказе.

Можно также выявить:

• Состояния гонки
• Утечки памяти.

Продолжительное тестирование/тестирование выносливости

Цель: имитировать стандартную нагрузку в течение длительного времени, чтобы убедиться, что использование ресурсов остается на том же уровне (дисковое пространство, утечки памяти, условия разгона).

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

Этот подход поможет найти:

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

И теперь самое веселое!

Пиковое тестирование

Цель: измерить способность системы обращаться с кривой экстремального спроса, удерживать высокую нагрузку короткое время, и эффективно восстановить ресурсы после этого всплеска.

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

Пиковое тестирование поможет выявить:

• Проблемы с одновременными транзакциями – условия гонки.
• Как быстро масштабируется приложение.

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

Это те типы тестирования производительности, с которыми я сталкивалась и которые использовала.

Обсудить в форуме