Jmeter подводные камни. Часть первая.

USER DEFINED VARIABLES

Все переменные, заданные в этой таблице будут проинициализированны непосредственно после запуска скрипта.
Не стоит использовать этот элемент для переопределения переменных перед каким-либо контроллером.
Лучше воспользуйтесь “User Parameters”

Путь к jmx файлу и исполняемому файлу jmeter
Все пути в скрипте рассчитываются, понятное дело, от исполняемого файла.
Для переносимости и мультиплатформенности проще все тест планы и необходимые файлы держать в одной папке, тогда
используйте относительные пути от файла тестов, вот путь к исполняемому jmx:
${__BeanShell(import org.apache.jmeter.services.FileServer; FileServer.getFileServer().getBaseDir();)}${__BeanShell(File.separator,)} 

При нагрузочном тестировании не используйте тяжелые компоненты

Как уже было сказано отключите все лишние listener, Debug Sampler, запускайте тест из консоли.
Отчёт лучше строить по итогам теста, но не в онлайн режиме.
От себя добавлю, что если необходимо вставить свой семплер, то пишите его на Java и используйте компонент Java Request
Вот сравнительные тесты.


Использование Module Controller

Тут ошибок можно наскрести на ровном месте, ибо стоит только поменять букву в названии верхнего контроллера и все ссылки порушаться.
Используйте переменные как названия тестов или сэмплеров!
Для нумерации подпунктов тоже можно использовать переменные или скрипт, как пример вот:
${__BeanShell(ctx.getThreadGroup().getName().split(" ")[0])}.01.01
${__BeanShell(ctx.getThreadGroup().getName().split(" ")[0])}.01.02 и т.п.


Говнокодинг (немного лирики)


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

Комментариев нет:

Отправить комментарий