QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Виды-методы-уровни тестирования

Тестирование API (API - Application Programming Interface)

PreviousТестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testingNextA/B тестирование (A/B Testing)

Last updated 2 years ago

Was this helpful?

Каждый день используя любимые мобильные приложения и веб-ресурсы вы незаметно взаимодействуете с API, скрытым под интерфейсом пользователя.

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

Еще более простой пример: примите официанта в качестве API ресторана. В ресторане вы даете заказ на основе блюд, определенных в меню. Официант принимает ваш заказ и на этом ваше участие заканчивается и вам не интересно, что там произойдет дальше. От официанта вы ожидаете только итог - вам приносят заказанное блюдо.

Можете попробовать взаимодействие с API сами: отправляете GET запрос на , и получаете в ответ список пользователей. Это очень удобно, когда вы хотите предоставить интерфейс взаимодействия со своим сервисом сторонним лицам. Например, у google, instagram, vk и, в общем-то, всех популярных продуктов есть открытая часть API. То есть у вас есть документ с перечнем того, что и как можно спросить и что вам на это придет в ответ. Взаимодействовать с API можно и с веб-страницы, и с помощью специальных инструментов и напрямую из кода. Помимо прочего, API бывает не только в контексте сетей, например, в той же системе Android есть внутреннее системное API.

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

https://cdn-images-1.medium.com/fit/t/1600/480/0*xP5HjXhJk383Jkyz.png

Типы тестирования API:

  • Unit testing: Для проверки функциональности отдельной операции;

  • Functional testing: Чтобы проверить функциональность более широких сценариев с помощью блока результатов unit-тестирования, протестированных вместе;

  • Load testing: Чтобы проверить функциональность и производительность под нагрузкой;

  • Runtime/Error Detection: Мониторинг приложения для выявления проблем, таких как исключения и утечки ресурсов;

  • Security testing: Чтобы гарантировать, что реализация API защищена от внешних угроз;

  • UI testing: Это выполняется как часть end-to-end integration тестов, чтобы убедиться, что каждый аспект пользовательского интерфейса функционирует должным образом;

  • Interoperability and WS Compliance testing: Совместимость и WS Compliance testing - это тип тестирования, который применяется к SOAP API. Функциональная совместимость между API-интерфейсами SOAP проверяется путем обеспечения соответствия профилям функциональной совместимости веб-служб. Соответствие WS- * проверено, чтобы гарантировать, что стандарты, такие как WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security и WS-Trust, должным образом реализованы и используются;

  • Penetration testing: Чтобы найти уязвимости при атаках злоумышленников;

  • Fuzz testing: Для проверки API путем принудительного ввода в систему некорректных данных для попытки принудительного сбоя;

  • Usability testing: проверяет, является ли API функциональным и удобным для пользователя и хорошо ли интегрируется с другой платформой;

  • Documentation testing: команда тестирования должна убедиться, что документация соответствует требованиям и предоставляет достаточно информации для взаимодействия с API. Документация должна быть частью окончательного результата;

Примеры проблем, которые обнаруживает тестирование API:

  • Некорректная обработка условий ошибки;

  • Неиспользуемые флаги;

  • Отсутствующие или повторяющиеся функции;

  • Вопросы надежности;

  • Сложность подключения и получения ответа от API;

  • Проблемы с безопасностью;

  • Проблемы с многопоточностью;

  • Проблемы с производительностью. Время отклика API очень велико;

  • Неправильные ошибки / предупреждение вызывающему абоненту;

  • Неправильная обработка допустимых значений аргументов;

  • Данные ответа неправильно структурированы (JSON или XML);

Контрактное тестирование API

В общем случае контрактное тестирование или 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 без документации
Список полезных статей и видео для изучения тестирования API
Тестирование GraphQL
Удачный шаблон документации на API, который будут читать
Игорь Гольшмидт. АPI тестирование без документации
Курс Тестирование ПО. Занятие 29. Тестирование API - QA START UP
Курс Тестировщика с нуля / 27 урок/ Тестирование API с помощью Postman
Rest Assured и Postman - два подхода к тестированию API
Эвристики и мнемоники в тестировании: шаблоны для тестирования 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: Контрактное тестирование
Как тестировать GraphQL API? Гайд для начинающих
Что такое API
Что такое API
Как передать в API фото формата base64
API: под каким углом на них смотреть
https://reqres.in/api/users