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 файл на полноту и валидность (соответствие схеме) и реакции системы на такие ошибки.
На этом у меня все!
Вы в поисках курсов для тестировщиков с нуля? Присоединяйтесь к ПОИНТ — Первому Онлайн ИНституту Тестировщиков!
Обучение стартует ежемесячно. Следить за актуальным расписанием можно в нашей группе VK.
Заполните эту небольшую анкету, чтобы получить чек-лист «Что должен знать и уметь начинающий тестировщик» 🙂
Отзывы выпускников курса ПОИНТ:
