testomat.io управление авто тестамиВ голову приходит - писать все запросы через прокси типа 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 уже протестировал и покрыл тестами…
Так и гарантии на тесты никто не даст тогда. Вам поддерживать же их тогда придётся.
Но разрешать тестам лезть напрямую в базу - не есть хорошо.
Тестовый дамп с нужными данными на худой конец. А всё остальное - через REST.
SoapUI для новичка гораздо сложнее. Я не думаю что новичку поручат что-то прямо эдакое в БД делать.
Это вполне покроется несколькими несложными тестовыми методами у разработчиков бэка.
А если вам надо и БД дёргать и REST - пишите лучше тесты на любимом ЯП.
А что плохого что тест лазит в БД? А если нужно проверить те изменения что внеслись после запроса?) Создавая тестовые данные руками ты можешь быть уверен в них ну или отвечать за их правильность, а что насоздает API одному богу известно) и в любом случае если окажется что косяк был в данных, то придут к тестерам а не разработчикам, а отвечать не за свой код у меня нет желания.
P.S.: возможно вам просто пока везёт и вы не сталкивались с такими проблемами, но у меня были случаи на практике когда казалось что вот она элементарная вещь, простая как 2+2, как там можно ошибиться? Но никогда не стоит недооценивать рукожопие или случайное стечение обстоятельств) По этому я предпочитаю расчитывать только на себя и отвечать только за свой код и свои данные.
1 лайк
Это чужая зона ответственности. Тест не должен знать как устроена БД. Тест должен знать как получить нужные данные, и если для этого не хватает тестируемого API - значит должно быть ещё тестовое.
У Postman легко делать цепочки CRUD, а большего от новичка и не потребуют.
По моему опыту поддерживать создание тестовых данных в бд гораздо сложнее, чем получить от разработчиков тестовые методы на экзотику + использовать открытое API. Чем проект крупнее тем тяжелее это делать.
Дело вкуса, наверное… Мне проще пару хранимок и процедурку генерации тестовых данных написать, а потом поддерживать, чем изучать и использовать какое-то АПИ с его особенностями и багами…
Что касается новичка, ему разве не нужно будет изучать это АПИ?
Разве это проще чем, допустим, заинсёртить в БД запись, выполнить какой-нить GET и заассёртить данные в БД и в респонде? Оо