Обновить
Комментарии 4
после каждого запроса идёт длинная череда assertions


А одинаковые проверки копипастили из кейса в кейс? Вообще, насколько легко сопровождать и актуализировать такие автотесты? Повторного использования и абстракций в JMeter ведь нет.
Непростой, очень неоднозначный вопрос.

С одной стороны всё так. Jmeter инструмент совершенно для другого, но, как ни странно, я не почуствовал никакой тяжести в том, чтобы поддерживать это два месяца и оставить в таком виде, что могу без проблем к этому вернуться.

Jmeter поддерживает видимость значений и переменных в иерархическом виде. Если мне нужно было поменять цель для тестирования с dev на test окружение, я просто редактировал одну единственную переменную в самом корне теста. Были переменные ниже по дереву, были те, которые работали только на уровне тест-кейса или http request

В общей массе кейсы это модификации кейсов, которые уже были, поэтому в 70% случаев кейс за основу для кейса брался другой simple controller в котором уже были созданы пользователи, получены токены для авторизации, созданы какие-то сущности в базе и т.д.

копипаст assertions также не был проблемой. Assertion болванки были правильно настроены как получать из сообщения код ответа, выдрать необходимое значение JSON и т.д. редактирование болванки требовало только подставить значение, или даже оставить так как есть.

С другой стороны такой копипаст требует значительной доли внимания и сосредоточенности.
А чем был обоснован выбор Jmeter для тестирования по сравнению, например, с SoupUI? Все-же JMeter в первую очередь имеет целевую аудиторию в виде performance testing, хотя и может быть успешно использован для автоматизированного тестирования.
Ну, я примерно об этом и писал. Работать для данного проекта оказалось легче в одном русле. Т.е. SoapUI прекрасная программа, но исторически пересекался с ней редко. Отправляясь в экстренное путешествие, когда на сборы немного времени, лучше ориентироваться на конечный результат — качество продукта и время на исправление дефектов, а не на инструмент.
Я не мог точно сказать, сможет ли быстро SoapUI сделать всё, что мне нужно, и смогу ли я сделать это хорошо на нём сразу. А про Jmeter знал, что он мне даст всё, что нужно для данной задачи.

Бывали и обратные примеры в моей практике. Написал скриптик на чем-нибудь, протестировал, а потом подумал «а вот бы тоже самое, но в 50 потоков», и такая библиотечка находилась. А меня спрашивали «А почему не Jmeter для нагрузки?»

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