сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · Тестирование API

Вопросы по тестированию API на собеседовании

Тестирование API это первое, что спрашивают у тестировщика после теории. Проверяют не знание кнопок Postman, а понимание протокола: какой код вернуть при ошибке валидации, чем PUT отличается от PATCH, что проверять кроме статуса ответа.

98 вопросов в банке·8 подтем·ниже разбор 9

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

Примеры вопросов с разбором

  1. #api_test_practice1 / 9
    Чем позитивные тесты API отличаются от негативных?
    A)Позитивные тесты пишут разработчики, а негативные — тестировщики, по разным правилам
    B)Позитив — валидный запрос даёт успех; негатив — битый/неавторизованный даёт ошибку
    C)Позитивные проверяют скорость ответа, а негативные — корректность данных в теле
    D)Негативные тесты запускают лишь после релиза, а позитивные — до него на стенде
    показать ответ и разбор
    +B)Позитив — валидный запрос даёт успех; негатив — битый/неавторизованный даёт ошибку

    // разбор: Позитивные тесты идут по счастливому пути: корректный запрос с валидными данными и правами возвращает ожидаемый успех (нужный код, правильное тело). Негативные проверяют устойчивость: битый JSON, отсутствующие поля, недопустимые значения, неавторизованный доступ, несуществующий ресурс — и убеждаются, что API отвечает корректной ошибкой (4xx с внятным телом), а не падает и не отдаёт 500. Полное покрытие требует и тех, и других: позитив подтверждает, что фича работает, негатив — что она безопасно обрабатывает всё остальное.

  2. #http_methods_codes2 / 9
    Что означает идемпотентность HTTP-метода?
    A)Метод срабатывает мгновенно и не зависит от текущей нагрузки на сервер приложения
    B)Повтор запроса даёт тот же итоговый результат
    C)Метод шифрует передаваемые данные, защищая их от перехвата по дороге к серверу
    D)Метод выполняется на сервере ровно один раз даже при нескольких повторных вызовах
    показать ответ и разбор
    +B)Повтор запроса даёт тот же итоговый результат

    // разбор: Идемпотентность значит, что многократное выполнение запроса приводит к тому же состоянию, что и однократное. GET ничего не меняет, PUT записывает одно и то же значение, DELETE повторно удаляет уже удалённое (результат тот же). POST не идемпотентен: каждый вызов создаёт новую сущность, поэтому повтор при таймауте даёт дубликат. Для тестировщика это карта рисков: где безопасно ретраить, а где нужен ключ идемпотентности.

  3. #integration_data3 / 9
    Как обеспечить, что повтор запроса на создание платежа не создаст второй платёж?
    A)Запретить клиенту повторять запрос — тогда платёж создастся ровно один раз
    B)Ключ идемпотентности: клиент шлёт его с запросом, сервер по нему распознаёт повтор и не выполняет операцию дважды
    C)Проверять сумму: если такой платёж уже был на ту же сумму, второй молча отклонять
    D)Замедлить обработку, чтобы между двумя запросами прошло достаточно времени
    показать ответ и разбор
    +B)Ключ идемпотентности: клиент шлёт его с запросом, сервер по нему распознаёт повтор и не выполняет операцию дважды

    // разбор: Создание платежа не идемпотентно: при сетевом сбое клиент не знает, дошёл ли первый запрос, и ретраит — рискуя списать деньги дважды. Решение — ключ идемпотентности: клиент генерирует уникальный ключ на операцию и шлёт его в заголовке; сервер запоминает выполненные ключи и, увидев повтор, возвращает результат первого запроса, не создавая второй платёж. Так ретраи становятся безопасными. Тестировщик проверяет: повтор с тем же ключом даёт один платёж и тот же ответ, а с новым ключом — новый платёж; параллельные повторы тоже не задваивают.

  4. #microservices4 / 9
    Что важно учитывать при тестировании GraphQL-API в отличие от REST?
    A)Один эндпоинт, клиент сам выбирает поля, а ошибки часто лежат в теле при коде 200
    B)Каждый ресурс лежит на отдельном URL, а состав полей задаётся через query-параметры в строке запроса
    C)Ответ приходит в бинарном виде, поэтому его проверяют через сгенерированный клиент
    D)Сервер сам решает, какие поля вернуть, и набор полей в ответе клиент не контролирует
    показать ответ и разбор
    +A)Один эндпоинт, клиент сам выбирает поля, а ошибки часто лежат в теле при коде 200

    // разбор: GraphQL — один эндпоинт (обычно /graphql), куда клиент шлёт запрос с точным списком нужных полей: это решает over-fetching (лишние данные) и under-fetching (не хватило, нужен второй запрос) REST. Особенность для тестировщика: транспортный код почти всегда 200, а частичные ошибки и нехватка прав лежат в теле ответа в массиве errors рядом с data — проверять надо и то, и другое. Плюс тестируют: пришли ли ровно запрошенные поля, глубину/сложность запроса, права на конкретные поля.

  5. #networking5 / 9
    Чем протокол TCP отличается от UDP?
    A)TCP работает исключительно в локальной сети, а UDP — только в глобальном интернете
    B)TCP шифрует передаваемые данные, а UDP передаёт их в открытом виде
    C)TCP гарантирует доставку и порядок пакетов, UDP быстрый, но без гарантий
    D)TCP передаёт только текст, а UDP — исключительно двоичные данные
    показать ответ и разбор
    +C)TCP гарантирует доставку и порядок пакетов, UDP быстрый, но без гарантий

    // разбор: TCP устанавливает соединение (рукопожатие), гарантирует доставку, порядок и целостность, переспрашивает потерянные пакеты — но за счёт накладных расходов. UDP шлёт датаграммы без соединения и подтверждений: быстрее и легче, но пакеты могут потеряться или прийти не по порядку. TCP — для HTTP, БД, почты; UDP — для видеозвонков, стриминга, DNS-запросов, где важнее скорость. Шифрование и сетевая среда на выбор между ними не влияют.

  6. #rest_principles6 / 9
    Что такое ресурс в REST-архитектуре?
    A)Сущность, адресуемая своим URI (/users/42); действие над ней задаёт HTTP-метод
    B)Отдельная функция на сервере, вызываемая по имени с параметрами через адрес запроса
    C)Файл на диске сервера, который клиент скачивает по прямой ссылке из браузера
    D)Сессия пользователя на сервере, которая идентифицируется по cookie в запросе
    показать ответ и разбор
    +A)Сущность, адресуемая своим URI (/users/42); действие над ней задаёт HTTP-метод

    // разбор: В REST всё крутится вокруг ресурсов — именованных сущностей (пользователь, заказ, товар), у каждой свой адрес-URI: /users/42, /orders/17. Что делать с ресурсом, говорит HTTP-метод: GET — прочитать, POST — создать, PUT/PATCH — изменить, DELETE — удалить. Отсюда правило «существительные в пути, глаголы — это методы»: /users/42, а не /getUser?id=42. Такой единообразный дизайн предсказуем и удобно тестируется: один и тот же URI по-разному отвечает на разные методы.

  7. #security7 / 9
    Что такое SQL-инъекция?
    A)Отказ базы, когда запрос без индекса перебирает всю таблицу и подвисает
    B)Ошибка приложения при вставке в поле значения неверного типа данных
    C)Ввод, который СУБД исполняет как часть SQL-запроса, а не как данные
    D)Повреждение строки, когда два запроса пишут в неё одновременно без блокировки
    показать ответ и разбор
    +C)Ввод, который СУБД исполняет как часть SQL-запроса, а не как данные

    // разбор: Уязвимость возникает, когда пользовательский ввод конкатенируется в текст SQL-запроса. Тогда строка вроде ' OR '1'='1 меняет саму логику запроса: приложение исполняет ввод как код, а не воспринимает как данные. Итог — обход авторизации, чтение или порча чужих данных. Лечится параметризованными запросами (ввод всегда идёт как значение). Тестировщик проверяет поля негативным вводом со спецсимволами.

  8. #web_fundamentals8 / 9
    Что описывает клиент-серверная модель веба?
    A)Клиент шлёт запрос, сервер обрабатывает его и возвращает ответ
    B)Сервер сам инициирует отправку данных клиенту, а клиент лишь пассивно их принимает
    C)Клиент и сервер — это две части одной программы в общей памяти одного процесса
    D)Клиент выполняет всю бизнес-логику, а сервер служит лишь для хранения файлов
    показать ответ и разбор
    +A)Клиент шлёт запрос, сервер обрабатывает его и возвращает ответ

    // разбор: В основе веба лежит обмен «запрос-ответ»: клиент (браузер, мобильное приложение, тестовый инструмент) формирует HTTP-запрос и шлёт его серверу; сервер выполняет логику, обращается к БД и возвращает HTTP-ответ. Стороны независимы и общаются по сети через согласованный протокол — клиент не знает внутреннего устройства сервера, сервер не хранит клиента у себя постоянно. Для тестирования API это ключ: можно слать запросы напрямую (Postman, код), минуя интерфейс, и проверять ответы сервера.

  9. #api_test_practice9 / 9
    Что такое коллекция в Postman?
    A)Один HTTP-запрос, сохранённый вместе с его последним полученным ответом от сервера
    B)Журнал всех запросов, которые сервер обработал за сессию, доступный для просмотра
    C)Набор сохранённых запросов (с окружениями и встроенными проверками), которые прогоняют и переиспользуют
    D)Список найденных в API дефектов с их серьёзностью и шагами воспроизведения
    показать ответ и разбор
    +C)Набор сохранённых запросов (с окружениями и встроенными проверками), которые прогоняют и переиспользуют

    // разбор: Коллекция Postman — организованная группа сохранённых HTTP-запросов, часто выстроенных в сценарий (логин → создать → проверить). К ним привязывают окружения (переменные baseUrl, токен), скрипты-проверки (tests) на код и тело, и данные. Коллекцию удобно переиспользовать, делиться ею с командой и запускать целиком — вручную или в CI через runner/Newman. Для тестировщика это способ превратить разовые ручные запросы в повторяемый, версионируемый набор проверок API.

это 9 из 98

Ещё 89 вопросов по теме — в тренажёре, с движком повторения

Прочитать разбор и ответить самому — разные навыки. В Сеньорчике вопросы идут сессиями, а движок возвращает подтемы, где вы ошибаетесь, пока они не начнут отскакивать. Бесплатно, лимит по энергии.

Открыть тренажёрДругие темы

Частые вопросы

куда дальше