Сетевые проблемы в мобильном приложении редко ограничиваются полным отсутствием интернета. Телефон может видеть Wi-Fi без доступа к серверу, переключаться между сетями, получать ответ с большой задержкой или потерять соединение после отправки данных. Поэтому хороший offline testing проверяет и недоступность сети, и переходы между состояниями.
Главный вопрос для QA — что пользователь знает о результате своей операции. Если приложение не получило ответ, это ещё не означает, что сервер не выполнил действие. Особенно опасна такая неопределённость при заказах, переводах и отправке сообщений.
Сначала определи возможности offline
Не каждое приложение должно полностью работать без сети. Зафиксируй, что можно читать из кэша, какие изменения разрешены локально, что ставится в очередь и какие функции требуют соединения. Отдельно опиши, насколько устаревшие данные допустимы.
Подход offline-first предполагает доступность ключевой части функций без интернета и продуманную работу локального источника данных. Но наличие одного кэшированного экрана ещё не делает весь продукт offline-first.
Какие сетевые состояния различать
Полезная матрица строится вокруг причин и момента сбоя. Нулевой сигнал, медленный ответ и ошибка API требуют разной обработки, даже если пользователь видит одинаковый индикатор загрузки.
- →Нет активного соединения до запуска приложения.
- →Соединение есть, но целевой сервер недоступен.
- →Запрос отправлен, ответ потерян или сильно задержан.
- →Wi-Fi сменился мобильной сетью в середине операции.
- →Сервер вернул ошибку или некорректные данные при исправной сети.
Режим полёта удобен, но его реальное состояние нужно проверять: Wi-Fi может быть включён отдельно. Значок сети также не подтверждает доступность конкретного API.
Как подготовить эксперимент
Выбери один сценарий и определи наблюдаемые точки: нажатие, отправка запроса, серверная запись, получение ответа, обновление экрана. Сохрани идентификаторы операции и начальное состояние данных.
Для повторяемых проверок используй управляемые задержки и ошибки на тестовом окружении, proxy или сетевые средства лаборатории. Ограничение скорости через HTTP-proxy моделирует часть условий, но не воспроизводит радиосеть, переключение базовых станций или все виды потери пакетов.
Практический пример: отправка сообщения
Представь чат, который сохраняет исходящие сообщения локально и отправляет после восстановления соединения. Ожидание — одно сообщение с понятным статусом, даже если сеть пропала в неудобный момент.
- 1.Открой разговор online и зафиксируй последнее сообщение на сервере.
- 2.Отключи доступ к сети, напиши новый текст и нажми отправку. Ожидается локальное сообщение со статусом ожидания, если такой режим поддерживается.
- 3.Перезапусти приложение в offline. Текст должен сохраниться вместе с корректным статусом.
- 4.Восстанови соединение. Проверь отправку, смену статуса и появление одного сообщения у получателя.
- 5.Повтори опыт, оборвав соединение после принятия сообщения сервером, но до получения ответа клиентом.
- 6.Выполни повторную попытку. Сверь сервер: повтор не должен создавать дубликат того же логического сообщения при предусмотренной защите от дублей.
Если такой защиты нет в требованиях, зафиксируй риск и согласуй ожидаемую модель. Само добавление кнопки «повторить» не решает неопределённый результат операции.
Состояния интерфейса
Проверь различие между загрузкой, отсутствием данных, устаревшим кэшем и сетевой ошибкой. Пустой экран после таймаута не должен убеждать пользователя, что его сохранённых объектов больше нет.
Ручная повторная попытка должна быть доступной и не запускать параллельные одинаковые запросы без ограничений. При восстановлении сети приложение не должно бесконечно дёргать экран, сбрасывать введённый текст или повторять устаревшие сообщения об ошибке.
Очередь и повторные попытки
Для очереди важны сохранность после перезапуска, порядок там, где он нужен бизнесу, ограничение повторов и корректная обработка постоянных ошибок. Повторять временный сетевой сбой и отказ в доступе одним бесконечным алгоритмом опасно.
Проверь очередь после выхода из аккаунта и входа под другим пользователем. Локальные изменения прежнего аккаунта не должны отправиться от имени нового. Если сессия истекла, приложение обязано восстановить доступ предусмотренным способом и сохранить допустимый контекст.
Конфликты и актуальность данных
Два устройства могут изменить один объект независимо. Подготовь конфликт: первое редактирует offline, второе сохраняет online, затем первое подключается. Ожидаемый результат определяется политикой продукта — объединение, выбор версии или сообщение о конфликте.
Не считай последнюю видимую запись автоматически правильной. Сверяй серверную версию, локальный результат и объяснение для пользователя. Для важных данных молчаливое перезаписывание может быть существенным дефектом даже при технически успешном запросе.
Что дополнить в регрессии
Добавь первый запуск без кэша, большой объём очереди, недостаток места, длительный offline и истёкшую сессию. Проверь повторный запуск после завершения процесса и переход в фон во время синхронизации.
Отдельно оцени расход батареи и трафика: частые неудачные повторы способны превратить небольшую сетевую проблему в постоянную нагрузку. Конкретные интервалы и ограничения берутся из архитектуры продукта, а не из универсального числа.
Типичные ошибки и вывод
Самая частая ошибка — выключить сеть на главном экране, увидеть баннер и завершить проверку. Основные риски находятся на границах операций: потеря результата, дубли, утрата черновика и конфликт версий.
В отчёте указывай точку обрыва, реальные сетевые условия, состояние кэша, идентификатор операции и результат на сервере. Сильный offline-тест доказывает сохранность данных и предсказуемость восстановления, а не только наличие сообщения «нет интернета».