Поговорим о том, каким должен быть интерфейс приложений, что делает его удобным для использования тестировщиками. Для начала рассмотрим критерии разработки удобных инструментов:
- запросы должны быть простыми и понятными;
- для каждого ресурса использовать только один идентификатор;
- количество используемых HTTP-статусов должно соответствовать количеству возможных ошибок, клиентской и серверной частей, т.е. 400х и 500х ошибок;
- структура ответов сервера должна быть унифицирована;
- использовать тип контента в заголовке запроса, xml или json.
Конечно, это неполный перечень для тестирования удобства использования API. Одни сервисы имеют мало функций, по которым к ним можно обращаться, другие, наоборот, имеют большой функционал, но во всех случаях важна логика построения запросов и удобство чтения запросов и ответов сервера.
Инструменты Open API делятся на множество категорий. Давайте рассмотрим наиболее часто употребляемые инструменты. Автоматические генераторы спецификаций на основе программного кода составляют отдельную группу. Для этого создается запрос, отправляющий данные в HAR файлах. HAR расшифровывается как Harmony Resource, формат для записи HTTP-сеансов для экспорта данных, включающих информацию о взаимодействии браузера с веб-страницей: содержимое скачанных страниц, файлы cookie с данными аутентификации, позволяющими зайти в пользовательский аккаунт, конфиденциальные данные, такие как пароли, номера кредитных карт. Этот удобный формат используется и для создания документации.
Следующая часто используемая категория инструментов это конверторы, которые преобразуют документацию из других форматов к формату Open API 3.0, т.к. этот формат принят в качестве стандарта и вся ранее созданная документация должна быть приведена к стандартному виду.
В отдельную категорию конвертеров выделены конверторы для преобразования структуры документа из JSON Schema в Open API Schema. Это делается также в целях приведения документации к стандартному виду, хотя документы со структурой вида JSON Schema по-прежнему могут использоваться в тестировании.
Валидаторы данных позволяют определить, соответствуют ли передаваемые данные описанию интерфейса API.
Категория DSL, Domain Specific Language, содержит языки описания Open API, создающие документ в формате YAML, формате описания серий данных, понятных человеку, не являющимся языком разметки, как сказано в расшифровке этой аббревиатуры.
Категория Mock Servers представляет собой серверные заглушки для еще не написанного интерфейса, чтобы можно было тестировать хотя бы ту часть функционала, которая уже написана и не ждать окончания разработки программного модуля.
Категория Testing позволяет использовать набор функций Open API для создания автотестов.
Надеюсь, материал был полезен. Конечно, недостаточно знать об этих функциях, надо еще уметь ими пользоваться. Эти вопросы, надеюсь, мы рассмотрим в будущих публикациях.
Подписывайтесь, если хотите получать полезные знания для тестирования, систематизировать свои знания.
В закрепленном сообщении бонусы для подписчиков.