Урок 01 — Клиент-серверная архитектура

Название: Веб-сайт, веб-приложение и веб-сервис — в чём разница
Описание: Разбираемся, как работает интернет изнутри: что такое клиент и сервер, чем веб-сайт отличается от веб-приложения, что такое веб-сервис и зачем QA-инженеру это знать.
Почему это важно для QA: Невозможно качественно тестировать то, чего не понимаешь. Знание архитектуры помогает грамотно составлять баг-репорты, понимать, на чьей стороне находится ошибка, и объяснять разработчикам, что именно сломалось.

1. Что такое клиент-серверная архитектура

Представь, что ты заходишь в кафе. Ты — клиент, официант — посредник, кухня — сервер. Ты делаешь заказ, официант передаёт его на кухню, кухня готовит, официант приносит тебе готовое блюдо. Ты не знаешь, как устроена кухня. Тебе важен результат.

В интернете работает точно так же.

Клиент — это программа, которая делает запрос. Чаще всего — браузер (Chrome, Firefox, Safari). Но клиентом может быть и мобильное приложение, и Postman, и другой сервер.

Сервер — это программа, которая принимает запросы, обрабатывает их и отправляет ответ. Сервер работает круглосуточно и не зависит от того, кто к нему обращается.

Ключевые понятия

Почему это важно для QA

Когда ты видишь ошибку — сначала нужно понять, где она произошла:

• На стороне клиента (в браузере, в JS-коде): ошибка в консоли, сломанная вёрстка, неправильное поведение после клика.
• На стороне сервера: неправильный ответ, ошибка 500, неверные данные в базе.
• В сети между ними: таймаут, обрыв соединения, неправильный URL.

Хороший баг-репорт всегда указывает, на чьей стороне проблема.

2. Веб-сайт — статический контент

Веб-сайт — это набор HTML-страниц, которые сервер просто отдаёт клиенту «как есть». Сервер не думает, не вычисляет, не обращается к базе данных. Он просто хранит файлы и отдаёт их по запросу.

Пример: портфолио-сайт

Пользователь → GET /index.html → Сервер возвращает файл index.html
Пользователь → GET /about.html → Сервер возвращает файл about.html
Пользователь → GET /style.css  → Сервер возвращает файл style.css

На каждый запрос сервер просто находит нужный файл в папке и отправляет его. Никакой логики, никакой базы данных.

Признаки статического сайта

• URL заканчивается на .html
• Одинаковый контент для всех пользователей
• Нет личного кабинета, нет авторизации
• Нет форм с обработкой данных на сервере

Примеры

• Сайт-визитка компании
• Документация (например, сайт docs.python.org)
• Сайт-портфолио разработчика

Что тестируют QA на статических сайтах

• Корректность ссылок (нет ли битых ссылок)
• Правильность текстов и изображений
• Кроссбраузерность
• Время загрузки страниц
• Корректность отображения на разных устройствах (адаптивность)

3. Веб-приложение — динамический контент

Веб-приложение — это программа, которая работает в браузере и взаимодействует с сервером для получения или изменения данных. В отличие от сайта, каждый пользователь видит свой уникальный контент.

Пример: социальная сеть

Пользователь → GET /feed → Сервер читает из базы данных посты
                            именно этого пользователя
                          → Возвращает персональную ленту

Сервер обрабатывает запрос динамически: смотрит, кто авторизован, какие у него настройки, делает запрос к базе данных и только потом формирует ответ.

Архитектура типичного веб-приложения

Признаки веб-приложения

• Личный кабинет, авторизация
• Данные меняются в реальном времени
• Формы, которые сохраняют данные
• Разные страницы для разных пользователей
• Кнопки «Сохранить», «Удалить», «Купить»

Примеры

• Gmail, Outlook (почта)
• GitHub (управление кодом)
• Trello, Jira (управление задачами)
• Интернет-банк

Что тестируют QA в веб-приложениях

• Функциональность: кнопки работают, данные сохраняются, формы валидируются
• Авторизация и доступ: нельзя попасть на чужие данные
• Граничные значения: что происходит при пустых полях, максимальной длине текста
• Обработка ошибок: понятные сообщения при неверных данных
• Производительность: как ведёт себя приложение под нагрузкой

4. Веб-сервис — API для других программ

Веб-сервис — это программа, которая принимает запросы и возвращает данные, но не для людей, а для других программ. У него нет интерфейса, нет HTML-страниц. Только данные — обычно в формате JSON или XML.

Пример: погодный API

Мобильное приложение погоды не хранит данные о погоде у себя. Оно отправляет запрос к погодному API:

Приложение → GET https://api.weather.com/v1/current?city=Moscow
           ← {"temperature": 18, "condition": "Cloudy", "humidity": 65}

Приложение получает данные в JSON-формате и само решает, как их отобразить пользователю.

Чем веб-сервис отличается от веб-приложения

Пример реального сценария

Когда ты заказываешь такси в приложении:

• Приложение такси → Карты API → Рассчитать маршрут
• Приложение такси → Банковский API → Проверить карту
• Приложение такси → SMS API → Отправить код подтверждения
• Приложение такси → Сервер такси → Найти ближайшего водителя

Одно действие пользователя вызывает цепочку запросов к разным веб-сервисам. QA должен понимать эту цепочку, чтобы знать, где могло сломаться.

Что тестируют QA в веб-сервисах

• Корректность ответов: правильные данные, правильная структура JSON/XML
• Коды ответов: 200 — успех, 404 — не найдено, 500 — ошибка сервера
• Авторизация: нельзя вызвать API без токена
• Граничные значения: что происходит при неверных параметрах
• Скорость: API должен отвечать в разумное время (обычно < 2 секунд)

5. Взаимодействие всех трёх компонентов

В реальной жизни веб-сайт, веб-приложение и веб-сервисы работают вместе.

Пример: интернет-магазин

Задача QA: тестировать не только интерфейс, но и интеграции с внешними сервисами. Что происходит, если платёжный API вернул ошибку? Показывает ли приложение понятное сообщение?

6. Трёхзвенная архитектура (Three-Tier Architecture)

В профессиональной среде ты часто встретишь термин «трёхзвенная архитектура». Это стандартное разделение системы на три уровня:

Почему QA должен знать об этих уровнях

Когда приходит баг, нужно понять, на каком уровне он возник:

• Уровень представления: кнопка не нажимается, поле не отображается, стили сломаны
• Уровень логики: неверный расчёт скидки, неправильная проверка прав доступа
• Уровень данных: данные не сохраняются, дублируются, удаляются неверно

Это помогает быстро определить ответственного разработчика и написать более точный баг-репорт.

7. Синхронная и асинхронная коммуникация

Клиент и сервер могут общаться двумя способами.

Синхронный запрос

Клиент отправляет запрос и ждёт ответа. Пока ответ не пришёл — ничего другого не делает.

Клиент: "Дай мне список товаров"
         ⏳ Ждёт...
Сервер: "Вот список: [товар1, товар2, товар3]"
Клиент: Продолжает работу

Проблема: если сервер медленно отвечает, интерфейс «зависает».
Что тестировать: отображается ли индикатор загрузки? Что происходит при таймауте?

Асинхронный запрос (AJAX)

Клиент отправляет запрос и продолжает работу. Когда ответ придёт — обновляет нужную часть страницы.

Клиент: "Дай мне список товаров" → Отправил запрос
         Пользователь листает страницу, интерфейс работает
Сервер: "Вот список товаров"
Клиент: Обновил только блок со списком товаров (без перезагрузки страницы)

Что тестировать: правильно ли обновляется контент? Нет ли состояния гонки (race condition)?

Итоги урока

Ключевые выводы для QA:

1. Ошибка может быть на стороне клиента, сервера или в сети — нужно уметь определить где.
2. Трёхзвенная архитектура помогает понять, на каком уровне сломалось.
3. Интеграции с внешними сервисами — отдельная зона тестирования.
4. Асинхронность требует тестирования состояний загрузки и граничных случаев.

Практические задания

1. Классификация: Открой 5 разных сайтов в браузере и классифицируй каждый: это веб-сайт, веб-приложение или веб-сервис? Аргументируй ответ.

2. Анализ инструментов разработчика: Открой любой сайт (например, github.com). Нажми F12, перейди во вкладку Network. Перезагрузи страницу. Посмотри на запросы: какие файлы загружаются? Какие из них HTML, CSS, JS, изображения? Какие запросы идут к API (обычно возвращают JSON)?

3. Анализ архитектуры: Возьми любое знакомое приложение (банковское приложение, соцсеть, сервис доставки еды). Нарисуй схему: из каких компонентов оно состоит? Какие внешние сервисы оно наверняка использует (платежи, карты, SMS)?

4. Составление чеклиста: Напиши чеклист из 10 пунктов для тестирования формы регистрации в веб-приложении. Для каждого пункта укажи, на каком уровне архитектуры ты проверяешь (представление / логика / данные).

5. Поиск ошибок: Найди в интернете примеры публичных постмортемов (postmortem) крупных сбоев (например, GitHub Status, AWS Status). Определи, на каком уровне архитектуры произошла каждая ошибка.

Следующий урок: Урок 02 — HTTP-протокол. Ошибка 404. Модель TCP/IP. Методы HTTP