К тому времени, когда любой проект разработки ПО близится к завершению, он, скорее всего, пройдет множество тестов, особенно в среде тестирования Agile, где тестирование и разработка происходят одновременно. Но независимо от того, сколько тестов вы выполнили, как только ваше приложение будет почти готово, есть только один способ узнать, сможет ли ваше приложение справиться с реальными требованиями, которые вскоре будут предъявляться к нему вашей армией конечных пользователей — нагрузочное тестирование.
Что такое нагрузочное тестирование?
Нагрузочное тестирование — это создание производственных симуляций в приложении или системе, которые максимально приближены к готовому продукту, готовому к развертыванию и массовому использованию. Используя специализированное ПО для тестирования, нагрузочное тестирование позволяет командам разработчиков ответить на такие вопросы, как «Делает ли моя система то, что я ожидаю, в этих условиях?» и «Достаточно ли хороша его производительность?» Как говорится в руководстве Microsoft «Performance Testing Guidance for Web Applications»:
«Нагрузочный тест позволяет измерить время отклика, пропускную способность и уровни использования ресурсов, а также определить предельную точку вашего приложения, предполагая, что критическая точка возникает ниже условий пиковой нагрузки»
Здесь «ниже условий пиковой нагрузки» просто предлагает методологию тестирования, которая соответствует параметрам нагрузочного теста, в отличие от стресс-теста (который, по определению, тестирует систему при пиковой нагрузке и за ее пределами). Нагрузочное тестирование может выявить задержку системы, проблемы с загрузкой страниц и все остальное, что может пойти не так, когда несколько пользователей обращаются к приложению или бомбардируют систему внезапным трафиком — вещи, которые можно легко упустить из виду в среде разработки и тестирования, где код часто проверяется отдельными пользователями. Однако добавьте сто или тысячу человек, пытающихся получить доступ к программному обеспечению или выполнить команды более или менее одновременно, и проблемы, которые могли быть не обнаружены в индивидуальных случаях использования, могут внезапно проявиться во всей своей глючной красе.
Почему нагрузочное тестирование важно?
Нагрузочное тестирование гарантирует, что ваше приложение будет работать так, как вы ожидаете, когда оно ожидается в рабочей среде. То, что ваше приложение пройдет функциональный тест, еще не означает, что оно сможет работать так же хорошо под нагрузкой. Нагрузочное тестирование определяет, где и когда ваше приложение выходит из строя, поэтому вы можете устранить проблему до отправки в рабочую среду.
Предприятия и потребители в значительной степени полагаются на цифровые приложения для критически важных функций, поэтому важно убедиться, что они могут выдерживать реалистичные сценарии нагрузки. С более широким внедрением цифровых приложений растут ожидания в отношении качества, и если ваше приложение не работает в производственной среде, оно может стать дорогостоящим. По данным Gartner, средняя стоимость простоя сети составляет около 5600 долларов в минуту. В среднем это около 300 000 долларов в час. Очень важно избегать простоев в рабочей среде, а нагрузочное тестирование помогает убедиться, что ваше приложение готово к работе.
Конечной целью инструментов нагрузочного тестирования всегда является снижение рисков - успешная работа приложения, опыт пользователей, доходы компании. Естественно, все три из них тесно переплетены, поэтому важно знать, как они соотносятся друг с другом и где вы, как разработчик или тестировщик, можете вмешаться для общего блага. Осмелимся предположить, что если вы сосредоточитесь на смягчении среднего критерия, опыта пользователя, то два других фактора, как правило, встанут на свои места. Многие проблемы нагрузочного тестирования в конечном итоге сводятся больше к восприятию пользователями, чем к конкретным идеальным временем загрузки страницы и другим техническим характеристикам.
Нагрузочное тестирование против стресс-тестирования
Как наиболее известный и наиболее часто проводимый тип тестирования производительности, нагрузочное тестирование включает применение обычной нагрузки к приложению, чтобы проверить, может ли оно работать должным образом в нормальных условиях. Этот тип связан со своим более крупным и жестоким двоюродным братом, стресс-тестированием. Нагрузочное тестирование гарантирует, что данная функция, программа или система может просто справиться с тем, для чего она предназначена, в то время как стресс-тестирование заключается в перегрузке вещей до тех пор, пока они не сломаются, применении нереалистичных или маловероятных сценариев нагрузки. Обе практики могут сыграть важную роль в точном определении того, насколько хорошо данная часть ПО, такого как веб-сайт, или внутренняя система, такая как сервер Apache, на котором размещен этот сайт, может справляться с фактическими нагрузками, с которыми они могут столкнуться при регулярном использовании. Стресс-тестирование преднамеренно вызывает сбои, чтобы вы могли проанализировать риск, связанный с критическими точками, а затем выбрать настройку программ, чтобы сделать их более изящными.
Стресс-тестирование полезно для подготовки к непредвиденным обстоятельствам и точного определения того, насколько сильно можно надавить на данную систему, исследуя высшие пределы производительности. Но когда дело доходит до простой проверки того, что приложение или сеть могут выдержать запросы и действия пользователя, с которыми они могут столкнуться в обычных обстоятельствах, нагрузочное тестирование является правильным методом для этой задачи.
Как начать нагрузочное тестирование
Начать нагрузочное тестирование не так сложно, как это было раньше. В прошлом для обучения загрузке теста (создания реалистичного сценария, написания сценария теста, воспроизведения теста и анализа результатов теста) требовалось огромное количество навыков и времени. Кроме того, каждый инструмент нагрузочного тестирования отличается. Поэтому изучение того, как использовать каждый инструмент для запуска тестов, чтобы они работали так, как вы хотите, всегда является проблемой.
Вот шаги, которые обеспечат хорошую основу для начала нагрузочного тестирования вашего приложения:
- Сбор требований — какие наиболее важные функции вам нужно протестировать? Что формирует ваш пользовательский опыт?
- Разметка пути пользователя — определите, как ваши пользователи взаимодействуют с вашим приложением. Это отличная возможность использовать данные мониторинга из любых инструментов APM, которые вы можете использовать.
- Определить стандарты — протестируйте приложение, чтобы установить надежный ориентир для тестирования вашего приложения. Каждый раз, когда производительность отклоняется от этого эталона, вы будете знать, что необходимо более глубокое погружение в тестовые данные.
- Автоматизация и Интеграция: сделайте нагрузочное тестирование частью своих процессов CI/CD и интегрируйте его с инструментами, которые вы уже используете.
Лучшие практики нагрузочного тестирования
Создавайте реалистичные сценарии
Думайте, как пользователь. Что важно для вашей пользовательской базы? Какие функции вашего приложения для них критичны? Используют ли они разные устройства? Создавая реалистичные нагрузочные тесты, вы можете лучше понять, как ваше приложение ведет себя или будет вести себя в рабочей среде с реальными пользователями. Реальные пользователи в определенной степени непредсказуемы, поэтому помните о случайности и изменчивости при оценке шагов, которые необходимо предпринять в тестах.
Тестируйте раньше, тестируйте часто
Независимо от того, принимает ли ваша команда Agile, DevOps или другие практики, важно тестировать как можно раньше и тестировать много. Часто тестирование производительности проводится изолированно и начинается после завершения проекта разработки. Однако за последние несколько лет увеличение количества отзывов на протяжении всего жизненного цикла разработки ПО оказалось чрезвычайно полезным для быстрого поиска и устранения проблем. Отдайте приоритет тестированию производительности и, в частности, нагрузочному тестированию, как части гибкой практики непрерывной интеграции и автоматизации.
Установите реалистичные ориентиры
Оптимизация производительности требует глубокого понимания вашего приложения и его пользователей. Определите практические и реалистичные тесты, которые могут отражать реальность, будь то выбор устройств, браузеров, количества пользователей и т. д. Кроме того, нагрузочные тесты не могут начинаться с нуля. В реальном мире маловероятно, что системы, которые вы хотите обновить, уже не будут работать под нагрузкой. Поэтому вместо того, чтобы начинать с нуля и постепенно добавлять виртуальных пользователей, пока не будет достигнута желаемая нагрузка, попробуйте запустить тесты после того, как ваши системы уже находятся под нагрузкой. Таким образом вы избегаете ложноположительных результатов, которые могут возникнуть при запуске нагрузочных тестов с нуля.
Используйте данные из реальной жизни
Чтобы получить реалистичные ориентиры и сценарии, используйте уже имеющиеся данные. Повторное использование данных из ваших инструментов мониторинга может помочь понять, что означает «реалистичный» в вашем конкретном случае. В большинстве случаев инструменты мониторинга работают с упреждающей и реактивной точки зрения. Это означает, что вы можете использовать синтетические и реальные пользовательские данные для отображения сценариев, которые не удалось выполнить в рабочей среде и/или добавить взаимодействия, которые ваши пользователи уже используют. ваше приложение в сценарии тестирования. Это могут быть данные, управляемые пользователем, такие как браузеры, устройства, пути пользователей, точки выгрузки и системные данные, такие как загрузка DOM, время до первого байта и многое другое.
Анализ тестовых данных для выявления основных проблем
После выполнения нагрузочных тестов первым очевидным шагом является выявление любых проблемных областей и принятие следующих оптимальных мер для повышения производительности этого компонента. Это означает сопоставление «заторов» производительности с кодом, чтобы изолировать основную причину проблемы. Часто это может быть сложно, если вы используете традиционные инструменты тестирования, потому что они требуют «преобразования» результатов тестирования в метрики, которыми вы можете поделиться со своей командой разработчиков, чтобы глубже изучить основной код, вызывающий проблему.