Appium — платформа автоматизации приложений через драйверы, которые знают конкретное окружение. Для мобильного QA это способ управлять нативными экранами, webview и мобильным браузером подходящими средствами. Возможности определяются установленным драйвером, устройством и приложением, а не одним названием Appium.
Мобильная автоматизация особенно чувствительна к окружению. Сборка приложения, версия ОС, клавиатура, разрешения и состояние устройства влияют на сценарий. Поэтому установка сервера является лишь началом: надёжный набор требует управляемой конфигурации и понятных диагностических данных.
Сервер, драйвер и клиент
Клиентская библиотека на выбранном языке создаёт сессию и отправляет команды серверу Appium. Драйвер преобразует их в действия конкретной платформы. Для Android распространён UiAutomator2, для iOS — XCUITest; их требования и возможности проверяют отдельно.
Сервер и драйверы устанавливаются и обновляются независимо. Документация современного Appium содержит переход на Appium 3, поэтому старые инструкции и capabilities нельзя переносить автоматически. Зафиксируйте совместимый набор server, driver, client, SDK и OS в описании тестового окружения.
Подготовка Android-окружения
Для учебного старта нужны совместимые Node и npm, Android SDK, подходящий JDK, подготовленный эмулятор или разрешённое устройство. До подключения Appium убедитесь, что adb видит ровно нужную цель. Устройство с недоступным экраном или отсутствующим разрешением отладки не исправляется настройкой локатора.
После проверки требований установите сервер и драйвер. Команды ниже относятся к подготовке локального учебного окружения; конкретные версии согласуйте по документации и закрепите в рабочем проекте. Запуск сервера в последней строке занимает отдельный терминал.
npm install -g appium
appium driver install uiautomator2
appium driver doctor uiautomator2
adb devices
appium --address 127.0.0.1 --port 4723Ожидается установленный драйвер, отчёт проверки зависимостей и сервер на локальном адресе. Если doctor сообщает проблему, сначала исправляют окружение. Успех этих команд ещё не означает, что APK запускается или что у тестового пользователя есть нужные данные.
Что передать в capabilities
При создании Android-сессии указывают platformName Android, automationName UiAutomator2 и конкретную цель через udid. Для установки используют путь к собственной тестовой APK либо настраивают запуск уже установленного приложения через параметры драйвера. Appium-специфичные capabilities используют пространство имён appium:.
Не копируйте один большой набор параметров из чужого проекта. Некоторые значения относятся к конкретному драйверу, другие меняют очистку состояния или запуск приложения. У каждого параметра должна быть причина и проверенный эффект. Особенно осторожно выбирают стратегию reset: она влияет на данные и независимость сценариев.
Практический сценарий: редактирование профиля
Возьмите собственную debug-сборку приложения с экраном профиля и тестовым API. Подготовьте пользователя Анну и известное сохранённое имя. Для поля и кнопки заранее согласуйте устойчивые идентификаторы, доступные в дереве автоматизации. Сессия должна запускать именно эту сборку на выбранном эмуляторе.
Откройте профиль, очистите имя, введите пробелы и отправьте форму. Ожидайте предусмотренную ошибку, отсутствие успешной записи и доступность исправления поля. Затем в отдельном сценарии введите Мария, сохраните и откройте профиль повторно. Ожидается сохранённое значение, подтверждённое чтением сервера или UI по цели проверки.
Дополнительно откройте клавиатуру на небольшом экране и убедитесь, что кнопка остаётся достижимой. Этот риск не проверяется одним API-тестом. Но десятки вариантов серверной валидации удобнее оставить на сервисном уровне, сохранив в Appium несколько важных пользовательских примеров.
Как выбирать элементы
Accessibility id и resource id часто дают более устойчивую основу, чем координаты и длинный XPath. Конкретный способ зависит от платформы и UI-технологии. Инспектор помогает увидеть, какие свойства действительно доступны, но хорошая стратегия начинается с договорённости с разработчиками.
Координаты привязаны к размеру экрана, масштабу, ориентации и состоянию клавиатуры. Используйте их только для обоснованных задач, где семантический элемент недоступен, и фиксируйте ограничения. Привычка нажимать «примерно сюда» делает набор дорогим при любом визуальном изменении.
Ожидания и переходы состояний
Ждите конкретный экран, доступность элемента или результат операции. Пауза после каждого действия одновременно замедляет тест и не гарантирует готовность на занятом устройстве. Не смешивайте проблему анимации с задержкой backend: для них нужны разные наблюдения.
После перехода в фон, системного разрешения или возврата из внешнего приложения заново подтвердите контекст. Отказ может возникнуть потому, что активен системный экран, а не ваше приложение. Полезно сохранять screenshot и hierarchy в момент первого нарушения.
Native и webview
Гибридное приложение может содержать нативные элементы и webview. Для работы с webview часто требуется отдельный контекст и соответствующая поддержка отладки в тестовой сборке. Список контекстов проверяют фактически, а не предполагают наличие webview по внешнему виду экрана.
Не переносите web-локаторы на нативную область и наоборот. При переключении нужно понимать, какая часть интерфейса проверяется, какие данные уже подготовлены и какой драйверный механизм доступен. Поддержка зависит от версии платформы и сборки, поэтому сначала делают небольшой технический эксперимент.
Отчёт и независимость устройства
Сохраняйте модель или конфигурацию эмулятора, OS, версию приложения, драйвер, capabilities без секретов и Appium-лог. Для Android полезен контекст logcat, для iOS — подходящие системные и инструментальные логи. Скриншот без этих данных часто показывает только симптом.
При параллельном запуске каждому процессу нужны собственная цель, данные и необходимые порты драйвера. Очистка приложения и завершение сессии должны выполняться предсказуемо. Общий физический телефон нельзя одновременно отдать двум независимым сценариям без координации.
Ошибки и рабочие выводы
Частые ошибки: нефиксированные версии, неявный выбор устройства, общий пользователь, необоснованный noReset и попытка лечить любые падения повторной установкой APK. Успех на одном эмуляторе не означает совместимость со всей матрицей устройств.
Appium полезен для важных мобильных взаимодействий, когда команда управляет сборкой и окружением. Сначала добейтесь одной воспроизводимой цепочки с хорошей диагностикой, затем расширяйте матрицу по рискам. Большое количество нестабильных сценариев не компенсирует отсутствие контроля условий.