1. Архитектура веб-приложений и протокол HTTP: фундамент взаимодействия клиента и сервера
Архитектура веб-приложений и протокол HTTP: фундамент взаимодействия клиента и сервера
Когда пользователь вводит адрес сайта в строку браузера и нажимает Enter, запускается сложнейший механизм, который отрабатывает за доли секунды. Для обывателя это магия появления картинки, но для QA-инженера — это последовательность четко регламентированных этапов передачи данных. Ошибка на любом из этих этапов может привести к тому, что кнопка «Купить» не сработает, данные профиля не загрузятся, а злоумышленник получит доступ к базе данных. Понимание того, как устроено «подкапотное пространство» веба, отделяет простого кликера от профессионала, способного локализовать баг еще до того, как будет открыт код приложения.
Клиент-серверная модель: кто за что отвечает
В основе любого современного веб-ресурса лежит клиент-серверная архитектура. Это концепция разделения функций между поставщиком услуг (сервером) и потребителем (клиентом). В контексте веба «клиентом» чаще всего выступает браузер (Chrome, Safari, Firefox), но им может быть и мобильное приложение, и даже другой сервер.
Клиентская часть (Frontend)
Клиент отвечает за интерфейс и взаимодействие с пользователем. Его задача — отправить запрос, получить данные и отрисовать их так, чтобы пользователю было удобно. Важно понимать: клиентская часть работает на устройстве пользователя (ноутбуке, смартфоне). Это означает, что ресурсы клиента ограничены мощностью этого устройства.С точки зрения тестирования, фронтенд — это «зона недоверия». Мы не можем гарантировать, что пользователь не изменит код страницы в консоли разработчика или не отправит запрос с поддельными данными. Поэтому любая логика, реализованная на клиенте (например, маска ввода номера телефона), должна дублироваться проверками на сервере.
Серверная часть (Backend)
Сервер — это мощный компьютер (или группа компьютеров), который постоянно находится в сети и ожидает запросов. Он хранит данные, обрабатывает тяжелые вычисления, проверяет права доступа и общается с базами данных.Если фронтенд — это официант, принимающий заказ и приносящий блюдо, то бэкенд — это кухня. Клиент не видит, как жарится стейк, он видит только результат. В тестировании бэкенда мы проверяем именно «правильность рецептуры»: корректно ли обработаны данные, не возникло ли ошибок в базе, и не отдал ли сервер лишнюю информацию, которую клиент не просил.
Анатомия веб-приложения: от монолита к микросервисам
Архитектура веб-приложений эволюционировала от простых систем к распределенным. Понимание структуры приложения помогает тестировщику понять, где именно искать причину бага.
Трехуровневая архитектура
Большинство классических веб-проектов строятся по схеме трех уровней:Микросервисная архитектура
В крупных проектах (например, маркетплейсах вроде Amazon или Ozon) бэкенд не является единым целым. Он разбит на десятки и сотни маленьких независимых программ — микросервисов. Один микросервис отвечает за поиск, другой за корзину, третий за систему лояльности. Для тестировщика это означает, что ошибка в одном сервисе (например, «Поиск») не должна «ронять» все приложение. Однако возникает сложность: нужно проверять не только каждый сервис по отдельности, но и их взаимодействие (интеграционное тестирование). Если сервис корзины не может получить цену из сервиса каталога, пользователь не увидит итоговую сумму.Протокол HTTP: язык, на котором говорит интернет
Если архитектура — это здание, то HTTP (HyperText Transfer Protocol) — это правила общения жильцов внутри него. Это протокол прикладного уровня, который работает поверх транспортного протокола TCP.
Ключевая особенность HTTP — его безсостоятельность (stateless). Это означает, что сервер не запоминает предыдущие запросы. Каждый новый запрос для него — как первый. Чтобы сервер «узнал» пользователя, который только что залогинился, используются дополнительные механизмы: Cookies и Токены (JWT), которые передаются в заголовках каждого запроса.
Структура запроса (Request)
Когда вы нажимаете кнопку на сайте, браузер формирует HTTP-запрос. Он состоит из четырех частей:User-Agent сообщает серверу, какой у вас браузер, а Content-Type говорит, в каком формате мы отправляем данные (например, JSON).Структура ответа (Response)
Сервер, обработав запрос, возвращает ответ:HTTP/1.1 200 OK.Методы HTTP: глаголы веба
Методы определяют тип операции, которую мы хотим совершить над ресурсом. В REST-архитектуре, которая является стандартом для современных API, методы используются строго по назначению.
| Метод | Назначение | Особенности для QA | | :--- | :--- | :--- | | GET | Получение данных | Параметры передаются в URL. Нельзя использовать для передачи паролей. Данные могут кэшироваться. | | POST | Создание нового ресурса | Данные передаются в теле. Не кэшируется. Используется для отправки форм и загрузки файлов. | | PUT | Полное обновление ресурса | Если ресурса нет, он может быть создан. Требует передачи всех полей объекта. | | PATCH | Частичное обновление | Обновляет только те поля, которые прислали. Экономит трафик. | | DELETE | Удаление ресурса | Важно проверять права доступа: может ли пользователь удалить чужой пост? |
Идемпотентность — важное понятие для тестировщика. Метод считается идемпотентным, если повторный вызов одного и того же запроса дает тот же результат, что и первый, не изменяя состояние сервера дальше.
GET идемпотентен: сколько бы раз мы ни запрашивали страницу, она (в теории) не должна меняться.POST не идемпотентен: если вы нажмете «Оплатить» дважды и запрос уйдет два раза, с карты могут списаться деньги дважды, если на бэкенде нет защиты.PUT и DELETE идемпотентны: повторное удаление уже удаленного объекта не изменит состояние сервера (он всё так же будет удален).Коды состояний: как сервер сообщает о результате
Коды ответов — это первая вещь, на которую смотрит QA при анализе сетевого трафика. Они делятся на пять групп по первой цифре.
2xx: Успех (Success)
3xx: Перенаправление (Redirection)
4xx: Ошибка клиента (Client Error)
Это зона ответственности тестировщика фронтенда или проверки валидации бэкенда.5xx: Ошибка сервера (Server Error)
Это всегда баг бэкенда. При виде 5xx тестировщик должен идти в логи сервера.Жизненный цикл запроса: путь от клика до картинки
Чтобы эффективно тестировать веб, нужно представлять путь данных. Допустим, мы открываем https://shop.com/product/1.
shop.com. Он обращается к DNS-серверу (телефонная книга интернета), чтобы получить IP-адрес (например, 93.184.216.34).Граничные случаи и нюансы для тестировщика
Знание теории архитектуры позволяет находить сложные дефекты, которые не описаны в чек-листах.
Проблема кэширования
Иногда баг воспроизводится только у тестировщика, а у разработчика — нет. Причина может быть в коде304 Not Modified или в том, что браузер сохранил старую версию скрипта. Профессиональный QA всегда проверяет гипотезу «чистого кэша» (Hard Reload через Ctrl+F5).Тайм-ауты (Timeouts)
Что будет, если база данных отвечает 30 секунд? Пользователь не должен видеть бесконечную загрузку. Тестировщик проверяет, как ведет себя система при задержках: отдает ли бэкенд504 Gateway Timeout и как фронтенд обрабатывает эту ошибку (показывает ли понятное сообщение «Попробуйте позже»).Безопасность и HTTPS
HTTP передает данные в открытом виде. Любой человек в той же Wi-Fi сети может перехватить ваш пароль. HTTPS (S — Secure) шифрует данные. Важная задача тестировщика — убедиться, что все редиректы сhttp:// на https:// работают корректно и что куки (Cookies) имеют флаг Secure, запрещающий их передачу по незащищенному каналу.Передача параметров: URL vs Body
В GET-запросах параметры передаются в Query-строке:?id=1&sort=desc. Существует лимит на длину URL (в разных браузерах от 2000 до 8000 символов). Если вы тестируете форму с огромным количеством полей, отправляемую через GET, данные могут просто обрезаться. Это классическая архитектурная ошибка, которую должен заметить QA.Практический взгляд: зачем это в ежедневной работе?
Представьте ситуацию: вы тестируете форму регистрации. Вы ввели данные, нажали «Зарегистрироваться», но ничего не произошло. Спиннер крутится бесконечно. Без знаний архитектуры вы напишете баг-репорт: «Регистрация не работает». Разработчик вернет его с пометкой «Не воспроизводится».
Со знаниями HTTP вы откроете вкладку Network в браузере и увидите:
/api/v1/register).400 Bad Request.{"error": "password_too_weak", "message": "Пароль должен содержать спецсимвол"}.Ваш баг-репорт станет профессиональным: «Фронтенд не отображает ошибку валидации пароля при получении 400 ответа от API». Вы сэкономили время себе, разработчику и ускорили исправление дефекта.
Архитектура веб-приложений — это не статичная картинка, а живой процесс обмена сообщениями. Понимая правила этого обмена, вы перестаете гадать, почему приложение ведет себя странно, и начинаете видеть систему насквозь. Это фундамент, на котором строятся все остальные навыки: от использования DevTools до автоматизации тестирования API.