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

На этой странице изложены рекомендации по использованию 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).
  • Устройство остается неподвижным во время теста (или нет, в зависимости от теста).
  • Устройство отключено от любого источника питания с уровнем заряда батареи Х процентов.
  • Никакие приложения, службы переднего плана или фоновые службы не работают, за исключением 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 Development .
  • Добавьте свои тесты в соответствующий план тестирования:
    • Используйте 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 см. в разделе График выпусков и информацию о филиалах .