Api testing что это
Стратегия тестирования REST API: что именно вам нужно тестировать?
Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.
Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).
Пирамида тестов
Когда у нас уже есть прочный фундамент из модульных тестов, охватывающих отдельные функции, тесты API обеспечивают более высокую надежность. Они проверяют интерфейс, более близкий к пользователю, но не имеют недостатков тестов пользовательского интерфейса.
Стратегия тестирования API
Основными задачами функционального тестирования API являются:
гарантировать, что реализация API работает в соответствии со спецификацией требований (которая позже становится нашей документацией по API).
предотвратить регрессий между написанным кодом(merge) и релизом.
эндпоинты правильно именованы;
ресурсы и их типы правильно отражают объектную модель;
нет отсутствующей или дублирующей функциональности;
отношения между ресурсами правильно отражаются в API.
Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).
Итак, какие аспекты API мы должны протестировать?
После того как мы проверили соглашение API, мы можем поразмышлять о том, что тестировать. Независимо от того, думаете ли вы об автоматизации тестирования или ручном тестировании, наши функциональные тест-кейсы имеют одинаковый набор тестовых действий. Они являются частью более широких категорий тестовых сценариев и их можно разделить на три потока тестирования.
Этапы тестирования API
Каждый тест состоит из тестовых шагов. Это отдельные атомарные действия, которые тест должен выполнять в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия:
Проверьте корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.
Проверьте полезную нагрузку ответа. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.
Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.
Проверьте правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить.
Проверьте базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.
Категории тестовых сценариев
Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:
Основные позитивные тесты (прохождение успешного сценария по умолчанию)
Расширенное позитивное тестирование с дополнительными параметрами
Негативное тестирование с валидными входными данными
Негативное тестирование с недопустимыми входными данными
Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи)
Тестирование успешного сценария по умолчанию проверяет базовую функциональность и критерии приемки API. Позже мы расширим положительные тесты, чтобы включить дополнительные параметры и дополнительные функции.
Тестовые потоки
Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:
Мы выполняем запросы через API и проверяем действия через пользовательский интерфейс веб-приложения и наоборот. Цель этих потоков проверки целостности состоит в том, чтобы гарантировать, что, хотя на ресурсы влияют различные механизмы, система по-прежнему поддерживает ожидаемую целостность и согласованный поток данных.
Пример API и тестовая матрица
Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).
Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API:
Api testing что это
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Дейв Вестервельд (DaveWesterveld)
Оригинал статьи
Перевод: Ольга Алифанова
Начиная тестировать API, я не знал о них ничего. За последние несколько лет я многое узнал, и теперь совершенно спокойно использую и тестирую API, но так было не всегда. Когда я начинал, было сложно даже определить, что же делать. Все еще помню, через какую боль я прошел.
На первом курсе университета у нас был профессор математики по кличке «Эйнштейн» – частично из-за его прически, а частично потому, что он делал математику такой же сложной, как теорию относительности. Он начинал решать задачу на доске, а затем говорил «следовательно, очевидно, что» и выводил решение. Мы сидели с озадаченными лицами. Очевидное для него было неочевидно нам, студентам. Нам нужно было знать промежуточные шаги, которые он проскочил, чтобы разобраться, что произошло.
Это частая история. Когда вы узнаете больше, стартовая боль кривой обучения проходит, и становится сложнее и сложнее объяснять что-то тем, кто только начал. Вы начинаете предполагать и делать логические скачки, очевидные для вас, но смущающие новичков в предмете. Продолжая развивать свои знания об API, я хочу записать ряд своих мыслей о тестировании API, пока не стало слишком поздно объяснять это начинающим.
Итак, после этого долгого вступления, вот моя попытка упрощенного руководства для начала API-тестирования.
Выясните конечные точки
Для меня это одна из самых сложных вещей в тестировании API. Как узнать, что там вообще тестировать? Что это API умеет? Если вы работаете с хорошо документированным публичным API, то выяснить это нетрудно, но по моему опыту, большая часть тестирования API проводится на внутренних API, поддерживающих различные части вашего приложения. Как правило, такие API плохо задокументированы (если документация вообще есть). Как же это выяснить?
Конечно, любая имеющаяся внутренняя документация вам поможет, поэтому всегда начинайте с нее, если она есть. И не забудьте, что она может лежать в самых неожиданных местах. К примеру, иногда вам могут помочь комментарии в коде или даже подписи в методе. Документацию можно также найти в сторис или требованиях, которые укажут вам нужное направление.
Еще один отличный источник информации – это люди. В компании есть люди, которые создавали, проектировали, тестировали и/или использовали ваш API? Найдите их и поговорите с ними – они могут быть бесценным источником информации.
И, наконец, можно посмотреть на сетевые вызовы в консоли разработчика, чтобы выявить доступные конечные точки API. Зачастую вызовы API отправляются через сеть, и, разглядывая их через инструменты разработчика, можно многое узнать об их работе.
Все эти источники информации дадут вам неполные и неточные сведения. Наверняка будет то, что вы просто не понимаете, и (особенно поначалу) все будет непонятным и туманным. Но если вы не сдаетесь и продолжаете задавать вопросы и получать обратную связь, то в один прекрасный день осознаете, что вы все поняли и разбираетесь, как API работает.
Авторизацияибезопасность
Авторизация. Аутентификация. Безопасность. Что это и как это работает? С моей точки зрения, процессы авторизации сложны для понимания. Безопасность, конечно, очень важна для работы API, но она может серьезно усложнить его использование. Эта статья сильно разрастется, если я углублюсь в этот вопрос, но хочу все же дать несколько подсказок.
Для начала разберитесь, как вам могут помочь ваши инструменты. Приложения вроде Postman сильно упрощают вопросы авторизации и аутентификации. Они также могут дать вам представление о безопасности вашего API. Покопайтесь в функциональности используемого инструмента, посмотрите, что он предлагает.
Другой момент – когда вас все это раздражает, считайте это полезным опытом. Задавайте вопросы коллегам (и Гуглу). Попытайтесь разобраться, как работает OAuth. Вникните в процесс авторизации. Лично мне изучение авторизации сильно помогло понять работу API и HTTP-протоколов, и это был отличный способ узнать больше о тестировании API.
И напоследок про безопасность – множество вопросов «безопасности» не связано напрямую с техническим тестированием безопасности. Проверка, что разные типы пользователей могут получать только ту информацию, на которую у них есть права, и что все пути отдают правильную информацию – это тоже формы тестирования безопасности. Не забывайте смотреть на ваше API в совокупности.
Учитесь делать, делая
Очень привлекательно потратить много времени на изучение чего-то вроде API-тестирования. Нам кажется, что нам надо знать, что мы делаем, до того, как мы приступим к делу, но я убежден, что лучший способ обучения – практический. Просто попробуйте сделать API-вызовы. Разберитесь, какова конечная точка, и попробуйте ее вызвать. Начните с самого небольшого известного вам участка и используйте его. Пробуя что-то сделать, застревая, разбираясь с этим, вы узнаете то, что вам надо знать про ваш рабочий API. Вы также узнаете, о чем вы не знаете, и что нуждается в изучении, и найдете ресурсы, которые помогут вам разобраться именно с этим вопросом.
Разберитесь с базовой терминологией
У меня есть словарик терминов. Это набор терминов, которые мне пришлось выучить. Возможно, он вам пригодится, но мне кажется важным также выяснить, какие из ваших рабочих терминов вам непонятны, и прояснить этот вопрос. Важно также слушать, какие термины употребляют коллеги, и убедиться, что они вам понятны. Зачастую разные команды и компании используют одинаковые и похожие термины, имея в виду разные вещи. Обращайте внимание на слова, постройте свой словарь. Это упростит задавание вопросов и понимание происходящего.
Что дальше?
Итак, что же делать дальше?
33 тестера
четверг, 23 июля 2015 г.
Коротко о API и его тестировании
В этом сообщении я постарался собрать информацию, которая может пригодиться тестировщикам, желающим узнать, что такое API. Надеюсь что-то полезное для себя найдут и опытные в тестировании API люди. Ну или хотя бы помогут найти ошибки в моей статье 🙂
Что такое API
Своими словами, API предоставляет нам возможность использовать чужие наработки в своих целях. Впервые я столкнулся с API на примере Windows API. Это набор функций, которые может использовать любое приложение, запущенное на данной ОС. К примеру, оно может использовать стандартные функции для отрисовки интерфейса.
Современные API часто принимают форму веб-сервисов, которые предоставляют пользователям (как людям, так и другим веб-сервисам) какую-то информацию. Обычно процедура обмена информацией и формат передачи данных структурированы, чтобы обе стороны знали, как взаимодействовать между собой.
Форматы передачи данных
Обычные GET запросы способен посылать веб-браузер. Для посылки других типов запросов могут потребоваться скриптовые языки или специальные инструменты (об этом будет ниже).
О H TTP методах можно подробнее почит ать на W iki.
HTTP к оды ответов
Сервер может посылать разные коды в ответ на запросы пользователей. Это могут быть коды ошибок или просто коды, информирующие пользователей о состоянии сервера. Подробное описание можно найти, опять же, на вики.
Инструменты тестирования API
Пожалуйста, учтите, что упомянутыми ниже инструментами их спектр для API тестирования не ограничен. Я говорю именно об этих, потому что ими я уже пользовалась.
В следующей секции я покажу, как провести тест API.
Swagger
Согласно официальному сайту, Swagger – это профессиональный инструментарий с открытым исходным кодом, который «упрощает разработку API для пользователей, команд и предприятий».
Я пользовалась Swagger UI, чтобы легко проверить API URL, разобраться в вызовах, а затем добавить их в код моих тестов, но опробовала не все инструменты Swagger. Мне кажется, это простой способ сообщить команде об изменениях API и задокументировать их.
В качестве альтернативы разработчики могут документировать вызовы API в другом формате – обычно списком, как сделано у Twitter. Проблема тут в том, что такая документация может устаревать, и затем надо копаться в коде разработки, чтобы понять, как конкретно выглядит этот вызов. Swagger подтягивает набор вызовов напрямую из кода, поэтому с ним проще работать и поддерживать актуальность документации.
Swagger сделан компанией SmartBear, как и SoapUI, поэтому для тестирования API с их помощью прочитайте следующую секцию.
SoapUI и Postman
s ” a Complete API Test Automation Framework for SOAP, REST and more”. There is an open source version and a professional one featuring more functionality. The API testing part looks like this:
Я взяла изображение с официального сайта, и оно довольно самоочевидно. Кроме того, проект хорошо документирован, что поможет вам разобраться с ним.
Postman – это «платформа для совместной разработки API». Для разработчиков Постман предоставляет автоматическую документацию, и это ликвидирует проблему, при которой разработчики меняют функциональность, а затем забывают сообщить об этом.
Приступить к тестированию API с Postman очень легко. Вы можете создавать запросы REST, SOAP и GraphQL. Инструмент поддерживает множество протоколов авторизации (я расскажу об этом позже) и управление сертификатами. Пожалуйста, посетите официальный сайт, чтобы узнать больше.
Wireshark и Fiddler
Эти два приложения очень полезны для анализа сетевых пакетов. Это мощные программы, которыми в обязательном порядке надо владеть, тестируя безопасность, сеть и производительность, а также проверяя пакеты на микро-уровне. Они помогают увидеть, какие конкретно данные пересылаются через сеть. Однако если вы ищете инструментарий для тестирования API, возможно, стоит выбрать что-то из вышеперечисленных – они более высокоуровневые, и предназначены именно для работы с API.
Несмотря на это, я использовала Wireshark и Fiddler для тестирования API, требовавшего особых сертификатов безопасности, а также для дебага проблем (особенно проблем производительности). Чтобы лучше познакомиться с Fiddler, прочитайте эту статью, а для Wireshark – эту.
Как это автоматизировать?
Если вы хотите добавить тесты API в свой код автоматизации, вышеуказанные инструменты помогут вам в этом. Однако в разных языках программирования различаются способы выполнения таких типов вызовов. К примеру, вот так делается REST-вызов в Python:
# сделать что-то с результатом
response.status_code # это дает вам код статуса, о чем говорилось выше
response.json() # это дает вам json с ответом
Это становится сложнее, если вам нужно добавить параметры, авторизацию, или проанализировать данные, но весь процесс хорошо документирован. Давайте рассмотрим конкретный пример, используя API numbersapi.com.
Результат после выполнения кода выше:
При помощи Python вы можете анализировать данные json, легко извлекая и валидируя текст или число.
Чтобы узнать больше о том, что именно тестировать при проверке API, прочитайте эту статью, которая чудесно объясняет этот вопрос на примере Postman.
А мне какое дело? Сравнение тестирования UI и API
Тестирование UI (пользовательского интерфейса) – наилучший способ имитировать реальное поведение пользователей. Однако мы склонны тестировать через UI то, что уже может быть покрыто тестами API (которые в некоторых компаниях могут выполняться другой группой или командой).
Допустим, разработчик изменил вызов API. Пусть это будет вызов списка избранных фильмов. Теперь представим, что этот вызов не изменился в какой-то части приложения, и в результате пользователь не может найти понравившиеся фильмы. Что происходит в UI-тесте?
UI-тест не сможет найти объект. Это может случиться из-за неверного вызова API, баге в автоматизации, обновлении способа получения объекта, нерабочей кнопки, спрятанного объекта…
Однако при наличии API-теста вы поймете, что вызов ничего не получает в ответ. Если вам нужно проверить что-то вроде результатов поиска, лучше использовать API для проверки всего списка (что можно сделать быстрым сравнением), и убедиться через UI, что результат появляется там, где должен, а не само содержание результата. Вы также должны убедиться, что вызов API верен (и обновить тестовый вызов, если это не так).
Переходим на уровень выше
Вызовы API меньше склонны к переменам по сравнению с объектами UI, и, как правило, перемены имеют другую версию, не затрагивая предыдущие релизы приложения. Это означает, что может быть разумным добавить функциональность проверки того, какая именно версия тестируется.
Тесты API также можно использовать для ускорения UI-тестирования. Наиболее распространенный пример – это метод авторизации. Этот метод обычно становится бутылочным горлом для остальных тестов, и если он падает – вы не можете узнать, что еще падает или успешно проходит, до исправления бага вы беспомощны. Очень важно иметь под рукой тест авторизации, чтобы убедиться, что ваши пользователи способны авторизоваться, но выполнение авторизации через UI при каждом прогоне тестов, для которых она требуется, увеличивает время выполнения этих тестов.
Что же делать? Использовать тестирование API, чтобы пропустить авторизацию. Будьте осторожны, в релизном окружении это будет небезопасным. К примеру, можно настроить уникальные токены (см. пример с SoapUI) с коротким сроком жизни для выполнения этого перехода, и отправлять их вместе с URL, или задать вызов API, настраивающий куки или сессию авторизации.
Если у вас есть другие повторяющиеся зависимые тесты, рассмотрите возможность прогонять API-вызовы, прежде чем переходить к зависящим от этих вызовов тестам. Это серьезно ускорит прогон тестов, и его результаты дадут вам более достоверную информацию о проблеме.
Учитывая вышесказанное, UI-тесты – наилучший способ убедиться, что все корректно работает относительно пользовательского поведения, E2E и интеграционные тесты не должны заменяться тестами API. Используйте их как вспомогательный инструмент, если они не увеличивают сложность и отказы ваших тестов.
И еще на уровень выше: статистика
Другая интересная штука, которую можно делать благодаря API-вызовам – это выяснять информацию о приложении и том, как его использует аудитория. Для глобального анализа и визуализации вызовов можно использовать такие инструменты, как elastic search и kibana, и даже пользоваться искусственным интеллектом для получения выводов об этих вызовах… но это уже другая история.
Тестирование API
Введение: Что такое API
В широком смысле слова API (Application Programming Interface) это метод который приложение предоставляет внешним пользователям для коммуникации с ним. Обычно через Интернет.
Это может быть взаимодействие с сервером приложения на смартфоне, между компьютерами или другими устройствами.
API применяются там где невозможна или нежелательна непосредственная интеграция с исходным приложением, то есть практически везде.
Крупные интернет-компании обычно предоставляют (платно или бесплатно) доступ к API своих сервисов.
Где применяют API
Сейчас будет несколько абстрактных примеров просто для понимания сути.
Конкретные примеры работы с API я разбираю в учебнике
Пример №1:
Если Вы хотите разместить на своём сайте яндекс-карты Вам не нужно устанавливать программы от Яндекса, достаточно послать несколько запросов и Яндекс передаст необходимую информацию.
Пример №2:
Предположим, что Вы создали сайт vk2.com. Вы хотите, чтобы вебмастера могли добавить на свои сайты возможность комментировать записи используя учётную запись vk2, но раскрывать или раздавать свой код не хотите.
Чтобы обойти эту проблему Вы выкладываете в публичном доступе правила, по которым вебмастера могут обращаться к vk2, чтобы получить комментарии.
Формат этих сообщений это обычно либо JSON либо XML. О них мы поговорим позже.
Повторим для закрепления сути: Смысл в том, что сайт написанный на любом языке, поддерживающем HTTP запросы, не посылает на сервер никаких PHP/C/Python команд, а общается ним с помощью запросов, описанных в API.
Если вам интересен реальный пример работы с API рекомендую статью Работа с API GitHub
Endpoint
Адрес, на который посылаются сообщения называется Endpoint.
Обычно это URL (например, название сайта) и порт. Если я хочу создать веб сервис на порту 8080 Endpoint будет выглядеть так:
Если моему Web сервису нужно будет отвечать на различные сообщения я создам сразу несколько URL (interfaces) по которым к сервису можно будет обратиться. Например
https://andreyolegovich.ru:8080 /resource1/status
https://andreyolegovich.ru:8080 /resource1/getserviceInfo
https://andreyolegovich.ru:8080 /resource1/putID
http://andreyolegovich.ru:8080 /resource1/eventslist
https://andreyolegovich.ru:8080 /resource2/putID
…
Как видите у моих эндпойнтов (Enpoints) различные окончания. Такое окончание в Endpoint называются Resource, а начало Base URL.
Такое определение Endpoint и Resource используется, например, в SOAP UI для RESTful интерфейсов
Endpoint = Base URL + Resource
Понятие Endpoint может использоваться в более широком смысле. Можно сказать, что какой-то определённый роутер или компьютер является Endpoint. Например, в понятии Endpoint Management под Endpoint имеют в виду конечное устройство. Обычно это понятно из контекста.
Также следует обратить внимание на то, что понятие Endpoint выходит за рамки RESTful и может использовать как в SOAP так и в других протоколах.
Термин Resource также связан с RESTful, но в более широком смысле может означать что-то другое.
На программистском сленге Endpoint иногда называют ручкой.
Спецификация
После того все эти интерфейсы созданы, их необходимо описать. Нужен документ из которого будет понятно
Этот документ должен быть доступен программистам с обеих сторон, иначе они просто не смогут договориться и реализовать работающий Web сервис.
HTTP методы
Вернёмся к первому пункту списка, а именно к тому, что такое методы.
В протоколе HTTP предусмотрено несколько способов отправить запрос на один и тот же Endpoint.
Про их свойства можно почитать здесь.
Когда мы знаем какие методы с какими Enpoint можно использовать составить запросы не составит труда.
GET http://andreyolegovich.ru:8080 /resource1/status
GET http://andreyolegovich.ru:8080 /resource1/getserviceInfo
PUT http://andreyolegovich.ru:8080 /resource1/putID
GET http://andreyolegovich.ru:8080 /resource1/eventslist
POST http://andreyolegovich.ru:8080 /resource1/eventslist
PUT http://andreyolegovich.ru:8080 /resource2/putID
…
Таким образом простейший запрос состоит из метода и Enpoint
Request = Method + Endpoint
Пример API
Чтобы узнать количество велосипедистов в городе нужно отправить GET запрос на https://topbicycle.ru:/bicyclists/$город
GET https://topbicycle.ru /bicyclists/helsinki
Получив такой запрос сайт вернёт число велосипедистов в Хельсинки.
Попробуйте вставить эту строку в браузер.
Это очень простые уроки для самых начинающих. Буду рад любым отзывам и предложениям в комментариях.
Тестирование API без документации
Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определетесь, насколько всё плохо. Какая у Вас есть информация об объекте тестирования.
Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints?
Сканирование портов
Перебор запросов
Если Вам известен нужный порт и соответствующий endopoint переберите все возможные HTTP методы. Начните с наиболее очевидных:
В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придётся перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.
Разработчики обычно не особо заморачиваются и закладывают минимально-необходиму информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты.
Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
Инструменты для тестирования
Существует множество инструментов для тестирования. Здесь Вы можете познакомиться с одними из самых популярных: Python и SOAP UI.
О работе с REST API на Python вы можете прочитать в статье «REST API с Python»