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 в ветке последнего релиза Android ( android16-release ). Команда Android проверяет код и, если он принят, выбирает изменения и объединяет их с внутренней веткой разработки. Подробнее см. в разделе «Где следует предлагать изменения в AOSP?» .

Руководство по написанию теста 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 см. в разделе График выпуска и информация о ветке .