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

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

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

API (Application Programming Interface) - набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах (Wikipedia).

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

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

На сайте https://dev.hh.ru/ (а точнее, https://github.com/hhru/api/blob/master/docs/general.md) вы можете найти описание того, как клиенты и сервисы HeadHunter API взаимодействуют между собой. Например, цитата с сайта:
Вы можете почитать подробное описание HH API - это хороший пример пользовательской документации.

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

Существует множество форматов данных, с помощью которых пользователи взаимодействуют с API. Например, широко известный XML. Или JSON - легковесный и несложный формат, который выглядит как:

{
 "id": "0001",
 "type": "donut",
 "name": "Cake",
 "image":
  {
   "url": "images/0001.jpg",
   "width": 200,
   "height": 200
  }
}
 
По ссылкам ниже вы можете посмотреть ответы, приходящие от MediaWiki API, в разных форматах:

JSON: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=jsonfm 
XML: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=xmlfm
PHP: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=php (осторожно, произойдет скачивание файла)

HTTP глаголы

Обычно при обращении к веб API используются запросы HTTP. Поэтому нужно хотя бы коротко сказать о стандартных методах, которые могут содержаться в HTTP запросе. Эти методы также называют HTTP глаголами:
  • GET. Наверное, самый популярный тип запроса. Используется для получения или чтения данных.
  • PUT. Обычно используется для обновления ресурса.
  • POST. Обычно используется для создания нового ресурса.
  • DELETE. Удаляет данные.
  • И другие  
Если мы хотим получить информацию о ресурсе, URI которого http://www.example.com/customers/12345, мы можем послать запрос:
GET http://www.example.com/customers/12345

Если мы хотим обновить ресурс - мы можем послать PUT-запрос:
PUT http://www.example.com/customers/12345/orders/98765  

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

О HTTP методах можно подробнее почитать на Wiki.

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

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

Наиболее известные коды - 4xx (проблемы на стороне клиента) и 5xx (проблемы на стороне сервера). О том, какие коды возвращать в той или иной ситуации, решают разработчики самих API. Например, API сайта Одноклассники возвращает коды, описание которых можно найти на странице https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003.

Кроме того, советую послушать песню Реквест-респонс - просто и понятно о кодах, возвращаемых в HTTP запросах (осторожно, репчик :)).

REST API

REST API - это идеология построения API, которая расшифровывается как Representational State Transfer API. Она основывается на следующих принципах, сформулированных ее создателем, Роем Филдингом: 
  1. Клиент-серверная архитектура
  2. Stateless сервер
  3. Кешируемость
  4. Многослойная структура
  5. Единый интерфейс
  6. Код по требованию
Не буду углубляться в детали, желающим почитать по теме могу посоветовать статью.

Аутентификация

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

Для интеграции сервисов друг с другом широко используется протокол аутентификации OAuth ‎(подробнее о нём можно почитать в статье 
http://m.geektimes.ru/post/77648/). Например, он может использоваться онлайн игрой, которая импортирует список друзей из Facebook.

Инструменты‎ для работы с API

Обычные GET запросы можно посылать при помощи браузера. Но существует множество специальных инструментов, которые предназначены для разработки и тестирования API. Они предоставляют возможность не только отправлять различные типы запросов, но и сохранять запросы, показывать результаты в различных форматах, выступать в роли proxy сервера. И многое многое другое.

Среди таких инструментов:
  • Postman. Расширение для Google Chrome, которое в бесплатной версии позволяет посылать запросы, записывать их, показывать историю. Удобно и понятно. 
  • jMeter. Инструмент, получивший известность прежде всего благодаря нагрузочному тестированию, которое можно проводить с его помощью. Но это лишь одно из множества его применений.
  • Fiddler. Позволяет просматривать посылаемые HTTP запросы. И много чего еще. 
  • SoapUI. Мощный продукт для разработки и тестирования веб приложений. Сам я его не использовал, но слышал много отзывов - и хороших, и плохих.
  • Runscope. Подробнее об этом инструменте - в статье на QAHelp и Хабрахабре.
  • Advanced REST Client. Еще одно расширение для Chrome для работы с API (конструкция запросов, их показ в удобном виде и другое).
Тестирование API

А теперь - очень коротко о том, как тестировать API.
 
Конечно, тут есть своя специфика, но мы можем использовать такие общепринятые техники, как:
  • Анализ граничных значений. В API запросах в явном виде могут передаваться значения параметров. Это отличный повод выделить границы входных и выходных значений и проверить их.
  • Разбиение на классы эквивалентности. Даже у небольшого API есть множество вариантов использования и множество комбинаций входных и выходных переменных. Поэтому мы можем лишний раз использовать наши навыки выделения эквивалентных классов.
Как мне кажется, при тестировании нужно учитывать, что API создаются во многом для интеграции сервисов. И работают с ними часто не люди, а другие программные системы. Поэтому нужно оценивать API с позиции удобства его использования другими продуктами, с позиции легкой интеграции с ним. Уважающий себя API должен также иметь понятную и подробную документацию.

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

Дополнительные материалы
Всем спасибо! Еще раз приглашаю всех на сессию Weekend testing, где мы будем тестировать API.

17 комментариев:

  1. спасибо Вам за статью и источники))

    ОтветитьУдалить
  2. присоединяюсь) спасибо за ссылки, весьма доступно

    ОтветитьУдалить
  3. Спасибо большое! То что искалю

    ОтветитьУдалить
  4. Спасибо за статью, хорошо обрисовывает общую картину

    ОтветитьУдалить
  5. Пожалуйста! Захвалили!
    Где тут смайлик "звёздная болезнь"? :)

    ОтветитьУдалить
  6. Довольно таки доступно и сжато, спасибо!

    ОтветитьУдалить
  7. Кортко, доступно и по делу. Люблю такие статьи:)

    ОтветитьУдалить
  8. Спасибо за статью, делал лекцию для отдела, вроде всё из статьи сам написал, а вот про граничные значения и вообще про покрытие отдельных методов что-то забыл, статья напомнила как раз под конец.

    ОтветитьУдалить
    Ответы
    1. спасибо вам! Очень рад, что статья вам пригодилась

      Удалить
  9. Большое спасибо за статью, и отдельное - за ссылки с примерами и определениями, очень удобно читать.

    ОтветитьУдалить
  10. Отлично описано. Без воды без примеси. В закладки однозначно!

    ОтветитьУдалить
  11. Как вводная статья - очень хорошо. Но почему вы описываете исключительно тестирование методов API?
    Я бы дополнил материал информацией о необходимости проверок записей в БД, типы данных в API и в БД, соотнесение параметров метода API, с параметрами, передющимися с UI, если таковой есть

    ОтветитьУдалить
    Ответы
    1. Привет, Максим! Вы правы, это тоже важно и тоже заслуживает упоминания. Но статья была написана не как полноценное руководство по тестированию API, а как вступление для тех, кто подобным тестированием не занимался. Если вы знаете ресурсы, где упомянутые вами вопросы освещаются - напишите пожалуйста ссылки. Думаю они будут полезными. Я вставлю их в список материалов.

      Удалить
  12. Честно?-здорово! Как я устал от формализованных понятий википедии. А здесь - доступная подача, своевременные примеры. Желаю создавать и дальше статьи. У Вас это получается отлично. Большое спасибо.

    ОтветитьУдалить
  13. Этот комментарий был удален автором.

    ОтветитьУдалить