Где вводил переменные?

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

Основные контексты использования переменных

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

1. В коде автотестов (языки программирования)

Это самый частый и важный контекст. Здесь я объявляю переменные непосредственно в теле скрипта или тестового класса.

• Для хранения тестовых данных: URL, учетные данные, параметры запроса.
• Для работы с элементами страницы: Локаторы веб-элементов (селекторы).
• Для промежуточных результатов: Ответы API, текст из элемента, статус операции.

Пример на Python (pytest):

import pytest

class TestLogin:
    # Объявление констант/переменных на уровне класса
    BASE_URL = "https://api.example.com"
    VALID_USERNAME = "test_user"
    VALID_PASSWORD = "secure_pass123"

    def test_successful_login(self):
        # Объявление переменных внутри метода
        login_endpoint = f"{self.BASE_URL}/login"
        payload = {
            "username": self.VALID_USERNAME,
            "password": self.VALID_PASSWORD
        }

        response = requests.post(login_endpoint, json=payload)
        # Использование переменной для хранения и последующей проверки
        auth_token = response.json().get("token")
        assert auth_token is not None

Пример на Java (JUnit):

public class CheckoutTest {
    // Переменная на уровне класса
    private static final String BASE_URL = "https://shop.example.com";

    @Test
    public void testAddItemToCart() {
        // Локальные переменные внутри метода
        String productId = "prod_12345";
        int expectedQuantity = 1;
        CartPage cartPage = new CartPage(driver);

        cartPage.addProductById(productId);
        int actualQuantity = cartPage.getItemQuantity(productId);

        assertEquals("Quantity mismatch", expectedQuantity, actualQuantity);
    }
}

2. В файлах конфигурации и переменных окружения

Чтобы отделить код от данных и сделать тесты универсальными для разных сред (dev, stage, prod), я выношу переменные во внешние файлы.

• .env файлы: Для хранения чувствительных данных (пароли, ключи API).

  DB_HOST=localhost
  DB_USER=qa_user
  DB_PASS=secret
  ENVIRONMENT=staging
  

• Конфигурационные файлы (JSON, YAML, .properties):

  # config.yaml
  environments:
    staging:
      url: "https://staging.app.com"
      api_key: "key_stag"
    production:
      url: "https://app.com"
      api_key: "key_prod"
  

• Переменные окружения операционной системы, которые можно установить в CI/CD пайплайне (Jenkins, GitLab CI) или в системе перед запуском.

  # Установка в терминале перед запуском тестов
  export BROWSER=chrome
  export HEADLESS=true
  pytest
  

3. В инструментах тестирования с низким кодом/без кода (Low-Code/No-Code)

В таких инструментах, как Postman (для API тестирования) или Katalon Studio, переменные вводятся через специальные интерфейсы.

• В Postman:

    *   **Глобальные переменные:** Доступны во всех коллекциях и запросах.
    *   **Переменные окружения (Environment):** Набор переменных для конкретной среды (например, `{{base_url}}`).
    *   **Локальные переменные коллекции:** Только для запросов внутри одной коллекции.
    *   **Локальные переменные запроса (в скриптах):** Устанавливаются в разделах *Pre-request Script* или *Tests*.

```javascript
// Пример в Postman Test script
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

// Установка переменной из ответа
const jsonData = pm.response.json();
pm.environment.set("auth_token", jsonData.token); // Вводим новую переменную в окружение
```

4. В CI/CD пайплайнах (Jenkinsfile, GitLab CI, GitHub Actions)

Для управления конфигурацией сборок и развертывания тестовых сред.

• В Jenkins: Через интерфейс Configure в проекте (папка Build Environment или Parameters), или прямо в Jenkinsfile (declarative или scripted pipeline).

  // Jenkinsfile (Declarative Pipeline)
  pipeline {
      agent any
      environment {
          // Объявление переменных уровня пайплайна
          TEST_SUITE = 'regression'
          REPORT_DIR = 'target/surefire-reports'
      }
      parameters {
          // Параметры, которые пользователь может задать перед запуском
          choice(name: 'BROWSER', choices: ['chrome', 'firefox'], description: 'Select browser')
      }
      stages {
          stage('Test') {
              steps {
                  script {
                      // Использование переменной параметра
                      echo "Running ${TEST_SUITE} tests on ${params.BROWSER}"
                  }
              }
          }
      }
  }
  

• В GitLab CI: В файле .gitlab-ci.yml в секциях variables: или через настройки в интерфейсе GitLab (CI/CD -> Variables).

5. В командной строке / скриптах оболочки

При запуске тестов из терминала для одноразовой передачи параметров.

# Передача переменных напрямую в команду запуска
mvn test -DbaseUrl="https://dev.example.com" -Dbrowser=firefox

# Использование переменных в bash-скриптах для подготовки данных
TEST_DATA_FILE="testdata_$(date +%Y%m%d).csv"
python generate_fixtures.py --output ${TEST_DATA_FILE}

Ключевые принципы работы с переменными

• Изоляция чувствительных данных: Пароли и ключи никогда не хардкодятся, а берутся из защищенных переменных окружения.
• Ясность именования: Имя переменной должно однозначно отражать ее назначение (например, MAX_LOGIN_ATTEMPTS, а не tempVar).
• Область видимости (Scope): Я всегда выбираю минимально необходимую область видимости — локальная переменная в методе предпочтительнее глобальной, если она не нужна elsewhere.
• Переиспользование и поддержка: Вынос повторяющихся значений в константы или конфигурационные файлы упрощает поддержку тестов. Чтобы изменить URL для всех тестов, его правят в одном месте.

Таким образом, ввод переменных — это не единичное действие в одном месте, а систематическая практика, применяемая на всех уровнях тестового фреймворка и инфраструктуры для достижения гибкости, безопасности и эффективности процесса тестирования.