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 можно почитать следующие статьи:

https://quality-lab.ru/soap-api-testing/
https://quality-lab.ru/rest-api-testing/
Метки
ISTQB FL (5)IT (1)Java для тестировщиков (1)Jedi Point (12)JSON (1)kaizen (2)Pairwise Testing (1)QA (25)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)softskills тестировщика (7)SQA Days-25 (1)Sql в тестировании (6)TestSuites (1)XML (1)xpath (1)Анна Палей (1)Исследовательское тестирование (3)История успеха (18)Курс тестирования для начинающих (15)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)Обучение тестированию (13)ПОИНТ (51)Роман Буданов (3)Сессионное тестирование (1)ТЗ (1)Таблица решений (1)Тест-анализ (2)Тест-дизайн (6)Тест-кейс (1)Тест-стратегия (1)Тест-туры (1)Тестирование usability (6)Тестирование ПО (7)Тестирование игр (4)Тестирование мобильных приложений (4)Тест менеджмент (4)Чек-лист в тестировании по (4)Чит-лист в тестировании (2)автоматизация тестирования (2)автотесты (1)английский для тестировщиков (3)аудит проекта (3)баг (1)багнапродакшене (1)введение в тестирование (1)виды тестировния (2)граничные значения (1)декомпозиция (1)инструменты тестирования по (4)как надо тестировать (2)как стать тестировщиком (2)комбинаторика в тестировании (1)метрики тестирования (1)начать карьеру в IT (8)начинающий тестировщик (11)негативное тестирование (2)ограничения (1)оптимизация QA-процессов (1)организация тестирования (1)персонажи (1)планирование тестирования (1)профессия тестировщик (3)резюме (1)сертификация ISTQB FL (4)скринкаст (1)смена работы (2)сопроводительное письмо (1)тест-кейс (1)тест-менеджмент (3)тестирование безопасности (1)тестирование веб (3)тестовая стратегия (1)удаленная работа (1)управление требованиями (6)фреймворк тестирования (1)школа тест-менеджера (3)
С 19.10 по 31.12, ОНЛАЙН Зарегистрироваться