Кормораздатчик мобильный электрифицированный: схема и процесс работы устройства...
Опора деревянной одностоечной и способы укрепление угловых опор: Опоры ВЛ - конструкции, предназначенные для поддерживания проводов на необходимой высоте над землей, водой...
Топ:
История развития методов оптимизации: теорема Куна-Таккера, метод Лагранжа, роль выпуклости в оптимизации...
Особенности труда и отдыха в условиях низких температур: К работам при низких температурах на открытом воздухе и в не отапливаемых помещениях допускаются лица не моложе 18 лет, прошедшие...
Характеристика АТП и сварочно-жестяницкого участка: Транспорт в настоящее время является одной из важнейших отраслей народного...
Интересное:
Лечение прогрессирующих форм рака: Одним из наиболее важных достижений экспериментальной химиотерапии опухолей, начатой в 60-х и реализованной в 70-х годах, является...
Влияние предпринимательской среды на эффективное функционирование предприятия: Предпринимательская среда – это совокупность внешних и внутренних факторов, оказывающих влияние на функционирование фирмы...
Национальное богатство страны и его составляющие: для оценки элементов национального богатства используются...
Дисциплины:
2022-07-03 | 71 |
5.00
из
|
Заказать работу |
|
|
В общем случае контрактное тестирование или Consumer Driven Contract (CDC) является связующим звеном между модульным и интеграционным тестированием.
Каждый интерфейс имеет поставщика (supplier) и потребителя (consumer). Само собой, сервисы поставщика и потребителя распределены между разными командами, мы оказываемся в ситуации, когда четко прописанный интерфейс между ними (или контракт) просто необходим. Обычно многие подходят к этой проблеме следующим образом:
● Пишут подробное описание спецификации интерфейса - контракт;
● Реализуют сервис поставщика согласно спецификации;
● Передают спецификацию интерфейса потребителю;
● Ждут реализации от другой стороны;
● Запускают ручные системные тесты, чтобы всё проверить;
● Держат кулачки, что обе стороны будут вечно соблюдать описанный интерфейс;
Сегодня многие компании заменили последние два шага на автоматизированные контрактные тесты, которые регулярно проверяют соответствие описания и реализации у поставщика и потребителя определенного контракта. Что является набором регрессионных тестов, которые обеспечивают раннее обнаружение отклонения от контракта.
Разберемся во взаимодействии на примере REST архитектуры: поставщик создает API c некоторым endpoint, а потребитель отправляет запрос к API, например, с целью получения данных или выполнения изменений в другом приложении. Это контракт, который описывается с помощью DSL (domain-specific language). Он включает API описание в форме сценариев взаимодействия между потребителем и поставщиком. С помощью CDC выполняется тестирование клиента и API с использованием заглушек, которые собираются на основе контракта. Основной задачей CDC является сближение восприятия между командами разработчиков API и разработчиков клиента. Таким образом, участники команды потребителей пишут CDC тесты (для всех данных проекта разработки), чтобы команда поставщика смогла запустить тесты и проверить API. В итоге команда поставщика с легкостью разработает свой API, используя тесты CDC. Результатом прогона контрактных тестов является понимание, что поставщик уверен в исправной работе API у потребителя. Следует обратить внимание, что команда потребителя должна регулярно осуществлять поддержку CDC-тестов при каждом изменении, и вовремя передавать всю информацию команде поставщика. Если регулярно фиксируем неудачно выполненные CDC-тесты, то следует пойти (в буквальном смысле слова, к пострадавшей стороне теста и узнать, в рамках какой задачи были изменения (что привело к падению теста).
|
Из того, что было описано выше, можно выделить следующие тезисы для выполнения контрактного тестирования:
● Команда разработчиков (тестировщиков) со стороны потребителей пишет автоматизированные тесты с ожидаемыми параметрами со стороны потребителей.
● Тесты передаются команде поставщика.
● Команда поставщика запускает контрактные тесты и проверяет результат их выполнения. Если происходит падение тестов, то команды должны зафиксировать сбой и перепроверить документацию (согласованность разработки).
Минусы CDC:
● CDC тесты не заменяют E2E тесты. По факту я склонен отнести CDC к заглушкам, которые являются моделями реальных компонентов, но не являются ими, т.е. это еще одна абстракция, которую нужно поддерживать и применять в нужных местах (сложно реализовать сложные сценарии);
● CDC тесты не заменяют функциональные тесты API. Лично придерживаюсь золотого правила – если убрать контракт и это не вызывает ошибки или неправильную работу клиента, то значит он не нужен. Пример: Нет необходимости проверять все коды ошибок через контракт, если клиент обрабатывает их (ошибки) одинаково. Таким образом контракт то, что важно для клиента сервиса, а не наоборот;
|
● CDC тесты дороже в поддержке, чем функциональные тесты;
● Для реализации CDC-тестов нужно использовать (изучать) отдельные инструменты тестирования – Spring Cloud Contract, PACT;
Отличие API от SDK:
SDK (software development kit) - это набор функционала (библиотек) и утилит для разработки. Собственно SDK и предоставляет реализацию некоторого API, это оболочка API's, которая упрощает работу для разработчиков.
● API: набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением для использования во внешних программных продуктах. Это интерфейс, похоже на спецификацию телефонной системы или электропроводки в вашем доме. Это список того, что можно вызывать и какого ждать результата;
● SDK: набор реальных инструментов внедрения. Это как чемодан деталей и инструментов, который позволяет вам подключиться к телефонной системе или электрической проводке. Это библиотеки, в которых реализованы вызываемые функции + файлы необходимые для подключения этих библиотек;
Тестирование API без документации/черным ящиком:
Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определитесь, насколько все плохо и какая у Вас есть информация об объекте тестирования. Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints? Если дело совсем плохо - просканируйте порты, например, с помощью netcat. Открытые порты сохраните в файл. Эта операция займет довольно много времени. Можете почитать советы по работе с Nmap и Netcat. Если Вам известен нужный порт и соответствующий endpoint - переберите все возможные HTTP методы. Начните с наиболее очевидных POST, PUT, GET. Для ускорения процесса напишите скрипт, например, на Python.В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придется перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.
Разработчики обычно не особо заморачиваются и закладывают минимально-необходимую информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты. Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
Источники:
● API Testing Tutorial: What is API Test Automation? How to Test
|
● A Comprehensive API Testing Guide
● API Testing Tutorial: A Complete Guide For Beginners
● Spring Cloud Contract. Что такое контрактное тестирование и с чем его едят
● Чем отличается api от sdk?
● Тестирование API без документации
Доп. материал:
● Курс Тестирование ПО. Занятие 29. Тестирование API - QA START UP
● Эвристики и мнемоники в тестировании: шаблоны для тестирования API
● От шока до принятия: пять стадий тестирования API
● Тестирование API
● Swagger/OpenAPI Specification как основа для ваших приемочных тестов
● История одного сервера и тестировщика Васи
● What Is an API?
● Тестирование API простыми словами за 8 минут / Тестировщик API
● Тестирование Web API — From Zero To Hero
● Стратегия тестирования REST API: что именно вам нужно тестировать?
● Test Design and Automation for Rest API. Part 1. Иван Катунов. Comaqa Spring 2018 + Test Design and Automation for Rest API. Part 2. Иван Катунов. Comaqa Spring 2018 + pdf
● What is the Difference Between an API and an SDK?
● Introduction to API Testing
● 19:05 «Контрактное тестирование Rest API» + презентация
● Организация контрактного тестирования микросервисов и графического портала
● Introduction To Contract Testing With Examples
● Микросервисы для разработчиков Java: Контрактное тестирование
● Black box API testing with server logs
|
|
Индивидуальные и групповые автопоилки: для животных. Схемы и конструкции...
Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...
Адаптации растений и животных к жизни в горах: Большое значение для жизни организмов в горах имеют степень расчленения, крутизна и экспозиционные различия склонов...
Кормораздатчик мобильный электрифицированный: схема и процесс работы устройства...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!