Русский
Русский
English
Статистика
Реклама

Gatling

Из песочницы Анализ результатов нагрузочного тестирования

08.08.2020 00:06:58 | Автор: admin
С каждым днем в мире становится все больше и больше инструментов для проведения нагрузочного тестирования. Собственно, и сам интерес к этой теме начинает возрастать.
Основная задача инструмента нагрузочного тестирования подать заданную нагрузку на систему. Но кроме этого есть еще одна, не менее важная задача предоставить отчет о результатах подачи этой нагрузки. Иначе мы проведем тестирование, но ничего не сможем сказать о его результате и не сможем достаточно точно определить, с какого момента началась деградация системы.

В настоящий момент наиболее популярными инструментами тестирования являются Gatling, MF LoadRunner, Apache JMeter. Все они обладают возможностями как генерации готовых отчетов по проведенному тестированию, так и отдельных графиков или сырых данных, на основе которых строится уже сам отчет.



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

Мы в Тинькофф активно используем инструмент Gatling, поэтому на его примере расскажем, как создать отчет вашей мечты и куда следует смотреть при его анализе. Также сразу хочу заметить, что почти все графики, описанные в статье, можно получать в режиме онлайн с помощью связки вашего инструмента с Grafana. Это наиболее удобный инструмент для создания отчетов на лету, с помощью сконфигурированного заранее дашборда. Более того, это позволяет более быстро создать почти любой график на основе отправленных вами данных. Уже сейчас есть готовые дашборды почти для всех инструментов нагрузочного тестирования. Графики для других инструментов MF LoadRunner и Apache JMeter тоже будут приведены, их анализ строится по аналогии с Gatling.

Основные метрики


Индикаторы


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

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

  • отличная время отклика менее 50 секунд;
  • средняя более 50, но менее 100 секунд;
  • ужасная более 100 секунд.

В Gatling вы сами можете настроить пороги для перехода из группы в группу и их количество в файле gatling.conf. Графики такого типа лучше строить на основе методики. APDEX (Application Performance Index)
Также можно добавить индикатор с количеством/процентами ошибочных запросов.



Метод APDEX позволяет использовать индикаторы в регрессионном тестировании для сравнения релизов: так сразу видно, насколько хуже или лучше стал релиз в общем. К сожалению, этого графика нет из коробки в MF LoadRunner и Apache JMeter, но его легко создать с помощью дашборда Grafana.

Таблица с временем отклика


По умолчанию Gatling строит таблицу по перцентилям, среднему и максимальному времени отклика, а также по ошибкам. По ней отслеживается выход за пределы SLA (превышение нефункциональных требований). Обычно в SLA указывают перцентили 95, 99 и процент ошибок. Таким образом таблица позволяет получить быструю оценку результатов тестирования.

Если группировать запросы в виде транзакций, можно увидеть в таблице как оценку отдельных запросов, так и оценку всей группы и транзакции сразу.
HTML Gatling Report
MF LoadRunner также создает таблицу сам в блоке Analysis Summary Report и называется Transaction Summary
В Apache JMeter эти данные можно найти в Aggregate Report

График Virtual Users


Обычно измеряется в штуках и показывает, как пользователи заходят в приложение, тем самым иллюстрируя реальный профиль нагрузки. Стоит сразу оговориться, что для MF LoadRunner и Gatling эти графики показывают количество Virtual Users, а для Apache JMeter количество Thread.

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

  • Active Users отображает, сколько потоков сейчас активно в секунду. Когда потоки стартуют и останавливаются, особенно в открытой модели нагрузки, этот показатель будет колебаться на протяжении всего теста.
  • Total VUsers показывает, сколько потоков стартовали и останавливались с начала тестирования суммарно. Удобно для закрытой модели нагрузки, в которой потоки не умирают.

Вид графика также зависит от модели нагрузки:

  • Закрытая модель пользователи должны заходить в систему согласно планируемому профилю нагрузки. Если на графике видны провалы или пики, это говорит о том, что нагрузка шла не по рассчитанному или запланированному сценарию, и требует дальнейшего изучения
  • Открытая модель на графике могут быть видны пики и провалы, и это нормально для этой модели. Пик на графике должен коррелировать с увлечением времени отклика, так как в этот момент пользователи ожидают ответа от сервера и общая нагрузка на систему начинает падать. В связи с чем инструмент начинает поднимать новых виртуальных пользователей, чтобы количество запросов к системе оставалось постоянным, несмотря на долгие ответы/ошибки приложения. Для защиты от чрезмерного увеличения количества пользователей необходимо использовать функции троттлинга, принудительно задающие верхний порог максимальное количество поднятых пользователей инструментом нагрузки.

HTML Gatling Report
В MF LoadRunner этот график называется Running Vusers
В Apache JMeter график называется Active Threads Over Time и не входит в стандартную поставку, но его можно бесплатно скачать на сайте JMeter-Plugins.org

График Response Time


Чаще всего измеряется в миллисекундах показывает время ответа на запросы к приложению. Время отклика не должно превышать SLA. Этот график является основным инструментом для поиска точек деградации при проведении нагрузочного тестирования.

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

Кроме графика времени ответа каждого запроса удобно показывать также линию с суммарным временем ответа (Total Response Time). Если наложить график подаваемой нагрузки (VU/RPS), можно отслеживать корреляцию с увеличением времени отклика от увеличения подаваемой нагрузки (VU/RPS). В Apache JMeter этот график называется Response Times vs Threads.

Далее пойдут графики, на которых может быть множество линий, каждая из которых отображает свой сценарий или запрос. Если у вас сложный тест со множеством операций и нелинейным профилем, советуем отражать в отчете лишь наиболее показательные запросы или группы запросов. Как вариант, можно отражать лишь запросы, превысившие SLA/SLO, чтобы не засорять график и отчет.
В MF LoadRunner график называется Average Transaction Response Time и показывает среднее время для транзакций
Для Apache JMeter график существует в двух вариантах в расширенном пакете с сайта JMeter-Plugins.org и называется Response Times Over Time и, по умолчанию, Response Time Graph. Более наглядный и удобный, на мой взгляд, первый вариант


Вариации графика


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

В тестировании производительности чаще всего используется 95 и 99 перцентиль для большей наглядности. Однако, если вы все же смотрите среднее время отклика, вам стоит учитывать при этом стандартное (среднеквадратичное) отклонение.
HTML Gatling Report
Для MF LoadRunner график будет называться Transaction Response Time (Percentile)
Также вы можете получить и перцентили для Apache JMeter с помощью графика Response Times Percentiles из этого же расширенного набора

Распределение Response Time


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

Этот вид графиков чем-то напоминает индикаторы, но показывает более полную картину распределения времени, без обрезки перцентилями или другими агрегатами. С помощью графика можно более наглядно определить границы для групп индикаторов. У MF LoadRunner такого графика нет.
HTML Gatling Report для каждого запроса
Есть еще один вариант распределения времени выполнения запроса от количества запросов в разрезе успешных и ошибочных запросов для всего теста
Для MF LoadRunner данный график будет называться Transation Response Time (Distribution) и показывать распределение для транзакций
В Apache JMeter тоже есть этот график в расширенном пакете и называется Response Times Distribution

Latency


Из этой метрики также можно выделить дополнительный параметр Latency (миллисекунды) время задержки (чаще всего под этим понимают Network Latency). Этот параметр показывает время между окончанием отправки запроса до получения первого ответного пакета от системы.
С помощью этого параметра можно измерять также задержки на сетевом уровне, если параметр будет расти. Желательно, чтобы он стремился к нулю. Этот и следующий тип графиков в основном используются при глубоком анализе и поиске проблем производительности. Этого графика из коробки нет в Gatling. В MF LoadRunner этот график называется Average Latency Graph в блоке Network Virtualization Graphs если у вас установленные агенты мониторинга.
В Apache JMeter этот график присутствует лишь в расширенном наборе и называется Response Latencies Over Time

Bandwidth


Аналогично метрике выше можно выделить параметр Bandwidth (килобит в секунду) ширину пропускания канала. Он показывает, какой максимальный объем данных может быть передан за единицу времени.

Изменяя этот параметр на инструменте нагрузки можно моделировать различные источники подключений к приложению: мобильная связь 4G или проводная сеть. В бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Этот график из коробки есть лишь в MF LoadRunner, находится в том же блоке, что и Latency, и называется Average Bandwidth Utilization Graph.

График Request Per Second


Измеряется в штуках в секунду показывает количество запросов, поступающее в систему за 1 секунду.

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

  1. Если наложить график на VU, можно увидеть увлечение RPS/TPS с увлечением количества пользователей, а также уменьшение в связи с выходом пользователей или стабилизацией подаваемой нагрузки.
  2. Если наложить график Response Time, можно увидеть среднее время, за которое обрабатываются все транзакции или запросы на протяжении теста.

HTML Gatling Report
В MF LoadRunner график называется Hits per Second
Для Apache JMeter существует график Hits per Second из расширенного пакета

TPS


Измеряется в штуках в секунду и показывает количество транзакций (в рамках транзакции может быть множество запросов) за 1 секунду.

Например, транзакция вход в личный кабинет включает следующие запросы: открытие главной страницы, ввод логина, пароля, нажатие кнопки отправить, переадресацию на приветственную страницу в единицу времени. В Gatling график можно получить лишь с помощью применения Grafana, так как для групп в HTML-отчёте строятся графики лишь по времени отклика.
MF LoadRunner Transactions per Second
Для расширенного пакета Apache JMeter Transactions per Second

График Errors


Обычно измеряется в rate (штук в секунду) график показывает рост количества ошибочных запросов. Также удобно измерять значение в процентах от общего числа запросов. По этому графику отслеживается выход за пределы SLA по количеству или проценту ошибок.

Если наложить график Response Time, можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения.

Gatling по умолчанию не имеет отдельного графика, отображающего лишь ошибки. В Gatling он совмещен с графиком VU и сразу показывает, как рост нагрузки сказывается на росте числа ошибок, и помогает обнаружить порог, с которого идет превышение SLA или вообще появляются ошибки. В Apache JMeter также нет отдельного графика, он совмещен с графиками количества транзакций.
HTML Gatling Report
В MF LoadRunner этот график называется Errors per Second

HTTP responses status


Возможно также выводить на график распределения количества ошибок по кодам ответа приложения удобно использовать для классификации ошибок.

Например, если на предыдущем графике вы получили 100%, вы начинаете анализировать, а какие именно 50x ошибки из-за того, что сервер не отвечает, или 403 из-за того, что неверный пул и пользователи не могу авторизоваться, если, например, вы используете HTTP-протокол.
Изначально в бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Чтобы график появился в бесплатной версии, необходимо перенастроить logback.xml так, чтобы логи собирались в graylog, и уже в нем строить нужный график.
В MF LoadRunner этот график называется HTTP Responses per Second
В Apache JMeter этот график называется Response Codes per Second из расширенного пакета

График Throughput


Измеряется обычно в битах в секунду. График показывает пропускную способность приложения, а именно какой объем данных был отправлен и обработан приложением в единицу времени.
Обычно его используют для глубокого анализа проблемы приложений. В Gatling этот график содержится лишь в FrontLine, в бесплатной версии его нет.
Этот график есть из коробки в MF LoadRunner, он называется Throughput
В Apache JMeter график называется Bytes Throughput Over Time из расширенного пакета

Возможные модификации


  1. Если наложить график Response Time, можно увидеть, что рост времени ответа часто связан с увеличением числа отправленных данных (Throughput). Если на графике замечен рост Response Time, а Throughput при этом остается прежним, это указывает на проблемы с сетью или с приложением: где-то начинает копиться очередь запросов.
  2. Если наложить график Bandwidth, то при совпадении объема данных на двух графиках будет видно, что ограничивающим фактором является пропускная способность сети.
  3. Если наложить график VU, то они должны полностью коррелировать, без резких скачков и провалов, так как рост нагрузки должен приводить к планомерному росту объема данных. Расхождения или резкие выбросы являются поводами для дальнейшего изучения.

Получение графиков


Большинство графиков можно получить, используя отчет HTML Based Gatling Reports после теста или же настроив связку мониторинга Graphite-InfluxDB-Grafana. Для отображения можно использовать готовый дашборд из библиотеки дашбордов https://grafana.com/grafana/dashboards/9935.

При анализе и составлении своих дашбордов для Gatling следует учитывать, что результаты в InfluxDB хранятся агрегированные и подходят только для предварительной оценки результатов НТ. Рекомендуется после теста повторно загрузить simulation.log в базу данных и уже по нему строить итоговый отчет и выполнять поиск проблем производительности системы.

Матричное описание метрик


Всё, что мы описали выше, представлено в виде маленькой таблички, суммирующей все эти знания.
Тип VU Response Time Requests Errors Throughput
VU Позволяет сравнить планируемую нагрузку с реальной Показывает, как увеличение пользователей сказывается на росте времени отклика при закрытой модели Можно увидеть увеличение RPS/TPS/HITS с увеличением количества пользователей, а также уменьшение в связи с выходом пользователей или стабилизацией подаваемой нагрузки Показывает, при каком числе VU происходит рост ошибок. Не всегда показателен, так как в открытой модели сложно коррелировать графики Метрики должны полностью коррелировать, так как рост пользователей приводит к росту объема данных, отправляемых ими. Расхождения или резкие выбросы являются поводами для дальнейшего изучения
Response Time Показывает, как быстро сервер отвечает на наши запросы. Основная метрика Показывает среднее время, за которое обрабатываются все транзакции или запросы на всем протяжении теста Можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения Рост времени ответа часто связан с увеличением количества отправленных данных (Throughput). Если на графике замечен рост Response Time, а Throughput при этом остается прежним, это указывает на проблемы с сетью или с приложением: где-то начинает копиться очередь запросов
Requests Показывает, сколько запросов выдерживает система в секунду, минуту и т. д. Позволяет найти значение интенсивности, после которой появляются ошибки. Удобно для определения SLA Позволяет контролировать рост объема данных и количества запросов. Эти метрики должны коррелировать. Появление проблем может свидетельствовать, что мы отправляем неверные запросы
Errors Позволяет оценить рост числа ошибок и тип ошибок, которые проявляются под нагрузкой Можно найти объем данных, при котором приложение начинает генерировать ошибки
Throughput Показывает, какой объем данных приложение может прокачать через себя за заданный промежуток времени
Подробнее..

Перевод Нагрузочное тестирование выполнять сложно, а инструменты далеки от совершенства. Почему?

07.01.2021 14:19:53 | Автор: admin


Если вы создаёте приложение, которое должно масштабироваться а все мы надеемся, что наши приложения будут расти то в определённый момент нам приходится разбираться, может ли оно это делать на самом деле. Именно тогда на помощь приходит нагрузочное тестирование: если вы хотите узнать, справится ли ваше приложение с крупными масштабами, то мы просто генерируем эти масштабы и проверяем! Звучит достаточно просто.

Но потом мы пробуем действительно сгенерировать нагрузку. Это делается легко, только если ваше приложение ужасно простое, ведь тогда можно использовать что-нибудь типа Apache JMeter для генерации повторяющихся запросов. Если у вас это получится, то я вам завидую: все системы, с которыми мне приходилось работать, сложнее и требовали более изощрённой схемы тестирования.

Если ваше приложение становится чуть сложнее, то вы переходите к инструментам наподобие Gatling. Они позволяют симулировать виртуальных пользователей, выполняющих различные сценарии, что намного полезнее, чем простая осада одного или нескольких URL. Но даже этого недостаточно, если вы пишете приложение, использующее одновременно WebSockets и HTTP-вызовы в течение долговременной сессии, а также требующее повторения по таймеру определённых действий. Возможно, я серьёзно недоглядел чего-то в документации, но мне не удалось найти способа, допустим, настроить периодическое событие, запускаемое каждые 30 секунд и выполняющее определённые действия при ответе на сообщение WebSocket, а также производящее действия по HTTP, и всё это в рамках одной HTTP-сессии. Я не нашёл такой возможности ни в одном инструменте нагрузочного тестирования (и именно поэтому написал на работе свой собственный инструмент, который надеюсь выложить в open source, если найду время на подчистку кода и отделения его от проприетарных частей).

Но предположим, что у вас есть стандартный инструмент наподобие Gatling или Locust, который работает и удовлетворяет вашим нуждам. Отлично! Теперь давайте напишем тест. По моему опыту, сейчас это самая сложная задача, потому что нам сначала нужно разобраться, как выглядит реалистичная нагрузка вас ждёт один-три дня кропотливого изучения логов и ведения заметок по показателям сетевых инструментов в браузере при работе веб-приложения. А после того, как вы узнаете реалистичную нагрузку, то вам придётся написать код, который сводится к следующему: подмножество вашего приложения будет притворяться пользователем, общаться с API и выполнять действия, которые совершает пользователь.

И на этом ещё ничего не закончилось! Здорово, мы написали нагрузочный тест, и он реалистичен. Но задача постоянно меняется, ведь выпускаются обновления. То есть теперь у нас появилась проблема поддержки: как обеспечивать актуальность нагрузочного теста при изменении приложения? Для этого нет качественных инструментов и почти ничто вам не поможет. Придётся сделать это частью процесса и надеяться, что вы ничего не упустите. Такой ответ не радует, и именно поэтому этот аспект является одним из самых сложных при тестировании приложения.

Можно даже опустить все заботы, связанные с запуском, потому что, честно говоря, если вы добились таких успехов в нагрузочном тесте, то его запуск окажется не самой тяжёлой задачей.

Откуда берётся сложность


По сути, ситуация такова:

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

Давайте подробно рассмотрим каждый из пунктов, и разберёмся, от какой степени сложности можно избавиться.

Симуляция пользователей. Действительно ли она нужна?


Здесь я могу ответить да, хотя это может зависеть от конкретного приложения. В данном случае подразумевается пользователь сервиса: если у вас монолит, то это все ваши пользователи, но в случае микросервисов пользователем может быть один из сервисов! При создании приложений, над которыми я работал, мне удалось достичь незначительного успеха с таргетированными тестами отдельных конечных точек. Но в конечном итоге для этого требовалась такая сложная система, что это оказалось ненамного проще самого нагрузочного теста! И хотя мы получили некоторые результаты и усовершенствования, покрыть всё не удалось (в приложении могут быть взаимодействующие конечные точки) и мы не смогли получить реалистичную нагрузку.

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

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

Написание тестов сложная задача. Как и их поддержка.


Создавать тесты сложно, потому что требуется выполнить несколько задач: нужно разобраться, каков поток использования API и написать симуляцию этого использования. Для понимания потока необходимо понимание других систем, кроме тестируемой, и поскольку ваша система вряд ли подробно рассматривается в их документации, не будет чёткой диаграммы того, когда и что вызывается; часто приходится разбираться в логах, пока не поймёшь, какова же истинная схема использования. Далее идёт написание этой симуляции тоже нетривиальная задача, поскольку необходимо обрабатывать состояние большого количества акторов, представляющих собой пользователей вашего API!

А, да, и теперь вам нужно писать для всего этого ещё и интеграционные тесты.

Существуют исследования о том, как упростить некоторые из этих задач. Например, можно разобраться в том, что вам нужно для первоначального теста, и распознавать регрессии (отсутствующие новые нагрузки) по автоматизированному анализу логов. Но насколько я понимаю, на GitHub, не говоря уже о коммерческой доступности, нет продукта, способного выполнить за меня эту задачу. Поэтому похоже, что в нашей отрасли подобные системы не получили широкой поддержки. Для самостоятельной реализации этот проект был бы слишком большим, и в этом может быть причина его увядания (или он реализуется в больших компаниях и о нём не говорят).

Может быть, не подвергать всё нагрузочному тестированию?


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

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

  • Старый добрый анализ. Усесться с ноутбуком, ручкой и пониманием системы в целом, выделить на это полдня, и вы получите примерные расчёты основных параметров и ограничений масштабирования системы. Когда вы наткнётесь на бутылочное горлышко или встретитесь с неизвестными переменными (сколько транзакций в секунду может поддерживать наша база данных? Сколько мы их генерируем?), то можно будет протестировать конкретно их!
  • Разворачивание фич. Если вы можете медленно разворачивать фичи на всех пользователей, то вам может и не понадобиться нагрузочное тестирование! Вы можете измерять производительность экспериментально и проверять, достаточно ли её. Достаточно? Разворачиваем дальше. Мало? Откатываемся назад.
  • Повторение трафика. Это совершенно не поможет с новыми фичами (для них воспользуйтесь предыдущим пунктом), но поспособствует пониманию критичных точек системы для уже имеющихся фич, при этом не требуя большого объёма разработки. Вы можете взять отслеженный ранее трафик и повторять его (многократно снова и снова, даже комбинируя трафик различных временных периодов), наблюдая за производительностью системы.



    На правах рекламы


    Серверы для разработки это эпичные от Вдсины.
    Используем исключительно быстрые NVMe накопители от Intel и не экономим на железе только брендовое оборудование и самые современные решения на рынке!

Подробнее..

Перевод Запускаем Gatling из Gradle Полное руководство для начинающих

02.04.2021 14:12:19 | Автор: admin

Привет, Хабр. Для будущих учащихся на курсе Нагрузочное тестирование подготовили перевод статьи.

Также приглашаем посетить открытый вебинар на тему Начало работы с Jmeter: запись скрипта, параметризация, отладка.


Хотите узнать, как использовать Gatling через Gradle? Тогда вы по адресу. В последнее время я достаточно часто использую инструмент стресс-тестирования Gatling. Он стал одним из моих излюбленных инструментов для тестирования производительности. На сайте Gatling есть неплохая документация по началу работы. Но она подразумевает загрузку zip-файла, а затем запуск BAT или SH скрипта для запуска Gatling. А затем вам нужно выбрать из списка тест, который вы хотите запустить.

Так что да, было бы намного приятнее делать все вышеперечисленное через Gradle. И естественно, намного удобнее. В частности, если вы хотите запускать Gatling-тесты как часть вашего Continuous Integration. Одним из наибольших преимуществ этого подхода является то, что Gatling может зафейлить вашу CI-сборку, если будет нарушен определенный порог производительности (например, слишком много ошибок или слишком большое среднее время отклика и т. д.).

Если вы хотите запускать Gatling через Gradle, вам понадобится плагин Gatling Gradle.

Это руководство проведет вас через настройку плагина Gradle для нового Gatling-проекта.

Чтобы сделать это руководство еще более удобным для новичков, мы будем производить настройку в IDE (Intellij). После завершения работы по настройке вы можете переключиться на запуск исключительно через командную строку, если вам угодно.

Предупрежу вас с самого начала я не буду вдаваться в подробности о Gatling в этой статье. Если вы хотите всесторонне познакомиться с Gatling, ознакомьтесь с другой моей статьей Нагрузочное тестирование с Gatling Полное руководство.

Предварительные требования

Перед тем, как мы начнем, вы должны удостовериться в наличии всех пунктов из списка предварительных требований, приведенных ниже:

1. Java 8 JDK

Вероятно, он у вас уже есть, но если нет, то здесь можно найти подробное руководство по установке JDK для всех типов ОС.

Я настоятельно рекомендую вам использовать Java 8 с Gatling, так как он наиболее с ним совместим.

2. Intellij

В этом руководстве я буду использовать Intellij, вы можете скачать последнюю версию Intellij здесь.

И это все, что вам нужно! Gatling Gradle плагин берет на себя установку Scala, и если же вы запускаетесь через Gradle Wrapper, то нет никакой необходимости даже загружать или устанавливать Gradle на вашей системе.

Давайте посмотрим, как мы можем начать использовать плагин для работы.


Руководство по запуску Gatling из Gradle

Создать Gradle-проект для Scala в Intellij, как я выяснил с годами, удручающе сложно.

Лучший способ начать создать образец проекта (sample project).

  1. Выполните следующую команду в терминале или командной строке, чтобы создать образец проекта с плагином Gatling Gradle:

curl -sL https://raw.githubusercontent.com/lkishalmi/gradle-gatling-plugin/master/bootstrap.sh | \    bash -s ~/sample-gradle-gatling && \    cd ~/sample-gradle-gatling && ./gradlew gatlingRun

2. Откройте начальную страницу IntelliJ и выберите Import Project.

Import Project to IntelliJImport Project to IntelliJ

3. Выберите файл build.gradle из репозитория, который вы загрузили на шаге 1, и нажмите Open.

Select build.gradle fileSelect build.gradle file

4. Откройте файл SampleSimulation.

Open Sample SimluationOpen Sample Simluation

5. Вы можете увидеть всплывающее окно, подобное ниже. Выберите Setup Scala SDK.

Setup Scala SDKSetup Scala SDK

6. Выберите SDK для Scala. Если его нет в списке, вам вместо этого может потребоваться кликнуть Configure и сначала загрузить бинарники Scala.

Choose Scala SDKChoose Scala SDK

7. На этом этапе уже все должно быть настроено. Чтобы запустить Gatling-тест из Gradle, введите:

./gradlew gatlingRun

Или, чтобы запустить конкретный тест:

./gradlew gatlingRun-SampleSimulation

Для получения дополнительных сведений об использовании и настройке плагина с официальной документацией Gatling Gradle Plugin.


Узнать подробнее о курсе Нагрузочное тестирование.

Смотреть открытый вебинар на тему Начало работы с Jmeter: запись скрипта, параметризация, отладка.

Подробнее..

Перевод Нагрузочное тестирование на Gatling Полное руководство. Часть 1

16.04.2021 20:09:46 | Автор: admin

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

Краткий обзор руководства

Если вам нужно провести нагрузочное тестирование вашего сервера HTTP-приложений, то Gatling - идеальный инструмент для этой задачи! Эта серия статей будет представлять собой подробное практическое руководство по нагрузочному тестировании на Gatling. К концу этого руководства у вас появится хорошее представление об использовании Gatling, которое вы сможете применить в ваших последующих проектах по нагрузочному тестированию.

Первый раз слышите о Gatling? Тогда для начала уделите внимание моей вводной статье о Gatling. Но если в двух словах:

  • Gatling - это инструмент для нагрузочного тестирования с открытым исходным кодом, полностью написанный на Scala.

  • Простой и выразительный DSL, который предлагает Gatling, упрощает написание скриптов нагрузочного тестирования.

  • Он не содержит графического интерфейса (например, как JMeter), хотя поставляется с графическим интерфейсом для облегчения записи скриптов.

  • Он может обрабатывать огромный объем трафика на одном компьютере, устраняя необходимость в сложной распределенной инфраструктуре тестирования.

  • Проверку кода с помощью Gatling можно встроить в систему контроля версий и легко использовать в связке с инструментами непрерывной интеграции для запуска нагрузочных тестов и тестов производительности как части вашей CI-сборки.

Что такое тестирование производительности?

Прежде чем мы начнем, давайте вкратце разберемся, что такое тестирование производительности (performance testing).

Тестирование производительности - это тестирование, которое вы выполняете, когда хотите увидеть, как ваша система справляется с различными уровнями трафика и пропускной способности.

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

Существует несколько различных типов тестирования производительности, такие как:

  • Нагрузочное тестирование (Load Testing) - тестирование системы на заранее определенном объеме пользователей и трафике (пропускной способности);

  • Стресс-тестирование (Stress Testing) - тестирование системы под постоянно увеличивающейся нагрузкой, чтобы найти точку останова (breakpoint).

  • Тестирование стабильности (Soak Testing) - тестирование со стабильным уровнем трафика в системе на более длительном периоде времени для выявления узких мест.

Gatling подходит для всех этих подвидов тестирования производительности.

Вот некоторые из метрик, которые вы можете собрать во время тестирования производительности:

  • Время отклика транзакции (Transaction Response Times) - сколько времени требуется серверу, чтобы ответить на запрос.

  • Пропускная способность (Throughput) - количество транзакций, которые могут быть обработаны за определенный период времени.

  • Ошибки (Errors) - сообщения об ошибках, которые начинают появляться в определенные моменты нагрузочного теста (например, тайм-ауты).

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

Исходный код

Вы можете найти весь исходный код из этого руководства в моем репозитории на Github.


1. Установка Gatling

Прежде чем начать что-либо делать, убедитесь, что у вас установлен JDK8 (или более новый). Если вам нужна помощь с этим, ознакомьтесь с этим руководством по установке JDK.

Самый простой способ установить Gatling - загрузить версию Gatling с открытым исходным кодом с сайта Gatling.io. Кликните Download Now, и начнется загрузка ZIP-архива:

Download GatlingDownload Gatling

Разархивируйте архив в любое место на вашем компьютере. Откройте полученную папку и перейдите в каталог bin. Оттуда запустите:

  • gatling.bat - если вы используете Windows

  • gatling.sh - если вы работаете на Mac или Unix

После окончания загрузки Gatling вам будет предложено выбрать симуляцию для запуска:

Choose Gatling Simulation to runChoose Gatling Simulation to run

Введите 0, чтобы выбрать computerdatabase.BasicSimulation. Вам будет предложено ввести описание запуска (run description), но это необязательно, и его можно оставить пустым.

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


2. Gatling Recorder

Можно, конечно, запускать скрипты, поставляемые с Gatling, но, несомненно, вы захотите разработать скрипты под ваше собственное приложение.

Как только вы овладеете Gatling (к концу этого руководства!), вы сможете писать скрипты с нуля в своей IDE или даже просто в текстовом редакторе.

Но прежде чем заняться этим, для начала вам будет проще использовать встроенный Gatling Recorder для записи вашего пользовательского пути (user journey).

2.1 Создание HAR-файла

Самый удобный способ использования Gatling Recorder, как мне кажется, предполагает генерацию HAR-файла (Http-архива) вашего пользовательского пути в Google Chrome.

Создание этих файлов и их импорт в Gatling Recorder позволяет обойти проблемы с записью на HTTPS.

Чтобы создать HAR-файл, выполните следующие действия:

  1. Откройте тестовый сайт Gatling с базой данных компьютеров - это сайт, с которого мы будем записывать пользовательский путь.

  2. Откройте Chrome Developer Tools и перейдите на вкладку Network.

  3. Кликните Clear, чтобы удалить все предыдущие сетевые вызовы, а затем убедитесь, что красная кнопка записи включена.

  4. Полистайте сайт, чтобы сгенерировать свой пользовательский путь - например, поищите какой-нибудь компьютер, создайте другой компьютер и т. д. Вы должны увидеть, что внутри вкладки Network начинают появляться новые записи.

  5. Кликните правой кнопкой мыши в любом месте вкладки Network и выберите Save all as HAR with content. Сохраните этот файл где-нибудь на вашем компьютере.

  1. Теперь перейдите в свою папку bin Gatling (в которой вы впервые запустили Gatling в предыдущем разделе) и запустите файл recorder.sh в Mac/Unix или recorder.bat в Windows. Загрузится Gatling Recorder.

  2. Измените Recorder Mode в правом верхнем углу на HAR Converter.

  3. В разделе HAR File перейдите к местоположению HAR-файла, созданного на шаге 5.

  4. Назовите свой скрипт, изменив Class Name на, например, MyComputerTest.

  5. Все остальное оставьте как было по умолчанию и кликните Start!

  6. Если все сработает так, как должно, вы увидите сообщение, что все прошло успешно.

Gatling Recorder screenshotGatling Recorder screenshot
  1. Чтобы запустить скрипт, вернитесь в папку bin Gatling и снова запустите gatling.sh или gatling.bat. После того, как Gatling загрузится, вы сможете выбрать только что созданный скрипт.

Если вы хотите посмотреть на только что созданный скрипт, вы можете найти его в папке user-files/simulations в вашем каталоге Gatling. Откройте скрипт MyComputerTest, который вы только что записали, в текстовом редакторе. Он должен выглядеть как-то так:

import scala.concurrent.duration._import io.gatling.core.Predef._import io.gatling.http.Predef._import io.gatling.jdbc.Predef._class MyComputerTest extends Simulation {val httpProtocol = http.baseUrl("http://computer-database.gatling.io").inferHtmlResources().userAgentHeader("Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36")val headers_0 = Map("Accept" -> "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9","Accept-Encoding" -> "gzip, deflate","Accept-Language" -> "en-GB,en-US;q=0.9,en;q=0.8","Upgrade-Insecure-Requests" -> "1")val scn = scenario("MyComputerTest").exec(http("request_0").get("/computers").headers(headers_0)).pause(9).exec(http("request_1").get("/computers?f=amstrad").headers(headers_0)).pause(4).exec(http("request_2").get("/assets/stylesheets/bootstrap.min.css").resources(http("request_3").get("/assets/stylesheets/main.css")))setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)}

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


3. Настройка проекта Gatling

Итак, теперь, когда вы получили представление о том, как выглядит скрипт Gatling (и как с ним запустить нагрузочный тест), давайте приступим к настройке среды для создания наших скриптов. Первое, что нам нужно выбрать, это IDE:

3.1 Выберите IDE для создания скриптов нагрузочного тестирования на Gatling

Хотя вы вполне можете создавать скрипты Gatling в любом текстовом редакторе, гораздо проще (и эффективнее) делать это в IDE. В конце концов, мы будем писать код Scala. Scala работает поверх JVM, поэтому любая IDE, поддерживающая JVM, должна нам подойти.

У вас есть несколько вариантов:

  • Другой вариант, который (недавно) стал доступен, - это Visual Studio Code или сокращенно VS Code. Эта IDE последние несколько лет развивалась с головокружительной скоростью и стала популярной среди разработчиков множества различных технологических стеков. Ознакомьтесь с другой моей статьей Создаем Gatling скрипты с помощью VS Code для получения указаний по настройке.

  • Мой личный выбор, который я и буду показывать в этом руководстве, - это IntelliJ IDEA. Бесплатная версия достаточно хороша и поставляется со встроенной поддержкой Scala. Она идеально подходит для разработки скриптов Gatling.

Теперь, когда мы выбрали нашу IDE, нам понадобится система сборки, которая будет сочетаться с ней:

3.2 Выберите систему сборки для Gatling

Конечно, вы можете использовать Gatling без системы сборки и просто запускать его из первичных zip-файлов (как мы делали в первом разделе). Но есть вероятность, что вскоре вы все-таки захотите использовать систему сборки в своем проекте нагрузочного тестирования Gatling. Это упростит обслуживание в системе контроля версий. Опять же, у вас есть несколько вариантов на выбор:

Я расскажу о настройке нового проекта в IntelliJ Idea с Maven в оставшейся части этого раздела.

3.3 Создание проекта Gatling из архетипа Maven

Откройте терминал или командную строку и введите:

mvn archetype:generate

В конце, вы увидите этот запрос:

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains):

Введите gatling.

Затем вы должны увидеть:

1: remote -> io.gatling.highcharts:gatling-highcharts-maven-archetype (gatling-highcharts-maven-archetype)

Просто введите 1 для выбора архетипа Gatling. На следующем экране выберите последнюю версию:

Choose Gatling VersionChoose Gatling Version

Я ввел 35, чтобы выбрать версию 3.3.1 для этого туториала.

Для groupId введите com.gatlingTest.

Для artifactId введите myGatlingTest.

Для version просто нажмите ENTER, чтобы принять 1.0-SNAPSHOT.

Для package нажмите ENTER еще раз, чтобы принять в качестве имени пакета com.gatlingTest.

В конце введите Y, чтобы подтвердить все настройки, и Maven создаст для вас новый проект.

Следующее, что нужно сделать, - это импортировать этот проект в вашу IDE. Я импортирую проект в IntelliJ.

На стартовой странице IntelliJ выберите Import Project.

Import IntelliJ Gatling projectImport IntelliJ Gatling project

Перейдите в папку проекта, которую вы только что создали, и выберите файл pom.xml. Кликните open, и Intellij начнет импортировать проект в IDE за вас.

После того, как импорт проекта будет завершен, откройте панель Project Directory слева и раскройте папку src>test>scala. Дважды кликните по классу Engine.scala. Вы можете увидеть сообщение No Scala SDK in module вверху экрана. Если это так, нажмите Setup Scala SDK:

Import Scala SDK in IntelliJImport Scala SDK in IntelliJ

Проверьте, какие версии Scala у вас есть:

Scala versions in IntelliJScala versions in IntelliJ

Если у вас нет версии, указанной здесь, кликните Create, выберите версию 2.12 и кликните кнопку download:

ПРИМЕЧАНИЕ: Я НАСТОЯТЕЛЬНО рекомендую использовать версию Scala 2.12 с IntelliJ - 2.13, похоже, не очень хорошо работает с Gatling

Download Scala in IntelliDownload Scala in Intelli

В качестве альтернативы, если у вас возникли проблемы с загрузкой бинарников Scala через IntelliJ, вы можете вместо этого загрузить бинарники Scala непосредственно со Scala-lang. Кликните Download the Scala binaries, как показано на этом скриншоте:

Download Scala binaries from Scala-langDownload Scala binaries from Scala-lang

Сохраните бинарники где-нибудь на жестком диске и распакуйте ZIP-архив. Вернувшись в IntelliJ, снова кликните Setup Scala SDK, и на этот раз кликните Configure. Нажмите кнопку Add в левом нижнем углу:

Add the Scala binaries to IntelliJAdd the Scala binaries to IntelliJ

Перейдите в папку, которую вы только что загрузили и распаковали, и выберите папку lib:

Select the Lib folder to import Scala BinariesSelect the Lib folder to import Scala Binaries

Теперь в диалоге Add Scala Support вы сможете выбрать библиотеку Scala, которую вы загрузили:

Add Scala SupportAdd Scala Support

На этом моменте, вам также может потребоваться пометить папку scala как source root в IntelliJ. Для этого кликните правой кнопкой мыши по папке scala и выберите Mark Directory As -> Test Sources Root:

Mark Test Sources as Root in IntelliJMark Test Sources as Root in IntelliJ

На всякий случай также отметьте всю папку src как source root:

Mark Sources RootMark Sources Root

Наконец, кликните правой кнопкой мыши объект Engine и выберите Run:

Run the Engine Object in IntelliJRun the Engine Object in IntelliJ

Вы должны увидеть сообщение типа There is no simulation script. Please check that your scripts are in user-files/simulations. Так и должно быть, далее мы приступим к настройке наших скриптов нагрузочных тестов Gatling.

3.4 Добавление базового скрипта Gatling

Чтобы протестировать нашу новую среду разработки, давайте добавим базовый скрипт Gatling. Этот скрипт запустит тест на базе данных компьютеров Gatling.

Примечание: В оставшейся части этого руководства мы будем писать Gatling-тесты для пользовательского приложения, которое я создал для этого туториала... Сейчас же я просто хотел продемонстрировать простой скрипт для базы данных компьютеров Gatling, чтобы мы могли проверить, правильно ли настроена наша среда.

Кликните правой кнопкой мыши папку scala и выберите New > Scala Package - назовите пакет computerdatabase. Кликните эту папку правой кнопкой мыши и выберите New > Scala Class - назовите этот класс BasicSimulation. Скопируйте весь приведенный ниже код в новый класс:

package computerdatabaseimport io.gatling.core.Predef._import io.gatling.http.Predef._import scala.concurrent.duration._class BasicSimulation extends Simulation {  val httpProtocol = http    .baseUrl("http://computer-database.gatling.io") // Здесь находится корень для всех относительных URL    .acceptHeader(      "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"    ) // Вот общие заголовки    .acceptEncodingHeader("gzip, deflate")    .acceptLanguageHeader("en-US,en;q=0.5")    .userAgentHeader(      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0"    )  val scn =    scenario("Scenario Name") // Сценарий представляет собой цепь запросов и пауз       .exec(        http("request_1")          .get("/")      )      .pause(7) // Обратите внимание, что Gatling записал паузы в реальном времени  setUp(scn.inject(atOnceUsers(1)).protocols(httpProtocol))}

Теперь давайте запустим скрипт. Кликните правой кнопкой мыши объект Engine и выберите Run Engine. Gatling загрузится, и вы должны увидеть сообщение computerdatabase.BasicSimulation is the only simulation, executing it. Нажмите Enter, и скрипт выполнится.

Мы также можем запустить наш Gatling тест напрямую через Maven из командной строки. Для этого откройте терминал в каталоге вашего проекта и введите mvn gatling:test. Эта команда выполнит Gatling тест с помощью плагина Maven для Gatling.

Наша среда разработки Gatling готова к работе! Теперь нам нужно приложение, которое мы будем тестировать. Мы могли бы использовать базу данных компьютеров Gatling, но вместо этого я разработал API-приложение специально для этого туториала - базу данных игр!


В преддверии старта курса "Нагрузочное тестирование" приглашаем всех желающих записаться на бесплатный демо-урок в рамках которого рассмотрим интерфейс LoadRunner Virtual User Generator, запишем скрипт тестирования web-сайта, проведём его отладку и параметризацию. В результате вы научитесь создавать скрипты нагрузочного тестирования web-сайтов.

ЗАПИСАТЬСЯ НА ДЕМО-УРОК

Подробнее..

Перевод Создаем Gatling скрипты с помощью VS Code

06.07.2020 20:09:26 | Автор: admin

Перевод статьи подготовлен в преддверии старта курса Нагрузочное тестирование.





Предисловие


Недавно, благодаря комментарию одного из студентов, изучающих мой курс Gatling Fundamentals, я узнал о том, что вы можете создавать Gatling скрипты с помощью Visual Studio Code. Я, честно говоря, понятия не имел, что это возможно, но был приятно удивлен, обнаружив, насколько хорошо это работает!


В этом посте мы рассмотрим, как настроить вашу среду разработки Gatling скриптов в VS Code. Мы рассмотрим инструменты сборки Maven и SBT.


Установка Metals


Первое, что нужно сделать, планируете ли вы работать с Maven или SBT, это установить плагин Scala Metals внутри VS Code. Этот плагин позволит языковому серверу Scala работать в VS Code и предоставит типичные функции, которые вы ожидаете от современного IDE.



Установите плагин из VS Code самым стандартным способом, перейдя на вкладку Extensions и выполнив поиск Scala (Metals):



Имея установленный Metals, давайте сначала посмотрим, как запустить Gatling в VS Code с помощью Maven.


Gatling VScode с Maven


Во-первых, вам нужно установить Maven вы можете скачать Maven с официального сайта и следовать инструкциям по установке на его странице.


Затем установите плагин Maven for Java внутри VS Code:



По-прежнему внутри VS Code, откройте Command Pallette (View > Command Pallette) и выберите Maven: Update Maven Archetype Catalog:



Как и следовало ожидать, это обновит каталог доступных архетипов Maven.


Теперь мы хотим создать новый проект Gatling из архетипа Gatling Maven. Для этого сначала откройте Command Pallette и выберите Maven: Create Maven Project. При выборе архетипа, нажмите more. Введите Gatling, после чего должен появиться архетип Gatling. Дальше смотрите видео ниже:



Сохраните проект в подходящем месте на вашем компьютере. Затем откройте проект как обычно в VS Code. Возможно, на этом этапе вам придется импортировать сборку. Для этого перейдите на вкладку Metals в VS Code и нажмите Import Build:



Это заставит Maven собрать ваш проект.


Теперь самым ординарным способом добавьте свой код Gatling симуляции. Если вы просто следуете моему примеру и вам нужен пример Gatling скрипта, вы можете использовать этот базовый скрипт ниже:


package computerdatabaseimport io.gatling.core.Predef._import io.gatling.http.Predef._import scala.concurrent.duration._class BasicSimulation extends Simulation {  val httpProtocol = http    .baseUrl("http://computer-database.gatling.io") // Здесь находится корень для всех относительных URL    .acceptHeader(      "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"// Вот общие заголовки    .acceptEncodingHeader("gzip, deflate")    .acceptLanguageHeader("en-US,en;q=0.5")    .userAgentHeader(      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0"    )  val scn =    scenario("Scenario Name") // A scenario is a chain of requests and pauses      .exec(        http("request_1")          .get("/")      )      .pause(7) // Note that Gatling has recorder real time pauses  setUp(scn.inject(atOnceUsers(1)).protocols(httpProtocol))}

Чтобы запустить скрипт, откройте терминал в VS Code, и введите mvn gatling:test. Если вы хотите запустить определенный тестовый сценарий, вы можете вместо этого выполнить


mvn gatling:test -Dgatling.simulationClass=computerdatabase.BasicSimulation

Советую вам узнать больше о плагине Gatling Maven.


Gatling VScode с SBT


Если вы предпочитаете запускать и создавать свои Gatling проекты с помощью Scala Build Tool (SBT), я считаю, что проще всего сначала клонировать проект Gatling SBT Plugin Demo.


Как только вы клонировали проект, откройте его как обычно в VS Code. Перейдите на вкладку Metals в VS Code и нажмите Import Build:



VS Code теперь должен собрать ваш проект Gatling с помощью SBT.


Чтобы запустить все тесты в вашем проекте, откройте терминал и введите sbt gatling:test. Или же чтобы запустить конкретный тестовый скрипт, вы можете выполнить команду sbt gatling:testOnly computerdatabase.BasicSimulation.


Вы можете узнать больше о плагине Gatling SBT в его документации.


Резюме


В этой статье мы узнали, как использовать Visual Studio Code для создания наших Gatling скриптов. Мы рассмотрели, как создать и запустить Gatling проект с инструментами сборки Maven и SBT.


Несмотря на то, что IntelliJ IDEA остается моей предпочтительной средой разработки для разработки кода Scala и Gatling, здорово иметь возможность использовать и более популярный VS Code!




Узнать подробнее о курсе Нагрузочное тестирование



Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru