Комментарии 12
Как правильно организовывать коллекции. Как поддерживать коллекции актуальными? Как правильно покрывать тестами, какие подводные камни? Как выстраивать тестовое ядро без дублирования? Как связывать API из OpenAPI-схемы и коллекции и почему постмен отключил эту функциональность «из коробки»? Что такое функционал «Flows» и как им пользоваться. Как организовать ci/cd и какие есть «особенности». Почему иногда стоит пользоваться браузерной версией, а не десктопной.
Эти вопросы у меня возникли, когда я начал юзать постман в петпроджекте. А здесь прод, кровавый энтерпрайз и джун-статья. Не серьезно.
Приветствую!
Вопросы правильные и также заслуживают внимания.
Однако, в рамках одной статьи или комментария достаточно проблематично дать исчерпывающее описание всех возможностей какого-либо софта.
Более того, Postman для нас является лишь одним из решением в стеке технологий и потому мы не выстраиваем процессы вокруг Postman, а встраиваем его в наши рабочие процессы (которые в свою очередь могут трансформироваться после добавления нового инструмента).
Поэтому я всего лишь хотел поделиться теми подходами, которые мы используем на практике и которые помогли нам оптимизировать те или иные процессы.
Но если вас действительно интересуют ответы на эти вопросы, то буду рад дать на них ответы в отдельном посте!
Ваша статья содержит так много воды, что 90% может выкинуть. И статья станет только лучше.
Описание возможностей есть в доке. Но кейсов системного использования нет.
У меня нет ответов на мои вопросы. Я считаю постмен решением, который подходит для очень небольшого круга задач: простых относительно небольших коллекций. Например, для тестирования api микросервисов. Для стартапов. Для набросков/примеров. Выходим на масштаб: всё, куча сложностей, проблем. Нужно менять паттерны использования.
Я своими видел использование постмана в подобном кровавом энтерпрайзе. И это куча проблем.
«Делиться коллекциями в месседжере» - это просто костыль, которым не решается системная проблема. То же самое к запуску автотестов ручками qa. Лучше было бы не терять и время и запустить разработчику. И вообще на стенде.
Подозреваю, для имиджа «корпоративного блога» Вы о проблемах не рассказываете. А именно это интересно. Сейчас Ваша статья - это пиар и графомарство. В ней сложно быстро понять: наши цели - такие, решение - такое, проблемы - такие, развитие такое. Нужно пробираться через кучу лишней инфы.
а можно карточки удаленно закрывать, в офисе постоянно че то все путают......
Раньше, когда требовалось создать какую-либо банковскую операцию, мы шли на «фронт» – в кассу, банкомат, банк и повторяли сценарий, который выполняет пользователь.Раньше вы поступали правильно.
Не имею ничего против Postman, но меня пугает современная тенденция: ручные тестировщики всё реже ставят себя на место конечных пользователей, заменяя их инструментами вроде Postman и средствами автоматизации.
Логин повторяется дважды.
Postman такую ошибку пропустит, потому что формально поле логина валидируется как ожидаемый тип String.
Поэтому не перебарщивайте с Postman и т. п. Хотя бы 1 раз из 10 тестируйте на полноценном end-to-end уровне, живыми глазами и руками.
Приветствую!
Справедливое замечание!
Немного опишу данный кейс с нашей стороны.
В задачи нашего направления не входит тестирование фронтальных частей систем (за редким исключением, например, сервисы и приложения связанные с СБП).
В основном, мы занимаемся тестированием взаимодействия между системами, а фронтом занимаются наши коллеги из смежных отделов (как ручное тестирование, так и UI-автотесты).
И через Postman мы просто генерим нужные нам операции для проверки объектов и взаимодействий которые находятся "под капотом".
В данном случае для нас действительно нет принципиальной разницы, будет сделана операция через фронт или же сформируется после выполнения цепочки запросов из Postman.
А с учётом того, что это существенно экономит нам время, мы можем выделить его на проверку именно тех взаимодействий которые нам и требуются.
Полностью с Вами согласен, что при ручном тестировании фронтальных систем нельзя полностью полагаться на решения по автоматизации, а надо пощупать фронт собственными руками.
API-тесты и e2e тесты имеют разные области применимости. И те, и те важны и нужны.
А чем API-тесты - не E2E? Актором вполне может выступать не живой человек, а какой-то сервис. В том числе и фронт приложения. Я бы даже сказал, что API-тесты формально - более E2E, чем UI-автотесты - потому что живой человек видит кнопку на которую нужно кликнуть и текст, который вернул сервер, а не их css-селекторы
Практически, вы правы. И в большинстве случаев этого достаточною.
НО... есть один нюанс, который надо учитывать.
E2E в общем случае предполагает проверку всего "самолёта" в сборе и полёте. Если дёргать только API, то мы исключаем из проверок дефекты "самолёта" по причине проблем в UI и коде сопряжения UI<>API.
Спасибо за статью! Кое-что взял для себя на вооружение)
Пять примечательных функций Postman, которые мы используем в тестировании банковских систем