Comments 43
Не сталкивались с SoapUI?
Было бы интересно увидеть такую же статью + сравнение.
Есть еще альтернативы? (поскольку по моему мнению в обоих решениях UI хромает)
Как альтернативы, могу посоветовать Fiddler и Advanced REST Client(хотя UI там хуже, чем у Постмана). Остальное — это библиотеки для ЯП.
у постмана совсем неконтрастные цвета (светлосерый на белом). что бы прочитать некоторые вещи нужно серьезно напрягать глаза

image

Имхо, лучше не стало. Все равно темно серый цвет на черном фоне. Контрастней не стало.

Сталкивались, но использовали его для ручного тестирования, именно, Soap сервиса. В этом случае он удобнее чем Postman, из-за возможности импорта запросов из WSDL. До автоматизации и более глубокого изучения дело не дошло (возможно из-за отталкивающего UI). Честно говоря, до вашего комментария и не знал, что там есть возможность писать тесты. Погляжу на него поближе.
Как сказал hprot из альтернатив использовали только библиотеки из ЯП (Codeception)
Ну строго говоря, чтобы делать «нормальный» автомат (тестовый стенд) на SoapUI, с вот-этим всем типа CI, CLI (command line), сценариями и мокапами нужен уже SoapUI Pro, который вовсе не бесплатен…
в сетинге можно настроить темную версию ui она контрастнее.
не понятно зачем тестировать сервисы вот так, проще же используя нормальный код тесты писать особенно если API меняется часто, а постман так для беглой проверки работает или нет, если с УИ тестами то понятно, что ручками потыкать иногда проще, то тут чисто работа с данными это всё равно что тестировать базу через клиент + сохранённые sql запросы
Тестировать внешний интерфейс тоже нужно.
проще же используя нормальный код тесты писать

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

Есть мнение, что версионность апи — зло, по крайней мере явное указание версии в урле или хэдерах.

Возможно я неправильно понял вопрос. API меняется часто, но поддержку старых версий никто не отменяет. Поэтому тесты помогают проверять, что клиенты, которые по каким-то причинам не могут обновиться будут работоспособны.
У нас, например, на некоторых проектах постман коллекции генерируются из тестов. Это удобно, т.к. если какой-то тест начинает падать — его можно всегда в постмане «руками» прогнать, покрутить параметры и т.д.

Ну и плюс иметь постман коллекцию удобно, если у вас ручные тестеры проверяют апи запросы.
А пробовали paw.cloud?
Выглядит прогрессивнее.

(Лично я по старинке пользуюсь REST Client что в VSCode, но присматриваюсь к профессиональным решениям)
Можно ли включать в документацию json-schema? А генерировать сервер и/или клиентов? Как по мне основной плюс подобных решений должен быть в автоматической синхронизации кодовой базы и документации. Как минимум возможности в любой момент проверить соответствие. Как я понял, постман такой возможности не предоставляет?
В документацию будет включён весь запрос с описаниями. Т.е. если в запросе будет json, то он будет и в документации. Также можно сохранить в запрос и варианты ответа (examples).
Генерация mock сервера есть, а клиента, насколько мне известно, нет.
Мы пользуемся Postman во время разработки, и когда появляется новый endpoint, разработчик вместе с тем создаёт и request в коллекции для ручного тестирования. Автоматического создания и синхронизации из кодовой базы там нет.

Json просто как пример или полная схема? Ну, например, есть в схеме для tv4


 "properties": {
        "type": { "enum": [ "residential", "business" ] }
      }

попадёт это в документацию?

Нет, просто, как пример. Json-schema используется для валидации, но в запрос ее не вставить, увы.

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

Все бы хорошо, но увы, что Postman, что ARC ужасно тормознуты на файлах json от мегабайта и выше.
Поэтому перешёл на Sublime text + плагин Requester.

Один раз понадобилось воспользоваться, ощущения неприятные. Адовые тормоза на простейших задачах и нескольких разных системах

Подскажите пожалуйста как задать какой-то определенный заголовок (header) что бы он присутствовал в каждом запросе (например Accept: application/json)


Если верить ихнему Issue Tracker то такой запрос отклонили — мол можно будет делать через Pre-request Script… но у меня это никак не завелось или руки кривые (не спец по JavaScript). Может кто какой пример приведет?

Динамически добавить дополнительный заголовок в запрос нельзя. Можно пользоваться плейсхолдерами в заголовках для изменения ключа и значения, если они установлены заранее.
Экспортированная коллекция имеет простой json формат, написать небольшой скрипт на том же javascript, который модифицирует все ваши запросы и добавит заголовок, не должно составить труда.
Как дела у PostMan с поддержкой Socks Proxy?

Когда PostMan был расширением браузера, то всё зависело от настроек браузера. А как оно для отдельного приложения?
А что, если я скажу, что Postman — говно.
Выжирать 500 метров — это много.
Но узнал новое из статьи.
Я конечно не совсем в теме, но мне непонятно, зачем использоваться Postman для тестов, если 100лет уже есть JMeter и похожие продукты. Да Postman довольно симпатичный UI для вызова http-запросов, но зачем тащить его в тестирование? Буду рад, если кто-то меня просветит.
Я полностью согласен с Frank59
Postman функционально не лучше JMeter, и у последнего есть существенный плюс — он может запускать тесты из косоли, или из CI.
А вот для одноразовой проверки какого-то сервиса или отправки запроса куда-то — Postman удобен.
И, кстати, в кровавом ентерпрайзе стандарт — SoapUI. Сложный, не самый удобный, но на нем можно все.
Jmeter обладает более объемным функционалом — факт.
Но для CI e Postman есть такая штука как Newman:
«Newman is a command line collection runner for Postman. It allows you to run and test a Postman Collection directly from the command line. It is built with extensibility in mind so that you can easily integrate it with your continuous integration servers and build systems.»
Ссылка

Долго использовали Postman, но эти импорты/экспорты — тупня полная. Peer review не сделать, в гите нормально не сохранить, конфликты не разрешить… В общем, сейчас пробуем тестировать привычным средствами: nodejs, mocha, chai. Пока полёт нормальный.

Очень не хватает возможности при проксировании приостановить запрос, отредактировать и послать дальше!
Эх, видели бы вы продукт этой компании. У нас в Казахстане все машины покупаются на «Колесах», безо всяких Авито и прочей раздутой фигни. Не раз наблюдал картину, как обесточивались некоторые ДЦ, в которых стоят их сервера, а сервис всё равно жив. Год за годом смотрел на прирост зоопарка серверов в ДЦ, ибо сам часто бегаю поддерживаю клиентские. Приятно наблюдать как компания растёт без скандалов, стремных инвестиций и просто делает продукт. Алга Казахстан). Но вот за вашу «Крышу» стало обидно. Квартиру так просто теперь не найдёшь, ибо там дохрена «Компаний» которые продают «Воздух»
Как альтернатива CURL'у на винде Postman просто прекрасен. Но для более-менее серьезной автоматизации он слаб. SoapUI мощнее и удобнее в плане тестов, JMeter — король для нагрузочного тестирования.

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

Как живая документация к API Postman слабоват, посмотрите в сторону Swagger.

Но за статью плюс, хорошая, буду рекомендовать своим джунам для знакомства с инструментом.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

2 September 1996

Location

Казахстан

Website

kolesa.kz

Employees

201–500 employees

Registered

27 February 2018