Что такое интерфейс и что такое API

Прошлая часть: Форматы сообщений часть 2. XML и типы данных.

Всем привет. Продолжаем потихоньку самообразовываться в темах, которые относительно связаны с тестированием ПО.

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

Что такое интерфейс?

Перед объяснением термина «Интерфейс» предлагаю вам забыть то, что вы привыкли представлять, слыша это слово. Забудьте про формочки веб-страниц и кнопочки, которые на этих веб-страницах можно нажимать – то есть про то, что по-умному называется «графический интерфейс приложения». Это частный случай, который совершенно не показывает общую картинку.

Вместо этого предлагаю вам вспомнить устройство, цель применения и способ применения самого обычного молотка. Самое главное – наберитесь терпения.

Из чего состоит молоток? - Из рукоятки и головки. Головка насажена на рукоятку.

Какая цель у молотка? – При помощи нанесения удара головкой по «чему-либо» это «что-либо» забить.

Как применяется молоток? – Человек берет молоток рукой за рукоятку, делает замах и ударяет головкой по предмету, который хочет забить.

Казалось бы «А причем тут интерфейс?» - не торопитесь, сейчас всё будет. В какой именно момент времени человек начинает своё взаимодействие с молотком и что именно позволяет человеку воспользоваться полезной функцией молотка? Правильно – в тот момент, когда рука человека начинает взаимодействовать с рукоятью молотка. То есть для того, чтобы заставить молоток работать – необходимо сначала с ним начать обычное человеческое взаимодействие через взятие предмета в руки. Вот именно в этом моменте молоток, как предмет, предоставляет человеку свой интерфейс, в виде рукояти, чтобы человек мог выполнить полезную работу.

Получается, что интерфейс, в общем смысле этого слова – это что-либо, что позволяет взаимодействовать двум объектам между собой.

Развиваем наш предыдущий пример на более сложную систему – двухкамерный холодильник. Какие полезные функции, через какие интерфейсы нам предоставляет холодильник и каким образом эти функции реализованы?

1. Функция хранения продуктов в холодильном отделении. Осуществляется через взаимодействие руки человека с ручкой двери холодильного отделения, путем открытия/закрытия двери и помещения продуктов внутрь холодильного отделения.
2. Функция хранения продуктов в морозильном отделении. Осуществляется через взаимодействие руки человека с ручкой двери морозильного отделения, путем открытия/закрытия двери и помещения продуктов внутрь холодильного отделения.
3. Функция включения холодильника. Осуществляется через взаимодействие руки человека с вилкой кабеля питания, путем вставки вилки кабеля питания в розетку.
4. Функция выключения холодильника. Осуществляется через взаимодействие руки человека с вилкой кабеля питания, путем отсоединения вилки кабеля питания от розетки.
5. Функция регулировки мощности охлаждения холодильника. Осуществляется путем взаимодействия руки человека с терморегулятором, путем перемещения положения терморегулятора из одного положения в другое.

Теперь давайте найдем здесь интерфейсы. Для того чтобы это сделать – зададимся вопросом «Что нам, как человеку, позволяет воспользоваться полезной функцией холодильника?»

1. Что нам позволяет воспользоваться функцией хранения продуктов в холодильном отделении? – Дверь холодильного отделения холодильника, а именно ручка на этой двери. Именно через нее мы взаимодействуем и получаем доступ до холодильного отделения.
2. Что нам позволяет воспользоваться функцией хранения продуктов в морозильном отделении? – Дверь морозильного отделения холодильника, а именно ручка на этой двери. Именно через нее мы взаимодействуем и получаем доступ до морозильного отделения.
3. Что нам позволяет пользоваться функцией включения холодильника? – Вилка кабеля питания. Именно через нее мы взаимодействуем с розеткой и получаем доступ до электрического тока, который необходим для работы холодильника.
4. Что нам позволяет пользоваться функцией выключения холодильника? – Всё та же вилка кабеля питания. Именно через нее мы взаимодействуем с розеткой и отключаем доступ до электрического тока, который необходим для работы холодильника
5. Что нам позволяет воспользоваться функцией регулирования температуры внутри холодильника? – Терморегулятор. Через него мы взаимодействуем с «умной» системой внутри холодильника, которая увеличивает/уменьшает мощность работы компрессора холодильника, тем самым усиливая/уменьшая холод внутри него.

Таким образом мы нашли 5 интерфейсов. И как вы можете увидеть – ни один из этих интерфейсов не связан ни с формочками в браузере, ни с нажимаемыми кнопочками на этих формочках.

Еще раз зафиксируем основную мысль и определение интерфейса. Интерфейс – это что-либо, что позволяет взаимодействовать двум объектам между собой.

Теперь вернемся к таким понятиям как «веб-интерфейс» / «графический интерфейс» / «графический пользовательский интерфейс» - то есть к тому, что изначально каждый из нас представлял, когда слышал слово «интерфейс». Является ли всё перечисленное интерфейсом?

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

Что такое API?

API дословно расшифровывается как «Application programming interface», а по-русски «Программный интерфейс приложения». Разобравшись с обычным интерфейсом достаточно просто понять, что «программный интерфейс» — это то, что позволяет «чему-либо» взаимодействовать с приложением.

Важно понимать, что API представляет собой более жёсткий контракт, в отличии от приведенных примеров обычных интерфейсов. Условно, если вы можете игнорировать интерфейс ручки на двери холодильника и открыть дверь любого отделения, взявшись сбоку за дверь и открыв ее, то в случае с API у вас такой опции нет. Точнее вы можете попытаться, но вероятнее всего сервер вас не поймет и выплюнет в вашу сторону ошибку. Программа будет ожидать, что в конкретную ее точку будут присылаться только определенные данные, только с определенной целью и только с определенным форматом – только так и никак иначе.

Давайте разберем самые простые пример API, когда в качестве клиента будет выступать web-браузер.

Теперь разберем по пунктам что здесь происходит:

1. Пользователь заполняет руками различные поля в графическом интерфейсе приложения с целью получить какой-то результат.
2. Итоговым действием пользователя будет нажатие на кнопку, которая будет сигналом для клиентской части приложения о том, что необходимо сформировать запрос к серверу.
3. На основании заполненных полей клиент формирует запрос к серверу в таком виде, в котором сервер способен понять задачу, которую необходимо исполнить.
4. Сформировав запрос клиент отправляет этот запрос на сторону сервера.
5. Сервер получает запрос от клиента.
6. Сервер преобразует данные, полученные в запросе в такой вид, в котором серверная часть приложения способна их обрабатывать.
7. Сервер начинает выполнять какую-то полезную функцию над преобразованными данными.
8. В результате выполнения полезной функции рождаются данные, которые необходимы и достаточны для того, чтобы описать на сколько успешно была выполнена функция и каков её результат
9. Сервер преобразует данные о результате работы функции в формат, который способна понять клиентская часть приложения
10. Сервер формирует ответ в сторону клиентской части приложения.
11. Сервер отправляет ответ в сторону клиентской части приложения.
12. Клиент получает ответ от сервера.
13. Клиентская часть приложения преобразует ответ сервера в данные, которые необходимы и достаточны для того, чтобы отобразить пользователю результат обработки данных сервером.
14. Клиентская часть приложения заполняет форму графического интерфейса преобразованными данными, которые были получены от сервера.
15. Пользователь видит какой-то результат в графическом интерфейсе.

При этом важно понимать следующее:

1. Это простейший пример клиент-серверного взаимодействия и тот обрезанный.
2. Всё это происходит каждый раз, когда вы, как пользователь, работаете в web-браузере и переходите по ссылками или нажимаете на кнопки, которые приводят к преобразованию введенных вами данных.
3. Всё это взаимодействие чаще всего занимает не больше пары секунд.
4. API в этом взаимодействии находится в пунктах: 3+4; 5+6; 9+10+11; 12+13.

Из главы про клиент-серверную архитектуру мы помним, что в этой архитектуре еще присутствует база данных, а также что клиент – это не всегда web-браузер. Более того – не в каждом взаимодействии на запрос к серверу будет формироваться какой-то ответ (есть такое понятие, как асинхронное взаимодействие). Давайте рассмотрим эту более сложную картину и отобразим на ней потенциальные программные интерфейсы приложения:

Так как картинка получилась очень большая - в нормальном разрешении вы можете посмотреть ее по этой ссылке (прошу прощения за неудобства).

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

1. На каждое взаимодействие с чем-либо имеется API, причем не важно с чем именно происходит взаимодействие. API есть и при взаимодействии с web-браузером, и при взаимодействии с БД, и при асинхронном взаимодействии.
2. Один и тот же сервер может иметь много взаимодействий с чем-либо, а следовательно, и много API.
3. Иногда сервер вашей системы может выступать в качестве клиента, то есть он выступает в качестве инициатора запроса к внешней системе.

Зачем тестировщику знать про API?

У вас может возникнуть резонный вопрос после прочтения этой главы - «А нахрена мне это всё знать?». Сейчас я вам объясню.

Представьте, что у вас есть строгий набор правил, которые необходимо реализовать при разработке конкретного функционала. Но реализовывать эти правила будут два совершенно разных человека или даже команды – одна команда будет делать реализацию на стороне клиента, а вторая команда на стороне сервера. Какова вероятность того, что какая-то часть правил будет не учтена одной командой, а другая часть правил другой командой? Или какова вероятность, что одна команда воспримет правила по-своему, а вторая команда воспримет их иначе?

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

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

И так далее...

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

Также знание «Что такое API?» поможет вам лучше понимать то, как именно программы взаимодействуют между собой, а следовательно, вам станет проще искать аналогии между тестируемыми задачами и подбирать наиболее оптимальные подходы к тестированию задачи.

Ну и последняя причина – вас не будет смущать сленг в командах. Когда вы будете слышать фразу «Я разрабатываю эту АПИшку» или «Я занимаюсь тестированием АПИ такого-то функционала» - вы будете понимать про что говорит тот или иной ваш коллега.

Следующая часть: Что такое URL? Из чего состоит URL и почему это необходимо знать тестировщикам?

Поддержать или поблагодарить можете:

Лайком;

Комментарием;

Подпиской на канал;