Сравните гарантии выполнения загрузки после сворачивания приложения на iOS и Android: что должен проверить тестировщик?
После сворачивания приложения ни iOS, ни Android не гарантируют продолжение произвольной загрузки в обычном режиме. Тестировщик должен проверить не только факт ухода приложения в фон, но и предусмотренный механизм фоновой работы: возможность завершить операцию, её приостановку, возобновление и корректность результата после возврата.
На iOS выполнение приложения обычно вскоре приостанавливается, если оно не использует разрешённый системой фоновый режим. На Android фоновые ограничения зависят от версии ОС, состояния приложения, энергосбережения и иногда политики производителя устройства, поэтому поведение может быть менее однородным.
Мобильные ОС ограничивают фоновую работу из-за дефицита батареи, памяти и сетевого трафика. Без таких ограничений приложения могли бы постоянно выполнять запросы, удерживать процесс активным и конкурировать за ресурсы даже без участия пользователя.
Поэтому современные платформы разделяют жизненный цикл интерфейса и выполнение фоновых задач. Система сама решает, когда приостановить, завершить или возобновить процесс, а приложению предоставляются только определённые способы заявить о допустимой фоновой работе.
Например, пользователь начинает загрузку файла и сразу блокирует экран. Если тест проверяет только успешный сценарий при открытом приложении, он может пропустить обрыв передачи, потерю прогресса, дублирование файла или ошибочное сообщение об успехе.
Неверно считать, что одинаковый код поведения обеспечит одинаковые гарантии на обеих платформах. На результат влияют версия ОС, режим энергосбережения, тип операции, размер файла, качество сети, блокировка экрана и настройки производителя Android-устройства.
Сначала нужно определить контракт операции: обязана ли загрузка завершиться в фоне, может ли она быть отложена, допустимо ли возобновление с места остановки и что увидит пользователь после возврата. Затем проверяется, использует ли приложение подходящий системный механизм, а не рассчитывает на то, что обычный процесс продолжит выполняться.
На iOS произвольная работа после ухода приложения в фон обычно быстро прекращается или приостанавливается. Для длительных передач следует применять поддерживаемый системой механизм фоновой передачи, а результат обрабатывать с учётом того, что приложение может быть повторно запущено позже.
На Android длительная фоновая работа также не должна зависеть от постоянно живого процесса. В зависимости от задачи применяются системные фоновые задания или явно разрешённый пользователем режим длительной работы; при этом нужно учитывать ограничения фонового запуска, энергосбережение и различия между версиями ОС.
Тестировщик проверяет переходы между состояниями: начало операции, сворачивание, блокировку экрана, принудительное завершение, восстановление сети, смену Wi-Fi на мобильную сеть, возврат в приложение и повторный запуск после остановки процесса. Важно проверять не только интерфейсный прогресс, но и серверный результат, чтобы исключить ложный успех или повторную отправку.
Ключевой компромисс таков: строгие системные ограничения экономят ресурсы, но делают завершение операции менее предсказуемым по времени. Надёжная реализация обычно использует возобновляемую передачу, хранение состояния вне памяти процесса, идемпотентность серверной операции и явное отображение статуса пользователю.
В приложении нужно отправить на сервер видеозапись размером 300 МБ. При открытом приложении передача завершается, но после блокировки экрана на части iOS-устройств файл остаётся незавершённым, а на некоторых Android-устройствах интерфейс показывает старый прогресс после возврата.
Рассматривались три варианта. Оставить обычную передачу в процессе было проще всего, но это не давало надёжных гарантий. Запретить блокировку экрана повышал вероятность успеха, однако ухудшал энергопотребление и пользовательский опыт. Перезапускать загрузку целиком после каждого прерывания было проще серверно, но приводило к лишнему трафику и долгому восстановлению.
Выбрали системно поддерживаемую фоновую передачу с сохранением идентификатора операции, возобновлением по частям и проверкой итогового статуса на сервере. После возврата приложение заново запрашивало состояние передачи, поэтому временное завершение процесса не превращалось в потерю результата или ложный сбой.
В регрессионный набор добавили тесты для блокировки экрана, потери сети, смены типа подключения, нехватки места, принудительного завершения и повторного открытия приложения. Отдельно проверили несколько версий iOS и Android, включая устройство с агрессивным энергосбережением.
1. Достаточно ли проверить, что приложение продолжает работать после сворачивания?
Нет. Сам факт продолжения работы в одном запуске не доказывает наличие гарантии: процесс может оставаться активным из-за свободной памяти, особенностей устройства или короткой длительности теста. Нужно проверить сценарии, в которых система приостанавливает или завершает процесс, а затем убедиться, что операция корректно возобновляется либо явно переходит в состояние, предусмотренное контрактом.
2. Чем отличается приостановка приложения от потери сетевого соединения?
При приостановке приложение может временно не исполнять свой код, хотя сеть сама по себе доступна. При потере соединения процесс продолжает работать, но запросы завершаются ошибкой или зависают до тайм-аута. Эти случаи требуют разных проверок: для приостановки — сохранение и восстановление состояния, для сети — повтор, возобновление передачи и отсутствие дублирования.
3. Можно ли считать успешным завершение загрузки, если пользователь видит 100 процентов?
Нет. Процент обычно отражает локально отправленные данные, но не обязательно подтверждает их полную обработку сервером. Надёжный критерий — подтверждённый сервером результат с устойчивым идентификатором операции; после повторного запуска приложение должно уметь запросить этот результат и не создавать дубликат.