Расположи уровни тестирования сверху вниз

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

В контексте многоуровневой архитектуры ПО и процессов разработки, уровни тестирования принято располагать сверху вниз, следуя логике от общих бизнес-требований к конкретной реализации и от внешних взаимодействий к внутренним компонентам. Такое расположение отражает движение от высокоуровневого системного взгляда к низкоуровневым компонентным деталям. Вот общепринятая иерархия:

1. Приемочное тестирование (Acceptance Testing)

Самый верхний, бизнес-ориентированный уровень.

• Цель: Проверить, соответствует ли система требованиям заказчика и готова ли к эксплуатации. Это финальное "одобрение" продукта.
• Кто выполняет: Заказчик, бизнес-аналитики или продукт-менеджеры, часто с поддержкой QA-инженеров.
• Пример: Проверка полного сценария оформления заказа на сайте электронной коммерции, включая интеграцию с платежным шлюзом и службой доставки, на соответствие бизнес-процессам.

2. Системное тестирование (System Testing)

Уровень проверки интегрированной системы как целого.

• Цель: Верификация полной, собранной системы на соответствие техническим спецификациям и требованиям. Тестируются нефункциональные характеристики (нагрузочное, стрессовое, тестирование безопасности) и функциональность сквозными сценариями (E2E).
• Кто выполняет: QA-инженеры, команда тестирования.
• Пример:

  # Пример E2E-теста для проверки системной функциональности (Python + Selenium)
  def test_user_can_complete_purchase(self):
      driver = webdriver.Chrome()
      driver.open("https://shop.example.com")
      login_page = LoginPage(driver)
      product_page = ProductPage(driver)
      cart_page = CartPage(driver)
  
      login_page.login("valid_user", "valid_pass")
      product_page.add_item_to_cart("Item_ID_123")
      cart_page.proceed_to_checkout()
      # Проверка, что заказ успешно создан в системе
      assert driver.find_element(By.ID, "order-success-message").is_displayed()
  

3. Интеграционное тестирование (Integration Testing)

Уровень взаимодействия между модулями, сервисами или системами.

• Цель: Обнаружение дефектов в интерфейсах и взаимодействии между интегрированными компонентами (модулями, микросервисами, базами данных, внешними API).
• Подходы: Снизу вверх, сверху вниз, большой взрыв.
• Кто выполняет: Разработчики и QA-инженеры (автоматизация API-тестов).
• Пример:

  // Пример интеграционного теста для REST API (JavaScript, используя Jest и SuperTest)
  test('POST /api/orders создает новый заказ и возвращает его ID', async () => {
      const newOrder = { productId: 789, quantity: 2 };
      const response = await request(app)
          .post('/api/orders')
          .send(newOrder)
          .expect(201); // Ожидаем статус "Created"
  
      // Проверяем структуру и данные ответа
      expect(response.body).toHaveProperty('id');
      expect(response.body.productId).toBe(newOrder.productId);
  
      // Интеграционная проверка: заказ сохранен в БД
      const orderInDb = await Order.findById(response.body.id);
      expect(orderInDb).not.toBeNull();
  });
  

4. Модульное / Компонентное тестирование (Unit / Component Testing)

Самый нижний, фундаментальный уровень.

• Цель: Проверить корректность работы минимальной тестируемой единицы кода (функции, метода, класса) в изоляции от других частей системы.
• Кто выполняет: Разработчики в процессе написания кода.
• Пример:

  // Пример модульного теста для класса-сервиса (Java, JUnit)
  public class CalculatorServiceTest {
      @Test
      public void testAdd_TwoPositiveNumbers_ReturnsCorrectSum() {
          // Arrange (Подготовка)
          CalculatorService calculator = new CalculatorService();
          int a = 5;
          int b = 3;
          int expectedSum = 8;
  
          // Act (Действие)
          int actualSum = calculator.add(a, b);
  
          // Assert (Проверка)
          assertEquals(expectedSum, actualSum);
      }
  
      @Test
      public void testDivide_DivisionByZero_ThrowsException() {
          CalculatorService calculator = new CalculatorService();
          assertThrows(ArithmeticException.class, () -> {
              calculator.divide(10, 0);
          });
      }
  }
  

Ключевой вывод о направлении

Представленный порядок (Приемочное -> Системное -> Интеграционное -> Модульное) отражает логическую последовательность уровней по степени охвата системы. Однако на практике процессы Agile и CI/CD часто "переворачивают" эту пирамиду в плане усилий и автоматизации: наибольшее количество автоматизированных тестов создается на уровнях Модульное и Интеграционное тестирование, формируя надежный фундамент для быстрых изменений. Меньшее, но критически важное количество тестов (часто скриптовых или exploratory) выполняется на уровнях Системного и Приемочного тестирования. Таким образом, иерархия сверху вниз описывает скорее уровень абстракции и близость к бизнес-требованиям, в то время как пирамида тестирования рекомендует распределение усилий и степени автоматизации снизу вверх.