а тут извне параметром управляешь тем как будут идти скрипты

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

да, тогда мавен - инстанс будет апдейтится везде. но я сам не использовал, тут лучше всего @smirnovqa расскажет

Если у кого какие идеи есть - рад буду услышать!

если я правильно понял суть вопроса, то почитай об использовании Test Fragment

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

это так же удобно, когда над одним тест-планом параллельно работают несколько человек, каждый над своей частью

у меня используются и фрагменты и include conrollers

вот об этом идея и есть

хочется организовать как можно более гибкую работу нескольких человек над этим тоже

Сложно. Почти всегда приходится проверять на разных версиях. И копировать скрипт или его часть, с помощью Ctrl+C / Ctrl + V проще зачастую. Мы пока так делаем.
Используя Test Fragment, как Max советует.

Для Groovy скриптов и построцессоров внешние файлы.

Есть коллеги, которые используют Include Controller, и импортируют в jmx-скрипт другие jmx-скрипты. Это такой подход к командной разработке одного скрипта. Я пока не использовал. И в Gatling тоже пока библиотеки с сценариями тоже не используем — копируем нужные части кода  в новый сценарий. А пишем так, чтобы удобно скопировать и вставить в другое место.

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

Если есть желание, то можно новые сценарии писать на Gatling. А переписывать долго. Старое оставить в JMeter.

можно ли с гатлинга что-то выиграть? Преимущества какие?

Можно, код удобнее переиспользовать

Можно накидать себе common модуль какой то

Преимущества:
* scala: наследование классов
* написание больших сценариев (за счёт более быстрой поддержки и рефакторинга)
* отладка с точками останова из idea
* лучший контроль версий, он тут точно будет

Недостатки:
* scala: её надо понять
* первую версию скрипта писать дольше, чем в JMeter, выигрыш будет при поддержке код
* отладчик не самый удобный, получить тело ответа можно не в едином виде (Tree View Controller), а поставив точку останова в нужном месте (прерывание) или залогировав запрос и ответ (через отладочную печать) — особо неудобно, если отлаживать AMQP, JMS, ... что-то, что нельзя отправить через HTTP Proxy

преимущества конечно хороши. Особенно отладка в idea и контроль версий!

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

И на данный момент Gatling потребляет меньше ресурсов при тестах по протоколу HTTP, чем JMeter. Так как создаёт меньше потоков