API-тестирование. Средний уровень(10/12)

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

API-тестирование всегда казалось мне предсказуемой областью — HTTP-запросы, статус-коды, заголовки, тело ответа. Разберем самые любопытные моменты.

Дисклеймер

Уважаемый читатель! Если после прочтения данного материала твои шансы пройти тестирование повысились хотя бы на долю процента — не ленись и ткни палец вверх 👍. Если же пользы оказалось примерно столько же, сколько витаминов в чипсах, вырази свое негодование смелым пальцем вниз 👎.

✏️Оставляй комментарии, ставь смайлики или реакции — именно это помогает автору понять, делает ли он мир чуточку лучше или просто жжёт трафик.

Вопрос 1

Выберите верное описание ограничений использования стандарта SOAP.

Варианты ответа:

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

Обоснование:
SOAP (Simple Object Access Protocol) действительно поддерживает как синхронные, так и асинхронные взаимодействия. Однако, он часто используется в синхронных сценариях, что может привести к неправильному восприятию этого аспекта.

Вариант 1 (неверно): SOAP поддерживает и асинхронные операции, особенно при использовании WS-Addressing и WS-ReliableMessaging.
Вариант 2 (неверно): SOAP не требует постоянного соединения, поскольку работает поверх протоколов, таких как HTTP и SMTP.
Вариант 3 (верно): SOAP поддерживает асинхронную модель передачи сообщений, например, через MQ (Message Queue) и другие механизмы. Однако он не предназначен для передачи данных в реальном времени, в отличие от WebSockets.
Вариант 4 (неверно): SOAP передает данные в формате XML, но может содержать бинарные вложения через MTOM (Message Transmission Optimization Mechanism).
Вариант 5 (неверно): SOAP не ограничивается только реальным временем и может поддерживать отложенные операции.

Выбранный ответ: 3: "Поддерживает асинхронную модель для передачи сообщений и не используется в реальном времени."

Вопрос 2

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

Отправка запроса с корректным значением нестандартного заголовка.
Отправка запроса с отсутствующим нестандартным заголовком.
Отправка запроса с некорректным значением нестандартного заголовка.
Проверка кодов ответа сервера и содержимого ответов для каждого из случаев.

Какую последовательность действий вы выберете для тестирования этих сценариев?

Варианты ответа:

Настроить Katalon Studio для выполнения запросов с динамическими значениями нестандартных заголовков.
Использовать Swagger UI для выполнения запросов с нестандартными заголовками и анализа ответов.
Создать коллекцию запросов в Postman, добавив X-Custom-Header с разными значениями, и проверить ответы сервера.
Создать JSON-файл с предопределёнными значениями нестандартных заголовков и использовать его для тестирования запросов вручную.
Написать cURL-команды для отправки запросов с различными значениями и с нестандартными заголовками.

Обоснование:
Для тестирования API с разными значениями нестандартных заголовков оптимальным инструментом будет Postman или cURL.

Вариант 1 (Katalon Studio) (неверно): Katalon Studio больше подходит для автоматизированного тестирования UI и API с более сложными сценариями. Хотя его можно использовать, это менее удобный инструмент для быстрой проверки заголовков.
Вариант 2 (Swagger UI) (неверно): Swagger UI в основном предназначен для документирования API и отправки тестовых запросов, но его возможности в проверке разных значений заголовков ограничены.
Вариант 3 (Postman) (верно): Postman позволяет удобно создавать коллекцию запросов, задавать переменные, динамически изменять заголовки и проверять ответы сервера. Это самый удобный и гибкий способ тестирования.
Вариант 4 (JSON-файл) (неверно): JSON-файл можно использовать для тестирования, но это не лучший способ отправки запросов и анализа ответов.
Вариант 5 (cURL) (частично верно): cURL позволяет отправлять HTTP-запросы с заголовками, но не так удобен для организации тестирования и анализа результатов, как Postman.

Выбранный ответ: 3 "Создать коллекцию запросов в Postman, добавив X-Custom-Header с разными значениями, и проверить ответы сервера."

Вопрос 3

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

Какой метод аутентификации и как следует использовать в этом случае?

Варианты ответа:

API ключи для генерации временных паролей для каждого клиента
Сессионные куки для хранения данных о сессии и доступа к API
JWT для подписанных токенов, которые включают логин и пароль пользователя
OAuth для предоставления безопасного доступа через токены, без передачи пароля
Basic Authentication для передачи зашифрованных данных в заголовке

Обоснование:

Вариант 1 (API ключи) (неверно): API-ключи могут использоваться, но они не обеспечивают гибкость и контроль доступа для сторонних приложений, особенно в контексте авторизации пользователей.
Вариант 2 (Сессионные куки) (неверно): Этот метод больше подходит для веб-приложений, работающих в браузере, а не для API, которые предоставляют доступ внешним сервисам.
Вариант 3 (JWT) (неверно): JWT (JSON Web Token) является хорошим способом передачи аутентификационной информации, но включение логина и пароля в токен противоречит принципу безопасной передачи данных.
Вариант 4 (OAuth) (верно): OAuth предоставляет безопасный доступ через токены (OAuth 2.0), исключая передачу пароля. Этот метод является стандартом для безопасной аутентификации API при взаимодействии сторонних сервисов.
Вариант 5 (Basic Authentication) (неверно): Basic Authentication требует передачи пароля (пусть даже в зашифрованном виде), что не соответствует требованиям безопасности.

Выбранный ответ: 4 "OAuth для предоставления безопасного доступа через токены, без передачи пароля."

Вопрос 4

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

Что нужно сделать для реализации такого решения?

Варианты ответа:

Изменить Basic Authentication на использование API ключей для каждого внешнего приложения
Настроить Digest Authentication для шифрования учетных данных
Внедрить JWT для хранения логина и пароля внутри токена
Применить Basic Authentication для всех сторонних приложений с проверкой прав доступа
Перейти с Basic Authentication на OAuth для предоставления доступа через токены

Обоснование:

Вариант 1 (API ключи) (неверно): API-ключи могут использоваться, но они не обеспечивают гибкий контроль доступа для пользователей, а также не исключают передачу ключа напрямую в запросе.
Вариант 2 (Digest Authentication) (неверно): Digest Authentication предоставляет только базовое шифрование учетных данных и не решает проблему безопасной передачи авторизационных данных без пароля.
Вариант 3 (JWT) (неверно): JWT (JSON Web Token) является хорошим методом для передачи данных аутентификации, но он сам по себе не исключает передачу логина и пароля. Он используется как часть механизма OAuth.
Вариант 4 (Basic Authentication с проверкой прав) (неверно): Basic Authentication предполагает передачу учетных данных в заголовках запроса, что не соответствует требованию исключения прямой передачи логина и пароля.
Вариант 5 (OAuth) (верно): OAuth является наиболее безопасным и современным методом аутентификации, позволяющим предоставлять доступ через токены без передачи пароля. OAuth 2.0 широко применяется для обеспечения безопасного доступа сторонних сервисов к API.

Выбранный ответ: 5 "Перейти с Basic Authentication на OAuth для предоставления доступа через токены."

Вопрос 5

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

Какова последовательность действий для преодоления последствий этой ошибки?

Варианты ответа:

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

Обоснование:
Ошибка 404 (Not Found) означает, что запрашиваемый ресурс недоступен. В данном случае проблема связана с маршрутизацией на сервере. Следовательно, важно:

Не увеличивать количество серверов (вариант 1 неверен), так как проблема не связана с нагрузкой, а с неправильными маршрутами.
Не использовать транзакции (вариант 2 неверен), так как 404 не возникает из-за некорректных изменений в базе данных.
Не ограничивать количество соединений (вариант 4 неверен), поскольку ошибка связана с маршрутизацией, а не с перегрузкой сервера.
Не полагаться только на кэширование (вариант 5 неверен), так как проблема не связана с производительностью, а с отсутствием корректных маршрутов.
Наиболее правильный вариант – обработка ошибок на клиенте (вариант 3 верен). Клиент может перехватывать ошибку 404, анализировать проблему и повторять запрос (например, если ресурс был временно недоступен из-за проблем маршрутизации или обновления API).

Выбранный ответ: 3 "Применить обработку ошибок на уровне клиента для перехвата и повторной отправки запросов при ошибке сервера."

Вопрос 6

Выполняя обновление данных методом PATCH, вы столкнулись с проблемой: некоторые клиенты получают ошибку 400 Bad Request из-за неверного формата данных даже при наличии корректных значений. Нужно устранить проблему и обеспечить корректное частичное обновление ресурса.

Какие действия лучше выбрать?

Варианты ответа:

Использовать метод GET, чтобы запросить данные перед их обновлением
Установить JSON как формат передачи данных в заголовке Content-Type
Переключиться на метод POST для отправки всех данных в виде новой записи
Изменить метод PATCH на PUT, чтобы выполнить полное обновление данных
Проверить данные запроса и добавить валидацию на стороне клиента перед отправкой

Обоснование:
Ошибка 400 Bad Request при использовании метода PATCH обычно возникает из-за:

Неправильного формата передаваемых данных
Отсутствия корректного заголовка Content-Type
Ошибок в структуре запроса

Анализируем варианты:

Вариант 1 (неверно): Запрос данных перед обновлением (GET) может быть полезен, но не решает проблему неверного формата данных.
Вариант 2 (верно): Указание Content-Type: application/json в заголовке поможет серверу правильно обработать формат данных.
Вариант 3 (неверно): Использование POST для обновления данных неправильно, так как PATCH предназначен именно для частичного обновления.
Вариант 4 (неверно): PUT заменяет весь ресурс, а не обновляет отдельные поля, что изменит логику работы.
Вариант 5 (верно): Проверка данных на стороне клиента перед отправкой поможет предотвратить отправку неверного формата.

Выбранный ответ: 2 "Установить JSON как формат передачи данных в заголовке Content-Type."

Вопрос 7

Ваш API получает запросы от клиентов с методами POST, PUT и DELETE, которые изменяют состояние сервера. Однако иногда состояние сервера изменяется некорректно:

создаются неполные данные,
обновления приводят к потере информации,
удалённые ресурсы продолжают отображаться в запросах.

Почему использование этих методов может вызывать такие проблемы?

Варианты ответа:

Из-за отсутствия проверки полномочий в методах перед выполнением операций
Методы не обеспечивают согласованность данных, если запросы выполняются одновременно
Методы зависят от наличия временных меток, которые могут быть некорректно обработаны
Методы принимают запросы на модификацию данных, что приводит к ошибке при неполных данных в теле запроса
Сервер автоматически повторяет запросы при задержках, что вызывает дублирование данных

Обоснование:

Вариант 1 (неверно): Проверка полномочий важна, но не объясняет проблему несогласованности данных.
Вариант 2 (верно): Одновременные запросы (race conditions) могут привести к некорректным обновлениям. Например, если два клиента отправляют PUT-запросы с разными данными одновременно, сервер может обработать их в неверном порядке или частично перезаписать данные. Это также может быть проблемой при удалении ресурсов (DELETE).
Вариант 3 (частично верно): Наличие временных меток (timestamp, ETag) может влиять на обработку данных, но проблема несогласованности вызвана именно одновременными запросами.
Вариант 4 (неверно): Ошибки при передаче данных могут случаться, но основная проблема здесь – согласованность при параллельных запросах.
Вариант 5 (неверно): Автоматический повтор запросов (retry) может привести к дублированию, но он не объясняет потерю данных и несогласованность при одновременных запросах.

Выбранный ответ: 2 "Методы не обеспечивают согласованность данных, если запросы выполняются одновременно."

Вопрос 8

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

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

Варианты ответа:

sort
limit
filter
page
offset

Обоснование:

sort (неверно): Отвечает за порядок сортировки данных, но не определяет, с какой записи начинать загрузку.
limit (неверно): Определяет количество записей в ответе, но не стартовую точку.
filter (неверно): Используется для фильтрации данных по критериям, но не управляет пагинацией.
page (частично верно): Указывает номер страницы, но не конкретную запись в общем списке.
offset (верно): Определяет начальный индекс записи, с которой начинается выборка. Например, offset=100 означает, что загрузка данных начнётся со 101-й записи.

Выбранный ответ: 5 "offset."

Вопрос 9

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

Какой метод вы для этого примените?

Варианты ответа:

Long Polling
Webhooks
Server-Sent Events
HTTP Polling
SOAP

Обоснование:

Long Polling (неверно): Постоянные длительные соединения с сервером могут потреблять много ресурсов, что неэффективно при большом количестве клиентов.
Webhooks (неверно): Webhooks отправляют уведомления от сервера к клиенту, но не являются полноценным решением для постоянного взаимодействия.
Server-Sent Events (верно): SSE (Server-Sent Events) — оптимальный вариант для передачи событий от сервера к клиенту с меньшими затратами ресурсов, чем WebSockets или Long Polling. SSE использует однонаправленный поток данных по HTTP/2 и хорошо подходит для масштабируемых решений.
HTTP Polling (неверно): Постоянные опросы сервера создают ненужную нагрузку.
SOAP (неверно): SOAP не предназначен для асинхронного взаимодействия в реальном времени.

Выбранный ответ: 3 "Server-Sent Events."

Вопрос 10

Вы заметили, что некоторые члены команды вносят изменения в API без обновления OpenAPI спецификации, что приводит к рассинхронизации документации и реальной реализации. Вам важно сохранять актуальность документации и спецификации API при внесении изменений в код.

Какой из подходов использовать?

Варианты ответа:

Настроить автоматическое обновление документации при каждом изменении кода API
Создать копию API спецификации и использовать ее для внутренних задач команды
Внедрить практику contract-first разработки, начиная с обновления спецификации перед кодированием
Использовать генераторы кода для автоматической генерации API из спецификации, избегая ручного кодирования
Вести документацию изменений в отдельных файлах, не затрагивая спецификацию OpenAPI

Обоснование:

Вариант 1 (частично верно): Автоматическое обновление документации полезно, но оно не гарантирует, что API всегда будет соответствовать спецификации OpenAPI.
Вариант 2 (неверно): Создание копии спецификации не решает проблему рассинхронизации, а только усложняет поддержку документации.
Вариант 3 (верно): Contract-first подход (спецификация перед кодом) решает проблему на корневом уровне. Разработка API начинается с OpenAPI-спецификации, а затем уже реализуется код, что предотвращает расхождения.
Вариант 4 (частично верно): Генерация кода из спецификации полезна, но не всегда возможна, особенно если API уже существует.
Вариант 5 (неверно): Ведение документации отдельно от OpenAPI приведёт к ещё большему рассинхрону.

Выбранный ответ: 3 "Внедрить практику contract-first разработки, начиная с обновления спецификации перед кодированием."

Вопрос 11

Какой формат данных НЕ поддерживает представление объектов в виде пар ключ-значение для API и не позволяет использовать вложенные структуры?

Варианты ответа:

XML
YAML
CSV
INI
JSON

Обоснование:

XML (неверно): Поддерживает вложенные структуры и пары ключ-значение.
YAML (неверно): Также поддерживает вложенные структуры и формат ключ-значение.
CSV (верно): CSV (Comma-Separated Values) предназначен для табличных данных и не поддерживает вложенные структуры. В нём нет естественного представления объектов с вложенностью.
INI (неверно): Хотя формат ограничен, он поддерживает вложенность через секции.
JSON (неверно): Полностью поддерживает объекты с вложенными структурами.

Выбранный ответ: 3 "CSV."

Вопрос 12

Ваше приложение использует распределенную архитектуру с несколькими сервисами.

Как влияет JWT на аутентификацию в этой ситуации?

Варианты ответа:

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

Обоснование:

Вариант 1 (верно): JWT (JSON Web Token) является статическим токеном, который не требует хранения сессий на сервере. Это позволяет передавать аутентификационные данные между сервисами без необходимости их постоянного хранения.
Вариант 2 (неверно): JWT не предоставляет единую точку входа, он только облегчает процесс передачи аутентификации.
Вариант 3 (неверно): Хотя JWT ускоряет процесс передачи данных, обмен ключами (public/private keys) для подписи токенов всё же может потребоваться в некоторых архитектурах.
Вариант 4 (неверно): JWT не хранит сессионные данные на сервере, так как он самодостаточен и передаётся между клиентом и сервером.
Вариант 5 (неверно): JWT используется для аутентификации, но сам по себе не ограничивает доступ – он только подтверждает подлинность пользователя.

Выбранный ответ: 1 "JWT позволяет сервисам обмениваться токенами, не требуя хранения их состояния на стороне сервера."

Заключение

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

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

Так что, если давно не пересматривали свои знания по API, попробуйте. Возможно, вас тоже ждет пара неожиданных открытий. 🚀