Вопросы на собеседовании тестировщика (QA)

Теория тестирования и тест-дизайн, работа с API, автоматизация, мобильное тестирование. Ниже — вопросы, которые реально задают QA-инженеру, с разбором.

1. #algorithms1 / 9

   Почему поиск по ключу в хеш-таблице (dict/set) в среднем O(1), а в списке — O(n)?

   A)Список хранит элементы строго отсортированными, а хеш-таблица — вперемешку без порядка

   B)В списке элементы занимают меньше памяти, поэтому поиск медленнее

   C)Хеш по ключу сразу вычисляет позицию (бакет), а список надо обходить подряд

   D)Разницы нет, оба O(n)

   показать ответ и разбор

   +C)Хеш по ключу сразу вычисляет позицию (бакет), а список надо обходить подряд

   // разбор: Хеш-функция превращает ключ в индекс бакета за O(1), и мы прыгаем прямо к нему. В списке адреса по значению неизвестны, поэтому линейный поиск обходит элементы один за другим — O(n). Цена O(1): нет порядка и есть накладные расходы на хеширование и коллизии.

2. #algorithms2 / 9

   Алгоритм работает за O(n). Что это значит на практике?

   A)Он выполняет ровно n операций при входе — ни больше, ни меньше

   B)Число операций растёт линейно с размером входа n

   C)В худшем случае он делает порядка n² операций

   D)Ему требуется ровно n байт дополнительной памяти

   показать ответ и разбор

   +B)Число операций растёт линейно с размером входа n

   // разбор: O(n) — про асимптотику: при росте входа вдвое время растёт примерно вдвое. Это верхняя оценка скорости роста, а не точное число операций и не про память. Константы и младшие члены отбрасывают: O(3n+5) — это O(n).

3. #algorithms3 / 9

   Бинарный поиск работает за O(log n). Какое условие обязательно для его применения?

   A)Массив должен состоять из чисел, строки бинарным поиском искать не получится

   B)Массив (или диапазон) должен быть отсортирован по искомому ключу

   C)В массиве не должно быть повторяющихся значений

   D)Размер массива должен быть степенью двойки

   показать ответ и разбор

   +B)Массив (или диапазон) должен быть отсортирован по искомому ключу

   // разбор: Бинарный поиск на каждом шаге отбрасывает половину диапазона, сравнивая середину с искомым — это возможно только если данные упорядочены по ключу. O(log n) — число делений пополам до одного элемента. Повторы и нечисловые типы допустимы (лишь бы был порядок); степень двойки не требуется.

4. #algorithms4 / 9

   Стек (stack) — это структура с дисциплиной...

   A)LIFO: последним пришёл — первым вышел

   B)FIFO: первым пришёл — первым вышел

   C)По приоритету: первым выходит элемент с наименьшим ключом среди всех имеющихся

   D)Случайного доступа по индексу

   показать ответ и разбор

   +A)LIFO: последним пришёл — первым вышел

   // разбор: Стек — LIFO: push кладёт наверх, pop снимает верхний, оба O(1). Аналогия — стопка тарелок. FIFO — это очередь, приоритет — куча. Стек естественно моделирует вложенность: вызовы функций (call stack), парсинг скобок, откат (undo), обход в глубину.

5. #api_testing5 / 9

   Что проверяют в ответе API при тестировании?

   A)Статус-код, тело (структуру и значения) и ключевые заголовки

   B)Достаточно проверить лишь статус-код: если он 2xx, тело и заголовки уже неважны

   C)Проверяют время ответа и объём тела в байтах, а содержимое полей значения не имеет

   D)Сверяют заголовки ответа, поскольку тело у REST-эндпоинтов обычно пустое

   показать ответ и разбор

   +A)Статус-код, тело (структуру и значения) и ключевые заголовки

   // разбор: Полноценная проверка ответа складывается из нескольких слоёв. Статус-код — ожидаемый ли исход (201 на создание, 404 на отсутствие). Тело — верна ли структура (нужные поля, типы) и конкретные значения (id совпадает, сумма верна). Заголовки — Content-Type, Location, заголовки кэша и безопасности, пагинации. Проверять только код недостаточно: 200 бывает и с битым телом; проверять только тело — упустить неверный код. Хороший API-тест смотрит все три уровня в меру их важности для сценария.

6. #api_testing6 / 9

   Чем HTTP-метод GET отличается от POST?

   A)GET запрашивает данные и не меняет состояние сервера

   B)GET передаёт данные в теле запроса, а POST — в адресной строке в виде параметров URL

   C)GET работает по защищённому протоколу, а POST по обычному незашифрованному соединению

   D)GET и POST взаимозаменяемы, различие между ними лишь в названии метода

   показать ответ и разбор

   +A)GET запрашивает данные и не меняет состояние сервера

   // разбор: GET — «безопасный» метод чтения: он не должен менять состояние на сервере, параметры идут в query-строке URL, ответ кэшируется. POST отправляет данные в теле запроса и обычно создаёт новый ресурс или запускает обработку, меняя состояние. Ключевое различие для тестировщика: GET можно повторять без последствий, а повтор POST способен создать дубликат. Отсюда и разные ожидаемые коды (200 против 201) и разные риски.

7. #api_testing7 / 9

   Почему после POST, создавшего запись, проверяют данные ещё и в базе (SQL)?

   A)Код 201 не гарантирует, что данные записались верно

   B)Потому что ответ API приходит зашифрованным, и прочитать его значения можно лишь из БД

   C)Потому что API не возвращает id созданной записи, и его узнают запросом к базе

   D)Потому что проверка в БД заменяет собой необходимость проверять сам ответ API

   показать ответ и разбор

   +A)Код 201 не гарантирует, что данные записались верно

   // разбор: Успешный код ответа говорит, что сервер принял и обработал запрос, но не доказывает, что в хранилище легли правильные данные: могло записаться не то, потеряться поле, сработать неверный дефолт, уйти в другую таблицу. Прямой запрос к БД после API-вызова сверяет фактическое состояние с ожидаемым — так ловят рассогласование между тем, что API «сказал», и что реально сохранил. Это уровень интеграционной проверки, дополняющий проверку ответа. На проде так не делают вслепую, но на тестовом стенде сверка с БД — сильный инструмент против тихих багов записи.

8. #api_testing8 / 9

   Чем gRPC отличается от привычного REST поверх JSON?

   A)GRPC — надстройка над REST, добавляющая к JSON-ответам обязательную цифровую подпись

   B)GRPC вызывает функции внутри одного процесса, а между сервисами по сети не используется

   C)gRPC гоняет бинарный protobuf поверх HTTP/2 по строгой .proto-схеме

   D)GRPC — это REST-запросы, завёрнутые в WebSocket для двусторонней связи

   показать ответ и разбор

   +C)gRPC гоняет бинарный protobuf поверх HTTP/2 по строгой .proto-схеме

   // разбор: gRPC — способ вызывать методы чужого сервиса (RPC): контракт задаётся в .proto, данные сериализуются в бинарный Protocol Buffers и идут поверх HTTP/2, что даёт компактность, мультиплексирование и стриминг. Это быстрее и строже REST/JSON, но ответ не прочитать глазом и не дёрнуть голым браузером — нужны grpcurl, Postman (есть поддержка gRPC) или сгенерированный клиент. Тестировщику важно: контракт — .proto, ошибки приходят статус-кодами gRPC (не HTTP 4xx/5xx), а проверка требует спец-инструментов.

9. #api_testing9 / 9

   Что делает DNS, когда вы открываете сайт по имени?

   A)Шифрует соединение между браузером и сервером сайта

   B)Переводит доменное имя (example.com) в IP-адрес сервера

   C)Хранит куки и историю посещений сайта в браузере

   D)Распределяет нагрузку между копиями сервера по очереди

   показать ответ и разбор

   +B)Переводит доменное имя (example.com) в IP-адрес сервера

   // разбор: DNS (Domain Name System) — телефонная книга интернета: по доменному имени возвращает IP-адрес сервера, потому что сеть маршрутизирует пакеты по IP, а не по именам. Браузер сперва резолвит имя через DNS (с кэшированием), затем открывает соединение к полученному IP. Тестировщик сталкивается с DNS, когда сайт «не открывается» из-за неверной записи, устаревшего кэша или неправильного окружения (dev/stage резолвится не туда).