Часто задаваемые вопросы по CTS

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

В этой статье приведены ответы на часто задаваемые вопросы, которые помогут более эффективно выполнять тесты CTS.

В чем разница между CTS Sharding и TF Sharding?

CTS Sharding и TF Sharding — это совершенно разные планы тестирования, основанные на разной базе кода тестовой инфраструктуры. Хотя команда запуска одинакова в разных версиях, результат сегментирования ведет себя по-разному. CTS Sharding статически назначает тестовые наборы тестируемым устройствам (DUT) следующим образом:

TF Sharding динамически назначает тестовые наборы доступным тестируемым устройствам следующим образом:

Что ожидается от устройства, поддерживающего несколько ABI?

Устройство должно пройти все CTS/Verifier для каждого режима ABI, который, как утверждается, поддерживает. Следовательно, необходимо выполнить приложение для конкретных ABI. Рекомендации для нескольких ABI следующие:

  • Для CTS/Verifier существуют выпуски ARM и x86 для каждой архитектуры. Каждый из них может поддерживать 32- или 64-битный режим.
  • Для тестов CTS, если устройство поддерживает и ARM, и x86, оно должно выполнить и пройти тесты ARM и x86 CTS соответственно.

См. CDD 3.3.1. Двоичные интерфейсы приложений для требований CDD в ABI.

Достаточно ли запускать тест только на основном ABI (например, 64-битном), чтобы сократить время выполнения теста?

Нет . Приложение для Android работает в собственной 32- или 64-разрядной среде выполнения. Фактический машинный код, путь кода и состояние различаются между 32 и 64. Если вы пропустите один режим, вы охватите только 50% ABI устройства.

Почему так много тестовых случаев сообщается как «Не выполнено»?

Вы должны проверить номер модуля «Готово » вместо номера « Не выполнено ».

В более старых версиях модули CTS сообщались как « Выполненный модуль » слишком агрессивно, прежде чем они были завершены. Таким образом, число выполненных модулей сообщалось без завершения всего тестового примера, даже если на некоторых устройствах были проблемы. Новый набор тестов более консервативен и сообщает о большем количестве невыполненных тестов при возникновении проблемы.

Модуль, запущенный до завершения, сообщает о том, что модуль не выполнен в самом последнем вызове (done="false") в отчете во время следующего:

  • Тестовый запуск модуля был прерван из-за проблемы с подключением устройства.
  • Не все ожидаемые тестовые прогоны модуля были выполнены.

  • Повторная попытка (с использованием параметра -r/--retry ) с дополнительными параметрами фильтрации, такими как:

    • --include-фильтр
    • --exclude-фильтр
    • -t/--test (опция еще не поддерживается при повторной попытке)
    • --retry-type не удалось
    • --подплан

Чтобы получить статус « Выполненный модуль » (done="true") для этих модулей, повторите следующее для самого последнего вызова:

run retry --retry <session_id> for Android 9 and later versions

run cts --retry <session_id> for Android 8.1 and previous versions

Модуль, выполненный без каких-либо проблем, упомянутых выше (даже с 0 оставшимися тестами), помечается в новом отчете как « Модуль выполнен ».

Исключения

  • CtsNNAPITestCases имеет известную проблему из-за ограничения аргументов Linux/OS. Модуль можно повторно запустить изолированно run cts -m CtsNNAPITestCases напрямую.

Как избежать сбоя подготовки к тесту из-за корпоративного брандмауэра?

Все наборы автоматизированных тестов пытаются загрузить либо медиафайлы CTS, либо файлы бизнес-логики во время выполнения. Во многих корпоративных средах обычно используется брандмауэр/прокси-сервер, из-за чего подготовка к тесту не проходит. Выполните следующую строку или добавьте ее в .profile (в Ubuntu).

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

Нужна ли мне SIM-карта для CTS для Secure Element?

Нужна ли SIM-карта для теста, зависит от понимания того, поддерживается ли эта функция в тестовом устройстве.

  • Если вашему устройству НЕ НУЖНА поддержка доступа приложений Android к защищенным элементам — либо в UICC (например, SIM-карте), распространяемой операторами мобильной связи (операторами), либо встроенной в устройство — вы можете настроить манифест HIDL, чтобы он не включал элемент HAL android.hardware.secure_element . В этом случае API android.se.omapi.SEService.getReaders() сообщит о пустом списке, а тест CTS автоматически пройдет и сообщит о прохождении CTS.
  • Если вашему устройству НЕОБХОДИМО поддерживать приложения Android, получающие доступ к любым защищенным элементам — либо в UICC (например, SIM-карте), распространяемой операторами мобильной связи (операторами), либо встроенной в устройство — вам необходимо должным образом внедрить безопасный элемент и протестировать его. в доме. Тест CTS для Secure Element описывает, как подготовиться к запуску тестов CTS, которые обеспечивают работоспособность пакета API android.se.omapi , добавленного в Android 9. Мы также рекомендуем провести дополнительное тестирование самостоятельно, так как тестовое покрытие CTS минимально.

Где я могу получить SIM-карты для CTS для Secure Element?

Вы можете обратиться к предпочитаемому поставщику SIM-карты.

Почему Orange SIM отображается на экране блокировки во время выполнения CTS с шардингом токена?

Тестовый случай не запускается, так как тестирование SIM-карты заблокировано. Отключите параметр «Блокировать SIM-карту» в «Настройках блокировки SIM-карты» перед выполнением CTS с сегментированием токена.