что такое тестирование апи

Инструменты тестирования 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, и даже пользоваться искусственным интеллектом для получения выводов об этих вызовах… но это уже другая история.

Источник

33 тестера

четверг, 23 июля 2015 г.

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

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

Своими словами, API предоставляет нам возможность использовать чужие наработки в своих целях. Впервые я столкнулся с API на примере Windows API. Это набор функций, которые может использовать любое приложение, запущенное на данной ОС. К примеру, оно может использовать стандартные функции для отрисовки интерфейса.

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

Форматы передачи данных

Обычные GET запросы способен посылать веб-браузер. Для посылки других типов запросов могут потребоваться скриптовые языки или специальные инструменты (об этом будет ниже).

О H TTP методах можно подробнее почит ать на W iki.

HTTP к оды ответов

Сервер может посылать разные коды в ответ на запросы пользователей. Это могут быть коды ошибок или просто коды, информирующие пользователей о состоянии сервера. Подробное описание можно найти, опять же, на вики.

Источник

Тестирование Web API — From Zero To Hero

Под фразой «тестирование API» большинство людей подразумевает именно тестирование Server-Side Web API, несмотря на то, что Web API всего лишь один из многих типов API. [1]

В статье представляем полный набор теории, инструментов, открытых Web API и Roadmap для освоения основ тестирования Server-Side Web API.

Термины

API (программный интерфейс приложения) — описание способов, которыми одна компьютерная программа может взаимодействовать с другой программой. [2]

Web API — это API для WEB, которое необходимо для взаимодействия веб-сервера и веб-клиента. [3]

Server-side Web API — это API на стороне веб-сервера, которое состоит из одного или нескольких публично доступных точек доступа (endpoints) для системы обмена определенными сообщениями вида запрос-ответ, которые, обычно, описываются при помощи JSON или XML и передаются через Web при помощи HTTP. [4, пер.]

Front-End и Back-End разработчики в компании, не проводящей тестирование API

Roadmap по обретению навыка тестирования Server-Side Web API

Процесс изучения тестирования Server-Side Web API:

Источник

Тестирование API

API (Application Programming Interface) расшифровывается как “интерфейс прикладного программирования” или “интерфейс программирования приложений”. Он позволяет осуществлять связь и обмениваться данными между двумя отдельными модулями программы. Система программного обеспечения, реализующая API, содержит функции/подпрограммы, которые могут быть выполнены с помощью другого программного обеспечения.

«Общение» между модулями приложения происходит с использованием стандартных форматов XML и JSON и посредством специальных протоколов REST и SOAP.

Форматы данных

В JSON существуют типы данных, которые записываются по-разному. Данные в JSON записываются парами «Ключ»:»Значение». Например:

Имя параметра — это строка в двойных кавычках слева от двоеточия.

Значение — может быть строкой в двойных кавычках, числом, логическим значением (true или false), объектом, массивом, или значением null. Эти структуры могут быть вложены друг в друга.

Объект — это множество пар «Ключ»:»Значение», заключённое в фигурные скобки < >. Между именем параметра и значением стоит двоеточие «:», а пары «Ключ»:»Значение» разделяются запятыми “,”.

“name”:”JamesKirk”,

«age»:40

Строка — это упорядоченное множество из нуля или более символов Unicode, заключенное в двойные кавычки.

Массив — это множество объектов. Массив заключается в квадратные скобки [ ], а значения отделяются запятыми (см. пример на изобрежнии выше).

В XML данные хранятся между так называемыми «тэгами».

Существуют открывающие и закрывающие тэги, а данные, в свою очередь, хранятся между ними.

Более подробно о принципах построения XML можно изучить в официальной документации тут.

XML является более громоздким форматов данных и все больше разработчиков API от него отказываются.

Понятие HTTP

HTTP (Hyper Text Transfer Protocol) – широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов. По умолчанию используется 80-ый порт.

HTTPS (Hyper Text Transfer Protocol Secure)— безопасный протокол передачи гипертекста. Это расширение протокола HTTP, поддерживающее шифрование посредством криптографических протоколов SSL и TLS. По умолчанию используется 443-ий порт.

Спецификация HTTP (и HTTPS) определяет то, как запросы к серверу должны быть построены, и то, как сервер должен отвечать на эти запросы.

Основные свойства HTTP:

Запросы HTTP

Клиент отправляет запрос на сервер в виде метода, URL и версии протокола, после которого идет некоторое сообщение, которое и содержит данные запроса.

Разберем подробнее каждую из частей запроса.

Для передачи параметров в строке запроса необходимо следовать ряду определенных правил:

Заголовки представляют пары «Ключ»:»Значение». Они содержат различную информацию о HTTP-запросе и Вашем браузере. Например, строка «User-Agent» предоставляет информацию о версии браузера и операционной системе, которую Вы используете. «Accept-Encoding» сообщает серверу, может ли Ваш браузер принимать сжатый output, например, gzip.

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

Кроме этого, сервер отправляет так же код состояния (statuscode) ответа. Коды состояния делятся на 5 групп:

Полный список кодов ошибок из каждой группы и их описание можно посмотреть тут.

Рассмотрим выполнение запросов на примерах.

Получим список пользователей для второй страницы:

Как мы видим, в поле ниже мы получили ответ в формате JSON, который содержит 3 записи о пользователях.

POST запрос. Функция используется для входа в приложение и возвращает ответ со значением токена авторизации.

Параметры тела запроса:

email – новое имя пользователя;

password – новая профессия пользователя.

Вызов функции и ответ сервера будет выглядеть таким образом:

PUT запрос. Функция изменения данных пользователя. Возвращает ответ с измененными данными пользователя и датой изменения.

Параметры тела запроса:

name – новое имя пользователя;

job – новая профессия пользователя.

Подставив параметры в URI и тело запроса, получим:

DELETE запрос. Функция удаления данных пользователя. Функция возвращает пустой ответ и код 204 (No Content)

Тело запроса не содержит данных.

Подставив нужный идентификатор пользователя в строку запроса, удалим его данные:

Понятие REST

Приложения на REST архитектуре должны быть:

Понятие SOAP

SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).

В отличие от REST, который может использовать любые форматы данных, SOAP работает только с XML форматом. При работе всегда удобно иметь стандартизированное описание возможных XML-документов и проверять их на корректность заполнения. Для этого существует XML Schema Definition (или сокращенно XSD). Две главные функции XSD для тестировщика – это описание типов данных и наложение ограничений на возможные значения. Например, некоторые элементы ответов сервера можно сделать необязательным для заполнения или ограничить его размер 255 символами с помощью XSD. Чем подробнее описан XSD, тем меньше головной боли доставит Вам тестирование сервиса. С помощью выстроенной схемы сервис сам сможет валидировать полученные данные и возвращать пользователю ошибку. Подробнее прочитать про XSD можно на w3schools и codenet (по-русски).

WSDL
(Web Services Description Language) – это язык на основе XML, который используется для описания веб-сервисов. В WSDL-документе содержится информация о местонахождении сервиса и доступных методах (операциях). Для каждого метода определяются параметры отправляемого и получаемого сообщения. Обратите внимание на то, что XSD может быть «встроен» внутрь WSDL-документа (например, у Yandex Speller API).

Типы тестов, применимые к тестированию API

В целом, к тестированию API применимы следующие типы тестов:

При тестировании API необходимо проверять следующие моменты:

С помощью тестирования API можно обнаружить следующие типы ошибок:

Лучшие практики тестирования API:

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

Тестирование API обладает рядом преимуществ перед обычным тестированием через UI:

Проблемы, с которыми сталкиваются тестировщики при работе с API:

Источник

Тестирование 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»

Источник