Эта страница содержит помощь по устранению неполадок и ответы на часто задаваемые вопросы о запуске тестов в 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 . Длительность этого этапа может зависеть от количества и размера артефактов.
Устранение неполадок, специфичных для Android
Артефакты выполнения теста (такие как снимки экрана и файлы журналов) хранятся в 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 . |
| Тестируемое приложение дало сбой. | Отладьте свое приложение. |
Часто задаваемые вопросы (FAQ)
Firebase Test Lab предлагает бесплатные квоты для тестирования на устройствах и использования облачных API. Обратите внимание, что квота на тестирование действует по стандартному тарифному плану Firebase, а квоты на облачные API — нет.
Квота на тестирование
Квоты тестирования определяются количеством устройств, используемых для запуска тестов. План Firebase Spark имеет фиксированную квоту тестирования, которая предоставляется бесплатно для пользователей. Для плана Blaze ваши квоты могут увеличиваться по мере увеличения использования Google Cloud. Если вы достигли своей квоты тестирования, подождите до следующего дня или перейдите на план Blaze, если вы уже используете план Spark. Если вы уже используете план Blaze, вы можете запросить увеличение квоты. Подробнее см. в разделе «Квота тестирования» .
Вы можете отслеживать использование своей тестовой квоты в консоли Google Cloud .
Квота API облачного тестирования
API Cloud Testing имеет две квоты: количество запросов в день на проект и количество запросов каждые 100 секунд на проект. Вы можете отслеживать использование ресурсов в консоли Google Cloud .
Квота API результатов облачного инструмента
API Cloud Tool Results имеет две квоты: количество запросов в день на проект и количество запросов каждые 100 секунд на проект. Вы можете отслеживать использование ресурсов в консоли Google Cloud .
Подробнее об ограничениях API см. в разделе «Квоты облачного API для Test Lab . Если вы достигли квоты API:
Подайте запрос на увеличение квот, отредактировав их непосредственно в консоли Google Cloud (обратите внимание, что большинство ограничений по умолчанию установлены на максимум), или
Запросите более высокие квоты API, заполнив форму запроса в консоли Google Cloud или обратившись в службу поддержки Firebase .
Со своего бэкэнда вы можете определить, поступает ли трафик с тестовых устройств, размещенных в Firebase, сверив исходный IP-адрес с нашими диапазонами IP-адресов .
Test Lab не работает с VPC-SC, который блокирует копирование приложений и других тестовых артефактов между внутренним хранилищем Test Lab и контейнерами результатов пользователей.
Чтобы обнаружить нестабильное поведение в ваших тестах, мы рекомендуем использовать--число-нестабильных-тестовых-попытокопция. Повторные запуски Deflake оплачиваются или засчитываются в вашу дневную квоту так же, как и обычные тестовые запуски.
Помните следующее:
- При обнаружении сбоя весь тест выполняется заново. Поддержка повторного выполнения только неудачных тестовых случаев отсутствует.
- Повторные запуски Deflake запланированы на одно и то же время, но не гарантируется их параллельное выполнение, например, когда трафик превышает количество доступных устройств.
Часто задаваемые вопросы по iOS
Хотя некоторые из этих пунктов есть в наших планах, в настоящее время мы не можем гарантировать поддержку этих платформ тестирования и разработки приложений.
Подробная информация об устройстве доступна через API и может быть получена из клиента gcloud с помощью команды describe :
gcloud firebase test ios models describe MODEL
В Test Lab для iOS изначально нет поддержки шардинга. Однако вы можете использовать клиент Flank для шардинга тестовых случаев iOS.
Это работает путём установки ключа и значений OnlyTestIdentifiers в файле .xctestrun . Подробнее см. страницу man по xcodebuild.xctestrun .
Для iOS 18 и более поздних версий мы не можем поддерживать видео в результатах поиска.
Часто задаваемые вопросы по Android
Да! Test Lab поддерживает Google Pixel Watch. Теперь вы можете проводить тестирование своего автономного приложения Wear на часах Google Pixel Watch. Подробнее об устройствах 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, для использования Test Lab не требуется устанавливать Firebase SDK. Если у вас ещё нет приложения, вы можете скачать APK-файл из интернета или собрать приложение и тестовый APK-файл из одного из примеров в репозитории AndroidX GitHub . Обратите внимание, что для запуска Robo-теста вам нужен только APK-файл вашего приложения, тогда как для инструментального теста требуются как приложение, так и тестовый APK-файл, собранные из исходного кода. Подробнее см. в разделе «Инструментальные тесты» .
Дополнительную информацию о функциях Test Lab см. в статье Начало тестирования Android с помощью Firebase Test Lab .
Тестирование с использованием скриншотов-разниц — это тестирование, в котором утверждения основаны на сравнении изображений экрана, полученных во время выполнения теста, с эталонными изображениями, представляющими ожидаемое поведение. Такие тесты могут быть менее стабильными на одних типах устройств, чем на других. Мы рекомендуем использовать для таких тестов устройства с эмуляторами Arm ( *.arm ). Устройства с эмуляторами Arm используют изображения, очень похожие или идентичные изображениям «универсальных» эмуляторов Android Studio.
Мы также рекомендуем вам изучить тестовые библиотеки, которые могут помочь сделать тесты снимков экрана более надежными при наличии ожидаемых изменений.
Да! Виртуальные устройства обновляются при внесении следующих изменений:
- Обновления существующих изображений
- Прекращение поддержки более ранних уровней API
- Добавлены новые уровни API Android
Чтобы включить отчёты о покрытии, добавьте 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 с помощью команды describe :
gcloud firebase test android models describe MODEL
Известные проблемы
Robo-тест не может обойти экраны входа, требующие дополнительных действий пользователя помимо ввода учетных данных для входа, например, заполнения CAPTCHA.
Известные проблемы, специфичные для iOS
Автоматический вход с использованием учетной записи Google не поддерживается в тестах Robo для iOS+ (бета-версия).
Известные проблемы, характерные для Android
Тест Robo лучше всего работает с приложениями, использующими элементы пользовательского интерфейса из фреймворка Android UI (включая объекты View , ViewGroup и WebView ). Если вы используете тест Robo для проверки приложений, использующих другие фреймворки пользовательского интерфейса, включая приложения на игровом движке Unity, тест может завершиться, не пройдя дальше первого экрана.