Что проще в использовании SoapUI или Postman?

Что проще для новичка, который будет работать в автоматизации простых запросов SoapUI или Postman?? аргументируйте пожалуйста!

хочется понять для себя, в чем я смогу быстрее и смогу ли вообще выполнить задачи!

1 лайк

У этих приложений разные задачи. Postman, по сути просто средство удобного хранения и повторного использования rest запросов. SoapUi - это уже полноценное средство автоматизированного тестирования. Хотя именно для REST он не очень удобен. В общем PostMan - это не автоматизация. А просто подёргать запросы.
Хм. Поправка. Оказывается они сделали его отдельным приложением. Не знал. Думал у них исключительно расширение для хрома. Но мнение своё не меняю. Для нормально автоматизации можно проще и своё сделать. Благо сейчас rest-клиентов под любые платформы завались.

4 лайка

Помогите тогда! Задача — нужно записывать запросы с к API и сравнить их с имеющимися на выходе т.е. создать тесты( имеется ввиду запись) и запускать проверку их с возможностью изменения

Какая тулза или стек подходит для этой задачи без скилов программирования?

API какой? Rest? Для rest оба подходят

В голову приходит - писать все запросы через прокси типа Fiddler / Charles / SoapUI (тоже умеет Recording Traffic | HTTP Recording) и т.д.
Полученные тела запросов потом закодить в тестах на любом вашем любимом ЯП (в SoapUI - см. ссылку выше).

2 лайка

без языка программирования можно обойтись?

Да хоть Jmeter) Хоть он и позиционируется как инструмент для нагрузки, но если использовать только в графическом режиме то и для функционального подойдет. Внутри и клиенты, и ассершены, и все что нужно. Причем умеет работать не только по http. Но это только временное решение, все-таки стоит задуматься об изучении программирования.
Postman, Paw - это программы с удобным графическим интерфейсом для работы по http. Лично я их использую для ознакомления с каким-нибудь новым апи, или если нужно явно (визуально) продемонстрировать запрос/ответ.
Когда в первый раз у меня появилась необходимость подергать эндпоинты, а языков я не знал - то пользовался утилитой командной строки curl. Очень мощный инструмент, до сих пор часто им пользуюсь для несложных запросов. Работать с ним нужно, как я уже сказал, в командной строке, а следовательно он может быть использован в bash скриптах.

5 лайков

Если хотите стать автоматизатором, то без языка никак. Что-то надо знать. Иначе это уже не автоматизатор а recorder. :)) Плюс, как правило, всё, что записывается не может потом воспроизвестись прямо ибо есть куки, дата/время, значения параметров какие-нибудь и так далее.

3 лайка

Можеш по пробивать Katalon studio мне он удобен для использования

1 лайк

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

Чтобы писать тесты, разобраться с программированием придется, но для базовых проверок нужны миниальные знания. В постмане есть примеры типовых проверок, которые можно подпилить под свои нужды (статус ответа сервера, время отклика, значение поля и т.д.)

7 лайков

В Postman тоже есть автоматизация, так что и тут SoapUI не лидер.

1 лайк

В Postman можно писать тесты, он даже генерит базовый код. Тесты поддерживают несколько языков

1 лайк

Если есть время, то сделай POC (proof of concept) на обоих инструментах. Набьешь шишки, почитаешь документацию. На многие вопросы тогда сам ответишь.

2 лайка

Только SoapUI. Он может и тестовые сценарии реализовывать, и в БД тестовые данные лить, и получать их для последующих ассертов.
Postman не может ничего кроме дерганья сервисов.

Что касается сложности, то осваивается при правильном настрое за неделю максимум.

1 лайк

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

Ну тут можно поспорить. Зачем тестам лесть в БД? По уму, должно быть тестовое API которое позволяет создавать и проверять тестовые данные.
К тому же вопрос был:

Тестовые данные Вы будете каждый раз ручками заливать? Или Вам они не интересны?
А, после отработки сервиса, вы только код респонда смотрите или еще и то, как в действительности (на живых данных) сервис отработал?

Я не хочу руками лить скрипты в БД каждый раз. Мне не достаточно ответа “200” или “201”.
И, понимая, что учиться нужно на упреждение решения более сложных и интересных задач, порекомендовал TS взяться за SOAPUI.

Спасибо за внимание.

1 лайк

Почему “ручками”? Тесты сами будут себе делать нужные объекты в БД.

А кто даст гарантии на это API? За годы работы тестировщиком я не раз убеждался что специально для тестовых нужд редко кто-то что либо делает, т.к. это не выгодно экономически, а использовать что либо из приложения в своих тестах не безопасно, т.к. там могут быть ошибки и другие подводные камни. В нашем деле можно доверять только себе )

2 лайка

Это если “по уму” сделано и если кто-то за вас ваше тестовое API уже протестировал и покрыл тестами…