спс

Воооот не зря нам говорили что надо экспресс-репорты хранить , надёжно)

а можно логфайл хранить. он даже жмется хорошо, при желании

Всем привет! Интересует следующее:строим процесс нт с нуля и в качестве инструментария приняли решение выбрать жметр. На проекте планируется n-людей и хотелось бы узнать/услышать советы/мнения:
Best practice  по разработке скриптов. Те вся система представлена ручками апи и какой подход лучше выбрать в разработке скриптов? Это будет один сценарий со множеством хттп реквевестов или модульный? Как лучше подойти ,чтобы вести разработку скриптов командой? Может уже все придумано?

Если планируется n людей то лучше заводиться на переиспользование кода или элементов теста

Делать несколько скриптов вместо одного удобнее.
Несколько человек могут не мешать друг-другу. Проще гитовать изменения.
Если один скрипт, и в нем 10 Thread Group, то надо условно x10 памяти для запуска, а на каждый из 10-ти скриптов надо х1 памяти - отлаживать проще.

Использовать Module Controller + Test Fragment удобнее, чем использовать просто запросы большим списком.
В JMeter работает Ctrl+C / Ctrl+V блоков из скрипта в скрипт. И если кто-то в скрипте 1 обновил/улучшил фрагмент Login, то в скрипты 2-10 можно будет перенести новый блок через Ctrl+C/Ctrl+V.
Если не будет модулей, то обмениваться общими участками кода сильно сложнее.
В имени фрагмента удобно указать версию сервиса, для которого написан сценарий.
Копирование участков кода по мере необходимости из проекта в проект из скрипта в скрипт проще, чем поддерживание общего набора библиотек. Из-за версионности сервисов - версий много.

Как писать сценарий - на отдельные методы или на всю систему?
Зависит от требований. Если важно измерить сквозной сценарий и для него есть требования (интенсивность, ожидаемое время выполнения), то тест пишется на сквозной сценарий. Вообще всегда стоит иметь такой сценарий.
На отдельные методы и сервисы тесты тоже пишутся. Быстрее запускать тесты на сервис "А", если изменения были внесены только в сервисе "А". Но тогда надо будет заглушить все другие сервисы ("Б", "В", ...). Если заглушек нет, то проще не делать тесты на отдельные методы.

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

Присоединяюсь к мнению
Коллег выше, но вместо test fragment + module controller

мы используем include controller + test fragment (отдельные jmx-файлы)

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

Но это не очень большой минус, если прописать ассоциацию на jmx-файлы:
Ctrl+c пути, win+r, ctrl+v, enter
И тест фрагмент открылся в отдельном жметре.

Подумал. Module Controller + Test Fragment - не сильно добавляют удобства по сравнению просто с Transaction Controller. Если придерживаться понятного наименования блоков, то модули не особо нужны, транзакций хватит. Главное не делать большую простыню запросов.

С простынёй запросов - мы зависим от того, что в системе есть :)

Если высокая интенсивность работы, то стоит учитывать расходы на парсинг Include Controller-ов. Расходы есть. Парсинг на каждой итерации будет

Если скриптов больше 5, то копипаста даже одного логина из скрипта в скрипт добавляет рисков облажаться

И ручной работы

Иоанн говорит про Gatling

А человек, который задал вопрос - про жметер :)

виндузятник треклятый

Я тебя тоже люблю :)

реди ту старт холивар?

xD

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

Вот можно развести холивар на тему - а что самое затратно в нагрузке?
Считаю, что не разработка скриптов.
Что угодно только не этот этап