Какими кейсами проверял установку мобильного приложения

Стратегия тестирования установки мобильного приложения

Тестирование установки — это критически важный этап, который проверяет первый контакт пользователя с продуктом. Я подхожу к нему комплексно, рассматривая не только базовый сценарий «скачал-установил-запустил», но и множество граничных условий и негативных сценариев. Моя стратегия строится на нескольких ключевых блоках.

Основные категории тест-кейсов

1. Позитивные сценарии установки

• Первичная установка на чистую систему: Санарий «счастливого пути» с проверкой корректности конечного состояния.
• Установка из различных источников:

    *   Официальные магазины (**Google Play** для Android, **App Store** для iOS).
    *   Сторонние магазины (Huawei AppGallery, Samsung Galaxy Store, APK-файл для Android).
    *   Установка через **adb** (Android Debug Bridge) для разработки и тестирования.

• Установка на разные версии ОС: Поддержка всех заявленных в требованиях версий iOS и Android.
• Установка на устройства с разной архитектурой и разрешением экрана.

2. Негативные сценарии и обработка ошибок

Это самая обширная и важная часть. Я проверяю устойчивость инсталлятора к неидеальным условиям.

• Недостаточно места на устройстве: Приложение должно корректно обработать ошибку, вывести понятное сообщение и не «зависнуть».
• Прерывание установки:

    *   Отмена установки пользователем.
    *   Потеря соединения с сетью во время загрузки.
    *   Переход устройства в **режим «в самолете»**.
    *   Вызов инкоминг-звонка или SMS.
    *   Резкое отключение питания (симуляция для Android через `adb shell`).

• Попытка установки несовместимой версии: Например, APK-файл, собранный для более новой версии Android, чем на устройстве.
• Установка приложения с уже существующим таким же Package Name/Bundle ID (для случая side-loading).

3. Сценарии обновления (Upgrade)

Обновление — это особая операция, часто более критичная, чем чистая установка.

• Обновление с предыдущей версии до текущей: Проверка сохранения пользовательских данных (логин, настройки, кэш), целостности БД после миграции.
• Даунгрейд (откат на более старую версию): Часто требует полного удаления приложения. Проверяю сообщение об ошибке и процесс.
• Обновление при активном сеансе пользователя: Что происходит, если обновление найдено, когда приложение открыто и в нем есть несохраненные данные?
• Пропуск версий: Обновление не с ближайшей, а с сильно устаревшей версии. Проверка всех промежуточных миграций данных.

4. Проверка требований безопасности и разрешений (Permissions)

• Установка и проверка манифеста: Соответствуют ли запрашиваемые разрешения заявленным в описании в магазине?
• Runtime-разрешения (Android 6.0+/iOS): Проверяю, что запрос на опасные разрешения происходит не при установке, а в момент первого использования соответствующей функции.
• Установка подписанного/неподписанного пакета (Android): Неподписанный APK не должен устанавливаться на production-устройствах.

5. Освобождение ресурсов и корректное удаление (Uninstall)

• Полное удаление приложения: Все файлы приложения, данные в /data/data/ (Android) и Library (iOS), настройки должны быть удалены. Проверяю с помощью файловых менеджеров и adb.
• Повторная установка после удаления: Должна проходить как первичная, без «призраков» от прошлой установки.

Пример автоматизации базового сценария

Для регрессионного тестирования я часто автоматизирую базовые сценарии установки/удаления с помощью Appium или прямых команд adb.

import subprocess
import pytest
import time

def test_fresh_install_and_launch():
    """Тест чистой установки и первого запуска."""
    app_path = "/path/to/app.apk"
    app_package = "com.example.myapp"
    app_activity = ".MainActivity"

    # 1. Предварительное удаление, если установлено
    subprocess.run(f"adb uninstall {app_package}", shell=True, capture_output=True)

    # 2. Установка приложения
    install_result = subprocess.run(f"adb install {app_path}", shell=True, capture_output=True, text=True)
    assert "Success" in install_result.stdout, f"Установка провалилась: {install_result.stdout}"

    # 3. Запуск приложения
    subprocess.run(f"adb shell am start -n {app_package}/{app_activity}", shell=True)

    # 4. Небольшая пауза для запуска и проверка, что процесс жив
    time.sleep(3)
    ps_result = subprocess.run(f"adb shell ps | grep {app_package}", shell=True, capture_output=True, text=True)
    assert app_package in ps_result.stdout, "Процесс приложения не запущен после установки."

    # 5. (Опционально) Проверка наличия ключевого элемента на стартовом экране через Appium
    # ... код взаимодействия с UI ...

    # 6. Корректное удаление
    uninstall_result = subprocess.run(f"adb uninstall {app_package}", shell=True, capture_output=True, text=True)
    assert "Success" in uninstall_result.stdout, f"Удаление провалилось: {uninstall_result.stdout}"

Ключевые инструменты и подходы

• ADB (Android Debug Bridge): Незаменим для установки, удаления, симуляции прерываний, просмотра логов (logcat).
• Xcode (для iOS): Установка через Xcode на симуляторы и реальные устройства, просмотр консоли.
• TestFlight / Внутренние треки Google Play: Тестирование процесса распространения, как это увидит конечный пользователь.
• Эмуляторы и симуляторы: Для покрытия матрицы устройств и ОС.
• Реальные устройства: Обязательно для проверки прерываний (звонки, SMS) и работы с аппаратной частью.

Итогом является чек-лист из 50+ сценариев, который проходит каждое приложение перед релизом. Это позволяет минимизировать риск «поломки на старте» и обеспечить положительный первый опыт пользователя.