Как создавал автотест

Процесс создания автотеста

Как Senior QA Engineer с более чем 10-летним опытом, я рассматриваю создание автотеста как целостный инженерный процесс, а не просто написание кода. Это цикл, который начинается задолго до первой строчки кода и продолжается после его выполнения. Вот мой подход, отточенный годами практики.

1. Анализ и проектирование (Pre-Code Phase)

Перед тем как открыть IDE, я провожу глубокий анализ:

• Анализ требований: Я изучаю User Story, техническое задание, спецификации или API-документацию. Ключевой вопрос: "Что именно мы проверяем и в каком контексте?"
• Определение границ и данных: Я четко определяю:

    *   **Scope:** Какие сценарии будут автоматизированы (позитивные, негативные, граничные случаи).
    *   **Тестовые данные:** Какие данные нужны для теста (валидные, невалидные, пограничные). Я планирую, как они будут создаваться (фикстуры, фабрики, предустановленные в БД) и очищаться.
    *   **Критерии успеха:** Четкие условия прохождения теста (expected results).

• Выбор инструментов и уровня: Я принимаю решение на основе контекста:

    *   **Уровень тестирования:** UI (Selenium, Cypress, Playwright), API (REST Assured, Supertest, Requests), Unit (JUnit, pytest, Jest).
    *   **Язык и стек:** Выбор зависит от стека проекта (Java/Kotlin для Android или корпоративного бэкенда, Python/JS для веба, C# для .NET) и соглашений в команде.

• Проектирование архитектуры: На этом этапе я думаю о поддерживаемости и масштабируемости. Я определяю, как тест будет взаимодействовать с Page Object Model (POM) для UI, клиентами для API, где будут храниться локаторы, конфигурации, утилитные функции.

2. Реализация (Coding Phase)

Здесь я перехожу к написанию кода, следуя принципам чистого кода и DRY (Don't Repeat Yourself).

# Пример структурированного UI-теста с использованием POM и pytest
import pytest
from pages.login_page import LoginPage
from data.test_data import TestUsers

class TestLogin:
    """Набор тестов для функциональности входа в систему."""

    @pytest.fixture(autouse=True)
    def setup(self, browser):
        """Фикстура для инициализации страницы перед каждым тестом."""
        self.login_page = LoginPage(browser)
        self.login_page.open()  # Открываем страницу логина

    def test_successful_login_with_valid_credentials(self):
        """Позитивный тест: успешный вход с валидными данными."""
        # Arrange (Подготовка данных)
        user = TestUsers.VALID_USER

        # Act (Выполнение действия)
        self.login_page.enter_username(user["username"])
        self.login_page.enter_password(user["password"])
        self.login_page.click_login_button()

        # Assert (Проверка результата)
        assert self.login_page.is_user_menu_displayed(), "Меню пользователя не отобразилось после входа"
        assert self.login_page.get_welcome_text() == f"Welcome, {user['username']}!"

    def test_login_fails_with_invalid_password(self):
        """Негативный тест: вход с неверным паролем."""
        # Arrange
        user = TestUsers.USER_WITH_INVALID_PASS

        # Act
        self.login_page.login(user["username"], user["password"])

        # Assert
        assert self.login_page.is_error_message_displayed(), "Сообщение об ошибке не появилось"
        assert "Invalid credentials" in self.login_page.get_error_message_text()

Ключевые принципы реализации:

• Читаемость: Тест должен читаться как сценарий (Arrange-Act-Assert паттерн).
• Изоляция: Каждый тест независим и не должен полагаться на состояние, оставленное другими тестами. Для этого используются фикстуры (fixtures) для setup/teardown.
• Гибкость: Конфигурационные данные (URL, таймауты, учетные данные) выносятся во внешние файлы (.env, config.yaml, properties).
• Надежность: Использую явные ожидания (explicit waits) вместо time.sleep() для взаимодействия с динамичными элементами UI.

3. Интеграция и запуск (Post-Code Phase)

Созданный тест — это не просто файл на диске. Он должен стать частью рабочего процесса команды.

• Интеграция с CI/CD: Я настраиваю запуск автотестов в пайплайне (Jenkins, GitLab CI, GitHub Actions). Это может быть запуск на каждый коммит (smoke-тесты), при создании pull request или ночью (регрессия).

  # Пример фрагмента GitHub Actions workflow
  - name: Run Automated Tests
    run: |
      pytest tests/smoke/ --alluredir=./allure-results
  

• Настройка отчетности: Подключаю системы отчетности для визуализации результатов (Allure Report, ExtentReports, pytest-html). Хороший отчет помогает быстро локализовать проблему.
• Тест-ранеры и параллелизация: Для ускорения прогона настраиваю параллельный запуск тестов (например, с помощью pytest-xdist или возможностей CI-системы).

4. Поддержка и рефакторинг

Автотесты — это живой код. Я постоянно занимаюсь их поддержкой:

• Анализ падений: Разбираюсь с каждым "флакyи" (flakey) тестом. Если тест неустойчив, я переписываю его, улучшаю локаторы или логику ожиданий.
• Рефакторинг: По мере роста набора тестов я выношу общую логику в хелперы, улучшаю структуру Page Objects или перехожу на более продвинутые паттерны (например, Screenplay Pattern).
• Обновление: Тесты обновляются вместе с продуктом. При изменении функциональности я вношу соответствующие правки в автоматизацию.

Итог: Мой процесс — это инженерный цикл, где анализ, качественный код и интеграция в процесс разработки одинаково важны. Цель — создать не просто "проверяющий скрипт", а надежный, поддерживаемый и ценный актив, который экономит время команды, снижает риски и повышает уверенность в качестве продукта на всех этапах его жизненного цикла.