Ответ
Двухуровневая архитектура (2-tier, клиент-сервер) — это модель, в которой приложение четко разделено на два логических компонента:
- Клиент (Frontend / Presentation Tier): Отвечает за пользовательский интерфейс и представление данных. Это может быть десктопное приложение, браузер или мобильное приложение.
- Сервер (Backend / Data Tier): Отвечает за бизнес-логику, обработку запросов, работу с базой данных и предоставление данных клиенту.
Подход к тестированию такой архитектуры:
-
Раздельное тестирование компонентов:
- Клиент: Юзабилити-тестирование, кросс-браузерное/кросс-платформенное тестирование, проверка корректности отображения данных, полученных с сервера.
- Сервер: Модульное и интеграционное тестирование API, тестирование бизнес-логики, нагрузочное тестирование эндпоинтов.
-
Интеграционное тестирование связи:
- Проверка корректности обмена данными (форматы JSON/XML, коды ответов HTTP).
- Тестирование обработки ошибок на стороне сервера и их адекватного отображения на клиенте.
- Проверка безопасности: аутентификация, авторизация, валидация входящих данных на сервере.
Пример тест-кейса для проверки интеграции:
Сценарий: Пользователь создает заказ через UI.
Шаги:
1. На клиенте заполняем форму заказа и нажимаем "Отправить".
2. Клиент отправляет POST-запрос на серверный эндпоинт `/api/orders`.
Ожидаемый результат:
- Сервер отвечает статусом 201 Created и JSON с ID нового заказа.
- Клиент корректно отображает сообщение об успехе и ID заказа.
- Данные заказа появляются в базе данных.
Варианты негативного тестирования:
- Отправка пустого тела запроса -> сервер возвращает 400 Bad Request -> клиент показывает понятную ошибку.
- Потеря сетевого соединения -> клиент показывает уведомление о попытке повторной отправки.Преимущества для тестирования: Четкое разделение позволяет эффективно использовать автоматизацию для API-тестирования сервера независимо от клиента.
Ответ 18+ 🔞
Ну слушай, вот есть у нас эта классика жанра — двухуровневая архитектура, или как её ещё обзывают, клиент-сервер. Представь себе, блядь, обычную столовую: есть раздача (это сервер), а есть ты с подносом (это клиент). Всё, больше никого. Никаких промежуточных шеф-поваров, которые тебе салат перекладывают. Просто и понятно, как два пальца обоссать.
Клиент (Фронтенд) — это твоя рожа, уткнувшаяся в экран. Всё, что ты видишь: кнопочки, поля, анимации, когда что-то грузится. Может быть браузер, мобильное приложение или какая-нибудь десктопная программа. Его задача — красиво нарисовать данные и принять твои клики.
Сервер (Бэкенд) — это, ёпта, та самая кухня, скрытая от глаз. Там вся магия: логика, расчёты, работа с базой данных. Клиент стучится к нему: «Эй, дай мне список товаров!», а сервер в ответ: «На, жри, только в JSON-е, как договаривались».
А теперь как это всё тестировать, чтобы не обосраться в итоге?
-
Тестируем по отдельности, как будто они незнакомы.
- Клиента гоняем по полной: удобно ли, не разъезжается ли вёрстка в разных браузерах, правильно ли отображает то, что ему сервер плюнул в ответ. Чисто внешний вид и реакции.
- Сервер долбим отдельно, без всяких интерфейсов. Пишем автотесты на его API: правильно ли считает бизнес-логику, не падает ли от кривых данных, выдержит ли овердохуища запросов. Это как проверять двигатель машины, не садясь в салон.
-
А потом сводим их и смотрим, не подерутся ли.
Вот это самое важное — интеграция. Тут мы проверяем, как они общаются.
— Клиент отправил запрос в неправильном формате? Сервер должен ему вежливо, но твёрдо послать нахуй (то есть статус 400), а клиент — не сгореть, а показать человеку внятную ошибку. Доверия ебать ноль между ними быть не должно, всё должно быть чётко по протоколу.
— Проверяем безопасность: чтобы без пароля никто в систему не влез, а если и влез, то увидел только то, что положено. Подозрение ебать чувствую ко всем входящим запросам на сервере должно быть.
Вот тебе пример, как это выглядит в жизни:
Сценарий: Юзер создаёт заказ.
Шаги:
1. На клиенте тыкает кнопки, заполняет поля и жмёт «Купить».
2. Клиент, недолго думая, шлёт POST-запрос на `/api/orders` с данными заказа.
Ожидаемый результат:
- Сервер, если всё ок, отвечает: «201 Created» и скидывает ID заказа.
- Клиент радостно пишет: «Заказ №12345 оформлен!».
- В базе данных этот заказ реально появляется, а не хуй в пальто.
А если что-то пошло не так:
- Отправили пустой запрос -> сервер ругается (400), клиент показывает: «Братан, заполни поля».
- Пропал интернет -> клиент не тупо впадает в кому, а пишет: «Сеть сдохла, пробуем отправить ещё раз».В чём, блядь, кайф для тестировщика?
Да в том, что серверную часть можно насиловать автотестами в полной изоляции, не завися от того, готов ли интерфейс. Пока дизайнеры и фронтендеры спорят про тени кнопок, ты уже можешь проверить всю логику и API. Это, сука, очень удобно.