Представьте, что вы смотрите на конфигурацию сетевого агента. У вас 12 UDP-портов, 12 TCP-портов, пул из семи прокси-нод, правила блокировки, перенаправления и игнорирования. И вам нужно убедиться, что каждый пакет уходит именно туда, куда должен. Руками проверить всё — неделя работы. И это без гарантии, что вы не пропустили хитрую комбинацию.

Однажды я пропустил баг именно из-за такой слепой проверки. Пакет уходил не через ту ноду, потому что я не учёл приоритет правил. После этого случая я перестал тестировать сеть «на глаз» и начал использовать математику. Тест-дизайн превратил хаос в понятную систему.

Расскажу, как я применяю четыре техники к сетевому взаимодействию Агента.

Техника 1. Классы эквивалентности. Делим трафик на группы

Агент — это MITM-прокси. Он перехватывает соединение на клиентской Windows-машине и решает: заблокировать трафик (block), пропустить мимо себя (ignore) или завернуть в прокси-ноду (redirect). Проверять каждый из 24 портов отдельно бессмысленно. Мы делим их на три логические группы.

Порты с правилом block. Порты с правилом redirect. Порты с правилом ignore. Внутри каждой группы поведение системы одинаковое. Я беру по одному представителю: порт 5056 для блокировки, 5060 для редиректа, 5065 для игнорирования. Три теста вместо 24. Экономия очевидна. Если один из представителей проходит, значит, и вся группа ведёт себя корректно.

Техника 2. Граничные значения. Ищем баги на стыках протоколов

В конфиге агента есть параметр transport. Правило без этого поля работает только для TCP. Если указать ANY, правило срабатывает и для TCP, и для UDP. Вот здесь прячутся самые злые баги.

Я проверяю границы. Порт только с TCP. Тот же порт с ANY. Тот же порт с UDP. В момент переключения между протоколами система часто путает контекст. Пакет UDP может пойти по правилам TCP. Или наоборот. Эти тесты ловят то, что не видно при обычном клике по интерфейсу.

Техника 3. Таблицы решений. Разбираем приоритеты правил

Логика агента имеет жёсткую иерархию. block важнее ignore. ignore важнее redirect. Если порт попадает под два правила, срабатывает то, что выше по приоритету.

Я рисую таблицу. Строки — это комбинации правил. Столбцы — ожидаемое действие. Для трёх правил получается восемь комбинаций. Например, если порт указан и в block, и в redirect, трафик должен быть заблокирован. Если в ignore и redirect, трафик проходит мимо. Таблица не даёт забыть ни одну ветку. Когда разработчик добавляет новое правило, я просто добавляю строку и проверяю стык.

Техника 4. Переходы состояний. Ловим режим BYPASS

Это мой любимый и самый сложный кейс. Агент работает с пулом прокси-нод. Если основная нода упала, он переключается на резервную. Если упали обе, включается режим BYPASS — трафик идёт напрямую, без прокси.

Состояний четыре: нормальная работа, отказ одной ноды, отказ всех нод, восстановление. Переходы между ними — самое хрупкое место в системе. Тест проверяет не просто «есть ли интернет». Тест проверяет маршрут. Я смотрю на IP-адрес источника, который видит сервер. Если видит IP клиента — трафик прошёл напрямую. Если видит IP ноды — трафик перехвачен.

Когда нода восстанавливается, система должна вернуться в нормальное состояние. Но часто застревает в BYPASS. Трафик продолжает идти мимо прокси, хотя он уже доступен. Автотесты с параметризацией по состояниям ловят эту задержку за секунды.

Как это выглядит в коде

Каждая техника ложится на pytest. Классы эквивалентности — это параметризация. Границы — отдельные сценарии. Таблицы решений — фикстуры с конфигами. Переходы состояний — маркеры для медленных тестов. Всё это собирается в allure. По каждому порту видно, на каком шаге сломался маршрут.

Итог

Двадцать четыре порта. Четыре техники. Одна понятная структура. Вместо недели ручной беготни — автоматический прогон с отчётом. Тест-дизайн в сетевом взаимодействии — это умение видеть структуру. Где классы. Где границы. Где переходы. Без этого вы просто перебираете порты в надежде, что баг сам выскочит 😅