Приложение после сворачивания выгружено ОС, а при возврате запускается заново. Какой механизм должен проверить тестировщик, чтобы отличить восстановление состояния от обычного нового запуска?
Тестировщик должен проверить механизм восстановления состояния после уничтожения процесса, а не только повторное открытие приложения. Корректный результат означает, что приложение восстанавливает необходимое состояние интерфейса и пользовательского сценария, не выдавая повторный запуск за продолжение работы.
Мобильные ОС ограничивают фоновые процессы из-за дефицита памяти, заряда батареи и необходимости быстро переключаться между приложениями. Поэтому приложение может перейти в фон, быть приостановлено, а затем завершиться без обычного сценария закрытия пользователем.
Механизмы сохранения и восстановления состояния появились для того, чтобы пользователь мог продолжить прерванный сценарий после пересоздания экрана или процесса. Они дополняют, но не заменяют постоянное хранение бизнес-данных.
Если тестировать только сворачивание и возврат в приложение, можно пропустить потерю состояния после уничтожения процесса. Такой дефект проявится, например, при возврате к форме заказа, незавершённой загрузке или экрану с фильтрами.
Важно различать состояние интерфейса, бизнес-данные и временные данные. Потеря временного кэша может быть допустимой, а потеря введённых пользователем данных или повторное создание заказа — критичной.
Проверка должна включать сценарий, в котором приложение уходит в фон, процесс принудительно завершается средствами ОС или тестового окружения, а затем приложение открывается снова. После запуска нужно сравнить фактическое состояние с ожидаемым: текущий экран, введённые значения, позицию в сценарии, авторизацию и незавершённые операции.
На Android пересоздание активности и уничтожение процесса — разные ситуации. Объект, живущий только в памяти экрана или процесса, не является надёжным способом восстановления после завершения процесса. Для временного состояния применяются механизмы сохранения состояния, а для важных данных — постоянное хранилище с учётом согласованности.
На iOS аналогично нужно учитывать различие между переходами жизненного цикла приложения или сцены и фактическим завершением процесса. Система может не предоставить приложению возможность выполнить финальное сохранение перед принудительным завершением, поэтому критичные данные следует сохранять заранее, а не рассчитывать на последний callback.
Тестировщик должен проверить не только наличие данных, но и корректность перехода состояния. Например, экран оплаты не должен показывать старую форму как подтверждённую, если результат операции неизвестен. При неоднозначном результате приложение должно безопасно синхронизироваться с сервером или явно сообщить пользователю о необходимости повторной проверки.
Полное восстановление всего состояния не всегда правильно. Секреты, устаревшие данные, временные разрешения и активные сетевые операции могут требовать повторной проверки или восстановления по отдельным правилам. Компромисс состоит в том, чтобы сохранять минимальный достаточный набор данных и валидировать его после запуска.
В приложении доставки после возврата из фона пользователь снова видел заполненный адрес и товары, но после уничтожения процесса корзина очищалась. Команда рассматривала три варианта: хранить корзину только в памяти, сохранять её локально при каждом изменении или восстанавливать её только с сервера.
Хранение только в памяти было простым, но не выдерживало уничтожения процесса. Запрос к серверу давал актуальные данные, однако зависел от сети и не покрывал изменения, ещё не отправленные серверу. Локальное сохранение при изменении корзины с последующей сверкой с сервером обеспечивало офлайн-устойчивость, но требовало разрешения конфликтов и контроля устаревших данных.
Выбрали локальное сохранение черновика корзины, восстановление после запуска и последующую синхронизацию с сервером. Тесты отдельно проверили обычное сворачивание, уничтожение процесса, отсутствие сети, устаревшую сессию и повторное открытие уже оформленного заказа. В результате исчезла потеря корзины, а повторная отправка заказа была предотвращена проверкой серверного статуса.
Нет. Пересоздание экрана проверяет сохранение состояния компонента, но не показывает, переживут ли данные завершение процесса. Для полноценной проверки нужны оба сценария: пересоздание экрана и восстановление после запуска нового процесса.
Нет. Визуальное совпадение не гарантирует корректность бизнес-состояния. Нужно проверить идентификаторы сущностей, статус операций, срок действия авторизации, актуальность данных и отсутствие побочных эффектов, например повторной оплаты или повторной отправки формы.
Приложение не может гарантировать восстановление данных, которые ещё не были сохранены. Поэтому критичные изменения следует фиксировать в подходящий момент до ухода в фон, а после запуска проверять целостность и версию данных. Если восстановление невозможно, приложение должно безопасно сообщить об этом, а не показывать пользователю предположительно корректное, но устаревшее состояние.