Методология тестирования
Методология тестирования определяет, какие утверждения можно публиковать и на каких условиях. Каждый результат привязан к платформе, версии, профилю, сети, шлюзу, дате, процедуре и ограничениям.
На этой странице
Тест должен отвечать на конкретное утверждение
Перед измерением формулируется проверяемое утверждение: маршрутизируется ли выбранный трафик, остается ли остальной трафик обычным, установлен ли полноустройственный маршрут, работает ли DNS, поддерживается ли нужный протокол или восстанавливается ли соединение после изменения сети. Общий тест скорости не заменяет эти проверки.
- Утверждение.
- Охват.
- Платформа и версия.
- Метод.
- Критерий успешности.
Матрица платформ и профилей
Тесты выполняются отдельно для Android, iPhone и iPad, macOS, Windows и Linux. Для каждой платформы проверяются только заявленные режимы. Профиль сервиса, Custom Profile и All Connectivity имеют разные сценарии, поэтому их результаты нельзя объединять в одну строку.
- Конкретная сборка и устройство.
- Конкретный профиль и версия правил.
- Точный режим маршрутизации.
- Поддерживаемые версии операционной системы.
Проверка охвата
Выборочный тест подтверждает путь совпавшего трафика и обычный путь контрольного трафика вне профиля. Полноустройственный тест подтверждает основные маршруты IPv4 и IPv6, DNS, публичный выход, исключения локальной сети и поведение при прерывании.
- Положительный контроль.
- Отрицательный контроль.
- Наблюдение маршрута.
- Проверка после смены профиля и сети.
Проверка качества и протоколов
Измеряются задержка, джиттер, потери пакетов, пропускная способность, доступность TCP, UDP и QUIC, состояние DNS и емкость шлюза. Для звонков, видео и длительных рабочих соединений используются отдельные сценарии. Результат сравнивается с обычным путем в одинаковых условиях.
- Несколько повторов и понятная выборка.
- Разделение синтетического теста и реальной задачи.
- Фиксация времени, сети и местоположения.
- Никакого обещания постоянного улучшения.
Проверка восстановления
Сценарии включают смену Wi‑Fi и мобильной сети, потерю связи, сон и пробуждение, изменение шлюза, обновление правил и истечение учетных данных. После каждого события 8Tunnel должен удалить устаревшее состояние, восстановить активный профиль и повторить обязательные проверки.
- Время обнаружения изменения.
- Время восстановления.
- Корректная очистка старых правил.
- Отсутствие ложного положительного статуса.
Как публикуется результат
Публичная таблица содержит дату, платформу, версию, профиль, сеть, регион, шлюз или его класс, размер выборки, показатели, метод, ограничения и ответственного проверяющего. Неудачные и неподтвержденные результаты не удаляются из объяснения только потому, что они ухудшают маркетинговую картину.
- Факты отдельно от выводов.
- Отсутствующие данные отмечены явно.
- Изменения методики записываются в журнал.
- Устаревшие результаты снимаются или помечаются.
Чего эта методология не доказывает
Тест в одной сети не доказывает результат во всех странах, у всех провайдеров и для всех сервисов. Измененный публичный выход не доказывает абсолютную анонимность. Пройденная функциональная проверка не заменяет независимый аудит безопасности или юридическое заключение.
- Нет универсальной гарантии скорости.
- Нет гарантии доступа к стороннему сервису.
- Нет обещания полной анонимности.
- Нет аудита без опубликованного отчета.
Частые вопросы
Почему нужны отрицательные контрольные проверки?
Чтобы подтвердить границу охвата: в выборочном режиме трафик вне профиля должен сохранять обычный путь.
Можно ли сравнивать результаты разных платформ?
Только с четким указанием различий механизма, сборки и условий. Одинаковое название профиля не делает реализацию одинаковой.
Как часто нужно повторять тесты?
После каждого существенного релиза, изменения правил, платформы, шлюзов или методики, а также по установленному графику для изменяемых показателей.
Связанные страницы
Продолжите с проверяемого места
Модель охвата, ограничения и методология проверок описаны рядом с продуктовыми обещаниями — начните с них.
