- Виды нагрузочного тестирования
- Методика
- Программные обеспечения
- Ошибки и причины возникновения
- Рекомендации
Привет, меня зовут Андрей Коненко, я девопс-инженер RDN Group.
Наша команда специализируется на разработке сложных и высоконагруженных решений для промышленных компаний: личных кабинетах, торговых площадках, порталах и интеграционных проектах. RDN Group один из 30 партнеров 1С-Битрикс с расширенной компетенцией крупные корпоративные внедрения Enterprise.
Сегодня я хочу поговорить про нагрузочное тестирование, для чего оно нужно, что важно учитывать при проведении тестирования и каким моментам уделить большее внимание.
Тестирование программного обеспечения включает в себя динамическую проверку того, что программа выдержит нагрузку после ряда определенных тестов.
Нагрузочное тестирование — это процедура, которая эмулирует поведение готовой системы под нагрузкой. Во время такого тестирования мы моделируем одновременное использование системы сотнями пользователей или другим расчетным количеством.
Этот тест необходим, чтобы выявить слабые места системы до ее запуска в продакшн, понять все ли хорошо спроектировано, какие возникают проблемы и понять хватает ли нам текущих мощностей оборудования, или что то требует изменений.
Нагрузочное тестирование — это метод проверки работы приложения в условиях максимально приближенных к реальным.
Виды нагрузочного тестирования
Виды нагрузочного тестирования зависят от задачи, нам важно понять нормально ли работает приложение при расчетной нагрузке на него, как восстанавливается после сбоев, как быстро возобновляет свою работу или насколько у системы деградирует производительность.
Выделяется стресс-тестирование— это разновидность нагрузочного тестирования, при котором нагрузка на тестируемую систему целенаправленно наращивается сверх расчетных показателей, чтобы определить предельный уровень нагрузки, при котором система достигает точки отказа.
Цель проведения нагрузочного тестирования- выявить потенциальные возможности приложения. Например, если приложение обслуживает 400 пользователей, но мы не знаем какой у нас максимальный потолок работы системы, и наша цель — выявить его.
Тесты масштабируемости
Если приложение имеет кластерную архитектуру, можно проверять, насколько быстро разворачиваются новые узлы системы при повышении нагрузки.
Тесты на производительность восстановления системы
Тесты на производительность восстановления системы. Другими словами производительность резервного копирования. Отметим, что с таким сталкиваемся редко- обычно такой тест делается, если у компании есть план Disaster Recovery, когда все сломалось и ничего не осталось кроме резервных копий.
Тесты на стабильность
Тесты на стабильность позволяют понять, стабильно ли работает продукт, не падает ли он под нагрузкой в длительном промежутке времени.
Тесты на отказоустойчивость
Тесты на отказоустойчивость проводятся при повышении нагруженных параметров. Под отказоустойчивость мы понимаем работу приложения в “деградированном” состоянии, когда некоторые компоненты при отказоустойчивой архитектуре искусственно выключаются, чтобы понять, как наше приложение
Тесты обмена
Тесты обмена совместимы с другими системами. Например, интернет-магазин и учетная система. Мы проверяем работоспособность при резком увеличении заказов и так далее.
Методика нагрузочного тестирования
Просто так тестировать ничего нельзя. Необходимо провести ряд мероприятий.
Для начала мы определяем метод тестирования, то есть целевые показатели приложения: отзывчивость приложения, количество документов, которые обрабатываются в единицу времени, скорость ответа сервера, скорость проведения транзакции. Необходимо установить важные для нас показатели. Например, для CRM-системы — это отзывчивость, то есть время ответа сервера.
Далее мы выделяем ключевые операции. Нам важно, чтобы регистрация пользователей тестировалась, как и логин системы, просмотр сложных высоконагруженных страниц. Мы определяем эти и другие операции и устанавливаем критерии выполнения по времени.
После чего мы обращаемся к шаблонам функционального тестирования. Когда мы понимаем, какую последовательность операций может выполнить пользователь. необходимо выбрать ПО (например, Apache JMeter) и обучить его проходить по страницам пользователя, авторизоваться, делать определенные вещи, которые важны для нашей системы.
Это и есть определенная методика тестирования — последовательность действий.
Мы описываем последовательность действий, ключевые операции, а потом уже обучаем наше ПО. В методике тестирования отражается, что есть для нас удовлетворительно, что нет.
В недавнем проекте клиент предпочел использовать методику оценки результатов тестирования, то есть APDEX- методика. Она отражает комфорт пользователя и зависит от времени работы/отдыха сервера.
Методика разрабатывается, отталкиваясь от технического задания. Следует предусмотреть, как мы будем тестировать. Часто в методике клиент отражает, какую отчетность и в каком формате он хочет видеть по результатам нагрузочного тестирования.
Нагрузочное тестирование продукта проводится на завершающем этапе его разработки, когда уже готова вся функциональность и фактически можно запускать продукт для пользователей. Это позволяет понять удовлетворяет ли разработанный продукт нашим требованиям, пока не поздно внести необходимые исправления.
Программные обеспечения для нагрузочного тестирования
Следует понимать, что когда мы говорим про нагрузочное тестирование, мы говорим про веб-приложение, в первую очередь.
Программное обеспечение фактически заходит на страницу, как пользователь, и делает определенные запросы. Таких программ существует множество.
Одним из самых простых эмуляторов нагрузки являются утилиты Apache Benchmark, Яндекс Танк, Load Minter и Web Load.
Часто компании предпочитают использовать Яндекс Танк, поскольку он обладает широкими возможностями сбора различных метрик производительности, может тестировать немного лучше чем другие. У Яндекс Танка высокий порог вхождения.
Я отдаю свое предпочтение Apache JMeter, поскольку это открытое программное обеспечение с достаточно широкими возможностями. Его плюсы- удобство и расширяемость, минусы- ограничение использования памяти.
Многие предпочитают Gatling, но на мой взгляд это более нишевый инструмент.
Каждый инструмент требует определенных навыков для работы — это подходит как для малых, так и крупных компаний, являясь своеобразным “швейцарским ножом”.
Ошибки и причины возникновения
При нагрузочном тестировании ошибки практически исключены. Однако появляются ошибки от неправильной интерпретации требований заказчика, и когда мы не умеем пользоваться инструментом.
Например, мы тестировали кластерное приложение и следует понимать, что устройство, на котором находится ПО называется стрессором. Этот сервер может генерировать огромный поток трафика на сети клиента, отправляя большое количество запросов, для многих провайдеров систем DoS-защиты.
Это может показаться неправильным и некрасивым, эти системы реагируют и блокируют любой трафик с этого сервера, и наш тест на этом прекращается.
Необходимо учитывать, что генерацию нагрузки нужно согласовывать, чтобы наш генератор нагрузки находился у всех возможных защит в белом списке.
Второй момент — ошибка при непосредственном тестировании из-за неполных данных от клиента.
Например, мы запускали тест только с одного генератора нагрузки, и нагрузка упала только на один узел кластера. Оказалось, что у клиента кластер, но он не сказал об этом, и нагрузка упала только на один узел.
При разборе полетов выяснилось, что нагрузка распределялась на разные узлы в зависимости от IP- адреса. Это делалось для того, чтобы не возникало ошибок. Если запрос приходит с одного и того же IP-адреса, то считается одним и тем же клиентом, и мы кладем его на один и тот же узел кластера, чтобы не было проблем и сложностей. При проектировании кластера нужно учитывать миграции сессий пользователей между его узлами и некоторые виды кэширования.
При нагрузке в основном возникают ошибки отказа в доступе. Многие видели, что при заходе на сайт возникают ошибки 500, 502, 504, 403 или потеря соединения.
Ошибка 403 — отказ в доступе. Потеря соединения при тотальной нагрузке, либо срабатывает определенный вид защиты.
Ошибка 500 — сложно интерпретируется, трактуется неизвестной ошибкой сервера. Может быть ошибка в самом приложении или ошибка в настройке клиентского оборудования. Приложению не удается обработать запросы правильно, и ошибка отлавливается намного раньше нагрузочного тестирования, потому что оно запускается на тех эндпоинтах, то есть на конечных точках приложения, которые заранее известны, что будут тестироваться, и заранее проверяются еще и вручную.
Ошибка 502, 504 — различные таймауты при перезагрузке приложения. Она может быть вызвана тем, что разработчики не рассчитали оборудование, не внесли корректные настройки в СУБД, в веб-сервер. Приложение работает не оптимальным образом, например, используют слишком мало оперативной памяти при ее наличии или наоборот оперативной памяти серверу не хватает, но настройками можем заставить ПО использовать меньше памяти, либо просто мощности сервера не хватает.
Есть два варианта развития событий:
- Все нормально. Мы смотрели, когда наше приложение сломается, оно справилось с расчетными нагрузками, все прошло корректно. После чего мы провели стресс тестирование, и приложение упало.
- Некорректные настройки сервера. Анализируются логи, проблемы и по каждой делается вывод и вносятся изменения или меняется архитектура приложения.
Все ошибки, которые возникают, как правило ожидаемы, и тестирование проводится для их выявления.
Исходя их опыта работы с клиентами, выделю еще одну причину тестирования, которая применяется к системам, разрабатываем постоянно. Обычно это очень большие системы, в них вносятся изменения постоянно. Например, с появлением новых аспектов в законодательстве, улучшением систем защиты или просто с внедрением нового функционала.
При релизе обновления до новой версии проводится нагрузочное тестирование, как правило стабильности или стресс тестирования, чтобы проверить, а не случилось ли в приложении регрессий, не стало ли хуже, тогда проводится на постоянной основе.
Что я могу порекомендовать при проведении нагрузочного тестирования
При проведении тестирования важно:
- Выбрать инструмент тестирования, с которым вы умеете работать.
- Постараться максимально точно учесть граничные точки.
- Нужно понять максимально точно, что хочет заказчик.
- Не пренебрегать сложностями и создавать генерацию нагрузки с нескольких узлов. Иногда бывает такое, что один узел не справляется.
Вывод
Нагрузочное тестирование необходимо проводить для обеспечения стабильной работы программного обеспечения. Оно позволяет выявить проблемы и узкие места в системе и обеспечить высокое качество конечного продукта.
Во время проведения нагрузочного тестирования необходимо учитывать особенности разрабатываемой системы, следовать ТЗ, чтобы выстроить архитектуру приложения и настроить нагрузку. Оно помогает избежать непредвиденных проблем, избежать возможной потери данных и улучшить UX, повысить эффективность работы приложения.
