Где тестировщик взаимодействует: UI, API, БД

Где тестировщик взаимодействует: UI, API, БД

Введение

Современное веб-приложение — это не один монолит, а слои, которые работают вместе. Тестировщик должен понимать, на каком слое находится баг, и уметь работать с каждым из них. Это позволяет быстрее находить первопричину проблем и эффективнее строить тест-планы.

Три уровня тестирования

┌────────────────────────────────┐
│         UI Layer (Browser)     │  ← Что видит пользователь
├────────────────────────────────┤
│         API Layer (Backend)    │  ← Бизнес-логика
├────────────────────────────────┤
│       Database Layer (БД)      │  ← Хранение данных
└────────────────────────────────┘

UI-тестирование

Что: тестирование через браузер — кнопки, формы, страницы, отображение данных.

Инструменты: браузер, Playwright, Selenium, ручное тестирование.

Что проверяется:

• Корректное отображение данных из API.
• Валидация форм (сообщения об ошибках, блокировка отправки).
• Состояния загрузки (спиннер пока данные грузятся).
• UX: понятные сообщения об ошибках, правильный редирект после действий.

Пример: открыл страницу профиля — проверил, что имя пользователя отображается корректно, кнопки доступны, форма редактирования работает.

API-тестирование

Что: тестирование напрямую через HTTP-запросы, минуя UI.

Инструменты: Postman, curl, Newman, REST Client.

Что проверяется:

• Правильные статус-коды (200, 201, 400, 404...).
• Структура и типы данных в ответе.
• Бизнес-логика (скидка рассчитывается правильно).
• Обработка ошибок (пришло понятное сообщение об ошибке).
• Авторизация и права доступа.

Пример: отправил POST /api/orders с данными заказа → проверил 201 Created и что в ответе есть id нового заказа.

Преимущество перед UI: быстрее, точнее указывает на источник бага, можно тестировать до готовности UI.

Тестирование базы данных

Что: прямые SQL-запросы к БД для проверки данных.

Инструменты: DBeaver, pgAdmin, TablePlus, mysql-клиент.

Что проверяется:

• Данные сохранились корректно (не только в ответе API, но и в БД).
• Данные удалились полностью (нет «зомби»-записей).
• Ограничения БД работают (unique, not null, foreign key).
• Нет мусорных данных после неуспешных операций.

Пример: создал пользователя через API → в таблице users появилась запись с правильными данными, пароль захеширован.

Почему тестировать несколько слоёв?

Ключевой принцип: баг может быть виден на UI, но жить на уровне API или БД. Умея работать со всеми слоями, ты находишь настоящую причину, а не симптом.

Практический воркфлоу тестировщика

1. Обнаружил баг на UI (неправильная сумма в корзине)
        ↓
2. Проверяю API: GET /api/cart — правильная ли сумма в ответе?
        ↓
   Если API возвращает неправильно → баг в бэкенде
   Если API возвращает правильно → баг в отображении на UI
        ↓
3. Если подозрение на уровень данных — смотрю в БД напрямую

Создание тестовых данных

Часто проще и быстрее создать тестовые данные через API, а не через UI:

• UI может требовать много кликов для создания одного объекта.
• API позволяет создать 100 тестовых пользователей скриптом за секунды.
• Прямая запись в БД — только если API недоступен, и осторожно: можно нарушить целостность данных.

Частые ошибки тестировщиков

• Тестировать только через UI. Некоторые баги не видны на UI (например, данные сохраняются с ошибкой в БД).
• Не проверять БД после операций. API может вернуть 201, но данные могут не сохраниться.
• Писать в БД напрямую, минуя API. Это нарушает целостность данных — лучше использовать API.

Что мы запомним

• Три слоя тестирования: UI (что видит пользователь), API (бизнес-логика), БД (хранение).
• Баг может быть виден на UI, но жить на другом уровне.
• API-тестирование быстрее UI-тестирования и точнее указывает на баг.
• Воркфлоу: сначала проверяй UI, потом API, потом БД — двигайся от симптома к причине.
• Тестовые данные удобнее создавать через API, а не через UI.