Комментарии 4
Есть много вопросов и комментариев, по большей части по тому что я довольно давно пропагандирую подобный подход и радует, что вы уже в начале пути.
Комментарии:
Кажется, что сервисная история должна упрощать процессы и снижать бюрократизацию, судя по набору требований из таска к вашей команде там у команды появляется очень не сервисная активность в виде сбора и формализации кучи вещей, которые ещё и вероятно будут заставлять их заниматься уточняющей коммуникацией. Мы ходили по такой модели, лучший вариант - это ввести практики которые бы собирали за них весь этот набор или давали бы его в полуготовом виде.
Сами UI-ые скрипты JMeter, конечно имеют преимущество над кодовыми решениями, но степень их поддерживаемости, переиспользуемости и прочих благ очень слабая. Чем больше вариантов каждого теста, чем больше продуктов это становится все сложнее. Нужно поменять креды юзера везде? Нашёл скрипт, открыл на локалке, поменял, закрыл, сохранил, залил. И так с каждым. С аналогичной проблемой сталкивались и мы, тут могу порекомендовать уехать на jmeter-java-dsl если хотите jmeter.
Вопросы:
Почему вы записываете сценарии а не нагружаете апишку в соответствии с тем количеством рпс которое приближено к проду. И если у вас сценарный подход то как вы матчите рпсы с прода и сценарии?
Почему бы не тестировать каждый релиз и каждый сервис, вместо того чтобы рождать сущности в виде регламентом и устраивать охоту на ведьм когда кто-то идёт мимо него?
А кто валидирует результаты тестов и ищет перформанс проблемы? Этому научить например функционального тестера очень ресурсоемко, а если заниматься этим самостоятельно то получиться что при большом количестве релизов вы будете постоянно находится в этом анализе. Мы эту проблему решили собственным анализатором результатов (Quality Gate) который не пустит в прод если есть проблема и сам ее максимально подсветит, чтобы была возможность команде ее самостоятельно решить.
Почему тесты идут с минимумом заглушек? Если надо запустить 2 теста параллельно они ждут когда стенд освободиться? Если это блокирует релиз то это очень негативное влияние на тайм ту маркет
Очень ещё интересно, а много вообще желающих этому обучаться внутри команд?
Если могу помочь - приходи, телегу знаешь)
В целом очень круто, выглядит как набор правильных решений на старте, а чтобы не было больно потом я надеюсь помогут комменты выше)
По вопросу №3 можно поподробнее как Вы это реализовали? Невольно вспоминается https://ru.wikipedia.org/wiki/Квартет_Энскомба при взятии в расчет только сухих цифр без анализа графиков.
Спасибо большое за фидбек!
Ответы:
Мы взяли интенсивность с прода, масштабировали под наш стенд и приблизили интенсивность к проду по методам. Использовали для подбора интенсивности метрики с прода
К этому варианту мы и идем. Сейчас поняли, что такой подход не работает и нужно пилить пайплайны с НТ
Сейчас я репортую о найденных проблемах в чаты и разработчикам. В дальнейшем хотим сделать что-то типа комитета, который будет учавствовать в разборе проблем перфы
У нас пока не такое большое кол-во тестов, чтобы блокировать друг друга. Есть инструмент, который позволяет кидать задания в очередь
Есть те, кто сопротивляется и есть те, кто сами приходят. Как всегда все
Звучит неплохо, надеюсь у вас получилось быстро всех организовать и было много заинтересованных ) Вопросы:
Какие типичные нагрузки подаются в тестах / приходят в Прод? Знаю что Jmeter с синхронным движком много не выдерживает, вопрос - не сталкивались ли с этим
Что с тестированием производительности БД - где проводите, делаете ли копии / наполнение БД прод данными и как ловите там баги производительности?
Load as a Service: нагрузочное тестирование в inDriver