Как выполнить внешнее тестирование API (черный ящик)

Предположим, вы используете API от поставщика, как убедиться, что его API работает должным образом?

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

Короткий ответ: вам нужен набор тестов для API стороннего поставщика - так что вам придется его разрабатывать.

Не ждите, что кто-то другой сделает это за вас, и не ожидайте, что «волшебная палочка» автоматически сгенерирует правильные тесты.

Некоторые вещи, которые вы можете попробовать дополнительно:

• спросите поставщика, предоставляют ли они список «критических изменений» для каждого нового выпуска
• спросите их, как они заботятся о совместимости API / сообщите, что это важная функция для вас
• проверьте, предоставляет ли API специфические тестовые зацепки, протоколирование вывода или что-то в этом роде для частей, которые также не могут быть легко протестированы
• оберните важные вызовы API своим собственным кодом регистрации, записав ввод и связанный вывод API в файл журнала, это облегчит отладку в случае непредвиденной ситуации
• добавьте утверждения к вызовам API для проверки предварительных и постусловий, поэтому, если в новом выпуске API обнаруживается непредвиденное поведение в вашем приложении, вы заранее получаете сообщение об ошибке

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

Судя по формулировкам постера, это больше, чем просто тестирование, IMO. После того, как вы напишите свой тестовый модуль для API и убедитесь, что все работает должным образом, вам необходимо отслеживать сторонние API, чтобы выявлять проблемы раньше, чем пользователи. Это реальный риск для сторонних API-интерфейсов - это не ваш код, и вы не можете контролировать, сколько тестов было выполнено на API или когда / если оно изменилось.

(Отказ от ответственности: здесь используются названия продуктов). Если вы используете soapUI для написания своих тестов API, эти тесты можно повторно использовать в AlertSite в качестве рабочего монитора, чтобы убедиться, что API продолжает работать так, как ожидалось. Если тест не пройден, вы можете получить уведомление до того, как ваши пользователи позвонят вам и пожалуются, что ваше приложение не работает.

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

1. Это значительно улучшает ваше понимание стороннего API.
2. Тесты помогают проверить, действительно ли заявленная новая версия обратно совместима или нет.

Есть 2 подхода к этой проблеме ...

Ваше приложение работает в реальном времени с реальным пользовательским трафиком:

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

Вы всегда должны учитывать, что:

• изменение API со временем
• у поставщика API могут быть ошибки
• Тест-комплекты производителей API могут содержать ошибки или не полностью покрывать все функциональные возможности API

Ваше приложение является установкой и имеет запланированные версии / выпуски:

в этом случае у вас есть льготный период для сбоя ... живой пользователь не вступает в силу немедленно из-за изменений внешнего API.

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

после выполнения этой задачи вы можете запускать ее каждые 24 часа, 1 минуту и ​​т. д.

хорошие практики:

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

инструменты:

• Мониторинг живого приложения: гиперик -реликт
• Тестирование апи: apimetrics runscope SoapUI