CTS на базе разработчиков

На этой странице изложены правила использования Developer-Powered CTS (CTS-D).

Тестовое покрытие

CTS-D, как и CTS и CTS Verifier, может обеспечивать соблюдение только следующих требований:

  • Все публичные API, описанные в SDK разработчика (developer.android.com) для определенного уровня API.
  • Все ОБЯЗАТЕЛЬНЫЕ требования, включенные в Документ определения совместимости Android (CDD) для определенного уровня API.

Необязательные требования, такие как НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ, СЛЕДУЕТ, МОЖЕТ, являются необязательными и не могут быть протестированы с помощью CTS.

Поскольку все требования API и CDD привязаны к определенному уровню API, все тесты CTS (CTS, CTS-D и CTS Verifier) ​​привязаны к тому же уровню API, что и соответствующие им API или требования. Если определенный API устарел или изменен, соответствующий ему тест должен быть устарел или обновлен.

Правила создания теста CTS

  • Тест должен постоянно давать один и тот же объективный результат.
  • Тест должен определить, прошло ли устройство тест или нет, проверив его один раз сразу после распаковки.
  • Создатели тестов должны исключить все возможные факторы, которые могут повлиять на результаты теста.
  • Если устройству требуется определенное аппаратное состояние/среда/настройка, эта настройка должна быть четко определена в сообщении о фиксации. Например, инструкции по настройке см. в разделе Настройка CTS .
  • Тест не должен длиться более 6 часов за раз. Если он должен длиться дольше, пожалуйста, включите обоснование в ваше предложение по тесту, чтобы мы могли его рассмотреть.

Ниже приведен пример набора тестовых условий для проверки ограничения приложения:

  • Wi-Fi работает стабильно (для теста, который зависит от Wi-Fi).
  • Во время теста устройство остается неподвижным (или нет, в зависимости от теста).
  • Устройство отключено от любого источника питания с уровнем заряда батареи X процентов.
  • Никакие приложения, службы переднего плана или фоновые службы не запущены, за исключением CTS.
  • Во время работы CTS экран выключен.
  • Устройство НЕ является isLowRamDevice .
  • Настройки экономии заряда батареи и ограничения приложений не были изменены по сравнению с заводскими настройками.

Право на прохождение теста

Мы принимаем новые тесты, которые обеспечивают поведение, которое не тестируется существующими тестами CTS, CTS Verifier или CTS-D. Любой тест, который проверяет поведение, выходящее за рамки нашего тестового покрытия, будет отклонен.

Процесс подачи CTS

  1. Напишите тестовое предложение: Разработчик приложения отправляет тестовое предложение с помощью Google Issue Tracker , описывая выявленную проблему и предлагая тест для ее проверки. Предложение должно включать связанный идентификатор требования CDD . Команда Android рассматривает предложение.
  2. Разработать тест CTS: После одобрения предложения его отправитель создает тест CTS на AOSP в основной (AOSP/main) ветке. Команда Android проверяет код.
  3. Опубликуйте тест: Отправьте свой CL на AOSP/main , а затем выберите его для последней ветки androidx-tests-dev . Тест теперь доступен для общественности.

Руководство по написанию теста CTS-D

  • Следуйте Руководству по стилю кода Java .
  • Выполните все шаги, описанные в разделе «Разработка CTS» .
  • Добавьте свои тесты в соответствующий план тестирования:
    • Используйте include-filters для добавления новых тестов в план тестирования CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml .
    • Используйте exclude-filters , чтобы исключить новые тесты из основного плана тестирования CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml .
  • Обрабатывайте все предупреждения и предложения, errorprone в build_error.log .
  • Переместите изменения в head . Это включает в себя планы тестирования cts-developer.xml и cts-developer-exclude.xml .
  • Обратитесь к своему инженерному контакту Google, чтобы определить, можно ли включить ваш тестовый случай в существующий модуль CTS. Если нет, они помогут вам создать новый модуль.
  • Для каждого нового созданного тестового модуля создайте файл OWNERS в новом каталоге тестового модуля.
    • Ваш файл OWNERS должен содержать следующую информацию, полученную от владельца теста Google, с которым вы работаете:
    • # Bug component: xxx
    • Тестовый владелец Google ldap
  • В AndroidTest.xml укажите следующие параметры. Примеры см. в файлах-образцах ( 1 , 2 ):
    • Instant_app или not_instant_app
    • secondary_user или not_secondary_user
    • all_foldable_states или no_foldable_states
  • Чтобы указать правильный minSDK, обратитесь к документации <uses-sdk> .
  • При регистрации новых методов тестирования, классов или модулей добавьте их в план тестирования CTS-D и исключите из основного плана тестирования CTS таким же образом, как и для новых тестов.

Проведите тест CTS-D

Запустите план тестирования CTS-D из командной строки с помощью run cts --plan cts-developer .

Чтобы запустить определенный тестовый случай, используйте run cts --include-filter "test_module_name test_name" .

Информацию о запуске полного CTS см. в разделе Запуск тестов CTS .

Принятие и освобождение

После отправки запроса на тестирование внутренняя команда рассмотрит его, чтобы убедиться, что он тестирует требование CDD или задокументированное поведение API. Если будет установлено, что тест проверяет допустимое требование или поведение, команда перешлет этот тестовый случай инженеру Google для дальнейшего рассмотрения. Инженер Google свяжется с вами и предоставит отзыв о том, как можно улучшить тест, прежде чем он будет принят в CTS.

Подробную информацию о графике выпуска CTS см. в разделе График выпуска и информация о ветке .