Вопрос по лицензированию и работе с SoapUI PRO

Могу лишь сказать что проект связан с морскими грузоперевозками. Используем SoapUI, потому что так заказчик захотел. Я бы использовал что то другое, т.к. SoapUI хорош только в проверке Soap сообщений, но очень часто с проверкой Soap идут сопутствующие проверки БД, mq и т.п.
Вы не сможете запустить тесты про версии на бесплатной если используете там функции платной версии. Не совсем понял про работу с библиотеками и ассерты. В бесплатной версии вас никто не ограничивает в подключении и использовании сторонних jar при помощи groovy, ассерты тоже есть, но в про версии больше готовых шаблонов, тем не менее, всегда можете использовать groovy assert.

1 лайк

Ну, я если честно не заметил проблем даже на бесплатном SoapUI при работе с БД или с MQ (работа с ним легко настраивается через HermesJMS или даже через Groovy, для “эстетов”).

Насчет “вы не сможете запускать тесты на Free-версии, если используются функции из платной” можно поподробней, а то я тут слышал нечто противоположное, что якобы через maven-плагин все же можно запускать эти тесты. Тут хотелось бы иметь полную ясность, т.к. от этого зависит число лицензий и соответственно бюджет.

Библиотеки - это вынос части кода в отдельные груви скрипты, чтобы избежать копи-пасты одинакового кода. Вот тут есть по ним описание: groovy-script-library. Отдельные шаги с Assertions про них вот тут немного написано: assertion-teststep. Суть в том, что иногда удобно не прерывать шаги, а выполнить код дальше, при этом сделать проверки чуть позже. При этом не хочется ставить общую настройку в TestCase, которая вообще не прерывает выполнение теста при ошибке на любом шаге. С Groovy Assert, наверно, может решить данную проблему, но в отличие от стандартных Assertions он прервется при первой же проблеме и не укажет на другие возможные ошибки (а вот Assertions отработают все), если же делать вывод в лог if-ами перед Assert’ами, то тогда можно что-то по логу еще увидеть, но это сильно увеличивает кодинг, а также усложняет чтение и отладку, а если в дополнение нет возможности Script Library (бесплатная версия SoapUI), то получается вообще печально.

У нас на проекте, к счастью, пока нет обязаловки использовать только один самый правильный инструмент.
По поводу работы с SoapUI у меня есть кое-какой опыт применения именно на soap/jms проектах и там он показал себя довольно хорошо. Часто слышал многие непонятные вещи в его сторону, но по факту было понятно, что люди просто не разобрались в теме и приписывали в минусы то, что минусом никак не могло являться. Например, переключение между контурами. У себя мы это решали просто перенеся в файл настройки и экспортом их оттуда в custom properties проекта. Главное тут при написании сценариев в нужных местах не завязываться на константы, а считывать их из custom properties и переключение между стендами занимает 2 секунды. В PRO-версии все еще проще с этим. Там уже есть Environment. Ну, и т.д. Вот поэтому из-за необоснованных “наездов” и из-за желания выбрать лучшее решение под свой проект и решили просчитать разные варианты и по удобству и по стоимости.

Из отмеченных мною плюсов SoapUI могу отметить несомненную простоту. Примером могут служить минимум 6 обученных мною сотрудников, причем 2 из которых “девушки-гуманитарии”. Правда не все из них пишут авто-тесты и просто проверяют, что-то вручную с помощью него, но порог вхождения по-моему скромному опыту оказался сильно ниже, чем с другими инструментами. А это тоже немаловажный фактор при выборе инструмента. Хотя, конечно, именно для авто-тестов это и не решающий фактор. Тут в противовес SoapUI мы смотрим в сторону Java + jUnit, возможно даже и новомодные огурцы и Allure. С Java конечно местами будет проще, местами наоборот. Но гуманитариям она уже точно не зайдет…

HermesJMS, устарел и не поддерживается уже давно. По этому мы на проекте используем Jar либы для конкретных MQ\JMS. Ну а вынос когда в либы можно спокойно делать в любой версии SoapUI, они легко подключаются через добавление Jar в lib или Ext директории. В любом случае если нужно тестировать что то кроме Soap\DB я бы выбрал любой Unit тест Фреймворк + любой ЯП по вкусу )

1 лайк

А, ну, так-то можно сделать, да. Просто если писать jar-либы, чтобы потом их подключать к SoapUI, то не проще ли сразу писать на Java и не использовать SoapUI вообще? Я бы понял одну-две специфичных штуки, если прописать через них. Но если хочется просто вынести в одинаковый groovy-скрипт из десятков однотипных сценариев, то почему бы не использовать для этого Script Library?

К тому же в платной версии кроме них есть и еще одна очень “вкусная вещь”, которую хотелось бы применить на проекте: data-driven-tests. У нас есть много сценариев со схожей структурой и проверками, но отличающихся входными данными. И вместо создания отдельных тестов применять данный подход было бы весьма и весьма удобно. И сэкономило время на разработку и особенно последующее сопровождение данных тестов.

Вот буквально пример из сегодняшнего. Пишем сценарии по конкретному методу. Там довольно большое число сценариев с проверкой многих условий и типов входных данных, граничных условий и т.п. И тут разработка изменила кое-что, поменяв промежуточный запрос. И тут сразу встает вопрос об актуализации уже разработанных сценариев… И после вот таких вот финтов конечно продолжать использовать бесплатный SoapUI нет никакого желания. Первые тесты конечно будут сделаны очень быстро, но цена дальнейшей поддержки будет всё больше и больше возрастать.

Так яж не спорю что платная версия хуже или ее не стоит использовать :slight_smile: SoapUI очень хороший инструмент для автоматизации именно Soap сервисов, просто если тесты выходят за рамки Soap ассертов, то тут начинается написание костылей в большинстве случаев.
P.S.: Чет наофтопили много, если говорить по теме, то я бы просто провел анализ ваших тест кейсов на предмет то что планируется в них проверять, если в большинстве случаев это Soap или DB проверки, то в принципе на платную версию можете забить, то что не покроют встроенные в SoapUI ассерты можно покрыть каким нибудь XMLUnit или при помощи других либ.

2 лайка

XMLUnit хорошая библиотека, сам использовал на одном из проектов, рекомендую

1 лайк

Забавное наблюдение:
Эту тему я написал примерно 2 месяца назад. За это время со мной не связался никто из продажников SmartBears ни в этой теме, ни через личку. При этом я слышал, что отдел QA у них вроде бы территориально находится в России ли какая-то из частей отдана на аутсорс в Россию. Т.е. мне кажется это очень странно, что представители или работники компании не используют ресурс одного из главных форумов пост-советского пространства по автоматизированному тестированию. Тем более, что тут по их продукту существует целый раздел и в целом инструмент довольно востребованный на рынке.

По поводу самой закупки, то из-за внутренних трений и некоторых технических нюансов и предстоящих изменений (изменение стека технологий к которому SoapUI будет не готов и потребует больших доработок и танцев с бубном) было решено не вкладываться в платную версию, а пилить авто-тесты на Java, а простенькие сценарии или отладку делать на бесплатной версии, т.к. она уже имеет весь нужный нам функционал, хоть и не всегда в удобоваримом виде. На Java вначале работать немного сложней, пока не написаны все нужные классы и методы, зато в дальнейшем работа с ней по сравнению с SoapUI - это просто сказка. Особенно, когда приходится править множество тестов или нужно делать приемку изменений или координировать работу нескольких сотрудников над одним проектом.

Так, что если кто-то как и я смотрит в сторону покупки SoapUI - взвесьте все “за” и “против”. Так как продукт не дешев (около 500 евро за одну лицензию на год минимум, а float-лицензия и того дороже), а стоимость владения со временем может только возрасти (и я тут не про ежегодную оплату лицензии, а про то, что множество уже написанных старых сценариев будут требовать постоянной актуализации и доработок). Тут, конечно, некоторые фишки платной версии “смягчают” эти обстоятельства, но все равно по удобству работы с полноценной IDE это даже рядом не стоит.

1 лайк

Приветствую.

У них не QA в России, а Customer Support - в Туле.

Мы пользуемся несколькими продуктами SmartBear - TestComplete и LoadComplete.
Если по TC поддержка молниеносная (в течение 24 часов, обычно быстрее), то по LC я ждал реакции 2 недели на официально зарегистрированный в их трекере тикет, пиная периодически как сам саппорт, так и своего менеджера. Зато сразу понятно, какой продукт флагманский :slight_smile:

В общем по моему опыту. Если хотите 100% реакции, то не надо никаких форумов - пишите сразу в саппорт и пинайте их, если не отвечают.

1 лайк

Благодарю, за ответ!
Уверен, что он будет полезен и другим участникам форума.

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

Советую поддержку по SoapUI искать, либо напрямую по официальным контактам, либо через их форум-сообщество.
Мне после скачивания бесплатной версии звонил прямо на мобильный менеджер и предлагал купить платную.

День добрый!
У меня был примерно такой же опыт общения с продажниками, только я искал систему мониторинга для тестовых серверов (проводили нагрузочное тестирование). Со мной в течении двух часов связался рускоговорящий специалист (звонили из Испании, по-моему) и спрашивал о том для чего нам их система и сколько мы готовы за неё заплатить. Я их поблагодарил, но покупать, конечно, мы ничего не стали. Написали, какую-то свою тулзу за пару дней на C#. На первое время нам её хватило. Так что с продажниками связаться всегда проще - они сами вас найдут и втюхают что-нибудь втридорога.

По-поводу же SoapUI, то мы от него в качестве тула для автоматизации отказались полностью. Чему я несказанно рад. Собственно, я и инициировал данный переход и полностью взял на себя риски данного мероприятия.

Могу сказать, что скорость разработки тестов не только не упала при этом, но и заметно возросла, а время поддержки значительно снизилось.

Недавно я подбивал статистику по автотестам за текущий и предыдущий кварталы и вот что у меня получилось на реальных цифрах:

За 2,5 месяца мы сделали Х тестов на SoapUI, а после этого за 4 месяца на Java было разработано 2,1 * Х тестов (более чем в 2 раза относительно тестов на SoapUI), т.е. на SoapUI у нас выходило в среднем 0,4 Х тестов в месяц, в то время как на Java - 0,525 Х (в месяц), что почти на 30% больше по средне-месячной производительности, относительно разработки на SoapUI. Более того, уже к концу первого месяца мы достигли производительности равной созданию тестов на SoapUI, т.е. в последующие месяцы она была даже выше 30%, а оверхед начальной разработки с нуля на Java не превысил срок в 1 месяц. После этого в целом и общем какой-то законченный “фреймворк” (тьфу-тьфу-тьфу) уже был готов и дальше просто писались тесты. Хотя тут стоит оговорится, что при разработке мы уже дважды проводили значительный рефакторинг и переработку кода всех тестов. Концепция менялась со временем и с появившимися новыми знаниями и потребностями. В дальнейшем скорее всего она также будет продолжать изменяться, т.к. есть еще много вещей, которые хотелось бы улучшить.

По поводу нас, то мы не программисты и даже не супер-пупер автоматизаторы с огромным багажом опыта. Даже Java по сути у нас была новым языком, т.е. изучение языка началось практически с момента перехода на него и отказа от SoapUI, т.е. мы писали тесты и изучали язык и технологии в режиме реального времени :slight_smile:

Какие мы получили от этого преимущества (сравниваю с бесплатной версией SoapUI, но и платная не сильно далеко от неё ушла, а на Java у нас только бесплатные и опенсорсные вещи взяты):

  1. Как уже показал на примере выше - у нас увеличилась производительность. Причем без изменения команды или других организационных мероприятий. Просто поменяли инструмент.
  2. У нас намного улучшился контроль разработки (код-ревью, контроль версий). В SoapUI в огромной XML’ке проекта было нереально разобраться что в ней поменялось и не сломалось ли что-то в другом месте.
  3. Появилась возможность делать параллельно разработку, в отличии от SoapUI, с его монолитным проектом. Там это было либо сложно, либо очень сложно. В Java же можно элементарно разнести задачи, а потом замерджить изменения в git’е в общую ветку.
  4. Возможность вести разработку в отдельной ветке (dev) и далее вносить стабильный функционал в master-ветку. В SoapUI - это было практически невозможно сделать и обходные пути требовали каких-то ручных действий и ненужных приседаний (отдельные проекты, импорт-экспорт TestSuite и т.п. вещи). Т.е. в Java у нас всегда есть стабильная версия тестов, которую можно гонять в любой момент, при этом мы можем (и уже дважды так делали) значительно переписать код.
  5. Практически пропала копи-паста, в SoapUI постоянно приходилось копировать логику из теста в тест и в случае изменения в ней - также править её отдельно в каждом тесте. Сами тесты стали более читабельными и понятными. В SoapUI было много непонятных костылей, и логика теста была непонятной обычному непосвященному человеку.
  6. Уменьшилось время на сопровождение и исправление тестов (хотя тут не до конца верно, т.к. из-за изначальных некоторых неудачных решений у нас возникли в дальнейшем потребности в глобальном рефакторинге). Но если в SoapUI нужно было вручную править каждый отдельный тест, то в Java за счет выделения логики и вынесения в отдельные классы правки делаются минимальные и их проще проверять и контролировать.
  7. Расширяемость + гибкость + кастомизируемость (отчеты, оповещение по почте, агрегатор ошибок и т.д.)
  8. Удобство работы с кодом в IDE. Я уже все глаза проплакал пытаясь разобраться в этих мелких закорючках в неудобном редакторе SoapUI. После него IntelliJ IDEA это просто какой-то праздник каждый день.
  9. Тесты стали более стройными, имеют лучшую читабельность, а также получили значительно больше дополнительных проверок и условий. Которые, в тесты на SoapUI было бы нереально добавлять (этот пункт дополняет пункт 5). Хотя тут, конечно на любителя и кому-то наш код покажется очередным макаронным монстром, но все познается в сравнении. И сравнивая с нашими предыдущими тестами в SoapUI мы видим изменения к лучшему.
  10. Последний пункт, но не последний по значению! Скорость выполнения самих тестов - при прямом сравнении теста на SoapUI и Java с абсолютно идентичной логикой совпадающей на 100% в обоих тестах, оказалось, что время выполнения теста на Java было в 5 раз быстрее, чем на SoapUI. Запуск был из системы управления тестами с помощью консольной команды. Итог: 4-5 сек на тест в Java против 20 сек тест в SoapUI. Возможно, что это был не очень удачный пример, т.к. на других более сложных примерах у нас такого же огромного прироста не наблюдалось, но там уже не было 100% совпадения по функционалу, поэтому сравнивать было не с чем (на Java тесты стали сложнее и богаче). Хочу еще раз отметить, что данный тест я провел в самом начале, когда еще только готовил переход на Java и был написан этот синтетический тест, который полностью повторял один из имеющихся тестов написанных на SoapUI и использующемуся у нас в регрессионной модели.

Ну, и напоследок дам ссылку на доклад с последнего Selenium Camp’а, где был обзор схожих инструментов, только вместо Java показывали Groovy, что для пользователей SoapUI может быть большим плюсом, т.к. в нем так же используются groovy-скрипты и не нужно много учить заново.
Fabulous tests with Spock and Groovy (Yaroslav Pernerovskyy, Ukraine)
Так что инструментов кроме Java есть много, многие из них уже довольно зрелые и удобные и многое дают прямо из коробки + позволяют работать в очень удобных IDE, а не гробить глаза в неудобных окошках SoapUI.
И что немаловажно - за все это часто даже не просят денег (у меня по крайней мере используется Community-версия IntelliJ IDEA, хотя фишки платной версии и не дают мне покоя… :pensive:)

Может сложиться мнение, что я хейтю SoapUI, но это не так. В своей нише для ручного тестирования данный инструмент весьма неплох и удобен. Позволяет быстро и без особых заморочек настроить его и начать работать. Дернуть сервис, проверить его работу вручную. Даже разрабатывая тесты на Java, можно иногда быстренько что-то протестировать предварительно в SoapUI и это не будет зазорно и даже наоборот весьма удобно и экономит кучу времени и помогает в работе. Возможно, что даже для “непритязтельной” автоматизации “на коленке” или для маленькой системы с небольшой тестовой моделью с одним автоматизатором-разработчиком такой инструмент будет приемлемым решением, особенно на первых парах, когда автоматизации нет вообще, но если ваши потребности выше, то советую глянуть в сторону более “взрослых” решений, тем более что они зачастую не сложнее, а даже проще и удобнее в работе и в целом дают множество других преимуществ (как перечисленные мною выше).

P.S. выше показанные выкладки могут содержать незначительные погрешности в связи с праздниками, отпусками, больничными и т.д. Но они не меняют картину в целом.

P.P.S. возвращаясь к главному вопросу - к деньгам. Данная операция нам ничего не стоила и даже более того - сэкономила значительные средства, время и нервы. Дала возможность по новой взглянуть на свои процессы и находить новые точки для их улучшения, а не тратить все свое время на копи-пастинг кода в SoapUI и бесконечные правки опечаток и т.п. вещи.

4 лайка

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

По частям можно работать только в платной версии, если не ошибаюсь. В ней же есть возможность выносить скрипты в отдельное хранилище и переиспользовать. Но зачем платить больше и работать в неудобном редакторе, если есть возможность перейти на полноценную и к тому же бесплатную IDE?

Недавно посмотрел довольно неплохой доклад по SoapUI с Selenium Camp’а:
SoapUI: one key to all doors (Yegor Maksymchuk, Ukraine).

В докладе была даже показана интересная фишка с подключением тестов SoapUI в Java проект. Фишка рабочая, но потенциал конечно у неё с моей точки зрения весьма сомнительный. Но фишка мне понравилась. За это - однозначный плюс докладчику.

Также в конце были высказаны вопросы, которые возникают у многих “опытных” пользователей SoapUI и по моему мнению какого-то вменяемого ответа не было дано.
Вот эти вопросы:

  1. как “эффективно” работать на одном проекте в команде?
  2. как избавляться от копи-пасты в тестах и делать удобные правки множества схожих тестов, если это требуется?
  3. еще вопрос был про токен, ответ в видео не попал и сам вопрос тоже по видео не до конца был понятен.

На первый вопрос докладчик ответил, что якобы нет никакой проблемы мерджить изменения в XML, ведь это просто текст, но это не совсем так. Проблема такая есть. Более того. Просто при открытии и закрытии проекта (если не указать закрыть без сохранения изменений) уже какая-то информация служебная будет записана в XML-проекта и её также нужно будет мерджить. При этом XML в отличии от обычного текста имеет строгую разметку и структуру и там нужно правильно и очень осторожно делать слияние иначе можно вообще разломать проект и он не будет открываться.
По вышеуказанной причине не очень удобно вести параллельную разработку в одном проекте разными людьми.

По второму вопросу он высказался в том ключе, чтобы выносить скрипты в поля и загружать их как и другие проперти. Но при этом они должны быть записаны в одну строчку. Весьма сомнительное удовольствие, особенно когда потом это нужно будет еще и мерджить. У меня были скрипты на десятки и сотни строчек. Если же скрипт состоит из нескольких шагов и нужно добавить в него еще один шаг или изменить или удалить и это нужно сделать во множестве подобных скриптов, то тут не очень понятно что нужно делать. Хотя там в докладе предложено редактировать XML в блокноте (или IDEA), только вот для более менее “нормальных” проектов размер такой XML превышает несколько десятков мегабайт. У меня один такой проект разросся до такого размера, что параллельно с ним уже ни один другой проект открыть нельзя было, да и сам он прилично так открывался даже в блокноте.

Так, что если показанных в докладе фишек вам достаточно, то можете использовать SoapUI. Инструмент добротный. Интерфейс по сравнению с JMeter’ом особенно для начинающих - небо и земля. Но если уровень тестировщиков в компании не днищенский, они готовы саморазвиваться, и SoapUI уже не справляется и объективно ограничивает вас в своих решениях, заставляя искать способ как это сделать в SoapUI, а не решать другую задачу - “как мне лучше протестировать эту фичу?”, то стоит глянуть в сторону более мощных и зрелых вещей. Таких как полноченные IDE. Если вам постоянно приходится в своих тестах писать много груви-кода, то скорее всего вы уже переросли в своих запросах то, что вам может предложить SoapUI.

2 лайка

Да, точно. Вы правы. Раздельные файлы в платной версии. :slight_smile:
Я в своё время работал с ним довольно плотно именно из-за того, что учил новичков. Сейчас бы конечно делал через Cucumber или что-то подобное.

Замечу, что бесплатная версия потому и бесплатная, что там много удоброго функционала урезано. По этому никак не пойму упорное ее использование в течении длительного времени и паралельная критика.

Самая высокая стоимость платной лицензии 600 EUR за год. Не знаю, как где, но у нас это черверть зарплаты мидла в месяц. Неужели много? Причем это десктопная версия, для разработки тестов, а запускаються они потом чудесно скриптом на серверах с бесплатной.

[quote=“Mihail_Bratuhin, post:19, topic:11324”]

  1. как “эффективно” работать на одном проекте в команде?[/quote]
    Проекты в SoapUI композитные, т.е. на практике разные люди работают с разными файлами. Служебная информация, которая сама по себе записывается в другие файлы - ингорится, т.е никуда не комититься, т.к. не нужна.

Вынос переиспользуемого кода во внешние библиотеки, как и везде (в groovy/jar файлы).


Пока самый значимый для меня недостаток в данном ПО - плохое автодополнение в groovy коде.

Сейчас как раз идет объединение с другим проектом, где самописный фрейморк на Java для тестирования аналочичного REST сервиса. Честно, даже смотреть туда не хочеться после SoapUI, так все не интуитивно.

1 лайк

аналогичная ситуация, собрались наконец с силами и прекратили пинать мертвую лошадь под названием SOAPUI.
от себя добавлю в минусологию:

  • категорически невозможно рефакторить resources раздел, который описывает используемые ендпоинты.
  • бесплатный soapui это стыд который людям нельзя даже показывать. Он похож на демо проект из начала 2000х, с архаичным интерфейсом и кучей багов. очевидно что поддержку его прекратили и ReadyApi! (платная версия) переписали чуть ли не заново
  • “как эффективно работать в SoapUI на одном проекте в команде?”
    Никак. deal with it

Михаил, на какой инструментарий вы поменяли Соап? И какие на ваш взгляд еще есть альтернативы? Цель - автоматизация регрешна для RESFul API.

1 лайк

Не могу похвастать 1/4 ЗП в 600 евро. Наверно я еще не миддл. И я ни разу не встречал чтобы закупку ПО для работы делал линейный сотрудник на свои кровно-заработанные, но возможно и были прецеденты (кресло и мониторы люди иногда покупали - это правда), к тому же это ПО непонятно как проводить через безопасность и через аудит. В основном такие вещи выносятся на уровень выше и вносятся в штатное расписание по закупкам и делается вовсе другими людьми и отделами, особенно в крупных компаниях. Особенности бюджетирования в крупных компаниях - это тема отдельного разговора. От того, что что-то было или не было закуплено я нисколько не проиграл. Все плюсы/минусы перехода я описал выше и привел примеры с раскладами по своему конкретному проекту. На других проектах и в других условиях все может быть иначе.

А почему сравнивал с бесплатной версией - потому что с нею до этого я работал и сменил бесплатный инструмент на другой бесплатный. Почему я должен был сравнивать с чем-то другим? К тому же, я указал те вещи, которые в платной версии работают несколько иначе и лучше, чем в ограниченной бесплатной версии. При этом в платном ReadyAPI!, хоть и исправили какие-то вещи и добавили кое-какие удобные функции - это все равно не идет ни в какое сравнение с тем, как удобно работать в полноценной среде разработки, например, в IntelliJ IDEA. Мои расклады я все привел выше и ничего нового там добавить нечего.

@Dmitry_Gr не очень понял вашу ситуацию, если вы уже распрощались с SoapUI, то значит уже куда-то смигрировали или вы просто выбросили инструмент и остались без ничего на проекте? Или же вы еще никуда не смигрировали, но у вас накопились “претензии” к SoapUI и вы уже четко для себя решили, что нужно что-то менять и куда-то мигрировать, но еще не нашли куда?

Когда я мигрировал, то смотрел по ситуации на своем проекте и текущим задачам, ресурсам, по рынку и т.д. Более того, переезд не был сразу выполнен и сначала в режиме “партизанской” разработки создавался новый фрейморк и пара тестов, которые бы показали применимость данной технологии и позволили бы уже на цифрах сравнить старое и новое и увидеть какие-то проблемы заранее, особенно с обучением новому инструменту. Тогда-то и смогли замерить реально два однотипных сценария и сравнить их производительность между собой.

Причем первые черновые вещи и тесты писались вообще в полу-процедурном стиле, без особого ООП и всяких паттернов проектирования. Задача была сделать быстро и на коленке, показать результат и сравнить со старым. После этого получить “добро” от нужных людей и начать уже полноценную миграцию. Причем у нас старые тесты до сих пор еще некоторые на SoapUI живут и здравствуют и пока не собираются на покой. Причем эти тесты еще с 2015 года так живут. Просто новое ничего на нём не создаётся и если есть время, то некоторое старое переписывается, но времени обычно нет.

По поводу автоматизации, то я бы на вашем месте глядел в сторону dev-ops разработки и того какие для этого нужны инструменты и что больше подойдет вам (возможно уже имеется и применятся в компании). К сожалению, я пока могу только что-то из мира java вам посоветовать, но думаю, что с SoapUI проще всего именно туда переходить, все-таки там Groovy был и он тоже из мира Java.

именно так, сейчас анализируем возможные варианты для миграции. Приоритетный InteliJ + JUnit + RESTAssured. Так же рассматривается описанный выше вариант Groovy + Spok. На это все конечно будут демки и POC, интересует опыт людей которые уже прошли этот путь и набили шишек с другими инструментами для restful автоматизации

1 лайк

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

по мне soapUI отлично подходит для ручного тестирования. Но для автоматизации я бы использовал связку java+restAssured из-за гибкости.

p.s. Писал автотесты на SoapUI Pro около года.

2 лайка