сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · Автоматизация тестирования

Вопросы по автоматизации тестирования на собеседовании

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

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

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

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

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

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

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

  1. #automation_strategy1 / 9
    Что описывает тестовая пирамида?
    A)Много быстрых unit-тестов в основании, меньше интеграционных, немного медленных e2e наверху
    B)Поровну тестов на каждом уровне — по одинаковому числу unit, интеграционных и e2e
    C)Больше всего e2e-тестов в основании, а unit-тестов — немного на вершине пирамиды
    D)Порядок запуска тестов: сначала e2e, затем интеграционные, в конце модульные
    показать ответ и разбор
    +A)Много быстрых unit-тестов в основании, меньше интеграционных, немного медленных e2e наверху

    // разбор: Тестовая пирамида — рекомендация по балансу уровней автотестов. В основании — многочисленные unit-тесты: быстрые, стабильные, точно указывают на сломанный компонент. Середина — меньше интеграционных, проверяющих стыки. Вершина — немного e2e/UI-тестов через весь продукт: они медленные, хрупкие и дорогие в поддержке, поэтому их держат мало и только на критичные пользовательские пути. Форма отражает соотношение: чем выше уровень, тем дороже тест и тем их меньше.

  2. #ci_tooling2 / 9
    Зачем автотесты встраивают в CI-пайплайн?
    A)Чтобы гонять их на каждый коммит и пулл-реквест автоматически
    B)Чтобы тесты запускались раз в месяц по расписанию и не отвлекали разработчиков чаще
    C)Чтобы перенести выполнение тестов с машины разработчика на сервер ради экономии его ресурсов
    D)Чтобы тесты писались автоматически самим пайплайном по мере появления нового кода
    показать ответ и разбор
    +A)Чтобы гонять их на каждый коммит и пулл-реквест автоматически

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

  3. #design_patterns3 / 9
    Что такое паттерн Page Object?
    A)Класс-обёртка страницы: держит её локаторы и действия, а тест зовёт методы, не зная селекторов
    B)Скриншот страницы, который тест сохраняет для последующего визуального сравнения
    C)Отдельная страница отчёта, куда выводятся результаты прогона всех тестов набора
    D)Объект браузера, через который драйвер отправляет команды на удалённый сервер
    показать ответ и разбор
    +A)Класс-обёртка страницы: держит её локаторы и действия, а тест зовёт методы, не зная селекторов

    // разбор: Page Object Model — приём организации UI-тестов: каждой странице (или её части) соответствует класс, инкапсулирующий её локаторы и действия (методы вроде login(user, pass), openCart()). Тест взаимодействует со страницей только через эти методы и не знает конкретных селекторов. Так низкоуровневые детали (как найти кнопку) отделены от сценария (что проверяем). Плюсы: локатор описан в одном месте, тесты читаются как бизнес-шаги, поддержка при изменении UI сводится к правке одного класса, код переиспользуется между тестами.

  4. #reliability4 / 9
    Что такое флаки-тест (flaky test)?
    A)Тест, который то проходит, то падает без изменений кода
    B)Тест, который выполняется дольше остальных из-за большого объёма проверяемых данных
    C)Тест, который падает стабильно, пока разработчик не исправит найденный дефект
    D)Тест, написанный без ассертов, который поэтому проходит при поведении системы
    показать ответ и разбор
    +A)Тест, который то проходит, то падает без изменений кода

    // разбор: Флаки-тест даёт непостоянный результат на одном и том же коде: запустил — прошёл, перезапустил — упал, хотя ничего не менялось. Причины — недетерминизм: гонки и асинхронность, зависимость от порядка выполнения или общих данных, время/таймзоны/рандом, внешние сервисы, сетевые задержки. Опасность флаки не в одном тесте, а в эрозии доверия: команда привыкает, что «красное — это, наверное, опять флак», перезапускает сборку не глядя — и однажды пропускает настоящий регресс, замаскированный привычным ложным падением. Поэтому флаки чинят или изолируют, а не терпят.

  5. #ui_automation5 / 9
    Что делают инструменты вроде Selenium или Playwright?
    A)Программно управляют браузером: открывают страницы, находят элементы, кликают, вводят текст, читают результат
    B)Генерируют исходный код тестируемого веб-приложения по описанию его страниц
    C)Заменяют браузер собственным движком, который проверяет вёрстку без реального рендеринга
    D)Нагружают сервер тысячами параллельных запросов для проверки его производительности
    показать ответ и разбор
    +A)Программно управляют браузером: открывают страницы, находят элементы, кликают, вводят текст, читают результат

    // разбор: Selenium и Playwright — драйверы браузера: они позволяют из кода делать то, что обычно делает человек мышью и клавиатурой. Открыть URL, найти элемент по локатору, кликнуть, ввести текст в поле, прочитать текст/атрибут, дождаться появления элемента, сделать скриншот. Так автоматизируют UI-тесты: скрипт проходит пользовательский сценарий и проверяет результат на странице. Playwright новее, с встроенными умными ожиданиями и мультибраузерностью; Selenium — давний стандарт с широкой экосистемой.

  6. #vcs_git6 / 9
    Что делает система контроля версий вроде Git?
    A)Автоматически находит и исправляет ошибки в коде перед отправкой в репозиторий
    B)Хранит историю изменений кода и позволяет вести параллельные версии в ветках
    C)Компилирует проект и собирает из исходников готовый к запуску артефакт приложения
    D)Разворачивает приложение на сервере после каждого сохранения файла в проекте
    показать ответ и разбор
    +B)Хранит историю изменений кода и позволяет вести параллельные версии в ветках

    // разбор: Git — распределённая система контроля версий: фиксирует изменения кода снимками (коммитами), хранит всю историю, позволяет откатываться, сравнивать версии и вести параллельную разработку в ветках. Это не компилятор и не деплой-инструмент. Автоматизатору Git нужен, чтобы версионировать автотесты, работать с командой в общих ветках и связывать прогон тестов с конкретными изменениями кода.

  7. #automation_strategy7 / 9
    Почему e2e-тестов держат мало по сравнению с unit?
    A)E2e-тесты дешевле и стабильнее unit, поэтому их сокращают лишь ради экономии времени
    B)e2e медленные, хрупкие и дорогие в поддержке, при падении плохо локализуют причину
    C)E2e точнее указывают на сломанный компонент, но их ограничивают из-за размера кода
    D)E2e трудно запустить в CI, поэтому их число ограничивают ручными сценариями
    показать ответ и разбор
    +B)e2e медленные, хрупкие и дорогие в поддержке, при падении плохо локализуют причину

    // разбор: e2e-тест гоняет весь стек через интерфейс: он медленный (секунды-минуты против миллисекунд у unit), хрупкий (падает от любого изменения UI, вёрстки, окружения, тайминга), дорог в поддержке и при падении лишь говорит «где-то сломалось», не указывая компонент. unit-тесты, наоборот, быстры, изолированы и точно локализуют. Поэтому основную массу проверок держат на unit, а e2e ограничивают несколькими критичными сквозными путями (регистрация, оплата), где важно проверить систему целиком. Иначе прогон становится долгим и нестабильным.

  8. #ci_tooling8 / 9
    Как обычно делят прогон smoke-тестов и полного регресса в CI?
    A)Smoke гоняют ночью, а полный регресс — на каждый коммит, чтобы всё покрывать сразу
    B)Быстрый smoke — на каждый PR; тяжёлый полный регресс — по расписанию (nightly)
    C)Оба набора запускают на каждый пулл-реквест, чтобы разработчик видел полную картину
    D)Smoke и полный регресс — один и тот же набор, разница лишь в имени триггера сборки
    показать ответ и разбор
    +B)Быстрый smoke — на каждый PR; тяжёлый полный регресс — по расписанию (nightly)

    // разбор: Полный регрессионный набор бывает долгим (десятки минут-часы), и гонять его на каждый коммит — тормозить разработку. Поэтому прогоны разделяют по назначению. Быстрые дымовые (smoke) тесты — на каждый пулл-реквест: за минуты проверяют, что ключевое работает, и служат быстрым барьером перед слиянием. Тяжёлый полный регресс запускают реже — по расписанию (nightly) или перед релизом, — когда допустимо подождать. Так команда получает мгновенную обратную связь на каждый PR, не жертвуя полнотой: глубокое покрытие набирается регулярным ночным прогоном. Иногда добавляют средний уровень на merge в основную ветку.

  9. #design_patterns9 / 9
    Как Page Object упрощает поддержку при изменении интерфейса?
    A)Он ускоряет прогон тестов, кэшируя найденные элементы страницы между разными тестами
    B)Локатор описан в одном месте: при перевёрстке правят Page Object, а не десятки тестов, которые им пользуются
    C)Он позволяет запускать тесты без браузера, обращаясь к странице напрямую по API
    D)Он автоматически чинит сломанные локаторы, подбирая новый селектор при падении
    показать ответ и разбор
    +B)Локатор описан в одном месте: при перевёрстке правят Page Object, а не десятки тестов, которые им пользуются

    // разбор: Без Page Object селектор кнопки может быть скопирован в десятки тестов напрямую. Изменили вёрстку — придётся искать и править его во всех этих тестах, легко что-то пропустив. Page Object собирает локаторы и действия страницы в одном классе: тесты обращаются к ней через методы. При изменении интерфейса правку вносят в единственное место — сам Page Object, — и все тесты, использующие его, продолжают работать без изменений. Это резко снижает стоимость поддержки набора и число ошибок при массовых правках. Тот же принцип DRY — «одно знание в одном месте».

это 9 из 72

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

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

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

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

куда дальше