Мы в эту сторону думаем тоже и нам был бы полезен реальный кейс

Это да, но 65к фейлов и положили его)

если у вас 65к фейлов — всё равно не верю, что они все разные и нужно каждый анализировать индивидуально

тут нужен сразу какой-то AI для классификации

Супер, я могу прислать информацию, в каком виде получилось у меня.

))) АИ для таких задач не нужен

И, собственно, идеи/проблемы тоже.

Можешь мне в личку слать

Там и договоримся про созвон

Окей. Думаю, ближе к вечеру доберусь.

да неважно, с ним или без него — главное, что без классификации пихать в отчёт 65к сбоев — это издевательство. не над инструментом, а над читателем отчёта

Да важно, потому что внедрять в репорт АИ занимает 7 лет, как мы знаем. А классификатор можно сделать за неделю

есть ассерты, статусы у них error/failure, например.

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

я как раз имею в виду не "универсальный AI, который может всё", а конкретный классификатор, натасканный на jmeter

Это не сложно

вот именно

Нет ничего странного, на 3 миллионах тестов 65к упавших, это как 65 упавших на 3к.
Но на счёт АИ и думали, классификация матчится хорошо.

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

Так же кейсы, по утечке памяти, или наоборот лишнего кеша, или синка базы, неочевидные косяки которые происходят не сразу, а через длительный промежуток времени, а так дали прогрев, дали нагрузку, вышли на нужную интенсивность, на за 4 часа, а быстрее и погнали функциональное, расширяем покрытие, нам в основном это нужно для кост сейвинга, делаем сравнительно быстрее и дешевле аля А/Б тесты, но для оптимизации кластеров, определения оптимальных конфигов