Criado por IAMelhorado por pessoas
Riqli · documentos vivos · atualizados continuamente
Onde o conhecimento da IA encontra a prática humana.
Partilhar com amigos
Автоматизация тестирования API с Python. Hard skill. (Автотесты api python. Тестирование api python requests. Python api тестирование. Pytest api тестирование. Tutorial. Practice. Standard.)
Введение
Аннотация.
Разработка и поддержка современных API требует высокой скорости и надежности. Ручное тестирование не успевает за быстрыми релизами, а ошибки в интеграциях между сервисами становятся главной проблемой. Данный курс решает задачу внедрения надежной и масштабируемой автоматизации тестирования API с использованием Python.
Мы изучим полный цикл: от настройки окружения и написания первого теста на Pytest до интеграции в CI/CD и анализа покрытия с помощью Swagger Coverage. Вы научитесь работать с синхронными и асинхронными протоколами, управлять тестовыми данными и создавать профессиональные отчеты.
Курс ориентирован на тестировщиков и разработчиков, которые хотят перейти от ручной проверки к созданию автономного набора API-тестов, который будет частью процесса разработки, а не отдельным этапом.
Цель курса.
После прохождения курса вы сможете самостоятельно спроектировать и реализовать на Python полноценный набор автотестов для REST API, интегрировать его в CI/CD процесс на базе GitHub Actions и настроить получение детализированных отчетов и метрик покрытия.
Результаты обучения.
- Знать: принципы работы протоколов HTTP/1.1, HTTP/2, gRPC и WebSockets; основные виды тестирования (функциональное, регрессионное, интеграционное); архитектуру и ключевые элементы CI/CD процессов.
- Уметь: писать автотесты на Pytest с использованием библиотек HTTPX, Pydantic и Faker; генерировать и анализировать Allure-отчеты; настраивать параллельный запуск и повторные проходы тестов.
- Владеть: навыками проектирования API клиентов с использованием паттерна Builder; управления тестовыми данными через Pydantic Settings; настройки пайплайнов в GitHub Actions для автоматического запуска тестов.
Для кого этот курс.
Кому будет полезно: Инженеры по тестированию (QA), автоматизаторы, разработчики, желающие внедрить практики Shift-Left Testing (сдвиг тестирования влево) в свои проекты. Курс подойдет тем, кто уже знаком с основами Python и хочет структурировать знания в области API-автоматизации.
Кому курс НЕ подойдёт: Начинающим программистам без опыта работы с Python; специалистам, которые ищут курс по тестированию пользовательского интерфейса (UI) или нагрузочному тестированию (Performance).
Основы тестирования и методология
Ключевые артефакты тестирования. В профессиональной работе QA-инженера артефакты играют ключевую роль, структурируя процесс. Главные из них: Тест-план — документ, описывающий цели, объем, ресурсы и расписание тестирования. Тест-кейс — набор шагов для проверки конкретной функции, включающий предусловия, шаги, ожидаемый результат и постусловия. Чек-лист — упрощенная версия кейса, список проверок без детальных шагов. Отчет о дефекте (баг-репорт) содержит информацию об ошибке: шаги воспроизведения, фактический и ожидаемый результаты, серьезность и приоритет. Тестовый набор (Test Suite) — это логическая группировка тест-кейсов по функциональному признаку. Все эти документы обеспечивают повторяемость и прозрачность процесса, особенно важны при адаптации новых членов команды.
Виды тестирования: Функциональное, Регрессионное и Smoke. Функциональное тестирование проверяет, соответствует ли программа заявленным требованиям (например, авторизация, создание заказа). Регрессионное тестирование — это перезапуск существующих тестов после внесения изменений в код, чтобы убедиться, что старый функционал не сломался. Оно является основной целью для автоматизации, так как требует многократного повторения. Smoke-тестирование — это быстрая проверка самой критичной функциональности (например, «открывается ли главная страница?», «можно ли авторизоваться?»). Цель — убедиться, что сборка стабильна и годится для более глубокого тестирования. Эти виды тестирования формируют пирамиду: широкое основание из быстрых модульных тестов и вершина из медленных end-to-end (E2E) тестов.
Ручное и автоматизированное тестирование: стратегия выбора. Ручное тестирование эффективно для исследовательского тестирования, проверки UI/UX и для сценариев, которые выполняются редко. Автоматизированное тестирование незаменимо для регрессионных проверок, тестирования нагрузки и производительности, а также для повторяющихся проверок критического API. Главная цель автоматизации на проекте — не заменить человека, а освободить его от рутины, ускорить обратную связь разработчику. Автоматизированные тесты пишутся для стабильных требований и являются частью кодовой базы, требуя такой же поддержки, как и основной продукт. Ключевые индикаторы для внедрения автоматизации: длительность регрессионных прогонов, частота релизов и требования к стабильности.
Сетевые протоколы: HTTP, gRPC, WebSockets
Протокол HTTP: структура запроса и ответа. HTTP (HyperText Transfer Protocol) — основной протокол передачи данных в вебе. Он работает по модели «запрос-ответ» и является stateless (без состояния), то есть каждый запрос не зависит от предыдущего. Структура HTTP запроса включает: метод (GET, POST, PUT, PATCH, DELETE), URI (путь к ресурсу), заголовки (Headers) и тело запроса (Body — не всегда). Структура HTTP ответа содержит: статус-код (200 OK, 401 Unauthorized, 500 Internal Server Error и др.), заголовки и тело ответа. Знание групп статус-кодов критично для тестировщика: 2xx — успех, 4xx — ошибка клиента, 5xx — ошибка сервера. Без понимания этих основ невозможно эффективно тестировать REST API.
gRPC: когда нужна высокая производительность. gRPC — это высокопроизводительный фреймворк для удаленного вызова процедур (RPC), разработанный Google. В отличие от REST, использующего JSON/XML, gRPC работает поверх HTTP/2 и использует Protocol Buffers (protobuf) для сериализации данных, что делает его значительно быстрее и компактнее. Контракт взаимодействия описывается в файле .proto, на основе которого генерируется код клиента и сервера на разных языках, обеспечивая строгую типизацию. gRPC поддерживает четыре режима взаимодействия: унарный (один запрос — один ответ), стриминг от сервера, стриминг от клиента и двунаправленный стриминг. Этот протокол идеален для высоконагруженных микросервисных архитектур и внутренних систем.
WebSockets: двусторонняя связь в реальном времени. WebSocket — это протокол, обеспечивающий постоянный канал связи между клиентом и сервером в реальном времени. В отличие от HTTP (где соединение разрывается после ответа сервера), WebSocket поддерживает соединение открытым, позволяя обеим сторонам отправлять данные независимо. Это критически важно для чатов, онлайн-игр, биржевых приложений и систем мониторинга. Для тестирования WebSockets в Python можно использовать библиотеку websockets (асинхронную) и websocket-client (синхронную). При тестировании нужно проверять не только отправку и получение сообщений, но и корректность обработки ошибок, таймаутов и поддержание соединения при переподключении. WebSocket-тесты обычно пишутся с использованием асинхронного синтаксиса (async/await).
Инструменты и библиотеки для автоматизации на Python
Pytest как основной фреймворк для тестирования. Pytest — это де-факто стандарт для написания тестов на Python. Его ключевое преимущество — простота: тесты пишутся как обычные функции, начинающиеся с префикса test_. Pytest обладает мощной системой фикстур (fixtures) для подготовки окружения, встроенной параметризацией тестов (@pytest.mark.parametrize), возможностью маркировки тестов (@pytest.mark.smoke) и богатой экосистемой плагинов. Он автоматически находит тесты в файлах с префиксом test_ или суффиксом _test.py. Конфигурация Pytest (например, имена тестовых файлов или флаги запуска) задается в файле pytest.ini или pyproject.toml. Настройка через pytest.ini позволяет стандартизировать поведение тестов на проекте для всех участников команды.
HTTPX: современный HTTP-клиент для API тестов. HTTPX — это полностью функциональный HTTP-клиент для Python 3, который является прямой заменой устаревшему Requests. Его главные преимущества: поддержка асинхронности (async/await), HTTP/1.1 и HTTP/2, строгая типизация и удобный клиент (Client) для переиспользования соединений. Пример запроса:
import httpx
response = httpx.get('https://api.example.com/users/1')
print(response.status_code, response.json())response = httpx.post('https://...', json={'key': 'value'})Pydantic: валидация данных и управление настройками. Pydantic — это библиотека для валидации данных и управления настройками через аннотации типов Python. Она используется для описания схем данных (моделей) ответов API, запросов и конфигураций проекта. Главная фишка — автоматическая валидация и преобразование типов. Пример модели:
from pydantic import BaseModel, EmailStr
class User(BaseModel):
id: int
name: str
email: EmailStrПрактика написания API автотестов
Структура API-клиента с HTTPX и Pydantic. Хорошая практика — создание собственного класса APIClient, который инкапсулирует логику работы с HTTPX: общую базовую URL (base_url), таймауты, заголовки авторизации. Внутри клиента создаются методы, соответствующие бизнес-сущностям, например create_user(request: CreateUserRequest) -> CreateUserResponse, где CreateUserRequest и CreateUserResponse — это Pydantic-модели. Это дает строгую типизацию и централизованное место для логирования и обработки ошибок. Пример метода:
def create_user(self, payload: CreateUserRequest) -> CreateUserResponse:
response = self.client.post('/users', json=payload.dict(exclude_none=True))
assert response.status_code == 201
return CreateUserResponse(**response.json())Параметризация тестов в Pytest. Параметризация позволяет запускать один тест с разными входными данными, избегая дублирования кода. Декоратор @pytest.mark.parametrize принимает имя аргумента и список значений (или список кортежей/словарей для нескольких аргументов). Пример:
@pytest.mark.parametrize("user_email, expected_status", [
("valid@test.com", 201),
("invalid", 400),
("", 422)
])
def test_create_user_various_emails(user_email, expected_status):
response = client.post('/users', json={"email": user_email})
assert response.status_code == expected_statusВалидация JSON Schema через Pydantic и pytest. JSON Schema — это контракт, описывающий ожидаемую структуру JSON-ответа. Валидация по схеме гарантирует, что API не изменил формат данных, даже если конкретные значения остались верными. В Python это реализуется через библиотеку pydantic. Модель Pydantic можно преобразовать в JSON Schema встроенным методом .schema(). Для автоматизации генерации схем по моделям и их валидации используется библиотека pydantic-schema или openapi-schema-validator. Тест проверки схемы может выглядеть так:
from pydantic import ValidationError
def test_user_response_schema():
response = client.get_user(1)
try:
UserResponse(**response.json())
except ValidationError as e:
pytest.fail(f"Ответ не соответствует схеме: {e}")Управление тестовыми данными и окружением
Генерация фейковых данных с Faker. Библиотека Faker — незаменимый инструмент для создания реалистичных тестовых данных, когда нет возможности или желания использовать предопределенные наборы. Она умеет генерировать имена (fake.name()), email-адреса (fake.email()), адреса, тексты на десятках языков. Локализация (locale='ru_RU') позволяет создавать данные, соответствующие региону. Для сложных сценариев можно создавать свои провайдеры. Важная практика — инкапсулировать генерацию данных через Pydantic-модель или фабрику, что позволит при необходимости быстро сменить стратегию генерации (например, использовать данные из внешнего файла вместо случайных). Faker используется для позитивных тестов (валидные данные), а также для генерации «почти валидных» данных для граничных тестов (например, email с длиной 257 символов).
Управление настройками через Pydantic Settings. Вынос конфигурации (URL API, таймауты, учетные данные, пути к файлам) в настройки — критически важно для гибкости и безопасности. Pydantic Settings позволяет создать класс настроек, который автоматически читает значения из переменных окружения (.env файлов) и валидирует их типы. Пример:
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
api_url: str = "http://localhost:8000"
timeout: int = 30
superuser_email: EmailStr
class Config:
env_file = ".env"
settings = Settings()Продвинутые техники Pytest
Маркировки (marks) и фильтрация тестов. Маркировки — это способ назначать тегам тесты, а затем запускать только отмеченные. Стандартные маркировки: @pytest.mark.smoke, @pytest.mark.regression. Кастомные маркировки необходимо регистрировать в pytest.ini во избежание предупреждений. Фильтрация происходит через флаги:
$ pytest -m "smoke" # только smoke
$ pytest -m "not regression" # все, кроме regression
$ pytest -m "smoke or regression" # любые из двухПропуск тестов и ожидаемые падения. Pytest предоставляет декораторы для управления выполнением тестов: @pytest.mark.skip(reason='...') — тест всегда будет пропущен. @pytest.mark.skipif(condition, reason='...') — тест пропускается, если условие истинно (например,
@pytest.mark.skipif(sys.platform == "win32", reason="Тест не работает на Windows")Продвинутые техники Pytest
Плагины Pytest: параллельный запуск и перезапуск. Экосистема плагинов расширяет возможности Pytest. Ключевые плагины: pytest-xdist — для параллельного запуска тестов на нескольких воркерах (-n auto). Это значительно ускоряет прогон больших наборов тестов. Важно тестировать стабильность сервера под нагрузкой от параллельных запросов. pytest-rerunfailures — позволяет автоматически перезапускать упавшие тесты заданное количество раз (--reruns 3). Это полезно для борьбы с флаки-тестами (flaky tests), которые падают из-за нестабильности окружения, а не реальных багов. Важно использовать перезапуски осознанно, не скрывая ими реальные проблемы в коде. conftest.py — это специальный файл для хранения фикстур и плагинов, которые должны быть доступны глобально на проекте.
Отчетность и логирование
Генерация и структура Allure-отчетов. Allure Framework — стандарт индустрии для создания наглядных отчетов о тестировании. Процесс состоит из двух шагов: 1) запуск тестов с генерацией промежуточных результатов (pytest --alluredir=./allure-results); 2) генерация HTML-отчета из этих данных (allure generate ./allure-results -o ./allure-report). Allure-отчет содержит: общую статистику, графики выполнения, историю запусков (History), детальные шаги теста, прикрепленные логи, скриншоты и запросы/ответы API. Интеграция с Pytest осуществляется через плагин allure-pytest. Всеure позволяет группировать тесты по фичам и историям через декораторы (@allure.feature, @allure.story), что делает отчет понятным не только для технических специалистов, но и для бизнес-аналитиков и менеджеров.
Добавление вложений и шагов в Allure. Декоратор @allure.step позволяет разбить тест на логические действия, которые будут отображаться в отчете, что критически важно для анализа падений. Контекстный менеджер with allure.step('...'): дает еще более гибкое управление. Для вложений используются allure.attach, например, для прикрепления cURL запроса к отчету:
import allure
allure.attach("curl_command", "Запрос к API", allure.attachment_type.TEXT)Allure TestOps как система управления тестированием. Allure TestOps — это платформа (TMS) для управления процессом тестирования, которая объединяет ручные и автоматизированные тесты. Позволяет создавать тест-кейсы, планировать запуски (тест-планы), анализировать тренды и интегрироваться с системами трекинга задач (Jira). Ключевая особенность — автоматическая синхронизация: при запуске автотестов, тест-кейсы в TestOps обновляются (шаги, теги) или создаются автоматически. Это решает проблему рассинхрона документации и кода. TestOps предоставляет те же Allure-отчеты, но с возможностью фильтрации по запускам, построения дашбордов и управления статусом тестов (активен, в разработке, устарел). Хотя система платная, изучение ее концепции и возможностей через демо-проект повышает ценность инженера на рынке.
Интеграция в CI/CD и управление покрытием
CI/CD: непрерывная интеграция и доставка. CI/CD (Continuous Integration/Continuous Delivery) — это практика автоматизации этапов разработки. CI (Continuous Integration) подразумевает частую интеграцию кода в общую ветку (main/master), при котором автоматически запускаются сборка и тесты, чтобы сразу обнаружить конфликты и баги. CD (Continuous Delivery) — это автоматическое развертывание протестированной версии в окружения, близкие к боевым (staging, prod). Для QA-инженера основная задача — встроить API-автотесты в CI процесс так, чтобы они запускались автоматически при Pull Request (PR) или после слияния. Стандартные триггеры: push в любую ветку, pull_request (для проверки перед слиянием) и schedule (запуск по расписанию). Успешный прогон тестов — это зеленый сигнал для команды продолжать процесс релиза.
Настройка GitHub Actions для запуска автотестов. GitHub Actions — встроенная CI/CD платформа. Пайплайн описывается в YAML-файле в директории .github/workflows/. Пример workflow для запуска API-тестов при пуше в main:
name: API Tests
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
- run: pip install -r requirements.txt
- run: pytest tests/ --alluredir=allure-results
- uses: actions/upload-artifact@v4
with:
name: allure-results
path: allure-resultsИзмерение покрытия API с Swagger Coverage. Swagger Coverage — инструмент, который измеряет, какие пути (endpoints), HTTP-методы и статус-коды из OpenAPI (Swagger) спецификации были реально вызваны вашими автотестами. В отличие от покрытия кода (coverage.py), он показывает бизнес-покрытие: протестировали ли вы все заявленные сценарии. Интеграция: библиотека swagger-coverage работает как middleware или прокси, записывая все запросы/ответы из тестов. Затем команда swagger-coverage-command-line генерирует HTML-отчет на основе этой информации и вашей OpenAPI спецификации (swagger.json). Отчет показывает какие эндпоинты и статусы покрыты, а какие нет, помогая находить пробелы в тестировании (например, эндпоинт DELETE вообще не тестируется, или статус 401 Unauthorized не проверен).
Итоговый проект и лучшие практики
Структура и настройка итогового проекта. Итоговый проект — это завершенный репозиторий с API-автотестами, соответствующий следующим требованиям: pytest как фреймворк, HTTPX для запросов, Pydantic для валидации и настроек, Allure для отчетов. Проект должен содержать файл README.md на английском языке с инструкцией по установке, настройке и запуску. В README указываются используемые библиотеки, переменные окружения (какие нужно создать) и примеры запуска (pytest + allure). Код должен быть задокументирован (docstrings). Необходимо использовать фикстуры через conftest.py или плагины, разделять API клиент, модели и бизнес-логику тестов (паттерн Page Object для API). Репозиторий должен быть чистым от учебных/временных файлов, иметь .gitignore и быть готовым к клонированию и запуску новым разработчиком.
Документирование через README.md. Файл README.md — это лицо проекта. Он должен содержать: название, описание (какой API тестируется, цель проекта); требования (версия Python, операционная система); инструкцию по установке (python -m venv venv, pip install -r requirements.txt); описание переменных окружения (API_URL, TIMEOUT, LOG_LEVEL) с примерами (.env.example); команды для запуска всех тестов, параллельного запуска и генерации отчета; пример просмотра Allure-отчета через allure open. Markdown позволяет использовать заголовки, списки, код-блоки. Профессионально написанный README существенно облегчает вхождение в проект новых членов команды и демонстрирует уровень системного мышления инженера.
Принципы Shift-Left Testing. Shift-Left Testing — это практика сдвига тестирования на более ранние этапы разработки (влево на временной шкале). Идея: находить и исправлять баги как можно раньше, когда их стоимость минимальна. На практике это означает: написание тестов одновременно с кодом (разработка через тестирование, TDD), активное участие QA в процессе анализа требований и проектирования, проведение тестов на уровне компонентов и интеграций до UI-тестов. В контексте API-тестирования это реализуется через запуск автотестов в pull requests до слияния кода, а также через концепцию Shift-Left for API — написание изолированных тестов на локальном окружении разработчика с мокингом внешних зависимостей, а не на полноценном staging-окружении. Это дает мгновенную обратную связь разработчику.
Основы тестирования и методология
Ключевые артефакты тестирования. В профессиональной работе QA-инженера артефакты играют ключевую роль, структурируя процесс. Тест-план — это документ, описывающий цели, объем, ресурсы и расписание тестирования. Он включает критерии начала и окончания тестирования, а также список рисков. Тест-кейс — это набор шагов для проверки конкретной функции, включающий предусловия, шаги, ожидаемый результат и постусловия. Тест-кейсы бывают позитивные (проверяют ожидаемое поведение) и негативные (проверяют обработку ошибок). Чек-лист — это упрощенный вариант кейса, список проверок без детальных шагов. Отчет о дефекте (баг-репорт) содержит информацию об ошибке: шаги воспроизведения, фактический и ожидаемый результаты, серьезность и приоритет. Серьезность (Severity) определяет влияние на систему, а приоритет (Priority) — важность для бизнеса. Тестовый набор — это логическая группировка тест-кейсов по функциональному признаку или типу тестирования (например, smoke или regression). Все эти документы обеспечивают повторяемость, прозрачность и возможность воспроизведения тестов в будущем, что критически важно при адаптации новых членов команды.
Виды тестирования: Функциональное, Регрессионное и Smoke. Функциональное тестирование проверяет, соответствует ли программа заявленным требованиям (например, авторизация, создание заказа, поиск товара). Оно отвечает на вопрос: "Работает ли функция так, как ожидается?". Регрессионное тестирование — это перезапуск существующих тестов после внесения изменений в код, чтобы убедиться, что старый функционал не сломался. Оно является основной целью для автоматизации, так как требует многократного повторения одного и того же набора проверок. Каждый релиз может содержать сотни таких тестов. Smoke-тестирование — это быстрая проверка самой критичной функциональности (например, «открывается ли главная страница?», «можно ли авторизоваться?», «создается ли заказ?»). Цель — убедиться, что сборка стабильна и годится для более глубокого тестирования. Smoke-тесты должны выполняться за несколько минут. Эти виды тестирования формируют пирамиду: широкое основание из быстрых модульных (unit) тестов, средний слой из API-тестов и вершина из медленных end-to-end (E2E) UI-тестов. API-тесты занимают идеальный баланс между скоростью и покрытием бизнес-логики.
Ручное и автоматизированное тестирование: стратегия выбора. Ручное тестирование эффективно для исследовательского тестирования (exploratory), проверки UI/UX и для сценариев, которые выполняются редко (например, раз в полгода). Оно позволяет быстро проверять новые, нестабильные фичи без затрат на автоматизацию. Автоматизированное тестирование незаменимо для регрессионных проверок, тестирования нагрузки и производительности, а также для повторяющихся проверок критического API. Оно обеспечивает быструю обратную связь разработчику после каждого коммита. Главная цель автоматизации на проекте — не заменить человека, а освободить его от рутины. Ключевые индикаторы для внедрения автоматизации: длительность регрессионных прогонов (более 2 часов), частота релизов (чаще раза в неделю) и требования к стабильности (uptime 99.9%). Автоматизированные тесты пишутся для стабильных требований и являются частью кодовой базы, требуя такой же поддержки, как и основной продукт. Это означает, что при изменении API тесты должны обновляться синхронно с кодом.
Сетевые протоколы: HTTP, gRPC, WebSockets
Протокол HTTP: структура запроса и ответа. HTTP (HyperText Transfer Protocol) — основной протокол передачи данных в вебе. Он работает по модели «запрос-ответ» и является stateless (без состояния), то есть каждый запрос не зависит от предыдущего. Сервер не хранит информацию о клиенте между запросами. Структура HTTP запроса включает: метод (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), URI (путь к ресурсу, например /users/123), заголовки (Headers), такие как Content-Type и Authorization, и тело запроса (Body — не обязательно для GET и DELETE). Структура HTTP ответа содержит: статус-код, например 200 OK, заголовки, такие как Content-Length, и тело ответа. Статус-коды делятся на классы: 1xx (информационные), 2xx (успех, например 201 Created), 3xx (перенаправление, 301 Moved Permanently), 4xx (ошибка клиента, 401 Unauthorized, 404 Not Found, 422 Unprocessable Entity) и 5xx (ошибка сервера, 500 Internal Server Error). Знание этих кодов критично для тестировщика, так как каждый из них требует своей проверки. Например, 401 проверяет сценарий неавторизованного доступа, а 422 — ошибку валидации данных.
gRPC: когда нужна высокая производительность. gRPC — это высокопроизводительный фреймворк для удаленного вызова процедур (RPC), разработанный Google. В отличие от REST, использующего JSON/XML, gRPC работает поверх HTTP/2 и использует Protocol Buffers (protobuf) для сериализации данных. Protobuf — это бинарный формат, который значительно компактнее и быстрее JSON. Контракт взаимодействия описывается в файле .proto, где определяются сервисы и сообщения. На основе этого файла генерируется код клиента и сервера на разных языках (Python, Go, Java, C#), обеспечивая строгую типизацию и предотвращая ошибки на этапе компиляции. gRPC поддерживает четыре режима взаимодействия: унарный (один запрос — один ответ), стриминг от сервера (один запрос — много ответов), стриминг от клиента и двунаправленный стриминг (real-time обмен данными). Этот протокол идеален для высоконагруженных микросервисных архитектур и внутренних систем, где скорость и эффективность важнее, чем человекочитаемость данных. Пример использования: внутренние сервисы Netflix, Uber и Google.
WebSockets: двусторонняя связь в реальном времени. WebSocket — это протокол, обеспечивающий постоянный канал связи между клиентом и сервером в реальном времени. В отличие от HTTP (где соединение разрывается после ответа сервера), WebSocket поддерживает соединение открытым, позволяя обеим сторонам отправлять данные независимо в любой момент. Это реализует полно-дуплексную (full-duplex) связь. Протокол работает поверх TCP и использует порты 80 (ws) и 443 (wss). WebSocket критически важен для чатов (Slack, Telegram Web), онлайн-игр, биржевых приложений (трансляция котировок), дашбордов мониторинга и систем, требующих мгновенного обновления данных. Для тестирования WebSockets в Python можно использовать библиотеку websockets (асинхронную) и websocket-client (синхронную). При тестировании нужно проверять не только отправку и получение сообщений, но и корректность обработки ошибок, поддержание соединения с помощью ping/pong сообщений, таймауты и механизмы переподключения при разрыве связи. WebSocket-тесты обычно пишутся с использованием асинхронного синтаксиса (async/await).