Реферальные программы — среди самых насыщенных письмами потоков, какие продукты выпускают: шеринг генерирует код, приглашённый получает письмо, регистрация создаёт атрибуцию, и в итоге два человека получают письма с наградами. Каждый шаг — отдельная поверхность отказа, и поток по своей природе мульти-ящиковый: один полный тест требует как минимум пригласившего и приглашённого. Это ровно то, где сияют одноразовые ящики: свежие адреса на прогон, запрограммированное извлечение кодов и ни один личный ящик коллег не заполняется тестовыми приглашениями.
Анатомия реферального потока, достойного тестирования
Прежде чем что-то автоматизировать, выпишите события, которые эмитит ваш продукт, и что каждое должно содержать:
- Генерация кода: уникальный для пригласившего, иногда на канал, с ограничениями формата вроде длины, алфавита и чувствительности к регистру.
- Письмо-шеринг: содержит код, персонализированную ссылку с идентификатором клика или и то и другое.
- Регистрация с применённым кодом: приглашённый переходит по ссылке или вводит код вручную — два разных пути кода.
- Атрибуция: бэкенд записывает связь приглашённого с пригласившим, обычно с окном атрибуции и правилами разрешения конфликтов.
- Письма с наградами: обычно два, по одному каждой стороне, отправляются, когда приглашённый выполняет квалифицирующее действие — а не при регистрации.
Большинство реферальных багов живёт в швах: код в письме не совпадает со сгенерированным, идентификатор ссылки срезается редиректом, награды срабатывают при регистрации вместо квалификации, или два шаблона наград путаются местами.
Мульти-ящиковый workflow тестирования
1. Подготовьте ящик A и зарегистрируйте пригласившего. [Создайте временный ящик](/) или подготавливайте аккаунты через API, как описано в статье временная почта для QA-тест-аккаунтов. 2. Запустите шеринг. Используйте путь «пригласить по email» с адресом ящика B как получателем. Проверьте, что письмо пришло, и извлеките код и ссылку — OTP-парсер вытаскивает коды из тел писем без регэкспов под каждый шаблон. 3. Подготовьте ящик B как действительно отдельный ящик. Детект самоприглашения — одна из тестируемых вещей; убедитесь, что ваш тест ловит его намеренно, а не случайно из-за алиасинга. 4. Завершите регистрацию приглашённого по ссылке из письма. Ссылка — носитель атрибуции; ручной ввод кода прогоняет другой путь. Проверяйте атрибуцию на сервере — в базе или админ-API, а не только по бейджу в UI. 5. Проверьте письма с наградами обеим сторонам. После квалифицирующего действия ящик A и ящик B должны каждый получить своё письмо. Проверяйте имена, суммы и ссылки по отдельности; перепутанные шаблоны — классический баг. 6. Прогоните негативные пути: истёкший код, код, использованный сверх лимита, самоприглашение, приглашённый из существующих клиентов, истечение окна атрибуции. Каждый должен давать ясное сообщение, а не тишину. 7. Повторите один раз с вручную введённым кодом, чтобы покрыть путь без ссылки.
Шаги с первого по пятый чисто скриптуются для CI, а песочница API — быстрый способ спрототипировать хореографию двух ящиков до того, как она станет набором тестов.
Атрибуция ссылок: где рефералки тихо ломаются
Ссылка из письма — хрупкая часть:
- Цепочки редиректов — письмо на трекинг-домен на приложение — могут терять query-параметры на любом прыжке. Захватывайте финальный URL посадки в тесте и проверяйте, что идентификатор клика пережил путь.
- Первый клик против последнего: когда приглашённый кликает две разные реферальные ссылки, ваше правило конфликта решает, кто получит награду. Тестируйте случай двойного клика явно; почти никто этого не делает.
- Кросс-девайсная реальность: клик на телефоне, регистрация на ноутбуке. Многие программы теряют атрибуцию здесь по дизайну; проверяйте, что задокументированное поведение совпадает с реализацией.
- Нормализация кода: регистр, пробелы и путаница нуля с буквой O. Код, который работает вставленным, но не набранным, — генератор тикетов в поддержку.
Ловушки анти-фрода
Реферальные программы агрессивно патрулируются от фрода, и тестовый цикл может выглядеть в точности как злоупотребление:
- Всплессы с одного IP: десятки регистраций с одного CI-раннера за минуты напоминают фрод-ферму. Изолируйте тестовый трафик в staging или добейтесь включения тестовых аккаунтов и IP-диапазонов в белый список.
- Блок-листы доменов одноразовой почты: реферальные потоки часто блокируют одноразовые домены именно из-за реферального абьюза. Ваш инструмент тестирования может быть заблокирован функцией, которую вы тестируете, — ждите этого и читайте это как данные о поведении собственного блок-листа, а не как загадочный сбой.
- Правила скорости: быстрые циклы генерация-шеринг-регистрация на аккаунт включают проверки velocity. Разносите автоматические прогоны или помечайте аккаунты как тестовые там, где система это поддерживает.
- Лимиты наград: лимит пригласившего может молча перестать начислять награды после заданного числа приглашённых, что выглядит как «письма перестали отправляться». Проверяйте счётчики, прежде чем винить почтовый конвейер.
Режим отказа, которого стоит избегать: набор тестов получает теневой флаг, рефералки перестают работать для его аккаунтов, и вы начинаете заводить почтовые баги, которые на самом деле — вердикты антифрод-системы.
Частые вопросы
Сколько ящиков нужно реферальному тесту? Минимум два: пригласивший и приглашённый. Добавьте третий при тестировании конфликтов атрибуции — два пригласивших борются за одного приглашённого — и используйте свежие пары на каждый прогон, чтобы прошлое состояние не протекало между тестами.
Как автоматически извлекать реферальные коды? Забирайте новейшее письмо из каждого ящика и парсьте код из тела выделенным парсером. Проверки наличия и формата кода куда стабильнее проверок окружающего текста, который постоянно меняется.
Должны ли реферальные тесты гоняться в CI на каждый коммит? Счастливый путь — да: с ящиками, подготавливаемыми через API, это дёшево. Держите сценарии, соседствующие с фродом, — velocity и лимиты — за флагом или в ночном окружении, где намеренно странный трафик безопасен.
Как отличить почтовый баг от вердикта анти-фрода? Сначала трассируйте отправку на сервере. Если ваша система не ставила письмо в очередь, причина обычно — правило: лимит, блок-лист, проверка velocity, — а не почтовый конвейер. Логи в точке решения каждый раз бьют угадывание со стороны ящика.
Итог
Реферальные потоки умножают поверхности почтового тестирования: две стороны, несколько писем, ссылки, несущие атрибуцию, и антифрод-системы, следящие за всем. Одноразовые ящики делают мульти-стороннюю постановку тривиальной: свежие пары на прогон, коды, распарсенные программно, атрибуция, проверенная на сервере. Тестируйте негативные пути так же строго, как счастливый; в реферальных системах именно несчастливые пути — это то место, где утекают деньги.