Содержание
Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API. Что же это за зверь такой? Давайте разбираться!
— А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…
А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.
Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.
Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:
- скучать в ожидании;
- проверять логику работы по API
Конечно, я за второй вариант! Так что давайте разбираться, что же такое API.
Что такое API
![image](https://habrastorage.org/webt/yb/fz/_k/ybfz_ksn6uvm5mkxoljdekflodi.jpeg)
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:
- мои обязанности — внести такую то сумму,
- обязанность продавца — дать машину.
Перевести можно, да. Но никто так не делает ?\_(?)_/?
Все используют слово «контракт». Так принято. К тому же это слово входит в название стиля разработки:
- Code first — сначала пишем код, потом по нему генерируем контракт
- Contract first — сначала создаем контракт, потом по нему пишем или генерируем код (в этой статье я буду говорить именно об этом стиле)
Мы же не говорим «контракт на продажу машины»? Вот и разработчики не говорят «договор». Негласное соглашение.
API — набор функций
Когда вы покупаете машину, вы составляете договор, в котором прописываете все важные для вас пункты. Точно также и между программами должны составляться договоры. Они указывают, как к той или иной программе можно обращаться.
Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:
- саму операцию, которую мы можем выполнить,
- данные, которые поступают на вход,
- данные, которые оказываются на выходе (контент данных или сообщение об ошибке).
![image](https://habrastorage.org/webt/2x/rv/qa/2xrvqa5qt01hubxsaytf2sgi_ia.png)
Тут вы можете мне сказать:
— Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!
Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция. Фактически у нас есть данные на входе, есть данные на выходе, и некая магия, которая преобразует одно в другое.
И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.
![image](https://habrastorage.org/webt/sn/jw/46/snjw46wwnvuatj0wkghyuueofao.png)
Как составляется набор функций
Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:
- отдельно API для входа в систему, где будет регистрация и авторизация;
- отдельно API для отчетности — отчет 1, отчет 2, отчет 3… отчет N. Для разных отчетов у нас разные формулы = разные функции. И все мы их собираем в один набор, api для отчетности.
- отдельно API платежек — для работы с каждым банком своя функция.
- ...
![image](https://habrastorage.org/webt/xh/4z/oz/xh4zozptcyhurgnczngm9uqhje0.png)
Можно не группировать вообще, а делать одно общее API.
Можно сделать одно общее API, а остальные «под заказ». Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. А любые хотелки заказчиков выносятся отдельно.
![image](https://habrastorage.org/webt/lf/jh/o6/lfjho6yakkb1jciqvtti0wonj00.png)
Получается, что в нашей системе есть несколько разных API, на каждое из которых у нас написан контракт. В каждом контракте четко прописано, какие операции можно выполнять, какие функции там будут
![image](https://habrastorage.org/webt/xo/nv/29/xonv293kj3r1fiwniobwatdn8f0.png)
И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Никто этого не запрещает.
![image](https://habrastorage.org/webt/uj/hm/wa/ujhmwa-iv-okyrifyzqpnu3acsw.png)
Получается, что разработчик придумывает, какое у него будет API. Либо делает общее, либо распределяет по функционалу или каким-то своим критериям, и в каждое апи добавляет тот набор функций, который ему необходим.
При чем тут слово «интерфейс»
— Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс?
Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:
- Инкапсуляция
- Наследование
- Полиморфизм
Инкапсуляция — это когда мы скрываем реализацию. Для пользователя все легко и понятно. Нажал на кнопочку — получил отчет. А как это работает изнутри — ему все равно. Какая база данных скрыта под капотом? Oracle? MySQL? На каком языке программирования написана программа? Как именно организован код? Не суть. Программа предоставляет интерфейс, им он и пользуется.
Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:
- что подать на вход;
- что получается на выходе;
- какие исключения нужно обработать.
Пользователи работают с GUI — graphical user interface. Программы работают с API — Application programming interface. Им не нужна графика, только контракт.
Как вызывается API
Вызвать апи можно как напрямую, так и косвенно.
Напрямую:
- Система вызывает функции внутри себя
- Система вызывает метод другой системы
- Человек вызывает метод
- Автотесты дергают методы
Косвенно:
- Пользователь работает с GUI
Вызов API напрямую
1. Система вызывает функции внутри себя
Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API!
Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. И он же его потребитель! А значит, проблемы с неактуальной документацией нет =)
Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…
2. Система вызывает метод другой системы
А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.
Одна система дергает через api какой-то метод другой системы. Она может попытаться получить данные из другой системы. Или наоборот, отправить данные в эту систему.
Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.
Я подключаю подсказки по API. И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:
- Он вводит букву на моем сайте
- Мой сайт отправляет запрос в подсказки Дадаты по API
- Дадата возвращает ответ
- Мой сайт его обрабатывает и отображает результат пользователю
Вон сколько шагов получилось! И так на каждый введенный символ. Пользователь не видит этого взаимодействия, но оно есть.
И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ?\_(?)_/?
Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.
Но тут фишка в том, что в самой системе в пользовательском интерфейсе есть только обычный поиск, просто строка ввода. Ну, может, парочка фильтров. А вот для интеграции нужна была целая куча доп возможностей, что и было сделано через SOAP-метод.
Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.
В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!
(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)
3. Человек вызывает метод
Причины разные:
- Для ускорения работы
- Для локализации бага (проблема где? На сервере или клиенте?)
- Для проверки логики без докруток фронта
Если система предоставляет API, обычно проще дернуть его, чем делать то же самое через графический интерфейс. Тем более что вызов API можно сохранить в инструменте. Один раз сохранил — на любой базе применяешь, пусть даже она по 10 раз в день чистится.
Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!
Конечно, это можно сделать в помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?
Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.
И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!
Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.
А еще в постмане можно сделать отдельную папку подготовки тестовой базы, напихать туда десяток запросов. И вот уже на любой базе за пару секунд вы получаете столько данных, сколько вручную вбивали бы часами!
Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.
4. Автотесты дергают методы
Есть типичная пирамида автоматизации:
- GUI-тесты — честный тест, «как это делал бы пользователь».
- API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
- Unit-тесты — тесты на отдельную функцию
![image](https://habrastorage.org/webt/hp/yc/ng/hpycngdplj56-mdkhf2tropqvhq.png)
Слово API как бы намекает на то, что будет использовано в тестах ?
Допустим, у нас есть:
- операция: загрузка отчета;
- на входе: данные из ручных или автоматических корректировок или из каких-то других мест;
- на выходе: отчет, построенный по неким правилам
Правила построения отчета:
- Ячейка 1: Х — Y
- Ячейка 2: Z * 6
- ...
GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.
API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.
Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.
Косвенный вызов API
Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.
То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает. Пользователь работает через GUI (графический пользовательский интерфейс).
![image](https://habrastorage.org/webt/-o/7i/b_/-o7ib_j6tnrt1rz3axldz8vqmxq.png)
Но на самом деле под этим графическим пользовательским интерфейсом находится API. И когда пользователь нажимает на кнопочку, кнопочка вызывает функцию построения отчета.
![image](https://habrastorage.org/webt/x3/co/rs/x3corsskpydptgjoaebtgrqvhbi.png)
А функция построения отчета уже может вызывать 10 разных других функций, если ей это необходимо.
И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!
Что значит «Тестирование API»
В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.
Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:
- автотесты на уровне API
- или интеграцию между двумя разными системами.
Интеграция — когда одна система общается с другой по какому-то протоколу передачи данных. Это называется Remote API, то есть общение по сети, по некоему протоколу (HTTP, JMS и т.д.). В противовес ему есть еще Local API (он же «Shared memory API») — это то API, по которому программа общается сама с собой или общается с другой программой внутри одной виртуальной памяти.
![image](https://habrastorage.org/webt/b3/of/e9/b3ofe9co4ncbwachodnenynwsxu.png)
Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API. Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются.
И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!
Резюме
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Контракт включает в себя:
- саму операцию, которую мы можем выполнить,
- данные, которые поступают на вход,
- данные, которые оказываются на выходе (контент данных или сообщение об ошибке). ».
Комментарии (20)
CheY
19.08.2019 19:48В жестоком реальном мире помимо «что на вход», «что на выходе» и «что делает» есть ещё потребность в описании возможных состояний системы. Даже если хочется делать 100% RESTful…
borv
20.08.2019 01:13Вот для этого есть DbC (https://en.wikipedia.org/wiki/Design_by_contract). Там правда засада в том, что если уж вы все контракты верифицировали, то тестировать API скорее всего смысла нет.
LilyDalass
21.08.2019 13:30Отличная статья! Большое спасибо, все очень понятно и простым языком. Супер
saipr
Золотые слова! Применительно к нашей практике, то многие и многие сайты захудалые или нет (я говоря про сайты где так или иначе используются цифровые сертификаты и электронная подпись) не раскрывают сознательно или нет API, по которому с ними можно общаться. Они говорят возьми то-то и то-то, поставь и все будет работать. А это вообще-то говоря навязывание, отсюда коррупционные схемы и многое другое. И самое главное трудно предложить что-то новое и более совершенное и тем более перейти от MS Windows к отечественным ОС. Это и тормоз импортозамещению. Взгляните на требования к рабочему месту пользователя хоть ФНС, хоть ЕГАИС, хоть мною уважаемые ГОСУСЛУГИ и вы поймете, что до открытости API ой как далеко.
AlexPonomar
А что с ЕГАИС? Насколько помню там не такой уж и большой список требований
saipr
Мы же говорим не про требования к рабочему месту, кто хочет получить доступ в ЕГАИС, а про API, на котором все разработано.
А что ЕГАИС? Да, там не так все плохо и можно использовать токены PKCS#11 с ГОСТ-ами. Но все работает только под Windows, а это уже нехорошо.
AlexPonomar
Насчёт требования к ОС соглашусь. Но насчет API не так уверен. API у ЕГАИС идут для связи с ККТ (контрольно-кассовой техникой) и получением ТТН (Товарно-транспортной накладной) и остальных документов и поработав с ЕГАИС, я не заметил каких-то проблем с этим (кроме тех, когда пользователи сами косячат с номерами, информацией и прочим).
saipr
Согласитесь, ведь было бы совсем здорово, если бы ЕГАИС-у было безразницы на какой платформе работает пользователь. Кстати, ведь все социальные сети не зависят от платформу пользователя, наш же с вами Хабр.
Понимаете, помимо Linux, есть еще увлеченные люди, которые кроме OS X ничего признавать не хотят.
AlexPonomar
Согласен, при кроссплатформенности ПО ЕГАИС было бы лучше для рядового потребителя ввиду меньших затрат на технику при постоянной работе на Linux.
С другой стороны были бы проблемы с доработкой ПО и обучением работы на нем. Ведь большинство программ, даже для тех же мобильников структура программ и их функционал различен. А если какие-нибудь, допустим партнеры 1С, предоставляют услуги сопровождения предприятия в ЕГАИС, то работнику будет немного проблемно работать минимум на 2 ОС и перестраиваться между ними. Не смотря даже на тоже набор API
saipr
А тут вы не правы. Возьмите API PKCS#11 и сделайте всю работу с криптографией (включая создание и проверку подписи) на нем и все будет Ok.
Посмотрите сами хотя бы это (здесь пока три платформы). Программы и функционал для всех платформ одинаков.
AlexPonomar
Возможно мог ошибиться, а что насчет сопутствующего ПО и минимальных требований к ЕГАИС? Jacarta, если не ошибаюсь, без проблем и на Linux подобных работать.
А с остальным, в т.ч. и УТМ и 1С есть много проблем, даже на том же Linux, как с установкой, так и с обновлением.
Если распространять ЕГАИС и остальное на другие ОС, то надо будет дорабатывать само ПО и поддерживать эго
saipr
Нет, не ошибаетесь. И OS X тоже поддерживается.
Именно про это я и говорю.
AlexPonomar
А будет ли целесообразно дорабатывать ПО для ОС с % рабочих мест порядка 25%, даже при наличии всего набора API
saipr
А как же права меньшинств?
AlexPonomar
А как же миллионные затраты на доработку и поддержку?
saipr
Правительство требует импортозамещение, а оно знает, что делает. -)
AlexPonomar
Думаю, надо согласиться с вами, т.к. со знающим человеком лучше не спорить
saipr
Спасибо за комплимент!