Что такое ПМИ?

Что такое ПМИ (Протокол Моделирования Интернета)?

ПМИ (Протокол Моделирования Интернета) — это собирательное, неофициальное и, скорее всего, ошибочное название, которое в контексте собеседований на позицию QA Engineer часто подразумевает стек протоколов TCP/IP (Transmission Control Protocol/Internet Protocol). С большой долей вероятности, это результат искажения или неправильного запоминания термина "IP-модель" или "модель Интернета". В классической теории сетей и тестировании сетевых приложений мы говорим о модели OSI (Open Systems Interconnection), состоящей из 7 уровней, и более практической модели TCP/IP, состоящей из 4 (или 5) уровней. Именно модель TCP/IP часто называют "моделью Интернета".

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

Понимание сетевых моделей критически важно для тестировщика, особенно при работе с:

• Веб-приложениями и API (REST, SOAP, GraphQL).
• Мобильными приложениями, взаимодействующими с бэкендом.
• Клиент-серверными и распределенными системами.
• Поиске и диагностике дефектов, связанных с сетевым взаимодействием.

Знание уровней позволяет целенаправленно проектировать тесты, изолировать проблемы (например, проблема на уровне приложения или на транспортном уровне?) и грамотно общаться с разработчиками и сетевыми инженерами.

Модель TCP/IP (та самая "модель Интернета")

Это практическая модель, на которой построен современный Интернет. Рассмотрим её уровни и их связь с тестированием.

### Уровень 4: Прикладной уровень (Application Layer)

Это уровень протоколов, с которыми непосредственно взаимодействует пользователь и наше приложение.

• Протоколы: HTTP/HTTPS, FTP, SMTP, DNS, WebSocket.
• Роль в тестировании: Здесь мы проводим основную часть функционального тестирования API и UI.

    *   **Пример теста:** Отправка POST-запроса через `curl` или Postman для создания ресурса и проверка HTTP-статуса `201 Created` и тела ответа.

```bash
# Пример тестирования на прикладном уровне с помощью curl (протокол HTTP)
curl -X POST https://api.example.com/users \
     -H "Content-Type: application/json" \
     -d '{"name":"John", "email":"john@example.com"}' \
     -v # Ключ -v покажет заголовки запроса и ответа (HTTP-уровень)
```

    *   **Типичные дефекты:** Неверные коды ответа, ошибки валидации в JSON/XML, несоблюдение спецификации API.

### Уровень 3: Транспортный уровень (Transport Layer)

Обеспечивает передачу данных между приложениями на хостах, управляет надежностью и потоками.

• Протоколы: TCP (надежный, с установлением соединения), UDP (быстрый, без установления соединения).
• Роль в тестировании: Тестирование на этом уровне часто связано с проверкой устойчивости, производительности и сетевых сбоев.

    *   **Пример теста:** Использование **`telnet`** или **`nc` (netcat)** для проверки доступности конкретного порта TCP на сервере (без участия прикладного протокола).

```bash
# Проверка, открыт ли порт 80 (HTTP) на сервере example.com (TCP-уровень)
telnet example.com 80
# Или с помощью netcat
nc -zv example.com 80
```

    *   **Типичные дефекты:** Соединение не устанавливается (firewall, сервер не слушает порт), обрыв соединения при передаче больших данных, переполнение буфера.

### Уровень 2: Сетевой уровень (Internet Layer)

Отвечает за маршрутизацию пакетов и логическую адресацию в сети (IP-адреса).

• Протоколы: IP, ICMP, ARP.
• Роль в тестировании: Тестирование маршрутизации, доступности сетевых узлов, диагностика проблем с сетью.

    *   **Пример теста:** Использование утилиты **`ping`** (протокол ICMP) для проверки базовой доступности хоста.

```bash
# Проверка доступности хоста на сетевом уровне (ICMP)
ping google.com
```

    *   **Типичные дефекты:** Хост недоступен из-за сетевых проблем, неправильная настройка маршрутов.

### Уровень 1: Канальный и Физический уровень (Link/Physical Layer)

Отвечает за передачу данных по физической среде (Ethernet, Wi-Fi, оптоволокно).

• Роль в тестировании: Обычно за пределами компетенции QA-инженера приложения, но важно понимать, что проблемы могут быть и здесь (например, плохой сигнал Wi-Fi).

Практическое применение в тестировании: пример сценария

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

1. Анализ по уровням:

    *   **Прикладной (HTTP):** Проверяем, корректно ли формируется `multipart/form-data` запрос, нет ли ошибок `4xx/5xx` от сервера.
    *   **Транспортный (TCP):** Моделируем нестабильную сеть с помощью инструментов: обрыв TCP-соединения (`iptables`), ограничение пропускной способности, таймауты.

```bash
# Пример симуляции потери пакетов в Linux (может потребовать прав root)
# Эта команда добавит 10% потерь пакетов на исходящие соединения
tc qdisc add dev eth0 root netem loss 10%
```

    *   **Сетевой (IP):** Проверяем, меняется ли IP-адрес во время загрузки (например, при переключении с Wi-Fi на мобильный интернет).

1. Тест-кейсы:

    *   Загрузка файла при нормальных условиях.
    *   Загрузка файла с симулированными таймаутами TCP.
    *   Загрузка файла с внезапным отключением и восстановлением сети.
    *   Проверка, как приложение обрабатывает частично загруженные данные (восстановление, повторная отправка, корректное сообщение об ошибке).

Вывод: Под "ПМИ" на собеседовании почти наверняка подразумевают стек протоколов TCP/IP (Интернет-модель). Глубокое понимание этой модели — не абстрактная теория, а мощный практический инструмент для QA-инженера. Оно позволяет системно подходить к тестированию сетевого взаимодействия, эффективно локализовать дефекты и проектировать сценарии, проверяющие устойчивость приложения в реальных, неидеальных условиях сети. На собеседовании я бы уточнил, что именно имеет в виду интервьюер под термином "ПМИ", а затем подробно рассказал бы о модели TCP/IP и её применении в тестировании.