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

На этой странице изложены правила использования CTS, разработанной разработчиками (CTS-D).

Покрытие теста

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

  • Все общедоступные API, описанные в SDK для разработчиков (developer.android.com) для определенного уровня API.
  • Все требования MUST, включенные в документ определения совместимости 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 ( android17-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 .
  • Обрабатывайте все предупреждения и предложения, содержащиеся в build_error.log , errorprone .
  • Перебазируйте свои изменения в 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 or 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 см. в разделе «График выпуска и информация о ветвях» .