Сколько уровней в пирамиде тестирования?

Уровни в пирамиде тестирования: классическая модель

Пирамида тестирования — это концепция, введенная Майком Кохном в 2009 году, которая визуализирует оптимальное распределение усилий по автоматизации тестирования. Она описывает иерархию тестов по их скорости выполнения, стоимости поддержки и степени изоляции.

В своей классической форме пирамида состоит из трех основных уровней, которые снизу вверх представляют собой:

1. Базовый уровень: Unit-тесты (Модульные тесты)

• Что это: Тестирование минимальных, изолированных единиц кода (функции, методы, классы) в отрыве от внешних зависимостей (база данных, сеть, файловая система). Это достигается с помощью моков (mocks), стабов (stubs) и фейков (fakes).
• Цель: Проверить корректность логики и алгоритмов. Они самые быстрые, дешевые в исполнении и дают мгновенную обратную связь разработчику.
• Кто пишет: Разработчики (часто в парадигме TDD — Test-Driven Development).
• Пример на Python (pytest):

  # Функция, которую тестируем
  def calculate_discount(price, discount_percent):
      if discount_percent < 0 or discount_percent > 100:
          raise ValueError("Discount must be between 0 and 100")
      return price * (1 - discount_percent / 100)
  
  # Unit-тест
  def test_calculate_discount():
      # Проверяем основную логику
      assert calculate_discount(1000, 10) == 900
      # Проверяем граничное условие (скидка 0%)
      assert calculate_discount(1000, 0) == 1000
      # Проверяем обработку невалидных данных
      with pytest.raises(ValueError):
          calculate_discount(1000, 150)
  

2. Средний уровень: Service-тесты (Интеграционные/API-тесты)

• Что это: Тестирование взаимодействия между несколькими модулями, классами или, что более типично, — тестирование API (Application Programming Interface). Эти тесты проверяют, как разные части системы (сервисы) общаются между собой через четко определенные контракты.
• Цель: Убедиться, что интеграция компонентов работает корректно, бизнес-сценарии на уровне сервисов выполняются, API возвращает правильные ответы (status codes, headers, body).
• Кто пишет: Чаще всего инженеры по автоматизации тестирования (QA Automation Engineers), реже — разработчики.
• Пример проверки REST API (Python, requests):

  import requests
  
  BASE_URL = "https://api.example.com/v1"
  
  def test_get_user_by_id():
      response = requests.get(f"{BASE_URL}/users/123")
      assert response.status_code == 200
      user_data = response.json()
      assert user_data["id"] == 123
      assert "email" in user_data
      # Проверяем контракт ответа
      assert isinstance(user_data["username"], str)
  
  def test_create_user():
      new_user = {"username": "test_user", "email": "test@example.com"}
      response = requests.post(f"{BASE_URL}/users", json=new_user)
      assert response.status_code == 201
      assert "Location" in response.headers  # Проверяем заголовок с ссылкой на новый ресурс
  

3. Верхний уровень: UI-тесты (End-to-End / E2E тесты)

• Что это: Тестирование полного, интегрированного приложения через его графический интерфейс пользователя, имитирующее действия реального пользователя (клики, ввод текста, навигация).
• Цель: Проверить корректность работы всего приложения "от начала до конца" в среде, максимально приближенной к продакшену. Это самый медленный, хрупкий и дорогой в поддержке тип тестов.
• Кто пишет: Инженеры по автоматизации тестирования.
• Пример E2E-теста для веб-приложения (Python, Selenium):

  from selenium import webdriver
  from selenium.webdriver.common.by import By
  
  def test_login_to_application():
      driver = webdriver.Chrome()
      driver.get("https://myapp.example.com/login")
  
      # Имитируем действия пользователя в UI
      username_field = driver.find_element(By.ID, "username")
      password_field = driver.find_element(By.ID, "password")
      submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
  
      username_field.send_keys("valid_user")
      password_field.send_keys("valid_password")
      submit_button.click()
  
      # Проверяем результат через UI
      welcome_message = driver.find_element(By.TAG_NAME, "h1").text
      assert "Добро пожаловать" in welcome_message
      assert driver.current_url.endswith("/dashboard")
  
      driver.quit()
  

Эволюция и современное видение

Важно понимать, что пирамида — это метафора, а не догма. Со временем модель эволюционировала, и сейчас часто говорят о 5 уровнях или типах тестов, детализируя средний сегмент:

1. Unit-тесты (основа)
2. Интеграционные тесты (тесты взаимодействия с БД, внешними сервисами)
3. API/Contract-тесты (тестирование сервисного слоя и контрактов между микросервисами)
4. E2E-тесты (сквозные тесты через UI)
5. Ручное исследовательское тестирование (вершина пирамиды, часто изображается как "облачко" над ней, подчеркивающее необходимость человеческого подхода для сложных сценариев)

Ключевой принцип пирамиды: Чем выше уровень, тем меньше тестов должно быть в этой категории. Оптимальное распределение часто описывают как 70% Unit, 20% Service/API, 10% E2E. Это позволяет создать быстрый, стабильный и экономичный набор автоматизированных проверок, который обеспечивает уверенность в качестве продукта на всех этапах разработки.