Игорь Колосов.ru Личная база знаний

Что такое бэкенд?

Бэкенд – это часть приложения, которая работает на стороне сервера (не в браузере) и отвечает на запросы от других систем или клиентов. Если фронтенд – это интерфейс и логика в браузере (HTML, CSS, JavaScript), то бэкенд – это скрытая от пользователя серверная логика: обработка данных, бизнес-правила, взаимодействие с базой данных и внешними сервисами. Бэкенд может быть реализован на разных языках программирования (Java, Python, PHP, C#/.NET и др.) и обычно включает работу с СУБД (MySQL, PostgreSQL, MongoDB и т.п.) для хранения данных.

Пример: когда вы заполняете форму на сайте и нажимаете «Отправить», фронтенд собирает введённые данные и по сети передаёт их на бэкенд. Бэкенд-подсистема принимает запрос, проверяет и обрабатывает данные (например, сохраняет их в базе или выполняет вычисления) и возвращает ответ. Пользователь напрямую не видит, что происходит на бэкенде, но ощущает результат – например, появление сообщения об успешной регистрации.

Связь фронтенда и бэкенда

Фронтенд и бэкенд взаимодействуют между собой по сети, чаще всего по протоколу HTTP(S). Фронтенд (клиентское приложение, например сайт или мобильное приложение) отправляет HTTP-запросы к бэкенду (веб-серверу/API), а бэкенд отвечает на них. Современные веб-приложения обычно обмениваются данными в формате JSON (JavaScript Object Notation) или реже XML: фронтенд посылает запрос и получает от бэкенда ответ с данными в формате JSON, которые затем используются в интерфейсе. Такой подход позволяет отделить клиентскую часть от серверной: бэкенд возвращает только данные (например, в виде JSON), а отображение и обработку этих данных на экране выполняет фронтенд (например, код на JavaScript в браузере).

Важно понимать, что хотя исторически были подходы, когда бэкенд генерировал HTML-страницы целиком, сегодня распространена архитектура с выделенным API. API (Application Programming Interface) бэкенда предоставляет эндпойнты (URLs), по которым фронтенд может получать или отправлять данные. Например, запрос GET /api/products может вернуть список товаров в формате JSON, а запрос POST /api/products – принять новые данные товара для сохранения. Формат JSON стал де-факто стандартом для таких обменов данными благодаря своей простоте и читаемости.

Почему JSON? JSON (JavaScript Object Notation) – текстовый формат данных, изначально созданный как лёгкая альтернатива XML. Он человекочитаем, прост для разбора и поддерживается практически во всех языках программирования. В веб-разработке JSON широко используется для передачи структурированных данных между фронтом и бэком (например, в веб-службах REST). В отличие от XML, JSON имеет минимальный синтаксис и не требует сложных схем в базовых случаях. Тем не менее, для сложных структур данных одних договорённостей недостаточно – требуется формальное описание структуры, о чём поговорим далее (JSON Schema).

Архитектура бэкенда: монолитная vs микросервисная

При разработке серверной части существуют разные подходы к архитектуре приложения. Два популярных стиля – монолитная архитектура и микросервисная архитектура. Рассмотрим их отличия и влияние на тестирование.

Монолитная архитектура – традиционный подход, при котором все компоненты серверного приложения (модули, функциональные блоки) объединены в единое целое. Монолит представляет собой одно приложение или процесс, включающий весь бэкенд целиком (например, обработка пользователей, платежей, бизнес-логики – всё в одном).

https://habr.com/ru/companies/haulmont/articles/758780/

Монолитная архитектура: все функциональные модули (авторизация, доступ к данным, логика приложений и др.) выполняются в одном приложении и используют единый ресурс базы данных. Такая цельная структура упрощает разработку и тестирование на ранних этапах, поскольку все части доступны внутри одного кода и процесса. На изображении показано, что пользователь взаимодействует с одним сервером, содержащим всю логику, работающую с общей базой данных. Это обеспечивает простоту: компоненты монолита тесно связаны между собой, поэтому писать и тестировать такой код сравнительно легко; единая база кода упрощает понимание общей логики приложения. Однако монолит развернуть или масштабировать можно только целиком, что со временем усложняет поддержку крупных проектов.

Основные плюсы монолита: простота и целостность – все части вместе, единое развертывание; легче отлаживать внутренние взаимодействия; нет накладных расходов на сетевое взаимодействие между модулями (всё в одном процессе, что позитивно сказывается на производительности). Минусы монолита: со временем такой проект может разрастись, его сложнее масштабировать (нельзя масштабировать отдельный модуль, только всю систему целиком); обновление требует выкатывать весь приложение сразу; ограничена гибкость в выборе разных технологий для разных модулей – весь монолит обычно привязан к единому стеку технологий.

Микросервисная архитектура – это подход, при котором бэкенд разделяется на множество небольших сервисов, каждый из которых отвечает за свою часть функциональности и может развёртываться независимо. Микросервисы взаимодействуют друг с другом через четко определенные интерфейсы (обычно через сетевые вызовы: REST API, сообщения и т.д.).

https://habr.com/ru/companies/haulmont/articles/758780/

Микросервисная архитектура: система разбита на ряд независимых сервисов (например, отдельные сервисы авторизации, управления пользователями, выставления счетов и др.), каждый из которых имеет свою зону ответственности и может иметь собственную базу данных. Пользовательские запросы проходят через точку входа (API-шлюз или балансировщик), который направляет их нужному сервису. Данный подход улучшает масштабируемость и гибкость: каждый микросервис можно развивать и масштабировать отдельно от остальных. Например, сервис обработки изображений можно запустить в нескольких экземплярах при росте нагрузки, не трогая другие части системы. Кроме того, команды разработчиков могут работать над разными сервисами параллельно, выбирая оптимальный технологический стек под задачи каждого. С точки зрения тестирования, микросервисы позволяют разрабатывать, тестировать и деплоить компоненты обособленно, без влияния на всю систему. Это ускоряет выпуск обновлений и упрощает локализацию изменений.

Однако у микросервисов есть и недостатки: сложнее координировать взаимодействие множества распределённых компонентов, требуется продуманная инфраструктура (оркестрация, мониторинг, логирование каждого сервиса), появляются накладные расходы на сетевые запросы. При тестировании микросервисной системы нужно уделять внимание не только каждому сервису в отдельности, но и их интеграции: проверить, как сервисы обмениваются данными, что происходит при сбоях одного из них и т.д. Таким образом, сложность архитектуры переходит и в более сложное интеграционное тестирование.

Резюме: Выбор между монолитом и микросервисами зависит от масштабов и требований проекта. Монолит проще вначале и его легче покрыть тестами на уровне модуля, а микросервисы дают гибкость и изоляцию компонентов, но требуют дополнительных усилий по обеспечению взаимодействия и тестированию интеграции сервисов.

Тестирование серверной части (Backend testing)

Backend testing – это тестирование серверной (внутренней) части приложения, проверка того, что на уровне бизнес-логики и хранения данных всё работает корректно. В отличие от фронтенд-тестирования, здесь обычно не используется графический интерфейс: тестировщик может напрямую вызывать функции/эндпойнты бэкенда и проверять возвращаемые данные (например, послать HTTP-запрос на API и получить ответ JSON), а также проверять состояние базы данных напрямую с помощью запросов. Таким образом, тестирование бэкенда часто включает в себя тестирование API и веб-сервисов, тестирование базы данных и проверку бизнес-логики.

Основные аспекты, которые проверяются при тестировании бэкенда:

  • Функциональность и бизнес-логика: проверка того, что серверные модули правильно обрабатывают входные данные и выполняют бизнес-правила. Например, если по логике скидка не должна превышать 50%, на бэкенде проверяется это условие и отклоняется некорректный ввод – тесты должны это подтвердить.

  • API-тестирование: проверка web-API (REST, SOAP, GraphQL и др.). Здесь тестировщик вызывает эндпойнты бэкенда с различными запросами и проверяет ответы. Проверяется корректность формата и содержания ответа (JSON/XML), коды ответа HTTP (200, 400, 500 и т.д.), обработка ошибок и неожиданных ситуаций. Например, тест API регистрации пользователя: отправляем запрос с корректными данными – ожидаем ответ 200 OK и JSON с созданным профилем; отправляем запрос с некорректным email – ожидаем ошибку 400 Bad Request и сообщение об ошибке в ответе.

  • Тестирование базы данных: проверка того, что данные правильно сохраняются, обновляются и извлекаются. Это включает проверку операций CRUD (Create, Read, Update, Delete) на базе данных, соответствие данных бизнес-требованиям, целостность связей. Например, после вызова API создания заказа проверяется, что в базе данных появилась правильная запись заказа. Иногда проверяются и более низкоуровневые свойства базы, такие как соблюдение свойств ACID при транзакциях, корректность работы хранимых процедур, функций, триггеров и т.д.. Также проводятся проверки на целостность данных (data integrity) – например, что невозможна запись некорректных данных, нарушающих ограничения схемы базы.

  • Производительность и нагрузка: для важных бэкенд-компонентов может проводиться нагрузочное тестирование – проверка, что сервер выдерживает требуемое количество одновременных запросов, что время отклика под нагрузкой остаётся в допустимых пределах. Например, с помощью инструмента вроде JMeter имитируют сотни одновременных пользователей и смотрят, не падает ли сервер и укладывается ли в нормативы времени ответа.

  • Безопасность: на уровне бэкенда проверяется, что система защищена от распространённых уязвимостей. Например, тесты на SQL-инъекции – отправка в запрос заведомо вредоносных SQL-фрагментов, которые бэкенд не должен исполнять; тестирование корректности разграничения прав доступа (что без авторизации нельзя получить данные, требующие авторизации, и т.д.). Эти проверки могут выполняться вручную или специализированными сканерами безопасности.

В процессе тестирования бэкенда часто используются инструменты, позволяющие имитировать или прослеживать работу серверных компонентов. Распространённый подход – написание автоматических тестов (например, модульные тесты на языке бэкенда, интеграционные тесты). Разработчики пишут юнит-тесты для своих функций (проверяя отдельные модули на корректность работы), а тестировщики могут писать скрипты для API-тестирования (например, с помощью фреймворков типа Postman/Newman, REST Assured, pytest для Python и др.).

Также широко применяется тестирование вручную через инструменты: например, с помощью Postman можно вручную отправлять различные HTTP-запросы к API и проверять ответы; с помощью командной строки (curl, httpie) – то же самое. Для проверки состояния базы данных – использовать SQL-клиенты и выполнять запросы прямо к базе, убеждаясь, что после определённых операций данные изменились правильно.

Важно отметить, что тестирование бэкенда может происходить без участия фронтенда. Если фронтенд ещё не готов или неудобно использовать UI, мы напрямую тестируем сервер. Например, вместо заполнения веб-формы можно сразу отправить HTTP-запрос с нужными параметрами и посмотреть, что вернёт сервер (JSON, XML) и что поменяется в базе. Такой подход позволяет изолированно проверить логику серверной части и легче локализовать проблемы (отделив их от возможных ошибок интерфейса).

Вывод: тестирование бэкенда – критически важная часть обеспечения качества, так как именно на сервере выполняются ключевые операции с данными. Грамотно протестированный бэкенд гарантирует, что приложение будет корректно обрабатывать данные и ситуации, даже если на фронте что-то пойдёт не так. Полученные навыки (тестирование API, проверка данных и логики) понадобятся для выполнения практического задания, связанного с JSON-данными.

Валидация данных: JSON и JSON Schema

Так как бэкенд обычно обменивается данными в формате JSON, тестировщик должен уметь проверять корректность JSON-данных. Корректность включает два аспекта: синтаксическая (правильно ли сформирован JSON как текст) и семантическая (соответствует ли содержимое JSON ожидаемым правилам – нужные поля, типы данных, допустимые значения и т.п.).

  • Синтаксическая валидация JSON: проверка, что JSON-файл/строка не содержит ошибок в формате. Например, все открытые скобки { [ имеют закрывающие } ], строки в двойных кавычках, нет лишних запятых. Если JSON синтаксически неверен, парсинг (разбор) на бэкенде провалится. Проверить синтаксис можно с помощью парсеров или онлайн-инструментов (так называемых JSON Lint). Простейший способ – попытаться открыть файл в специальном редакторе или даже браузере: многие выдадут ошибку, если JSON неверен. В языке JavaScript есть функция JSON.parse(), которая выбросит ошибку при некорректном формате. В PHP версии 8.3 даже появилась функция json_validate() для проверки валидности JSON-строки. В общем, синтаксическую правильность обычно проверяют автоматически.

  • Семантическая валидация (проверка структуры и содержания): после проверки синтаксиса нужно убедиться, что данные соответствуют требуемой структуре и бизнес-правилам. Например, если JSON должен содержать поле «email» (строку с адресом электронной почты), то нужно проверить, что это поле есть и значение соответствует формату email; если возраст должен быть числом больше 0 – проверить и это. На уровне кода можно писать отдельные функции проверки или использовать специальные схемы.

Для формального описания структуры JSON-документов существует стандарт JSON Schema. JSON Schema — это спецификация для описания структуры JSON-документов; по сути, строгий контракт между клиентом и сервером о том, какие данные можно отправлять в запросах или получать в ответах. С помощью JSON Schema можно задать ожидаемые поля, их типы (строка, число, объект, массив…), диапазоны допустимых значений, обязательность полей и многие другие ограничения. Это решает проблему неоднозначности – и разработчики, и тестировщики имеют единое машиночитаемое описание формата данных.

Зачем нужна JSON Schema? Она позволяет автоматически проверять, что полученный или отправляемый JSON соответствует заданным правилам. Это обеспечивает целостность данных: гарантируется, что JSON-сообщения синтаксически корректны и содержат все необходимые элементы в нужном формате. Кроме того, схема служит отличной документацией – по ней сразу видно, какие поля ожидаются, каких они типов, какие ограничения (например, строка не длиннее 100 символов, число в диапазоне 1–5 и т.д.). Наличие таких явных правил облегчает отладку и предотвращает множество ошибок на ранней стадии разработки.

JSON Schema поддерживается множеством инструментов. В разных языках программирования есть библиотеки для валидации по схеме (например, jsonschema для Python, ajv для JavaScript, встроенные средства в некоторых фреймворках). Также существуют онлайн-валидаторы JSON Schema, где можно в одно окно вставить JSON-схему, в другое – JSON-данные, и получить результат проверки. Например, есть публичный сервис JSON Schema Validator от Newtonsoft – интерактивный онлайн-инструмент, поддерживающий различные версии стандарта схем. При проверке он укажет, валиден ли JSON относительно схемы, и если нет – покажет какие поля не соответствуют требованиям.

Использование JSON Schema особенно рекомендуется для сложных структур данных. В контексте тестирования API это крайне полезно: разработчик пишет JSON Schema для ответов своего сервиса, а тестировщик может автоматически валидировать полученные ответы, экономя время на ручную проверку каждого поля. В некоторых системах контрактного тестирования микросервисов JSON Schema применяется, чтобы проверить, что сервисы обмениваются данными строго оговорённого формата.

Пример: допустим, бэкенд должен возвращать JSON с информацией о пользователе, содержащий поля: id (целое число), name (строка не пустая), email (строка – валидный email) и age (целое, минимум 18). Мы можем описать JSON Schema для этого объекта, которая явно задаст эти правила. Тогда тест, получив JSON от API, проверит его функцией валидации: если, скажем, поле email отсутствует или равняется 123 (не email), схема обнаружит несоответствие. Ниже показан фрагмент возможной JSON Schema для пользователя:

Иллюстрация к материалу «Игорь Колосов.ru»

Эта схема требует, чтобы JSON был объектом с указанными свойствами. Поле email должно соответствовать формату электронной почты, age – не меньше 18, а name – непустая строка. Если бэкенд вернёт что-то не по контракту, валидатор сообщит об ошибке (например: «age»: 16 не пройдет проверку минимального значения).

Для проверки JSON по схеме вручную можно воспользоваться онлайн-сервисом. Нужно вставить схему и JSON – и сервис покажет, валидны ли данные. Такой подход вы будете применять в практической работе.

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

[task_id id=»21104″]

Базовая структура

JSON всегда начинается с фигурных скобок.

{
"ключ": значение
}

  • Ключ всегда в двойных кавычках

  • Между ключом и значением используется двоеточие

  • Пары разделяются запятыми

Типы значений

Строка

Текстовое значение.

"name": "Иван"

  • Используются двойные кавычки

  • Подходит для имени, email, статуса, описания

Число

Целое или дробное.

"age": 25
"price": 199.99

  • Кавычки не применяются

  • Используется для количества, цены, идентификаторов

Логическое значение

Состояние или флаг.

"isActive": true
"isAdmin": false

  • Всегда пишется строчными буквами

  • Подходит для включено, доступно, подтверждено

Пустое значение

Отсутствие данных.

"middleName": null

  • Используется, когда поле предусмотрено, но значение отсутствует

Объект внутри объекта

Объект — это вложенная структура с собственными ключами.

"user": {
"id": 10,
"email": "test@mail.ru"
}

  • Вложенный объект оформляется фигурными скобками

  • Применяется для группировки связанных данных

Пример: адрес, профиль, настройки.

Массивы

Массив — список значений.

"roles": ["user", "editor"]

  • Используются квадратные скобки

  • Значения разделяются запятыми

  • Элементы массива одного типа

Массив объектов

Частый вариант для списков.

"orders": [
{
"id": 1,
"sum": 500
},
{
"id": 2,
"sum": 1200
}
]

  • Каждый элемент массива — отдельный объект

  • Подходит для заказов, товаров, комментариев

Вложенность

JSON поддерживает многоуровневую структуру.

{
"user": {
"profile": {
"name": "Иван",
"contacts": {
"email": "ivan@mail.ru"
}
}
}
}

  • Каждый уровень отражает иерархию данных

  • Глубина выбирается по смыслу, а не случайно

Форматирование

Рекомендуется:

  • Использовать отступы

  • Каждый ключ писать с новой строки

  • Закрывающие скобки выравнивать

Это упрощает чтение и проверку.

Частые ошибки

  • Пропущенная запятая между полями

  • Лишняя запятая в конце объекта

  • Одинарные кавычки

  • Комментарии внутри файла

JSON воспринимается строго, формат читается буквально.

Проверка JSON

Для проверки используются онлайн-валидаторы.
Они показывают синтаксические ошибки и место сбоя.