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

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

• Регрессионные и smoke-проверки запускают часто, поэтому автоматизация сокращает объём повторной ручной работы.
• Стабильные входные данные и наблюдаемые результаты позволяют скрипту однозначно определить успех или провал.
• Проверки с большим объемом данных выигрывают от автоматизации, потому что скрипт последовательно обрабатывает много комбинаций.
• Одноразовую проверку меняющегося прототипа обычно дороже автоматизировать, чем выполнить вручную.

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

• Исследовательское тестирование опирается на наблюдения и уточняющие вопросы, которые фиксированный скрипт не может предсказать.
• Удобство, визуальная привлекательность и качество текста требуют человеческой оценки, если нет измеримого критерия приемки.
• Быстро меняющийся прототип делает поддержку селекторов и сценариев дорогой.
• Редкие проверки с низким бизнес-риском могут никогда не окупить стоимость реализации и поддержки.

Детерминированный тест дает одинаковый результат, когда код и контролируемые входные данные не меняются.

• Он контролирует время, случайность, тестовые данные и внешние зависимости, а не наследует меняющиеся значения.
• Он ждет измеримого состояния, например видимости элемента, вместо паузы на 5 секунд.
• Он создает или сбрасывает собственные данные, чтобы другой тест не изменил ожидаемый результат.
• При 20 повторах на одной сборке детерминированный тест не должен чередовать успех и провал.

Пирамида тестирования рекомендует много быстрых unit-тестов, меньше integration-тестов и небольшое число end-to-end тестов.

• Unit-тесты изолируют небольшие части логики и должны давать обратную связь за миллисекунды.
• Integration-тесты проверяют реальные границы, например код приложения вместе с базой данных или HTTP-сервисом.
• End-to-end тесты покрывают критичные пользовательские пути, но дороже в запуске и поддержке.
• Такая форма сохраняет быструю обратную связь и при этом проверяет работу собранного продукта.

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

• Фикстура содержала бы известные записи, чтобы ожидаемые количества, статусы и распределение по выходным файлам вычислялись независимо от реализации.
• Я бы разобрал JSON и проверил его схему и стабильные значения вместо сравнения исходного текста, в котором порядок свойств может меняться.
• Я бы проверил, что выходной каталог содержит ровно два завершённых файла, затем разобрал их и сравнил обязательные строки, поля и порядок только там, где он входит в контракт.
• Сгенерированные временные метки и ID контролировались бы или нормализовались, а временные и неожиданные файлы приводили бы к провалу теста.

Smoke-тестирование проверяет базовую работоспособность сборки, а регрессионное широко проверяет сохранность существующего поведения.

• Smoke-набор покрывает несколько критичных путей, например запуск, вход и одну основную операцию.
• Он быстро выполняется после деплоя или сборки и останавливает глубокое тестирование, если продукт неработоспособен.
• Регрессионный набор покрывает много ранее работавших функций и обычно выполняется дольше.
• Оба набора можно автоматизировать, но smoke-набор должен оставаться достаточно малым для быстрой обратной связи.

Функциональное тестирование проверяет, что делает система, а нефункциональное проверяет качества ее работы.

• Функциональная проверка подтверждает поведение, например создание заказа с валидными данными.
• Нефункциональные проверки охватывают время ответа, доступность, безопасность и надежность.
• Для обоих нужны измеримые ожидания, например статус 201 при создании или задержка p95 ниже 500 мс.
• Функция может работать правильно, но быть неприемлемой из-за низкой скорости или недоступности.

Полезная проверка подтверждает одно наблюдаемое требование с точным и стабильным ожиданием.

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

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

• Список сохраняет порядок и может содержать последовательность тест-кейсов или полученных записей.
• Словарь сопоставляет имена полей со значениями, что подходит для JSON с полями name и email.
• Множество удаляет дубликаты и быстро проверяет вхождение, а кортеж представляет фиксированную группу значений.
• Выбор типа по его поведению делает проверки понятнее, чем принудительное преобразование всех данных в строки.

Используйте конструкцию with, чтобы Python закрыл файл даже при ошибке.

• Открывайте текстовые файлы с явной кодировкой, например UTF-8, чтобы избежать разного декодирования на разных машинах.
• Осознанно выбирайте режим: r читает, w заменяет содержимое, а a дописывает.
• Читайте большие файлы построчно вместо загрузки всего файла в память.
• Обрабатывайте ожидаемые исключения, например FileNotFoundError, и указывайте затронутый путь.

pathlib представляет пути объектами и делает операции с ними понятными и переносимыми.

• Path(base) / results.xml соединяет части с правильным разделителем для операционной системы.
• Методы exists, mkdir, read_text и glob прямо выражают типичные файловые операции.
• resolve может получить абсолютный путь, когда он нужен инструменту.
• Это избавляет от ручного склеивания строк, которое создает двойные или неправильные разделители.

Читайте настройки окружения во время запуска и проверяйте обязательные переменные до старта тестов.

• os.getenv может читать значения вроде BASE_URL, BROWSER или имени тестовой учетной записи.
• Задавайте значения по умолчанию только для безопасных необязательных настроек, например BROWSER со значением chromium.
• Завершайте работу с понятным сообщением при отсутствии обязательного значения, а не передавайте None глубже в код.
• Никогда не печатайте и не коммитьте пароли, токены или API-ключи из окружения.

Используйте subprocess.run с явными аргументами и проверяйте результат процесса.

• Передавайте список аргументов, например git, status, вместо одной shell-строки с недоверенными данными.
• Установите check=True, если ненулевой код завершения должен вызвать CalledProcessError.
• Используйте capture_output=True и text=True, когда скрипту нужны читаемые stdout и stderr.
• Добавьте таймаут, чтобы зависший внешний инструмент не блокировал автоматизацию бесконечно.

Код завершения сообщает об успехе команды: по соглашению 0 означает успех, а ненулевое значение означает ошибку.

• Shell, CI-раннер или родительский процесс использует код, чтобы решить, запускать ли следующий шаг.
• Разные ненулевые значения могут различать неверные входные данные, падение теста и отсутствие зависимости.
• Перед возвратом кода ошибки скрипт должен вывести полезное сообщение в stderr.
• Если скрыть ошибку и завершиться с кодом 0, сломанная тестовая задача может выглядеть успешной.

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

• При разборе файла результатов ловите конкретный тип, например JSONDecodeError, а не общий Exception.
• Добавляйте контекст, например путь к файлу или имя команды, и сохраняйте исходную причину при повторном выбрасывании.
• Используйте finally для очистки, обязательной и при успехе, и при ошибке.
• Никогда не оставляйте пустой блок except, потому что он превращает реальный сбой в вводящий в заблуждение результат теста.

Надежные Bash-скрипты заключают переменные в кавычки, проверяют ошибки команд и явно задают поведение конвейеров.

• Используйте двойные кавычки вокруг подстановок вроде $file, чтобы пробелы не разделили один путь на несколько аргументов.
• Конвейер передает stdout одной команды в stdin следующей, например от команды-источника к grep.
• set -e завершает shell при многих необработанных ненулевых статусах, но имеет контекстные исключения для условий, списков команд и частей конвейера, поэтому ожидаемые ошибки нужно обрабатывать явно, а set -o pipefail использовать для выявления ошибок внутри конвейера.
• Отправляйте диагностику в stderr и возвращайте ненулевой код, если скрипт не может завершить работу.

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

• Начните от обновленной ветки main, чтобы изменение теста основывалось на актуальном коде.
• Используйте git status и git diff, чтобы проверить, какие именно файлы и строки попадут в коммит.
• Напишите короткое сообщение коммита о добавленном или исправленном поведении.
• Отправьте ветку и откройте pull request, чтобы до изменения main прошли тесты и ревью.

Конфликт слияния возникает, когда Git не может безопасно объединить конкурирующие изменения и требуется решение человека.

• Git отмечает в файле конфликтующие фрагменты текущей и входящей веток.
• Прочитайте обе версии, оставьте нужное итоговое содержимое и удалите все маркеры конфликта.
• После редактирования запустите связанные тесты, потому что синтаксически разрешенный файл все еще может быть логически неверным.
• Добавьте исправленный файл в индекс и завершите merge или rebase согласно процессу команды.

pytest находит тесты по соглашениям об именовании, а затем собирает подходящие функции и классы.

• По умолчанию он ищет файлы с именами test_*.py или *_test.py.
• Он собирает функции test_* и методы test_* внутри классов Test*.
• В тестовых классах не следует определять __init__, потому что pytest сам создает их экземпляры.
• pytest --collect-only показывает, что будет запущено, не выполняя тесты.

Fixture в pytest предоставляет тестам переиспользуемые данные или ресурсы через аргументы функций.

• Пометьте функцию-поставщик через pytest.fixture и запросите ее, указав имя параметром теста.
• Fixture может вернуть тестовые данные, настроенный API-клиент или страницу браузера.
• Код после yield выполняет teardown, например закрывает соединение после теста.
• Fixtures сокращают дублирование настройки и сохраняют зависимости видимыми в сигнатуре каждого теста.