RTM: SoapUI для чайников

Данная статья написана в помощь студентам ПОИНТ, которые проходят вебинар “Тестирование веб-сервисов”, и является, в первую очередь, практическим руководством по основам работы с программой SoapUI.

Вступление и пара слов о теории

Сегодня нужно хорошо постараться, чтобы найти софт, который никак не взаимодействует с другими программами. Обычно либо происходит равноценный обмен данными, либо стороннее ПО выполняет какие-либо вспомогательные функции, например, вычисления. И это совершенно нормально, при наличии тысяч готовых решений невыгодно или невозможно создавать все с нуля. Поэтому, то, что для конечного пользователя может выглядеть как единая программа или система, на самом деле чаще всего является набором самостоятельных сервисов. Этим сервисам нужно как-то между собой взаимодействовать (интегрироваться). И, как для общения программ с человеком существует пользовательский интерфейс UI, так и для взаимодействия программ между собой существует специальный интерфейс API (Application Programming Interface – интерфейс программирования приложений).

Почти у каждого тестировщика в карьере рано или поздно наступает момент, когда уже не получается ограничиваться лишь тестированием через UI (которого иногда вообще нет) и возникает необходимость погрузиться на следующий уровень, уровень API. Именно о тестировании на уровне API чаще всего идет речь, когда разговор касается интеграционного тестирования. Наличие навыков в таком виде тестирования выгодно как бизнесу, так и самому тестировщику: уровень локализации дефектов растет, взаимодействие между тестируемыми системами на уровне API происходит быстрее, чем через UI, легче и быстрее создать тестовые данные.

В данной статье речь пойдет об инструменте для функционального тестирования веб-сервисов — или, простыми словами, о специальных программах-помощниках. Они помогают сайтам и веб-приложениям общаться между собой в сети Интернет и передавать данные через специальный протокол HTTP(S). Веб-сервисы основываются на открытых протоколах и следуют общепринятым стандартам. Именно поэтому у приложений есть возможность общаться между собой вне зависимости от использованных при их создании технологий или пользовательского окружения. Для взаимодействия веб-приложений в основном используется два типа интерфейсов: REST API и SOAP API. Их различия и области типичного применения являются темой для отдельных статей.

Для тестирования API веб-приложений существует множество возможностей: начиная от написания своих собственных скриптов, работы в консоли и заканчивая специальными фреймворками, у которых доступен UI через обычный браузер (Swagger, Django REST framework и т.п.).  SoapUI — это один из многих инструментов для такого тестирования. Он поддерживает множество дополнительных возможностей, которые в самом начале могут не понадобиться, но именно поэтому может показаться новичкам излишне сложным. Однако, очевидным плюсом для новичков является то, что SoapUI предлагает поддержку REST и SOAP API, поэтому можно не осваивать отдельную программу для каждого типа веб-API.

Первый REST проект

Если веб-приложение использует REST API, то форматы документации могут сильно отличаться, а схема (WADL) опциональна. Единственное, без чего при тестировании REST не обойтись, так это без информации об endpoint, т.е. конечного адреса, куда отправляются запросы сервиса, инициирующего взаимодействие. Или, с другой стороны, точки входа для программы, с которой это взаимодействие осуществляется. Конечная точка сама по себе является просто ссылкой на URL, который принимает веб-запросы, которые в свою очередь могут быть или не быть REST. В зависимости от конкретной проверки этот адрес уточняется или к нему добавляются дополнительные параметры. Уточнения адреса являются уже детализированными ссылками на ресурсы, т.е. кусочки программы, которые непосредственно содержат данные, информацию о связях с другими кусочками программы, реализованные методы для взаимодействия и т.п. Иногда понятия ресурс и эндпоинт употребляются как синонимы.

Итак, приступим. В качестве подопытного будет выступать API спеллчекера от Яндекс https://tech.yandex.ru/speller/doc/dg/concepts/api-overview-docpage/ документация.

1. Создаем через меню File новый REST проект. Или в Navigator через меню, которое открывается по клику правой кнопкой мыши по Projects.

2. В открывшемся диалоговом окне вводим наш базовый URL, куда будут уходить все запросы: https://speller.yandex.net и нажимаем OK. Можно ввести и всю ссылку целиком, умный SoapUI сам разделит эндпоинт и ресурс.

3. После того, как проект создался, в рабочей области откроется окно с самим запросом. Здесь выбираем метод (в нашем случае по документации GET) и уточняем URL, дописываем ресурс, к которому обращаемся. У спеллчекера реализовано два ресурса checkText и checkTexts. Пока добавим первый.

4. Теперь можно смело добавить все возможные параметры для этого метода, они перечислены в документации. При этом значения можно оставлять пустыми, получится шаблон для тестов.

5. Для того, чтобы создать тест-кейс на основании данного запроса, нужно нажать на неприметную галочку рядом с методом.

6. После этого SoapUI автоматически предложит создать и назвать папку с тестами и назвать первый тест-кейс. Если тест-сьют уже есть в проекте, то SoapUI сначала предложит выбрать, куда именно добавлять кейс.

7. Добавляем в новый тест-кейс сам запрос. На данном этапе можно переименовать запрос. Но это переименование будет касаться только тест-кейса.

8. Ура, первый тест-кейс почти готов! Обратите внимание, что в самом тест-кейсе уже нельзя редактировать эндпоинт или ресурсы. Зато можно добавить значения параметрам и поменять запрос, который используется, если их несколько.

9. Самое время проверить, что сервис работает и ответ на запрос приходит. Заполняем параметр text словом с ошибкой и нажимаем на кнопку Play (зеленый треугольник). Видно, что параметр автоматически добавился в URL.

10. А теперь можно добавить второй ресурс /services/spellservice/checkTexts к уже существующему эндпоинту. Кликаем правой кнопкой мыши по нему и выбираем в контекстном меню New Resource. Так как эти ресурсы равноценны, то нужно его добавлять имено к эндпоинту, а не как дочерний ресурс к добавленному выше checkText.

11. Здесь все то же самое, выбираем метод, добавляем возможные параметры.

12. Чтобы поделиться REST проектом, его можно экспортировать как xml и тогда любой другой тестировщик сможет добавить этот файл в свой SoapUI и воспользоваться готовыми тест-кейсами. Для этого нажимаем правой кнопкой мыши на саму папку проекта и выбираем Save Project или Save Project as.  Если выбрать пункт Export Project, то xml файл проекта будет добавлен в zip-архив. Тоже самое можно сделать через главное меню в разделе Project.

Выше приведены самые базовые действия для создания тест-кейсов по REST сервису в SoapUI. На самом деле возможности инструмента, конечно, гораздо шире. Обо всем этом можно узнать на официальном сайте https://www.soapui.org/

Тестирование параметров происходит также, как на UI тестирование полей в форме, все базовые техники применимы и тут. Особенностью тестирования REST является возможность смотреть не только значения параметров, но и проверить, как тестируемая система реагирует на запросы к несуществующим ресурсам, с несуществующими параметрами, неверным методом. Если углубляться в данный вид тестирования, то можно проверять также заголовки запроса и форматы запросов/ответов.

Первый Soap проект

Если используется Soap API, то можно быть спокойным, у вас будет файл схемы. Тут уже все происходит автоматически, SoapUI создает проект на основе схемы и можно сразу увидеть все доступные запросы.

Продолжим с Яндексом. По данной ссылке https://speller.yandex.net/services/spellservice?WSDL  доступен WSDL файл, который нужно сохранить в формате xml.

1. Снова открываем меню File и создаем уже новый Soap проект.

2. В открывшемся диалоговом окне нужно назвать свой проект и загрузить скачанный ранее файл со схемой. Остальные галочки можно оставить по умолчанию.

3. Готово, проект создан, есть примеры запросов.

4. Теперь вместо “?” можно добавить значения в xml и отправить первый запрос.

5. Тест-кейсы и экспорт проекта происходят точно также, как и в REST. Полезно знать, что всегда по любой сущности можно кликнуть правой кнопкой мыши и в появившемся контекстном меню увидеть, какие действия доступны.

В тестировании SOAP также применимы все базовые техники: можно проверять граничные значения и анализировать софт, разбивая на классы эквивалентности. Дополнительно тестирование на уровне SOAP API дает возможность проверить уже сам xml файл на полноту и валидность (соответствие схеме) и реакции системы на такие ошибки.

На этом у меня все!

P.S.: По теории и более подробном тестировании REST и SOAP можно почитать следующие статьи:

Метки
#Тестирование ПО (3)Android (1)Cache (1)Cookie (1)courses (1)HR (1)iOS (2)istqb (1)ISTQB FL (1)java (1)Jedi Point (10)JSON (1)kaizen (2)pairwise (1)QA (14)QualityLab (1)REST API (1)selenium (1)SOAPUI (1)SOAP UI (1)softskills (1)softwaretesting (1)SQA Days-25 (1)sql (5)TestSuites (1)usability (2)web (1)XML (1)Анна Палей (1)БАГИ (1)Исследовательское тестирование (2)Истории поинт (8)Команда разработки (1)Курс тестирования для начинающих (1)Кэш (1)Лаборатория Качества (1)Мнемоники (1)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)ПОИНТ (39)ПРомо-вебинар (1)Подготовка к istqb (1)Роман Буданов (3)Скриншот (3)Таблица решений (1)Тестирование (16)Тестирование ПО (3)Тест менеджмент (1)Тренер (11)Туры (1)автоматизация (2)алгоритмы (1)баг (1)безопасность (1)бесплатный вебинар (1)введение в тестирование (1)граничные значения (1)декомпозиция (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (8)как надо тестировать (2)комбинаторика (1)конференция (1)котик (1)курс для начинающих тестировщиков онлайн (1)лайфхак (1)минутка юмора (1)мобилки (3)мобильное тестирование (4)настройка мозгов (1)начинающий тестировщик (7)негативное тестирование (2)обучение (1)обучение тестированию (8)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)режим разработчика (3)резюме (1)сертификация ISTQB FL (1)скринкаст (1)сопроводительное письмо (1)с чего начать (1)тайм-менеджмент (1)тест дизайн (1)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование веб (2)тестирование игр (3)тестирование мобильных приложений (1)тестировщик (5)улучшайзинг (1)ученик (2)фреймворки (1)чеклист (3)чит лист (1)что должен делать тестировщик (1)ятренерпоинт (1)
С 3.02 по 6.04, ОНЛАЙН Зарегистрироваться