testomat.io управление авто тестамиМогу лишь сказать что проект связан с морскими грузоперевозками. Используем 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 нет никакого желания. Первые тесты конечно будут сделаны очень быстро, но цена дальнейшей поддержки будет всё больше и больше возрастать.
Так яж не спорю что платная версия хуже или ее не стоит использовать 
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 недели на официально зарегистрированный в их трекере тикет, пиная периодически как сам саппорт, так и своего менеджера. Зато сразу понятно, какой продукт флагманский 
В общем по моему опыту. Если хотите 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, т.е. мы писали тесты и изучали язык и технологии в режиме реального времени
Какие мы получили от этого преимущества (сравниваю с бесплатной версией SoapUI, но и платная не сильно далеко от неё ушла, а на Java у нас только бесплатные и опенсорсные вещи взяты):
- Как уже показал на примере выше - у нас увеличилась производительность. Причем без изменения команды или других организационных мероприятий. Просто поменяли инструмент.
- У нас намного улучшился контроль разработки (код-ревью, контроль версий). В SoapUI в огромной XML’ке проекта было нереально разобраться что в ней поменялось и не сломалось ли что-то в другом месте.
- Появилась возможность делать параллельно разработку, в отличии от SoapUI, с его монолитным проектом. Там это было либо сложно, либо очень сложно. В Java же можно элементарно разнести задачи, а потом замерджить изменения в git’е в общую ветку.
- Возможность вести разработку в отдельной ветке (dev) и далее вносить стабильный функционал в master-ветку. В SoapUI - это было практически невозможно сделать и обходные пути требовали каких-то ручных действий и ненужных приседаний (отдельные проекты, импорт-экспорт TestSuite и т.п. вещи). Т.е. в Java у нас всегда есть стабильная версия тестов, которую можно гонять в любой момент, при этом мы можем (и уже дважды так делали) значительно переписать код.
- Практически пропала копи-паста, в SoapUI постоянно приходилось копировать логику из теста в тест и в случае изменения в ней - также править её отдельно в каждом тесте. Сами тесты стали более читабельными и понятными. В SoapUI было много непонятных костылей, и логика теста была непонятной обычному непосвященному человеку.
- Уменьшилось время на сопровождение и исправление тестов (хотя тут не до конца верно, т.к. из-за изначальных некоторых неудачных решений у нас возникли в дальнейшем потребности в глобальном рефакторинге). Но если в SoapUI нужно было вручную править каждый отдельный тест, то в Java за счет выделения логики и вынесения в отдельные классы правки делаются минимальные и их проще проверять и контролировать.
- Расширяемость + гибкость + кастомизируемость (отчеты, оповещение по почте, агрегатор ошибок и т.д.)
- Удобство работы с кодом в IDE. Я уже все глаза проплакал пытаясь разобраться в этих мелких закорючках в неудобном редакторе SoapUI. После него IntelliJ IDEA это просто какой-то праздник каждый день.
- Тесты стали более стройными, имеют лучшую читабельность, а также получили значительно больше дополнительных проверок и условий. Которые, в тесты на SoapUI было бы нереально добавлять (этот пункт дополняет пункт 5). Хотя тут, конечно на любителя и кому-то наш код покажется очередным макаронным монстром, но все познается в сравнении. И сравнивая с нашими предыдущими тестами в SoapUI мы видим изменения к лучшему.
- Последний пункт, но не последний по значению! Скорость выполнения самих тестов - при прямом сравнении теста на 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, хотя фишки платной версии и не дают мне покоя… 
)
Может сложиться мнение, что я хейтю 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 и по моему мнению какого-то вменяемого ответа не было дано.
Вот эти вопросы:
- как “эффективно” работать на одном проекте в команде?
- как избавляться от копи-пасты в тестах и делать удобные правки множества схожих тестов, если это требуется?
- еще вопрос был про токен, ответ в видео не попал и сам вопрос тоже по видео не до конца был понятен.
На первый вопрос докладчик ответил, что якобы нет никакой проблемы мерджить изменения в XML, ведь это просто текст, но это не совсем так. Проблема такая есть. Более того. Просто при открытии и закрытии проекта (если не указать закрыть без сохранения изменений) уже какая-то информация служебная будет записана в XML-проекта и её также нужно будет мерджить. При этом XML в отличии от обычного текста имеет строгую разметку и структуру и там нужно правильно и очень осторожно делать слияние иначе можно вообще разломать проект и он не будет открываться.
По вышеуказанной причине не очень удобно вести параллельную разработку в одном проекте разными людьми.
По второму вопросу он высказался в том ключе, чтобы выносить скрипты в поля и загружать их как и другие проперти. Но при этом они должны быть записаны в одну строчку. Весьма сомнительное удовольствие, особенно когда потом это нужно будет еще и мерджить. У меня были скрипты на десятки и сотни строчек. Если же скрипт состоит из нескольких шагов и нужно добавить в него еще один шаг или изменить или удалить и это нужно сделать во множестве подобных скриптов, то тут не очень понятно что нужно делать. Хотя там в докладе предложено редактировать XML в блокноте (или IDEA), только вот для более менее “нормальных” проектов размер такой XML превышает несколько десятков мегабайт. У меня один такой проект разросся до такого размера, что параллельно с ним уже ни один другой проект открыть нельзя было, да и сам он прилично так открывался даже в блокноте.
Так, что если показанных в докладе фишек вам достаточно, то можете использовать SoapUI. Инструмент добротный. Интерфейс по сравнению с JMeter’ом особенно для начинающих - небо и земля. Но если уровень тестировщиков в компании не днищенский, они готовы саморазвиваться, и SoapUI уже не справляется и объективно ограничивает вас в своих решениях, заставляя искать способ как это сделать в SoapUI, а не решать другую задачу - “как мне лучше протестировать эту фичу?”, то стоит глянуть в сторону более мощных и зрелых вещей. Таких как полноченные IDE. Если вам постоянно приходится в своих тестах писать много груви-кода, то скорее всего вы уже переросли в своих запросах то, что вам может предложить SoapUI.
2 лайка
Да, точно. Вы правы. Раздельные файлы в платной версии.
Я в своё время работал с ним довольно плотно именно из-за того, что учил новичков. Сейчас бы конечно делал через Cucumber или что-то подобное.
Замечу, что бесплатная версия потому и бесплатная, что там много удоброго функционала урезано. По этому никак не пойму упорное ее использование в течении длительного времени и паралельная критика.
Самая высокая стоимость платной лицензии 600 EUR за год. Не знаю, как где, но у нас это черверть зарплаты мидла в месяц. Неужели много? Причем это десктопная версия, для разработки тестов, а запускаються они потом чудесно скриптом на серверах с бесплатной.
[quote=“Mihail_Bratuhin, post:19, topic:11324”]
- как “эффективно” работать на одном проекте в команде?[/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 лайка