Skip to content

testing.md

Latest commit

 

History

History
97 lines (62 loc) · 19.1 KB

testing.md

File metadata and controls

97 lines (62 loc) · 19.1 KB
Raw

Тестирование

Локальные проверки

Из папки проекта, в отдельном Python-окружении:

python -m pip install -e . pytest cryptography
python -m pytest -q
python -m compileall -q cdn_xhttp

Тесты проверяют ввод данных, формирование ссылок, параметры одного и двух серверов, уникальные UUID, сохранение файлов, SSH-установщик и обработку ошибок. Проверка HTTP использует локальную службу и сверяет полученные данные по SHA256. Успех тестов с заглушками сетевых вызовов не доказывает доступность CDN.

При изменениях мастера и восстановления проверяйте следующие контракты:

  • Первый новый запуск запрашивает origin SSH, распознаёт существующую установку и восстанавливает её без локального JSON. Новая установка продолжает мастер выбора одного/двух VPS.
  • Пароли передаются нужному VPS только в памяти; не попадают в файлы и сообщения об ошибках. Неизвестный ответ Y/N и неверное поле повторяют соответствующий вопрос.
  • Повторная выдача ссылок сохраняет UUID; увеличение количества добавляет UUID, уменьшение удаляет последние только после предупреждения. Первый UUID не меняется.
  • Перед изменениями и повторной выдачей ссылок загружается актуальная серверная копия. Если другая папка программы отозвала UUID, они не экспортируются из старого локального файла. При отказе SSH ссылки не выдаются. Чужая либо изменившаяся после чтения конфигурация не перезаписывается.
  • Отмена и прерывание не теряют сохранённые настройки. Частично применённое изменение двух VPS можно продолжить с теми же UUID; успешное обновление серверов сохраняется локально и выдаёт ссылки даже при отказе последующей проверки.
  • После успешных deploy, link и check ссылки и клиентские JSON выдаются всегда, с CDN-доменом в адресе, до проверки подключения. Отказ или исключение проверки записывает отрицательный status.json и предупреждение, но не меняет ссылки; код 2 возвращает только check. repair-edge выполняет link; plan явно остаётся непроверенным.
  • Повтор неудачной первой установки с исправленным CDN- или origin-доменом не блокируется маркером владельца сертификата; чужой сертификат того же домена отклоняется. Вывод SSH-команды читается до EOF после кода завершения, а ошибка SSH-чтения установки показывает причину с сервера без паролей.
  • Невыполнимое изменение схемы отклоняется до записи pending и запроса паролей; pending такого изменения от прежней версии можно удалить из меню. Ответ DNS из 198.18.0.0/15 (fake-ip локального VPN) даёт предупреждение, а не ошибку; неверный реальный адрес по-прежнему останавливает установку. Сообщение меню называет фактический диапазон пунктов.
  • Конфигурации прежних версий загружаются: connect_address с любым значением отбрасывается, xray_version: "26.5.9" заменяется на 26.9.9; серверный конфиг прежней версии распознаётся при восстановлении и сверке перед обновлением.

Для проверки подключения проверяйте профиль временного Xray (CDN-домен, SNI/Host, uplink в заголовках, SOCKS с паролем), отказ при неверном сертификате, хеше, UUID или выходном IP, перевод сетевых ошибок в результат без текста исключения и прерывание по Ctrl+C. Временный Xray и его папка должны удаляться как при успехе, так и при ошибке; заблокированный антивирусом файл не должен превращать результат в ошибку. Проверка не должна менять адаптеры или системный VPN.

SSH и внешние сетевые вызовы в регрессионных тестах заменяются заглушками либо локальными службами. Тесты запуска проверяют повторное использование окружения, обновление зависимостей при изменении метаданных и обработку ошибок подготовки.

Часть тестов установщика требует Bash. На Windows они используют Git Bash при его наличии; пропущенные тесты видны в отчёте pytest.

Проверка настоящим Xray

Скачайте официальный Xray 26.9.9 для своего компьютера и сверьте SHA256 архива с файлом .dgst. Укажите путь к распакованному бинарнику:

python tests/smoke_xray.py --xray /path/to/xray

На Windows укажите путь к xray.exe.

Сценарий сначала проверяет сгенерированные конфиги клиента и origin командой xray run -test, затем запускает Xray-клиент, origin и при необходимости exit во временных папках на локальных портах. Он проверяет четыре сочетания: один/два сервера и fast/original. 3 МиБ отправки сверяются по SHA256. Соединение с exit использует TLS + Vision.

Локальный HTTP-прокси заменяет CDN и Nginx: сохраняет padding, преобразует OPTIONS в POST и, как Yandex CDN, отвечает 413 на OPTIONS с телом. Тест требует, чтобы каждый пакет отправки шёл в заголовках X-Data-N не длиннее 4096 символов, без тела и с заголовками запроса не больше 32 КБ. Участок клиент → локальный прокси работает без TLS. Поэтому этот тест не подтверждает работу конкретного CDN, выпуск публичных сертификатов или скорость интернета.

Для проверки runtime информационной проверки выполните:

python tests/smoke_verify.py
python tests/smoke_verify.py --xray /path/to/xray

Без --xray сценарий сам скачивает закреплённый официальный Xray и проверяет SHA256; только эта загрузка обращается в интернет. Остальной тест использует временные loopback-службы: TLS с явно доверенным тестовым сертификатом и отпечатком клиента firefox, XHTTP с uplink в заголовках и SOCKS с паролем. Проверяются 1 000 000 байт отправки, 1 MiB получения, целостность данных и отсутствие тела у OPTIONS. Этот тест не проверяет публичный CDN или конкретный VPS.

Проверка на VPS

Для проверки полной схемы нужны готовый CDN, домены и отдельный VPS. Для режима двух серверов нужен дополнительный exit.

  1. Выполните plan и проверьте адреса, конфиги и порты до установки.
  2. Выполните deploy. Убедитесь, что сертификаты выпущены, службы работают, а nginx -t и xray run -test завершаются успешно.
  3. Проверьте выдачу ссылок и проверку после установки. В result/status.json должны быть endpoint_verified=true и vless_tunnel_verified=true; проверка с включённым VPN может идти через него.
  4. Выполните check. /cdn-check через CDN должен получить заголовки X-Data-N без изменений и пустое тело. Реальный Xray должен авторизоваться тем же UUID, передать данные с совпадением хешей и показать ожидаемый внешний IP origin либо exit. Установщик не поддерживает VPS за NAT с другим внешним адресом.
  5. Импортируйте выданную ссылку или клиентский JSON в приложение с ядром Xray 26.3.27 или новее. Проверьте отправку и получение файлов, отправку дольше минуты, внешний IP и отказ с незарегистрированным UUID. В адресе, SNI и Host должен быть CDN-домен, в XHTTP — внешний mode=packet-up и uplinkDataPlacement=header в extra.
  6. Запустите программу из новой папки без deployment.json, подключитесь к origin и проверьте восстановление доменов, пути, UUID и exit, если он используется. Выдача ссылок не должна требовать повторного ввода доменов.
  7. Увеличьте количество UUID и проверьте работу старых и новых ссылок. Затем уменьшите количество: сохранённые UUID продолжают работать, удалённые больше не авторизуются. Повторная установка сохраняет оставшиеся UUID.
  8. На тестовом CDN проверьте смену доменов и XHTTP-пути после подготовки DNS/CDN владельцем. Если CDN ещё не применил настройки, серверные настройки должны сохраниться, ссылки — выдаться, а отрицательный статус и предупреждение — сообщить, что туннель не подтверждён.
  9. На одноразовых VPS прервите обновление между exit и origin, затем продолжите его через меню. Сверьте сохранение UUID, серверные конфиги и состояние служб.
  10. Проверьте продление сертификатов командой certbot renew --dry-run. Отдельно проверьте перечитывание сертификата службами и копирование на exit: тестовое продление не всегда запускает deploy-hook.

Для сравнения скорости используйте одинаковый клиент и направление, минимум три передачи файлов по 20–100 МБ в обе стороны для каждого профиля. Записывайте скорость и ошибки; меньший интервал сам по себе не доказывает прирост скорости.

Проверка архива релиза

Пользовательский архив — Source code (zip) конкретного GitHub-релиза. Перед публикацией проверьте запуск из чисто распакованной папки: run.cmd --version на Windows, bash run.sh --version на Linux, затем --help и офлайн plan с демонстрационным конфигом. Запуск должен подготовить своё окружение и показать версию из тега.

В архив должны попасть run.cmd, run.sh, bootstrap.py, пакет, документация и метаданные зависимостей. В него не должны попадать .venv, deployment*.json, known_hosts, result/, VLESS-ссылки, секреты и результаты реальных серверных проверок. Архивы wheel/sdist не заменяют полный исходный архив для сценария запуска через run.cmd/run.sh.

Границы совместимости

Установщик рассчитан на Ubuntu 22.04/24.04, amd64/arm64 и systemd. В прежней версии установщика установка и прямое подключение к origin проверены на Ubuntu 22.04 и 24.04 amd64. На Ubuntu 24.04 также проверены два UUID, передача по 1 000 000 байт с совпадением SHA256, выход в интернет через VPS, отказ незарегистрированному UUID и тестовое продление сертификата с deploy-hook.

На одном готовом ресурсе Yandex Cloud CDN прежняя схема с телом OPTIONS проходила функциональную проверку на Ubuntu 24.04; к 29.09.2026 Yandex CDN стал отвечать HTTP 413 на тело OPTIONS. Схема с uplink в заголовках измерена 01.10.2026 через настоящий edge Yandex CDN (upload ≈12 Мбит/с, download ≈75 Мбит/с). Выпуск 0.4.0 проверен 02.10.2026 установкой на Ubuntu 22.04 amd64 за ресурсом Yandex Cloud CDN в режиме одного сервера: отказ ставиться поверх чужого сертификата, выпуск сертификата, Xray 26.9.9 с проверкой SHA256, UFW, ссылка с CDN-доменом, встроенная проверка /cdn-check и полного VLESS-пути, а также внешний клиент Xray 26.9.9 по выданному client.json — выход через IP origin, загрузка ≈52 Мбит/с, отправка 8 и 16 МиБ ≈11–12 Мбит/с. Восстановление, управление UUID и режим двух серверов через настоящий CDN требуют отдельной приёмки. Текущие сетевые результаты хранятся локально в result/status.json, а выполненные проверки конкретного выпуска перечисляются в его описании на GitHub.

arm64, два физических VPS и импорт в конкретные клиентские приложения требуют отдельной проверки. Работу через CDN нужно проверять отдельно для выбранного ресурса и сети пользователя: успешное прямое подключение к origin её не подтверждает. Успех локальных тестов не заменяет такую проверку.

Проверка обновления программы

Тесты обновления используют локальные архивы и заглушку GitHub. Проверяйте стабильную версию, отказ/недоступность сервиса, согласие пользователя, SHA256 и состав манифеста, запрет traversal/symlink и конфликтов имён. Успешное обновление должно сохранить байты deployment, pending, backup, known_hosts, result и нестандартных пользовательских файлов; ошибка должна оставить исходную папку рабочей. Проверяйте приватность копий, отказ для Git checkout и изменённого кода. Обновление не должно запускать SSH или серверные операции.

Опубликованный release ZIP и его SHA256 проверяются отдельно после загрузки с GitHub. Юнит-тесты не подтверждают доступность GitHub у каждого пользователя или работу CDN на его сети.

Подготовка выпуска с автообновлением

Зафиксируйте проверенные изменения и версию в Git. Выполните python tools/build_release.py --output /path/to/release-assets с новой пустой папкой назначения. Сборщик читает только Git HEAD: незакоммиченные файлы, локальные конфиги и .venv в архив не попадают. Версия пакета должна совпадать с pyproject.toml.

В GitHub Release с тегом vX.Y.Z загрузите оба файла: cdn-xhttp-setup-vX.Y.Z.zip и cdn-xhttp-setup-vX.Y.Z.zip.sha256. Манифест уже находится внутри ZIP. Публикуйте стабильный релиз после загрузки обоих assets; автоматический Source code ZIP сам по себе не подходит для механизма обновления. После публикации скачайте assets обратно, проверьте SHA256 и принятие архива download_release() из cdn_xhttp.updates.