Зачем использовать трехуровневую архитектуру
Что проверяют
Понимаете ли вы, из каких частей состоит система, которую тестируете, и умеете ли по этой схеме искать, где живёт дефект. Для QA вопрос не столько про проектирование, сколько про локализацию багов и выбор уровня проверки. Следом часто просят разобрать случай: кнопка «Сохранить» ничего не сохранила, куда смотреть.
Как отвечать
Назовите три уровня и их роли:
- представление: веб-интерфейс или мобильный клиент. Показывает данные и собирает ввод, бизнес-решений не принимает;
- логика приложения: сервер с API, где живут правила, проверка прав и валидация;
- данные: база и другие хранилища, к которым клиент напрямую не ходит.
Зачем так делают: уровни можно менять и масштабировать независимо (добавить серверов приложений, не трогая базу), база спрятана от клиента, а один API обслуживает и веб, и мобильное приложение. Цена: больше сетевых вызовов и точек отказа.
Главное в ответе QA это связь схемы с тестированием:
- UI: Playwright, Selenium, ручные сценарии. Самые медленные и хрупкие проверки, поэтому их меньше всего;
- API: Postman, REST Assured или pytest с
requests. Бизнес-логику здесь проверяют быстрее и стабильнее, чем через интерфейс, и шлют запросы в обход клиентской валидации; - данные: SQL-запросом убеждаются, что запись действительно появилась и связи не сломаны.
При локализации бага идите по уровням: во вкладке Network в DevTools смотрите, ушёл ли запрос и что ответил сервер. Ошибка в ответе API указывает на сервер или данные, корректный ответ при неверном экране указывает на клиент.
Где спотыкаются
Путают уровни (tiers) со слоями (layers). Три слоя можно собрать в одном процессе, а уровни это физически разнесённые части, которые общаются по сети.
Считают достаточной валидацию в интерфейсе. Если сервер не проверяет данные сам, запрос из Postman запишет в базу что угодно, и это баг.
Пересказывают теорию про модульность и не показывают, как схема помогает в работе: где искать дефект и на каком уровне писать автотест.