На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы о запуске тестов с помощью Firebase Test Lab . Известные проблемы также задокументированы. Если вы не можете найти то, что ищете, или вам нужна дополнительная помощь, присоединяйтесь к каналу #test-lab в Firebase Slack или обратитесь в службу поддержки Firebase .
Поиск неисправностей
При выборе в каталоге Test Lab устройства с высоким уровнем мощности тесты могут запускаться быстрее. Если устройство имеет низкую емкость, выполнение тестов может занять больше времени. Если количество вызванных тестов намного превышает емкость выбранных устройств, выполнение тестов может занять больше времени.
Тесты, выполняемые на любом уровне мощности устройства, могут занять больше времени из-за следующих факторов:
- Трафик, который влияет на доступность устройства и скорость тестирования.
- Сбои устройства или инфраструктуры, которые могут произойти в любой момент. Чтобы проверить, существует ли отчетная инфраструктура для Test Lab , см. панель мониторинга состояния Firebase .
Дополнительные сведения о емкости устройства в Test Lab см. в сведениях о емкости устройства для Android и iOS .
Неубедительные результаты тестов обычно происходят либо из-за отмены тестовых запусков, либо из-за ошибок инфраструктуры.
Ошибки инфраструктуры вызваны внутренними проблемами Test Lab , например сетевыми ошибками или неожиданным поведением устройства. Test Lab самостоятельно прекращает выполнение тестовых запусков, которые несколько раз приводят к ошибкам инфраструктуры, прежде чем сообщить о неубедительном результате; однако вы можете отключить эти повторы с помощью FailFast .
Чтобы определить причину ошибки, выполните следующие действия:
- Проверьте наличие известных сбоев на панели состояния Firebase .
Повторите тест в Test Lab чтобы убедиться в его воспроизводимости.
Попробуйте запустить тест на другом устройстве или типе устройства, если это применимо.
Если проблема не устранена, свяжитесь с командой Test Lab по каналу #test-lab в Firebase Slack.
Сегментирование может привести к тому, что ваши тесты будут выполняться дольше, если количество указанных вами сегментов превышает количество устройств, доступных для использования в Test Lab . Чтобы избежать такой ситуации, попробуйте переключиться на другое устройство. Дополнительную информацию о выборе другого устройства см.Емкость устройства .
Когда вы отправляете запрос на тестирование, ваше приложение сначала проверяется, повторно подписывается и т. д. в рамках подготовки к запуску тестов на устройстве. Обычно этот процесс завершается менее чем за несколько секунд, но на него могут влиять такие факторы, как размер вашего приложения.
После подготовки приложения выполнение тестов планируется и остается в очереди до тех пор, пока устройство не будет готово к его запуску. Пока выполнение всех тестов не завершится, статус матрицы будет «Ожидание» (независимо от того, находятся ли выполнения тестов в очереди или активно выполняются).
После завершения выполнения теста артефакты теста загружаются с устройства, обрабатываются и загружаются в Cloud Storage . На продолжительность этого шага может влиять количество и размер артефактов.
Артефакты выполнения тестов (например, снимки экрана и файлы журналов) хранятся в Google Cloud Storage и напрямую отображаются в консоли Firebase . Если выполнение теста выполнялось в течение последних 90 дней, убедитесь, что вам назначены роли на уровне проекта (владелец проекта, редактор проекта или просмотрщик проекта). Также убедитесь, что ведение журнала облачного аудита не включено для вашего проекта или вашей организации.
Если выполнение выполнялось более 90 дней назад, скорее всего, артефакты теста были автоматически удалены. Вы можете проверить конфигурацию сегмента результатов, щелкнув вкладку «Результаты теста» на панели инструментов Test Lab . Корзина результатов по умолчанию настроена на хранение объектов в течение 90 дней.
Чтобы дольше сохранять артефакты тестирования, запустите команду gcloud firebase test android run
с флагом --results-bucket
и передайте имя сегмента результатов. Для получения дополнительной информации посетите справочную документацию gcloud firebase test android run
.
При запуске инструментальных тестов вы можете увидеть ошибки теста, указывающие на частичные результаты, содержащие сообщения типа Test run failed to complete. Expected x tests, received y
(где y
меньше x
). Эта ошибка означает, что Test Lab не удалось проанализировать logcat на наличие маркеров начала или конца тестового примера, которые обычно генерируются AndroidJUnitRunner .
Ниже приведены распространенные причины этой проблемы:
Описание проблемы | Возможное решение |
---|---|
Тестовый пример не был выполнен из-за тайм-аута. Если общая продолжительность тестов превышает указанное вами время ожидания или превышает максимальное время ожидания , Test Lab отменяет остальные тестовые случаи. |
|
Тестовый пример не удалось завершить, поскольку он завершился преждевременно или завис. Тестовый пример может завершиться преждевременно из-за неперехваченного исключения или ошибки утверждения. Тестовые случаи могут застрять в бесконечном цикле или не могут быть продолжены, например, если приложение не отображает правильное представление и тестовый пример не может выполнить действие в пользовательском интерфейсе. | Посмотрите видео и logcat чтобы выяснить, где остановился тест. |
Пользовательский исполнитель тестов (включая расширение AndroidJUnitRunner) неожиданно аварийно завершился сбой или записал неожиданные маркеры начала или конца тестового сценария в logcat . | Проверьте код запуска тестов. |
В logcat записывались избыточные журналы, что приводило к перегрузке буфера или сбою процесса logcat . | Уменьшите количество записей в logcat . |
Тестируемое приложение вышло из строя. | Отладка вашего приложения. |
Часто задаваемые вопросы
Firebase Test Lab предлагает бесплатные квоты на тестирование на устройствах и использование Cloud API. Обратите внимание, что квота тестирования использует стандартный тарифный план Firebase, а квоты Cloud API — нет.
Квота тестирования
Квоты тестирования определяются количеством устройств, используемых для запуска тестов. План Firebase Spark имеет фиксированную квоту на бесплатное тестирование для пользователей. Для плана Blaze ваши квоты могут увеличиться, если со временем вы увеличите использование Google Cloud. Если вы достигли своей квоты на тестирование, подождите до следующего дня или перейдите на план Blaze, если вы сейчас используете план Spark. Если вы уже используете план Blaze, вы можете запросить увеличение квоты. Дополнительные сведения см. в разделе Тестирование квоты .
Вы можете отслеживать использование квоты тестирования в консоли Google Cloud .
Квота API облачного тестирования
API облачного тестирования имеет два ограничения квоты: количество запросов в день на проект и количество запросов каждые 100 секунд на проект. Вы можете отслеживать свое использование в консоли Google Cloud .
Квота API результатов Cloud Tool
API результатов Cloud Tool имеет два ограничения квоты: количество запросов в день на проект и количество запросов каждые 100 секунд на проект. Вы можете отслеживать свое использование в консоли Google Cloud .
Дополнительную информацию об ограничениях API см. в разделе Квоты Cloud API для Test Lab . Если вы достигли квоты API:
Отправьте запрос на увеличение квот, отредактировав квоты непосредственно в консоли Google Cloud (обратите внимание, что для большинства ограничений по умолчанию установлено максимальное значение) или
Запросите более высокие квоты API, заполнив форму запроса в консоли Google Cloud или обратившись в службу поддержки Firebase .
Из своего серверного интерфейса вы можете определить, поступает ли трафик с тестовых устройств, размещенных на Firebase, проверив исходный IP-адрес по нашим диапазонам IP-адресов .
Test Lab не работает с VPC-SC, который блокирует копирование приложений и других тестовых артефактов между внутренним хранилищем Test Lab и сегментами результатов пользователей.
Чтобы обнаружить нестабильное поведение в ваших тестах, мы рекомендуем использовать--num-flaky-test-attemptsвариант. Повторные запуски Deflake оплачиваются или засчитываются в вашу ежедневную квоту так же, как и обычное выполнение тестов.
Имейте в виду следующее:
- При обнаружении сбоя все выполнение теста запускается заново. Не поддерживается повторная попытка только неудачных тестовых случаев.
- Повторные запуски Deflake запланированы на одно и то же время, но их параллельное выполнение не гарантируется, например, когда трафик превышает количество доступных устройств.
Да! Test Lab поддерживает Google Pixel Watch. Теперь вы можете запускать тесты в своем автономном приложении Wear на Google Pixel Watches. Дополнительные сведения об устройствах Test Lab см. в разделе Тестирование на доступных устройствах .
Да! Test Lab поддерживает планшеты Google Pixel и Google Pixel Fold. Вы можете запускать тесты на своих автономных физических устройствах. Дополнительные сведения об устройствах Test Lab см. в разделе Тестирование на доступных устройствах .
Если вы тестируете свое приложение в Firebase или запускаете тесты для отчета о предварительном запуске в Play Console, вы можете определить, запускается ли тест на устройстве, размещенном в Firebase, проверив системное свойство firebase.test.lab
в ваш файл MainActivity
. Затем вы можете выполнить дополнительные инструкции на основе логического значения testLabSetting
. Дополнительные сведения см. в разделе «Измененное поведение тестов» .
Хотя некоторые из этих пунктов включены в нашу дорожную карту, в настоящее время мы не можем взять на себя обязательства по поддержке этих платформ тестирования и разработки приложений. Однако если вы создали свое приложение с помощью платформы, поддерживающей Espresso (например, Flutter), вы можете написать инструментальный тест с использованием Espresso , а затем запустить тест в Test Lab .
Test Lab явно не поддерживает обфускацию или деобфускацию. Хотя приложение, скорее всего, будет работать, любые запутанные данные приложения, такие как трассировки стека, будут отображаться в журналах как запутанные.
Да! Вы можете протестировать свое складное устройство в складном состоянии и положениях .
Складные устройства могут находиться в различных сложенных состояниях, например FLAT
(полностью раскрытое) или HALF_OPENED
(между полностью открытым и полностью закрытым).
С другой стороны, положения включают определенную ориентацию устройства и его складное состояние. Например, положение столешницы, которое представляет собой состояние HALF_OPENED
в горизонтальной ориентации, или положение книги, которое представляет собой состояние HALF_OPENED
в вертикальной ориентации.
Если вы проводите инструментальные тесты, вы можете использовать библиотеку Jetpack WindowManager и следить за тестированием своего приложения на складной документации, чтобы протестировать различные состояния и положения.
Альтернативно, доступные состояния зависят от устройства, и с ними можно взаимодействовать с помощью adb shell command cmd device_state
.
- Чтобы просмотреть текущее состояние, запустите
adb shell cmd device_state state
. - Чтобы установить или переопределить текущее состояние, запустите
adb shell cmd device_state state <IDENTIFIER>
. - Чтобы сбросить состояние, запустите
adb shell cmd device_state state reset
. - Чтобы проверить доступные состояния, запустите команду
adb shell cmd device_state print-states
на складном устройстве.
Google Pixel Fold (идентификатор модели felix
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSED', app_accessible=true}, DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true}, DeviceState{identifier=2, name='OPENED', app_accessible=true}, DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true}, ]
Samsung Galaxy Z Fold4 (идентификатор модели q4q
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSE', app_accessible=true}, DeviceState{identifier=1, name='TENT', app_accessible=true}, DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true}, DeviceState{identifier=3, name='OPEN', app_accessible=true}, ]
В отличие от других продуктов Firebase, вам не нужно добавлять Firebase SDK, чтобы использовать Test Lab . Если у вас еще нет приложения, вы можете скачать APK онлайн или создать приложение и тестовый APK из одного из образцов в репозитории AndroidX GitHub . Обратите внимание: для запуска роботизированного теста вам понадобится только APK-файл вашего приложения, а для инструментального теста требуется как приложение, так и тестовый APK, созданные на основе исходного кода. Подробнее читайте в разделе Инструментальные тесты .
Дополнительные сведения о функциях Test Lab см. в статье Начало тестирования Android с помощью Firebase Test Lab .
Тестирование различий между скриншотами — это тестирование, в котором утверждения теста основаны на сравнении изображений экрана, полученных во время выполнения теста, с золотыми изображениями, представляющими ожидаемое поведение. Такие тесты могут быть более хрупкими для некоторых типов устройств, чем для других. Мы рекомендуем использовать для подобных тестов устройства-эмуляторы Arm ( *.arm
). В устройствах-эмуляторах Arm используются изображения, которые очень похожи или идентичны «универсальным» эмуляторам Android Studio.
Мы также рекомендуем вам изучить тестовые библиотеки, которые помогут сделать скриншоты тестов более надежными в случае ожидаемых изменений.
Да! Виртуальные устройства обновляются при внесении следующих изменений:
- Обновления существующих изображений
- Прекращение поддержки более ранних уровней API
- Добавлены новые уровни Android API.
Чтобы включить отчеты о покрытии, добавьте coverage=true
в поле environmentVariables
. Если вы используете Android Test Orchestrator, вам необходимо указать каталог для хранения результатов покрытия:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
Если вы не используете Orchestrator, вы можете указать путь к файлу:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
Подробная информация об устройстве доступна через API, и к ней можно получить доступ из клиента gcloud с помощью команды описания :
gcloud firebase test android models describe MODEL
Известные проблемы
Робо-тест не может обойти экраны входа, которые требуют дополнительных действий пользователя, помимо ввода учетных данных для входа, например прохождения CAPTCHA.
Робо-тест лучше всего работает с приложениями, которые используют элементы пользовательского интерфейса из платформы пользовательского интерфейса Android (включая объекты View
, ViewGroup
и WebView
). Если вы используете Robo-тест для проверки приложений, использующих другие платформы пользовательского интерфейса, включая приложения, использующие игровой движок Unity, тест может завершиться без перехода за пределы первого экрана.