Тестировщик | Вопросы собесов

🤔 Что известно о классе StringBuilder? StringBuilder — это класс в Java, предназначенный для эффективной работы с изменяемыми строками. Он позволяет изменять содержимое без создания новых объектов, в отличие от String, который является неизменяемым. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Как бы провел автоматизацию валидации имейла (кейса)? Автоматизация валидации email-адреса — это важная задача в тестировании, так как неправильный ввод email может привести к проблемам с регистрацией, авторизацией или отправкой уведомлений. Я бы провел автоматизацию следующим образом: 🟠Определение требований и правил валидации Прежде чем писать тесты, нужно понять, какие требования предъявляются к email. Обычно email должен: Содержать "@" и "." Иметь корректную структуру ([email protected]) Не содержать запрещенные символы (например, пробелы, кириллицу) Не быть слишком коротким ([email protected] — невалидно) Не быть слишком длинным (например, > 320 символов) Соответствовать формату регулярного выражения (RFC 5322) Пример регулярного выражения для валидации email: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ 🟠Написание автоматических тестов Я бы реализовал тестирование с помощью Selenium + Pytest или JUnit/TestNG в Java. import pytest from selenium import webdriver from selenium.webdriver.common.by import By @pytest.fixture def driver(): driver = webdriver.Chrome() driver.get("Ссылка скрыта # Открываем страницу регистрации yield driver driver.quit() @pytest.mark.parametrize("email, expected", [ ("[email protected]", True), # Валидный email ("invalid-email.com", False), # Нет "@" ("@nodomain.com", False), # Нет имени ("[email protected]", False), # Нет домена ("[email protected]", False), # Двойная точка ("[email protected]", False), # Слишком короткое доменное расширение ]) def test_email_validation(driver, email, expected): email_input = driver.find_element(By.NAME, "email") submit_button = driver.find_element(By.NAME, "submit") email_input.clear() email_input.send_keys(email) submit_button.click() error_message = driver.find_element(By.ID, "email-error") if expected: assert error_message.is_displayed() is False, f"Ошибка для валидного email: {email}" else: assert error_message.is_displayed() is True, f"Нет ошибки для невалидного email: {email}" 🟠Проверка на сервере (API-тестирование) Помимо UI, нужно проверять валидацию на сервере через API-запросы. Пример API-теста с Postman + Newman или RestAssured в Java import pytest import requests BASE_URL = "Ссылка скрыта @pytest.mark.parametrize("email, expected_status", [ ("[email protected]", 200), ("invalid-email.com", 400), ("[email protected]", 400), ]) def test_email_validation_api(email, expected_status): response = requests.post(BASE_URL, json={"email": email}) assert response.status_code == expected_status 🟠Интеграция тестов в CI/CD Чтобы автоматические тесты запускались регулярно, их можно интегрировать в Jenkins, GitHub Actions, GitLab CI. name: Run Email Validation Tests on: push: branches: - main jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v3 with: python-version: '3.9' - name: Install dependencies run: pip install -r requirements.txt - name: Run tests run: pytest tests/ Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое разработка тестирования? Разработка тестирования — это процесс создания стратегий, планов, сценариев и самих тестов для проверки качества продукта. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Чем отличается тестирование монолитного бэкенда и тестирование схемы веб сервисов? Тестирование монолитного бэкенда и сети веб-сервисов (микросервисной архитектуры) сильно различается из-за их архитектурных особенностей. 🚩Тестирование монолитного бэкенда Монолит – это единое приложение, где вся логика, база данных и API находятся в одном коде. 🟠Фокус на функциональном тестировании Проверяем, работает ли бэкенд как единое целое (API, БД, бизнес-логика). 🟠Юнит-тестирование (Unit Tests) Проверяем отдельные функции и классы (обычно через pytest, JUnit). 🟠Интеграционные тесты (Integration Tests) Проверяем связь между слоями (БД, API, бизнес-логика). 🟠Проще дебажить Весь код в одном месте, можно легко найти ошибку. def test_login(api_client): response = api_client.post("/login", json={"user": "admin", "pass": "123"}) assert response.status_code == 200 🚩Тестирование схемы веб-сервисов (микросервисов) В микросервисной архитектуре каждый сервис – отдельное приложение, взаимодействующее через API. 🟠Тестирование API-коммуникаций Проверяем REST или gRPC-запросы между сервисами. 🟠Контрактное тестирование (Contract Testing, Pact) Проверяем, что микросервисы обмениваются данными по заданному контракту. 🟠End-to-End (E2E) тестирование Проверяем, что все сервисы вместе работают корректно. 🟠Мониторинг и логирование Используем Jaeger, Prometheus для отслеживания ошибок между сервисами. 🟠Тестирование отказоустойчивости Проверяем, что система работает при сбоях (Chaos Monkey). import requests def test_order_service(): response = requests.get("Ссылка скрыта assert response.status_code == 200 Ставь 👍 и забирай 📚 Базу знаний

🤔 Если необходимо сгруппировать, какой нужен запрос? В SQL используется GROUP BY, в API — это может быть агрегация на стороне сервера, группировка по определённому полю в теле запроса или параметре. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 В чем разница между promise.all и promise.any? В JavaScript Promise.all() и Promise.any() – это методы, которые работают с массивом промисов и возвращают один итоговый промис. Но они ведут себя по-разному при успешных и неуспешных результатах. 🚩`Promise.all()` – ждет ВСЕ промисы Успешно выполняется только если ВСЕ промисы успешны. Если хотя бы ОДИН промис ошибочный, Promise.all() сразу отклоняется (reject). const p1 = Promise.resolve(1); const p2 = Promise.resolve(2); const p3 = Promise.resolve(3); Promise.all([p1, p2, p3]).then(result => { console.log(result); // [1, 2, 3] (все успешны) }); Пример с ошибкой const p1 = Promise.resolve(1); const p2 = Promise.reject("Ошибка!"); const p3 = Promise.resolve(3); Promise.all([p1, p2, p3]).catch(error => { console.log(error); // "Ошибка!" (первый reject ломает всё) }); 🚩`Promise.any()` – ждет ЛЮБОЙ успешный промис Выполняется, как только первый промис исполнится (resolve). Если все промисы завершаются с ошибкой, Promise.any() отклоняется с AggregateError. const p1 = Promise.reject("Ошибка 1"); const p2 = Promise.resolve(2); const p3 = Promise.resolve(3); Promise.any([p1, p2, p3]).then(result => { console.log(result); // 2 (берётся первый успешный) }); Пример (все с ошибками – ошибка) const p1 = Promise.reject("Ошибка 1"); const p2 = Promise.reject("Ошибка 2"); Promise.any([p1, p2]).catch(error => { console.log(error.errors); // ["Ошибка 1", "Ошибка 2"] }); Ставь 👍 и забирай 📚 Базу знаний

🤔 Для чего используется стек? Стек используется для хранения данных по принципу LIFO (Last-In, First-Out) — последний вошедший элемент обрабатывается первым. Примеры: управление вызовами функций, отмена действий, парсинг выражений. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Что лучше Postman или полноценный фреймворк? Выбор между Postman и полноценным фреймворком для API-тестирования (например, RestAssured, JMeter, Cypress, Karate) зависит от задач и масштаба тестирования. Давайте разберем, когда лучше использовать Postman, а когда стоит писать тесты в коде. 🚩Когда Postman — хороший выбор? Это удобный инструмент с графическим интерфейсом для тестирования API. Подходит для ручного тестирования и быстрого создания автотестов. 🚩Плюсы Postman ➕ Простота не требует программирования, удобный UI. ➕Автоматизация есть встроенный JavaScript для тестов (pm.test). ➕Коллекции можно сохранять запросы и запускать их пакетами. ➕Интеграции Postman поддерживает CI/CD, Newman, экспорт в другие форматы. 🚩Минусы Postman ➖Медленный при больших тестах сложно поддерживать сотни сценариев. ➖Ограниченные возможности сложные проверки требуют костылей на JavaScript. ➖Мало гибкости сложные логики (например, работа с БД) реализовать сложно. ➖Трудно версионировать хранение тестов в Postman сложнее, чем в коде (например, в Git). 🚩Когда лучше использовать фреймворк для API-тестирования? Фреймворки, такие как RestAssured (Java), Cypress (JavaScript), Karate (Java), JMeter, Playwright API позволяют писать мощные тесты с полной автоматизацией. 🚩Плюсы фреймворка ➕Гибкость можно писать сложные тесты с циклами, логикой, базами данных. ➕Хорошая интеграция с CI/CD удобно запускать в Jenkins, GitHub Actions, GitLab CI. ➕Версионирование хранится в Git, легко отслеживать изменения. ➕Масштабируемость подходит для больших тестов и многопоточного выполнения. 🚩Минусы фреймворка ➖Сложнее в освоении нужно знать язык программирования (Java, Python, JS). ➖Дольше настраивать требует конфигурации проекта, зависимостей. ➖Меньше визуального удобства нет готового UI, как в Postman. Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие бывают случаи, когда нам надо выбрать только тест-кейсы или чек-листы? Тест-кейсы предпочтительны, когда необходима документация, точное воспроизведение шагов и проверка сложной логики. Они полезны в больших проектах, где важна история выполнения и автоматизация. Чек-листы уместны в проектах с высокой скоростью, где важнее гибкость, чем формальность. Это также хороший выбор для исследовательского тестирования, когда заранее неизвестен весь функционал. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний