- Поддержка протоколов
- Возможности интеграции в CI/CD
- Интеграция с инструментами метрик
- Cloud readiness
- Масштабируемость
- Легкость освоения
- Возможности анализа и репорты
- Open source vs Enterprise
- Возможности коллаборации
- Поддержка и комьюнити
- Итоговая таблица
«Современная платформа должна включать в себя возможности, охватывающие много взаимосвязанных критериев. Мы проиллюстрируем те из них, которые, по нашему мнению, должны быть приоритетными. Сразу оговоримся, что подобных инструментов намного больше (десятки) и возможно по каким-то параметрам среди них есть выдающиеся. Мы просто выбрали инструменты, которые наиболее часто используем при тестировании сервисов наших корпоративных клиентов.
Поддержка протоколов
В зависимости от протоколов, которые будут тестироваться (например, HTTP, SAP, GUI, Citrix и т. д.), на рынке доступны различные варианты инструментов. Некоторые из них больше ориентированы на обычный HTTP/S, в то время как другие поддерживают более специфические протоколы, такие как SAP.
Протокол HTTP/S является наиболее распространенным и поддерживается большинством инструментов и платформ. Что действительно имеет значение, это способность платформы поддерживать и автоматизировать создание сценариев тестирования протоколов. Создание сценариев, ориентированных на протокол HTTP/S как правило требует много ручной работы, если в инструменте нет механизма автокорреляции, который обычно предоставляется платформами корпоративного уровня.
Кроме того, могут быть особенности, зависящие от тестируемого приложения. Если нам нужно тестировать нагрузку только на API-запросы, то наиболее популярное опенсорсное решение, такое как JMeter, может быть более чем достаточным. Если же речь идет о сложных пользовательских путях в приложении, состоящих из множества переходов между страницами, или применяются не-HTTP протоколы (типа Citrix или SAP), то лучше рассмотреть такие инструменты как NeoLoad или LoadRunner. Когда речь идет об имитации поведения пользователя в сложных веб-приложениях, то браузерные протоколы, такие как TruClient в LoadRunner и RealBrowser в NeoLoad, дают явные преимущества. Эти протоколы позволяют генерировать сценарии, имитирующие действия пользователей в веб-браузере, обеспечивая более точное представление пользовательского опыта и производительности системы. В отличие от HTTP/S-сценариев, эти браузерные протоколы могут обрабатывать сложные пользовательские пути и сценарии на стороне клиента, что делает их вариантом для тестирования приложений со сложными пользовательскими интерфейсами.
Возможности интеграции в CI/CD-пайплайн
Современные нагрузочные платформы изначально рассчитаны на интеграцию в систему непрерывной интеграции и доставки (CI/CD). Это важная функциональность, так как она необходима для быстрого продвижения по жизненному циклу разработки ПО и внедрения эффективных методик таких как непрерывная интеграция и DevOps. Интеграция в CI/CD создает условия для оптимизации процессов.
Важно уточнить, поддерживает ли инструмент автоматизацию тестирования ключевых компонентов продукта на ранних стадиях цикла разработки; а также, можно ли тестировать при каждом коммите, чтобы оперативно устранять любые проблемы, не допуская проблем в дальнейшем.
В данное время JMeter, Neoload, k6 и Gatling являются лучшими вариантами с точки зрения простоты настройки, если приоритетом является интегрируемость в CI/CD. LoadRunner также можно интегрировать с CI/CD, но придется выделить время на этап настройки и аналитическую часть.
Интеграция с инструментами метрик
В зависимости от требуемого покрытия, интеграция с внешними инструментами метрик может быть решающим моментом в выборе инструмента. Интеграция с аналитическими платформами дает возможность значительно расширить понимание того что происходит, когда в систему подается определенная нагрузка, и какие в системе возникают проблемы.
Как правило все инструменты тестирования производительности выдают некие базовые метрики, такие как время отклика, пропускная способность, частота ошибок и так далее. Некоторые инструменты также могут извлекать дополнительную информацию из тестируемой системы, например, использование процессора, сети и дисковой подсистемы.
Интеграция с платформой аналитики (метрик) значительно расширяет возможности анализа при нагрузочном тестировании. Она обеспечивает хорошую видимость (observability) отдельных интересующих запросов по каждому сервису, видимость запросов к базам данных и пр.
Интеграция между платформой тестирования производительности, платформой аналитики, и пайплайном разработки может также обеспечивать автоматическую проверку производительности кода, позволяя тестировать его до того, как он попадет в прод, и проверять, есть ли ограничения производительности.
Neoload и LoadRunner дают основу для интеграции в экосистему, включая необработанные (raw) метрики от хостов (например, Sitescope в случае LoadRunner) и инструменты мониторинга производительности типа Dynatrace. Neoload нативно интегрируется с Gremlin, одной из широко используемых платформ хаос-инжиниринга.
Другие инструменты в нашем списке не имеют такой качественной интеграции, но для них существуют кастомные решения.
Cloud readiness
Большинство платформ тестирования производительности в настоящее время поддерживают облачное тестирование в той или иной форме.
В прошлом, если вы хотели создать test factory, сначала нужно было создать набор хостов в качестве контроллеров и генераторов нагрузки. Очевидно, что это создавало дополнительные расходы, поскольку каждый хост должен был поддерживаться во всех версиях и всегда быть доступным.
Теперь же некоторые из наиболее продвинутых инструментов предоставляют набор хостов в облаке в нескольких точках по всему миру. Теперь поставщики облачных услуг сами управляют этими узлами, поддерживая их в актуальном состоянии и в постоянной готовности. Когда нужно запустить тест, можем просто подключиться к облачным генераторам нагрузки и запустить их.
Это означает, что у вас есть потенциально бесконечное количество генераторов нагрузки, которые можно использовать если сценарий тестирования требует больших объемов нагрузки. После завершения тестирования не нужно обслуживать хосты и платить за аренду оборудования.
Более того, некоторые корпоративные платформы тестирования, такие как Neoload Web или StormRunner, предоставляют веб-консоль, с помощью которой можно управлять тестами и хост-зонами, проверять результаты и делиться ими с другими командами или с руководством проекта.
Масштабируемость
Еще один важный момент при выборе инструмента тестирования производительности, имеющий отношение не только к платформе, но и к тестовой ферме. Некоторые инструменты, особенно с открытым исходным кодом, масштабируются не так легко, как корпоративные. Это может быть существенным недостатком на крупных проектах.
Легкость освоения
Простой в настройке и конфигурировании инструмент можно передать разработчикам, чтобы они получили возможность самостоятельно проводить небольшие тесты на своих этапах разработки приложения. Это даст им возможность выявлять и устранять возможные проблемы производительности на ранних стадиях. Это поможет избежать эффекта накопления ошибок, который может возникнуть к тому времени когда приложение достигает стадии окончательного сквозного тестирования производительности. Этот сложный и как правило большой финальный тест обычно проводится всего за несколько дней до передачи на продакшен, и если тест не пройдет успешно, то релиз могут отложить.
k6, который теперь является частью Grafana Labs, — лучший выбор, если вам нужен быстрый нагрузочный тест API. Нагрузочный тест в k6 можно легко настроить всего за 10 минут. Легкость обучения (и скорость в случае несложных тестов) — это не про корпоративные решения.
Возможности анализа и репорты
Фреймворки тестирования производительности с открытым исходным кодом часто не лучшие в плане анализа результатов тестов.
Углубление в различные графики и временные рамки, возможность коррелировать сквозные системные метрики, сравнение тестовых экспериментов на различных конфигурациях или версиях продукта являются критически важными задачами для инженеров производительности. Поэтому расширенные возможности анализа, встроенные в инструмент тестирования производительности, часто являются необходимыми.
Но, несмотря на отсутствие собственных аналитических функций, большинство современных инструментов могут легко интегрироваться с платформами для создания дашбордов, такими как Grafana или Tableau. Для популярных фреймворков тестирования существует множество кастомных дашбордов в открытом доступе.
С открытыми исходниками или корпоративные
Как и почти в каждой области ИТ, выбор между открытым исходным кодом и коммерческим ПО также важен и при выборе инструмента тестирования производительности. Тип нагрузки, которую нужно будет подать, определяет выбор инструмента.
При рассмотрении вариантов с открытым исходным кодом или же корпоративных инструментов, именно модель лицензии может определять выбор. Как правило, лицензии основаны на количестве виртуальных пользователей (VU, virtual users), которых вам нужно будет создавать.
Некоторые поставщики нагрузочного ПО используют модель лицензирования по подписке: вы приобретаете определенное количество виртуальных пользователей на определенный период (например, на год). Каждый раз, когда вы запускаете тест, вам будут доступны все количество виртуальных пользователей. Другие поставщики используют VUD-модель (Virtual Users Hours): вы покупаете «пакет» виртуальных пользователей, и каждый из них «живет» например один час с момента первого использования. Это означает, что если вы уже знаете, что вам понадобится x тестов и для каждого из них не более y виртуальных пользователей, то вам понадобится не менее x*y VU.
Возможности совместной работы в команде
Если в вашей компании специальная QA-команда отвечает за тестирование всех или большинства приложений, то вам нужен инструмент с централизованной платформой, с функциями совместной работы (коллаборации) для управления графиком тестирования, резервированием ресурсов (VU, генераторы нагрузки, контроллеры и т.п.), контролем версий, шерингом результатов, и параллельным тестированием.
С помощью корпоративных инструментов, которые обеспечивают такой контроль, вы можете управлять всеми процессами тестирования, избегая дублирования тестов, которое может привести к ненадежности результатов. Вы также можете использовать сценарии или конфигурации мониторинга, созданные другими членами команды, что ускоряет процесс. Кроме того, наличие платформы, позволяющей легко делиться результатами в масштабах организации, делает их более наглядными для разработчиков и руководителей.
Поддержка и комьюнити
Если предыдущие пункты объективно отдавали предпочтение корпоративным решениям, то в случае решений с открытым исходным кодом есть безусловный плюс — активное сообщество, комьюнити, развивающее и поддерживающее инструмент. Это означает, что решение постоянно совершенствуется и что можно легко найти плагины для конкретных нужд.
Например, JMeter, инструмент с открытым кодом, который позволяет выполнять базовые тесты производительности с помощью нескольких кликов и базовых функций. Но что, если нужно рандомизировать параметры? Можно скачать плагин, который, к счастью, кто-то уже написал за вас. Это относится к сотням возможных задач и функций. Поэтому, хотя корпоративное решение способно предоставить много удобнейших встроенных возможностей, хорошо управляемый проект с открытым кодом, за которым стоит активное сообщество разработчиков, также может быть отличным вариантом, особенно для проверки нескольких базовых функций приложения.
Итоговая таблица
Итак, в таблицу сведены наиболее важные факторы, которые, по нашему опыту, крупные организации должны учитывать, выбирая инструменты тестирования производительности.»
В таблице: JMeter — LoadRunner — NeoLoad — Gatling — k6 — Locust
Также по теме:
Бесплатные опенсорсные инструменты нагрузочного тестирования
