Как протестировать SMS-интеграцию без платных отправок

Подключите приложение к эмулятору SMS-шлюза и закройте тестовой среде доступ к реальной отправке. Так можно проверить очередь сообщений, обработку ошибок и статусы доставки без платных SMS. Эмулятор принимает запросы вместо поставщика и отвечает по вашему сценарию: подтверждает приём, задерживает ответ или разрывает соединение. Ниже разберём, как подготовить такую проверку для API и SMPP, какие сбои воспроизвести и по каким признакам понять, что приложение готово к следующему этапу.

Что можно проверить без отправки SMS на телефон?

Эмулятор SMS-шлюза — это тестовая программа, которая воспроизводит нужную часть поведения поставщика. Для HTTP API она принимает запросы приложения и возвращает ответы. Для SMPP поддерживает тестовое соединение и обменивается сообщениями по протоколу. Полностью копировать инфраструктуру поставщика для этого не требуется: начните с операций, которые использует ваше приложение.

Например, интернет-магазину нужно проверить уведомление о готовности заказа. После смены статуса приложение создаёт задание, передаёт его шлюзу и получает результат. Эмулятор позволяет пройти эту цепочку без выхода в сеть оператора. При этом подтверждение приёма сообщения шлюзом и подтверждение доставки должны оставаться разными событиями.

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

Если способ подключения ещё не выбран, сначала сопоставьте задачи приложения с особенностями SMPP и HTTP API для небольшой SMS-интеграции. Эмулятор должен поддерживать именно тот интерфейс, через который будет работать приложение.

Как подготовить изолированную тестовую среду?

Начните с границы между тестом и реальной отправкой. Одной замены адреса шлюза недостаточно, если приложение умеет автоматически переключаться на резервного поставщика. Проверьте весь путь сообщения: основной канал, запасной маршрут и фоновые задачи.

1. Создайте отдельную конфигурацию приложения. Укажите адрес эмулятора и тестовые учётные данные, которые не подходят к рабочему шлюзу.
2. Запретите тестовой среде соединяться с рабочими SMS-шлюзами. Ограничение на уровне сети защитит от случайной подмены адреса в настройках.
3. Подключите отдельную очередь для тестовых заданий. Рабочие процессы не должны забирать из неё сообщения, а тестовые процессы — читать рабочую очередь.
4. Настройте журнал проверки. Для каждой операции фиксируйте её идентификатор, попытки отправки, ответы эмулятора и изменения статуса.

Для HTTP API сверьте с документацией поставщика структуру запроса, способ авторизации и формат ошибок. Если приложение получает статусы через вебхуки, эмулятор должен отправлять такие уведомления в тестовый обработчик. Для SMPP проверьте установку сессии, подтверждение приёма сообщения и получение отчёта о доставке.

Сначала запустите успешный сценарий. Приложение создаёт задание, эмулятор принимает сообщение, затем присылает статус доставки. Проверка пройдена, если в журнале видна вся цепочка, а приложение связывает отчёт именно с исходным сообщением.

Какие сценарии сбоев нужно воспроизвести?

Задавайте сбои явно, чтобы разработчик мог повторить их после исправления. Случайные задержки полезны на следующем этапе, но для первого разбора лучше сценарий с понятной последовательностью событий. В задании на тест запишите действие эмулятора и ожидаемую реакцию приложения.

• Шлюз принял сообщение, но ответ не дошёл. Эмулятор фиксирует приём и закрывает соединение. Приложение должно сохранить неопределённый результат и применить согласованное с поставщиком правило проверки или повтора.
• Шлюз временно отклоняет запрос. Эмулятор сообщает о перегрузке или ограничении скорости. Приложение оставляет задание в очереди и повторяет попытку с паузой.
• Шлюз возвращает постоянную ошибку. Например, запрос не соответствует ожидаемому формату. Приложение прекращает автоматические повторы и показывает причину отказа.
• Отчёт о доставке приходит повторно или с задержкой. Повторный отчёт не должен создавать новую отправку, а позднее промежуточное событие не должно стирать итоговый статус.
• SMPP-соединение обрывается при непустой очереди. После восстановления приложение возобновляет работу в пределах лимитов подключения, без одновременной отправки всей очереди.

Особое внимание уделите таймауту после приёма сообщения. Приложение не знает, успел ли шлюз принять запрос, поэтому простой повтор способен создать дубль. Этот случай разобран в материале о мониторинге SMS-интеграции (smpp.by, «Как настроить мониторинг SMS-интеграции в 2026 году»). В тесте эмулятор должен различать попытку обращения и саму операцию отправки.

Защиту от дублей проверяйте по договорённостям конкретного API. Если поставщик поддерживает ключ идемпотентности, то есть идентификатор для распознавания повторного запроса, воспроизведите его правила в эмуляторе. Сам по себе одинаковый идентификатор в журнале приложения ещё не гарантирует, что внешний шлюз остановит повторную отправку.

Как понять, что интеграция прошла проверку?

Смотрите на результат всей операции, а не только на ответ шлюза. Для каждого сценария заранее определите ожидаемое состояние задания: оно завершено, ждёт повтора, отклонено или требует проверки. Затем сравните ожидание с журналом. Если разработчик не может объяснить, почему сообщение осталось в очереди, тест ещё не даёт достаточной уверенности.

Проверьте перезапуск приложения между отправкой и записью результата. После запуска оно должно восстановить состояние из доступных записей и применить правила повтора. Перезапуск не должен автоматически превращать все незавершённые операции в новые сообщения.

Для SMS-кодов отдельно воспроизведите задержку очереди до истечения срока действия кода. Устаревшее сообщение нужно обработать по правилам приложения, чтобы очередь не отправляла пользователю уже бесполезный код. Этот сценарий связан с обработкой истечения срока действия OTP-кода в SMS API: срок жизни кода и срок ожидания отправки должны согласовываться.

Попросите разработчика сохранить сценарии и результаты так, чтобы их можно было повторить после обновления приложения. В отчёте достаточно указать условие сбоя, ожидаемое поведение и фактический результат. Для неудачной проверки приложите идентификатор операции и последовательность событий из журнала.

При подключении SMPP-шлюза или настройке API такой набор сценариев можно включить в критерии приёмки интеграции. Аналитику трафика тоже стоит проверить на эмуляторе: отдельно считать попытки обращения, принятые сообщения и отчёты о доставке. Иначе повторные запросы будут выглядеть как новые SMS.

Типичные ошибки при тестировании SMS-интеграции

• Проверяют только успешный ответ. Добавьте таймаут после приёма сообщения: он покажет, как приложение действует при неопределённом результате.
• Оставляют рабочий резервный маршрут. Отключите его в тестовой конфигурации и закройте сетевой доступ к реальным шлюзам.
• Считают приём сообщения доставкой. Разделите эти события в логике приложения и в отчёте проверки.
• Эмулятор отвечает так, как удобно приложению. Сверьте его поведение с документацией поставщика, включая ошибки и правила повторов.
• Ожидают, что бесплатный тест подтвердит доставку абоненту. Зафиксируйте границу проверки: эмулятор проверяет поведение приложения, а реальный маршрут требует отдельного испытания.

Следующий шаг на ближайшие две минуты: добавьте в задачу разработчику сценарий «шлюз принял SMS, но приложение не получило ответ» и укажите ожидаемый результат — приложение сохраняет неопределённый статус и не делает слепой повтор.