Автоматизация Android-лаборатории: устройства и эмуляторы

Превратите небольшую группу телефонов и эмуляторов Android в воспроизводимую лабораторию устройств с явными состояниями запуска, наблюдаемыми проверками, ограниченными ожиданиями, свидетельствами сбоев и четким правилом сборки или покупки.

Краткий ответ: автоматизируйте рабочий цикл, а не полку.

Лаборатория устройств Android становится полезной, когда каждый запуск начинается с именованного состояния, выполняет одну ограниченную проверку, проверяет постусловие и оставляет доказательства, которые может просмотреть другой человек. Телефоны, USB-концентраторы, подставки и этикетки — это только физический уровень. Автоматизация лаборатории устройств Android — это рабочий уровень, который превращает эти устройства в повторяемые проверки выпуска, поддержки и локализации.

Если вы все еще выбираете телефоны, кабели, питание или хранилище, начните снедорогого руководства по лабораторной установке Android-устройств. Эта статья начинается после того, как это оборудование уже существует. В нем объясняется, как объединить реальные устройства и эмуляторы, определить небольшую тестовую матрицу, создать карту запуска устройства, синхронизировать наблюдаемое состояние, сделать снимки экрана и журналы, а также решить, когда облако размещенных устройств является лучшим выбором.

Целью не является замена модульных тестов, тестов Compose, Espresso, UI Automator, Appium, Gradle Managed Devices или Firebase Test Lab. Эти инструменты имеют разные границы. Инструмент автоматизации AndroidAIнаиболее полезен в качестве видимого уровня рабочего процесса для проверок реальных устройств, который необходимо понимать операторам, специалистам по контролю качества и группам поддержки.

Дайте реальным устройствам и эмуляторам разные задачи

Лаборатория устройств не требует проведения всех тестов на каждом устройстве. Эмуляторы быстро создаются, сбрасываются, параметризуются и выполняются параллельно. Реальные телефоны предоставляют встроенное ПО производителя, физические камеры, Bluetooth, биометрические подсказки, температурное поведение, фоновые ограничения, доставку уведомлений, состояние USB и поверхности ввода, которые виртуальное устройство может не воспроизвести точно. Используйте эти различия, чтобы разделить ответственность, а не отстаивать одну универсальную платформу.

Практический стартовый шаблон — это широкий виртуальный уровень и узкий физический уровень. Выполните быстрые детерминированные проверки виртуальных конфигураций, а затем направьте небольшой критический пакет через два или три реальных телефона, выбранных с учетом реального риска для клиента. Разворачивайте только тогда, когда данные об ошибках показывают, что другая модель, версия Android, языковой стандарт или поведение поставщика меняют результат.

Определите матрицу устройств с одной причиной в каждой строке

Firebase Test Lab описывает матрицу тестирования как комбинацию выбранных устройств и тестовых конфигураций. Эта идея также работает для местной лаборатории, но матрица должна быть основана на оценке рисков, а не исчерпывающей. Каждому ряду нужна причина, владелец и ожидаемое решение. Телефон, который существует только потому, что он был доступен, будет незаметно расходовать время на зарядку, перезагрузку и обслуживание, не повышая уверенности в выпуске.

• Сохраните одну текущую базовую версию Android для основного пути выпуска.
• Сохраните один старый поддерживаемый уровень API для обеспечения совместимости и возможности обновления.
• Добавляйте один реальный телефон конкретного поставщика только в том случае, если его прошивка, разрешения, политика использования батареи или доля клиентов создают явный риск.
• Добавьте конфигурацию с маленьким экраном или большим шрифтом, если макет и доступность имеют значение.
• Добавляйте локаль, тему, ориентацию, сеть или состояние учетной записи только для проверок, результат которых может измениться при этом условии.
• Удалите из обращения строки матрицы, в которых больше не обнаруживаются явные дефекты или которые не поддерживают текущий сегмент клиентов.

Назовите решение, которое поддерживает каждая строка: заблокировать выпуск, собрать доказательства проверки, воспроизвести запрос в службу поддержки или изучить предполагаемый сбой конкретного устройства. Это решение определяет, насколько надежность, изоляция и отчетность необходимы для строки. Блокировщик релизов требует более строгих правил сброса и утверждения, чем контролируемая исследовательская проверка.

Создайте карту выполнения перед написанием автоматизации

Самая маленькая полезная спецификация для лабораторной проверки — это карта выполнения. Это предотвращает сохранение скрытых предположений в памяти одного оператора и дает автоматизации стабильный контракт. Напишите карту в понятных терминах, прежде чем выбирать узлы, селекторы или код платформы.

Не определяйте успех как последовательность нажатий. Определите видимое или структурированное состояние, которое должно существовать после последовательности. Меняются макеты пользовательского интерфейса; постусловия бизнеса более долговечны. Проверка входа в систему завершается успешно, потому что ожидаемое состояние учетной записи и домашняя поверхность присутствуют, а не потому, что автоматизация коснулась координат, где раньше была кнопка.

Сбросить состояние, не стирая доказательства

Общие устройства выходят из строя по причинам, похожим на дефекты приложений: устаревшие учетные записи, кэшированное согласие, ожидающие обновления, измененные разрешения, нехватка памяти, неожиданная клавиатура, открытое системное диалоговое окно, наложение уведомлений или предыдущий запуск, оставшийся на полпути оформления заказа. Сбросьте только состояние, указанное в карте запуска, и зафиксируйте сбой до того, как восстановление изменит его.

1. Определите устройство и выполните сборку, прежде чем прикасаться к состоянию.
2. Сделайте снимок текущего экрана, когда предыдущий запуск неожиданно завершился.
3. Верните приложение в заявленное начальное состояние, используя наименее разрушительный сброс.
4. Подтвердите сеть, время, хранилище, ориентацию, локаль, масштаб шрифта и необходимые разрешения.
5. Проверьте маркер начального состояния перед первым бизнес-действием.
6. Поместите устройство в карантин, если перезагрузка неоднократно завершается сбоем; не превращайте ошибку инфраструктуры в ошибку продукта.

Полная очистка не становится автоматически безопаснее. Это может разрушить точное состояние, необходимое для воспроизведения дефекта, и увеличивает время настройки, что побуждает команды пропускать проверки. Сохраняйте отдельные профили для путей новой установки, обновленной установки, входа в систему, выхода из системы и восстановления учетной записи, если эти состояния несут разные риски.

Синхронизируйте состояние вместо того, чтобы спать дольше

Руководство по тестированию стабильности Android предостерегает от произвольного перехода в режим сна, поскольку производительность устройства и асинхронная работа различаются. Фиксированная задержка может быть как слишком короткой на занятом телефоне, так и неоправданно медленной на быстром. Предпочитайте явное ожидание значимого условия с тайм-аутом и артефактом сбоя, когда это условие никогда не появляется.

• После запуска приложения дождитесь стабилизации элемента пользовательского интерфейса или состояния экрана, а не предполагаемого количества секунд.
• После касания проверьте постусловие перед отправкой следующего ввода.
• Используйте ограниченное повторение для состояний, которые действительно нуждаются в опросе; записать последнее наблюдение по тайм-ауту.
• Считайте диалоговые окна разрешений системы, запросы на обновление и наложения OEM как именованные ветки, а не случайный шум.
• Остановитесь, когда видимое состояние выходит за пределы утвержденного набора, особенно перед оплатой, удалением, согласием или изменением учетной записи.

Текущий контракт LaiCai Flow следует этой видимой модели: наблюдения пользовательского интерфейса, распознавание текста, сопоставление шаблонов и наблюдение за состоянием снимков экрана; узлы ввода и указателя выполняют одну операцию; Узлы потока обрабатывают ожидания, ветвления, ограниченные циклы, дочерние потоки, возвраты и остановки. Разделение наблюдения, принятия решений и действий упрощает анализ рабочего процесса и делает его более безопасным в обслуживании.

Создайте читаемый LaiCai Flow для лабораторных проверок.

LaiCai Flow — это функция автоматизации внутри LaiCai Screen Mirroring. При запуске устройства в лаборатории держите основной поток на том уровне, который может прочитать рецензент контроля качества: подготовьте устройство, откройте целевой объект, выполните критическую проверку, соберите доказательства и завершите. Поместите многоэтапные технические детали в небольшие дочерние потоки вместо того, чтобы раскрывать длинную цепочку совпадений, выборов, касаний и ожиданий. РуководствоLaiCai Flowобъясняет, как организованы профили и потоки.

1. Прочтите контекст подключенного устройства и выберите предполагаемый псевдоним последовательного порта; не думайте, что первое устройство правильное.
2. Прежде чем открывать или изменять приложение, подтвердите пакет и текущее состояние пользовательского интерфейса.
3. Используйте состояние пользовательского интерфейса, когда информация о доступности стабильна, распознавание текста, когда видимый текст является доказательством, и сопоставление шаблонов только для проверенного целевого изображения.
4. Разместите явные ожидания между действиями и последующими наблюдениями, зависящими от экрана.
5. Проверяйте постусловие после каждой фазы, которая меняет состояние экрана или приложения.
6. Делайте снимок экрана или запись только в том случае, если это поддерживает указанное решение по проверке.
7. Вернуть четкий результат фазы; остановить прогон, когда следующее действие не оправдано текущим наблюдением.

Во время подготовки к этому руководству контекст LaiCai, доступный только для чтения, сообщил о 73 доступных типах узлов и одном подключенном телефоне Samsung Android 16. Это подтверждает текущий контракт и путь информирования об устройствах; это не показатель производительности. Прежде чем рассматривать профиль как инфраструктуру выпуска, проверьте свое собственное приложение, устройства, ресурсы и поддержку среды выполнения.

Собирайте пакет сбоя, а не красную точку

Неудачная проверка должна ответить на вопрос, что и где выполнялось, что наблюдала система и почему выполнение остановилось. Firebase Test Lab предоставляет полезную модель, возвращая статус теста вместе с журналами, скриншотами и видео, если они доступны. Локальная лаборатория устройств требует такой же дисциплины, даже если ее хранение проще.

• Идентификатор запуска, отметка времени, версия рабочего процесса, версия сборки и среда.
• Модель устройства, версия Android, стабильный серийный псевдоним, размер экрана, локаль, тема и ориентация.
• Начальное состояние, идентификатор входного прибора и последняя завершенная бизнес-фаза.
• Ожидаемое постусловие и фактически выбранный результат пользовательского интерфейса, оптического распознавания символов, изображения или платформы.
• Снимок экрана перед восстановлением, короткая запись только тогда, когда движение имеет значение, и ограниченный соответствующий отрывок журнала.
• Классификация: дефект продукта, дефект теста, инфраструктура устройства, данные, окружающая среда или требуется проверка человеком.

Используйте стабильные имена файлов и манифест вместо неструктурированной папки со скриншотами. Отредактируйте личные или секретные данные, прежде чем делиться ими. Не загружайте журналы устройства целиком, если достаточно короткого интервала очистки после сбоя. Доказательства должны уменьшать объем работы следующего человека, не создавая при этом новых проблем с конфиденциальностью или сохранением информации.

Выбирайте проверки, которые зарабатывают время, потраченное на устройство.

Минут реального использования устройств мало, поскольку устройства нуждаются в зарядке, очистке, обновлениях и доступе человека. Предоставьте их рабочим процессам, видимое или физическое поведение которых имеет значение. Хорошими первыми кандидатами являются дымовые проверки после развертывания, пути разрешений и системного пользовательского интерфейса, настройка камеры или Bluetooth, потоки уведомлений, доказательства локализации, регрессии, зависящие от поставщика, и точное воспроизведение поддержки.

Сохраняйте бизнес-логику, синтаксический анализ, форматирование и поведение компонентов в более быстрых тестах ближе к коду. Используйте реальное устройство, чтобы доказать границу, которую не могут преодолеть эти тесты: установленную сборку, операционную систему, внешнее приложение, поверхность ввода, сетевой переход или видимую человеку композицию. Сравнение инструментов автоматизации тестированияAndroidпомогает назначить каждое требование соответствующему уровню.

Критический пакет из пяти надежных путешествий более ценен, чем пятьдесят потоков, которым никто не доверяет. Начните с одного репрезентативного пути, измерьте стоимость сброса и сортировки, а затем добавляйте покрытие только тогда, когда новая проверка защищает конкретную версию, клиента или операционное решение.

Измерьте лабораторию, прежде чем масштабировать ее

Команды, обсуждающие автономные фермы устройств, постоянно возвращаются к одним и тем же исходным данным, связанным со сборкой и покупкой: поведением очереди, пиковым параллелизмом, временем ожидания, сбоем загрузки или сброса, усилиями по обслуживанию и дефектами, которые появляются только на физических устройствах. Отслеживайте эти сигналы в течение нескольких циклов выпуска, прежде чем покупать дополнительное оборудование или переносить все в облако.

• Ожидание в очереди по времени суток и приоритету рабочего процесса.
• Использование устройства и время, недоступное для зарядки, обновлений или ремонта.
• Частота отказов в начальном состоянии или сбросе по устройствам.
• Повторные запуски вызваны сбоями в автоматизации, а не изменениями продукта.
• Среднее время от отказа до полезной классификации.
• Явные дефекты обнаруживаются только на реальных устройствах конкретных производителей или определенных версиях Android.
• Минуты оператора за успешный запуск и за поддерживаемый рабочий процесс.

Это управленческие показатели, а не тщеславные информационные панели. Если время ожидания в очереди невелико, но преобладает обслуживание, размещенная служба может снизить стоимость владения. Если конфиденциальность, локальная периферия, быстрая интерактивная отладка или повторяющаяся поддержка воспроизведения имеют большее значение, чем широкий охват моделей, небольшая местная лаборатория может оставаться правильным центром тяжести.

Используйте гибридное правило сборки и покупки.

Местные и размещенные лаборатории дополняют друг друга. Управляемые устройства Gradle могут определять виртуальные устройства в сборке и группировать их для выполнения тестов. Firebase Test Lab может расширить матрицу на размещенные виртуальные и физические устройства и возвращать управляемые артефакты. Локальный пул обеспечивает немедленный доступ, фирменные периферийные устройства, контролируемую отладку и стабильные устройства для периодических эксплуатационных проверок.

Разумный гибрид проводит быстрые тесты инфраструктуры в управляемой виртуальной инфраструктуре, отправляет выбранные проверки совместимости на размещенные реальные устройства и сохраняет небольшой локальный стенд для ценных физических или контролируемых потоков. Правильное разделение может меняться по мере изменения условий параллелизма, конфиденциальности и данных о клиентских устройствах.

Контрольный список автоматизации лаборатории устройств Android

1. Назначьте одну цель и решение для каждой строки матрицы устройств.
2. Отдельные обязанности по эмулятору, локальному реальному устройству, хостингу, тестированию платформы и визуальному потоку.
3. Создайте карту запуска со сборкой, устройством, начальным состоянием, входными данными, постусловиями, остановками и свидетельствами.
4. Проверьте начальное состояние перед первым бизнес-действием.
5. Дождитесь наблюдаемых условий вместо того, чтобы добавлять более продолжительный слепой сон.
6. Сохраняйте наблюдения, решения и действия устройства как отдельные проверяемые шаги.
7. Соберите доказательства до того, как сброс или восстановление изменят сбой.
8. Классифицируйте сбои инфраструктуры, данных, тестирования, среды и продукта отдельно.
9. Отслеживайте очередь, использование, надежность сброса, неустойчивые повторы, время сортировки и только физические дефекты.
10. Используйте гибридную локальную и хостинговую стратегию, если это подтверждается фактами.

Начните с одного реального телефона, одной конфигурации эмулятора и одной критически важной для бизнеса карты запуска. Сделайте этот цикл надежным и доступным для проверки, прежде чем добавлять другое устройство или рабочий процесс. Когда уровень наблюдаемых устройств подойдет вашей команде, изучитеAI автоматизацию Android с помощью LaiCai Flowи сохраните детали реализации в руководстве поFlow с учетом локали.

Редакционное примечание:BeePOS LLC, компания, создавшая LaiCai Screen Mirroring, исследовала это руководство, используя официальную документацию Android и Firebase, указанную ниже, текущие контракты на продукты LaiCai, доступные только для чтения, и общедоступные обсуждения качества. Возможности продукта определяются отдельно от нейтральных рекомендаций по рабочему процессу. Вопросы или исправления можно отправлять по адресу support@laicaiapp.com.

• Разработчики Android: масштабируйте свои тесты с помощью управляемых устройств Gradle
• Разработчики Android: проверьте стабильность
• Лаборатория тестирования Firebase: начните тестирование Android
• Reddit r/QualityAssurance: поддержка инфраструктуры эмулятора Android
• Android Developers: UI Automator