Ученик пишет в поддержку: «Сайт не работает, курс не записывается». Это всё, что у вас есть на старте. Проблема может быть где угодно: браузер ученика, сеть между ним и сервером, сам сервер, или база данных, где хранятся места в группе. Не понимая, из каких частей вообще состоит продукт, вы не сможете даже начать сужать круг подозреваемых.
Чему научишься за этот урок:
— назвать, из каких частей состоит клиент-серверное приложение и что делает каждая часть;
— проследить путь запроса от нажатия кнопки до записи в базе данных и обратно;
— объяснить разницу тонкого и толстого клиента и то, где искать дефект в каждом случае.
Клиент и сервер
Клиент — программа на устройстве пользователя, с которой он напрямую взаимодействует: браузер, мобильное приложение. Клиент не хранит основные данные продукта и не решает сложную логику сам — он отправляет запросы и показывает то, что получил в ответ.
Сервер — удалённый компьютер (или несколько), который принимает запросы от клиентов, выполняет основную логику и хранит или достаёт данные. Один и тот же сервер обычно обслуживает тысячи клиентов одновременно.
Путь запроса от кнопки до базы
Проследим, что происходит, когда ученик нажимает кнопку «Записаться на курс» на нашем учебном полигоне:
- Браузер (клиент) отправляет запрос на сервер: «запиши ученика №123 на курс №45».
- Запрос идёт по сети от устройства ученика до сервера.
- Сервер получает запрос и выполняет логику: проверяет, есть ли свободные места, не записан ли ученик уже.
- Если всё в порядке, сервер обращается к базе данных и добавляет туда новую запись.
- База данных подтверждает серверу, что запись сохранена.
- Сервер формирует ответ («Вы записаны») и отправляет его обратно по сети.
- Браузер получает ответ и показывает ученику сообщение об успехе.
Клиент (браузер) Сервер База данных
"Записаться на курс"
|
| запрос --------> проверяет места,
| записывает ученика
| |
| | сохранить --------> запись создана
| |<-------------------- подтверждено
|<-- "Вы записаны" --------|
|
показывает результат
Дефект может застрять на любом из этих шагов: браузер отправил неверные данные, сеть оборвалась на середине, сервер неверно проверил условие, база не сохранила запись. Понимание цепочки помогает не гадать, а целенаправленно проверять конкретный шаг.
Трёхуровневая архитектура
То же самое можно описать тремя уровнями по назначению, а не по физическим машинам:
- Уровень представления — то, что видит пользователь: кнопки, формы, страницы. В нашем примере — браузер с интерфейсом каталога курсов.
- Уровень логики (приложения) — правила и вычисления: проверка мест, проверка повторной записи. Это код на сервере.
- Уровень данных — хранение: база данных, где физически лежат записи учеников и курсов.
Три уровня не обязаны находиться на трёх разных физических серверах — иногда логика и данные живут на одной машине. Важно не физическое разделение, а то, что каждый уровень отвечает за своё: интерфейс не хранит данные сам, логика не рисует кнопки, база не решает, можно ли записать ученика.
Толстый и тонкий клиент
Тонкий клиент — клиент, где почти вся логика и данные живут на сервере, а на устройстве пользователя происходит по минимуму. Наш учебный полигон — именно тонкий клиент: браузер в основном показывает то, что ему прислал сервер, а всю работу (проверки, доступ к базе) делает сервер.
Толстый клиент — клиент, где значительная часть логики выполняется прямо на устройстве пользователя, иногда даже без постоянной связи с сервером (например, десктопное приложение, которое работает офлайн и синхронизируется с сервером время от времени).
Почему это важно для тестировщика: у тонкого клиента бо́льшая часть логики — на сервере, значит, многие дефекты нужно искать со стороны сервера (что реально пришло в ответе, что записалось в базу), а не только смотреть на экран. У толстого клиента часть багов может быть чисто локальной, никак не связанной с сервером.
Итог:
— клиент отправляет запросы и показывает результат, сервер выполняет логику и работает с данными;
— запрос проходит цепочку из нескольких шагов, и дефект может застрять на любом из них;
— три уровня (представление, логика, данные) разделены по назначению, а не обязательно физически;
— наш полигон — тонкий клиент: большинство проверок нужно вести со стороны сервера, а не только смотреть на экран браузера.
Контрольный вопрос. Что из перечисленного точнее всего описывает роль клиента в клиент-серверной архитектуре?
Подсказка: Вспомни, кто в примере с записью на курс отправляет запрос, а кто проверяет условия и хранит данные.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какой уровень трёхуровневой архитектуры отвечает за проверку, есть ли свободные места в группе, при записи на курс?
Подсказка: Это про правило и вычисление, а не про то, что видит пользователь, и не про физическое хранение записей.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Где физически хранятся записи учеников и курсов в трёхуровневой архитектуре?
Подсказка: Это уровень, отвечающий именно за хранение, а не за интерфейс и не за вычисления.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие из утверждений про тонкий клиент верны (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Сверь каждое утверждение по отдельности с определением тонкого клиента из урока.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется удалённый компьютер, который принимает запросы от множества клиентов, выполняет логику и хранит или достаёт данные? Ответь одним словом.
Подсказка: Это второе из двух главных понятий урока, противоположное клиенту.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется тип клиента, где значительная часть логики работает прямо на устройстве пользователя, иногда даже без постоянной связи с сервером? Ответь одним словом.
Подсказка: Это противоположность тонкому клиенту, о котором подробно шла речь в примере с нашим полигоном.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Ученик нажал «Записаться на курс», но браузер потерял связь с сетью ровно в момент отправки запроса, и запрос не дошёл до сервера. Из-за чего конкретно застрял дефект в цепочке урока? Ответь одним словом.
Подсказка: Запрос не дошёл до сервера вообще — значит, проблема раньше, чем сервер и база успели что-либо сделать.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Сервер получил запрос на запись, проверил, что места есть, дал команду хранилищу сохранить запись — но оно в этот момент было перегружено и не смогло сохранить, хотя серверу об этом не сообщило вовремя. Ученику пришло сообщение «Вы записаны», хотя записи нигде нет. На каком уровне трёхуровневой архитектуры физически произошёл этот сбой? Ответь одним словом.
Подсказка: Сбой в том, что не сохранилось хранимое — подумай, какой уровень отвечает именно за хранение.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Ученик жалуется: «Нажимаю «Записаться», кнопка нажимается, крутится колесо загрузки, но запись так и не появляется в личном кабинете». Опиши в 2-3 предложениях, на каких минимум ДВУХ разных шагах цепочки «клиент → сервер → база → ответ» может застрять этот дефект, и что бы ты проверил на каждом из них.
Критерий приёмки: названы минимум два РАЗНЫХ шага цепочки из урока (например: запрос не дошёл до сервера — проверить сеть/консоль браузера; сервер получил запрос, но база не сохранила — проверить логи сервера и саму базу; сервер сохранил, но ответ не дошёл обратно до браузера — проверить, что реально вернул сервер). Общие фразы вроде «что-то сломалось» не засчитываются.
Подсказка: Вспомни семь шагов цепочки из урока и подумай, на каком из них колесо загрузки могло бы застрять, если конечный результат так и не появился.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. Десктопное приложение для чтения книг умеет открывать и читать книги без интернета, а синхронизирует прогресс чтения с сервером только раз в час, когда есть связь. Как одним словом называется такой тип клиента? Ответь одним словом.
Подсказка: Обрати внимание на то, что приложение работает и без постоянной связи с сервером — это ключевой признак одного из двух типов клиента.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Обязаны ли три уровня архитектуры (представление, логика, данные) физически находиться на трёх разных серверах?
Подсказка: В уроке прямо сказано, что физическое разделение — не главное.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Что дальше
Мы разобрали, из каких частей состоит продукт и как запрос идёт от клиента к серверу и обратно. Но что именно происходит «по сети» между вводом адреса в браузере и появлением ответа? Разберём это в следующем уроке — сеть для тестировщика: IP-адреса, DNS и порты.
