Comments 5
Есть два подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API.
Звучит словно это взаимоисключающие вещи.
Первым делом узнайте какая есть документация на проекте, есть ли пример запросов, может кто-то из коллег уже создавал проекты и сохранил их. А вторым пунктом установите SoapUI и приступайте к работе!
Я понимаю, что статья именно об использовании SoapUI, но не могу согласиться с тем, что первое, что нужно делать при погружении в тестирование SOAP API, это тыкать в запросы. Сначала нужно таки разобраться с XSD и WSDL, чтобы понимать как построен контракт и иметь возможность сразу заметить косяки в оном. В моей практике косяки контрактов обычно намного важней проблем в имплементации.
Спасибо большое за обратную связь!
Безусловно опытный тестировщик сначала смотрит схемы, узлы, параметры, типы переменных и тд.
Но данная статья предназначена для людей, которые только вступили на тропу тестирования и столкнулись с API. И не всегда, это люди, которые легко разбираются в XSD и WSDL.
Чтобы постичь ВЕЛИКОЕ нужно начать с малого :)
Именно с этим я и не согласна. Моя позиция в том, что начинать нужно с изучения XSD (хотя бы базового), а не фигачить ассершены в SoapUI. XSD/OpenAPI/AsyncAPI/etc документация — это артефакты, необходимые для понимания того, как API должно работать, часть документации, которая и используется для определения, а что собственно тестировать-то. Как те же user story, jobs to be done, ЧТЗ, или какой еще вариант описания фич используется.
Погружение qa junior в пучину API с использованием SoapUI(Open Source)