Когда используется json, ингода хочется получить конкретное поле (а их может быть много с таким именем, в разных местах), причем вложенное, тогда xpath extractor гораздо элегантнее в использовании.

Благодарю за пояснение)

Всем привет, подскажите, может кто-то сталкивался с такой ошибкой jsr223 preprocessor?:
org.codehaus.groovy.GroovyBugError: BUG! exception in phase 'semantic analysis' in source unit 'Script5.groovy' Unsupported class file major version 61
at org.codehaus.groovy.control.CompilationUnit$ISourceUnitOperation.doPhaseOperation(CompilationUnit.java:905) ~[groovy-3.0.7.jar:3.0.7]
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:627) ~[groovy-3.0.7.jar:3.0.7]
С чем может быть связано?

Если регулярка не адовая - то regex будет НАМНОГО быстрее

Подробности тут

https://habr.com/ru/post/518702/

В jmeter можно применять экстракторы не к запросам - а к переменным

Это порой здорово помогает в сложных случаях.

Выдираете кусок ответа в переменную, а в куске ответа уже ищите

https://gist.github.com/CMCDragonkai/6c933f4a7d713ef712145c5eb94a1816
В таблице в колонке Java
там где стоит No - это не поддерживается и может приводить к ошибкам

Репост из канала Данилы Кутенина (орфография и пунктуация автора) про тестирование движка для регулярных выражений:

В последние 2 недели периодически, когда мне было лень работать, я пытался сделать что-то интересное, но до большого и громкого поста не дотягивало. В любом случае, поделиться стоит.

Меня задолбали различные движки регулярных выражений и каждый раз, когда я смотрел на них, мне хотелось понять, как они под капотом тестируются. После изучения многих библиотек, я понял, что поддержка огромного количества токенов так грустно покрыто юнит тестами, что я захотел либо найти достойное тестирование (спойлер, не нашёл), либо десятки багов в этих движках. Суммарно за несколько дней я нашёл 11 багов, 2 в boost (уже были зарепорчены 1, 2), 4 новых в hyperscan, 5 новых в compile time regular expressions (будущие regex в плюсовом стандарте) и огромное количество (нет, просто капец тьму) несоответствия между синтаксисами различных движков, например, что в RE2 синтаксисе whitespace (\s) не поддерживается вертикальный tab \v, хотя во всех остальных движках оно одинаково поддерживается. Или даже лучше (не баг, различие в грамматиках):

#include <boost/regex.hpp>
#include <regex>
#include <iostream>

int main() {
  {
    std::regex e{"\\<\\<\\w+"};
    std::cout << std::regex_search("a ", e) << std::endl; // prints 0
  }
  {
    boost::regex e{"\\<\\<\\w+"};
    std::cout << boost::regex_search("a ", e) << std::endl; // prints 1
  }
}

Python RE, PCRE/PCRE2, RE2 прошли тестирование. Видимо, big tech является для них самым главным тестировщиком :)

В отличие от стандартного тестирования, я пытался сделать что-то новое, а именно

1. Создаем случайное валидное регулярное выражение, например, с помощью случайного дерева или автомата
2. Если движок отказывается его компилировать, это баг. Можно здесь ещё считать majority от движков и репортить те, которые не подчиняются ему
3. Создаем строки подходящие под это регулярное выражение, если они не матчатся, то это баг. Создаём почти подходящие строки, если они матчатся, это баг. Здесь я использовал идеи из статьи egret и питонячнее .sre_parse
4. Фаззим с помощью libfuzzer входные строки для поиска, пытаемся найти рантайм баги и сверяем корректность у majority движков

У многих движков настроен фаззинг, только они не проверяют полноту. К счастью, видимо, весь хлеб такого тестирования фаззинг у меня и забрал, мой план лишь быстрее увеличивал покрытие. Например, такой план увеличивал покрытие hyperscan до 90% за 2 часа, когда как обычный фаззинг делал это 3 дня.

Несмотря на баги, hyperscan всё ещё считаю лучшим движком by far от всех остальных. Там очень много очень классного кода, написано хорошо, работает очень быстро (сотни мегабайт в секунду). Недавно узнал, что там можно собирать регулярные выражения в satisfiability дерево, например, в ((1 & 2) | (!3 & 2)), где 1, 2, 3 — регулярные выражения. Так они ещё там внутри и оптимизируются.

Если говорить про различие синтаксисов, то есть неплохая табличка.

Ну, 11 багов, that ain't much but that's honest work. Надеялся на много десятков минимум :)

Дождалися
https://github.com/gatling/gatling/milestone/100?closed=1

Добрый день, коллеги! 😌
Столкнулась с такой проблемой: банковская система не позволяет авторизоваться в одном клиенте под разными пользователями (в одном браузере на разных вкладках), из-за чего я не могу стартовать НТ. Мой вопрос: я могу  генерировать для запросов пользователя некий уникальный хидер, который говорил бы серверу о том, что каждый из пользователей авторизован из разных клиентов? Использую JMeter 5.4.1. Спасибо 😇

Let's deprecate ${} and introduce #{} so new Java and Kotlin users will directly go with the new syntax.

гатлингисты держитесь 😆

и тут же следом) https://github.com/gatling/gatling/releases/tag/v3.7.1

Ну может проще будет кому-то)

да это всё богомерзкие коклины, там пришлось бы экранировать всегда доллар

@vladimirsitnikv смотри как интересно выкрутились)

Я не пойму. Они сделали официальный Kotlin DSL?

хотя, судя по репозиторию на Kotlin у них пока только примеры

Похоже лучше сразу писать на stackoverflow

DSL то один