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).
  • Устройство остается неподвижным во время теста (или нет, в зависимости от теста).
  • Устройство отключено от любого источника питания с уровнем заряда батареи X процентов.
  • Никакие приложения, службы переднего плана или фоновые службы не запущены, за исключением CTS.
  • Экран выключен во время работы CTS.
  • Устройство НЕ isLowRamDevice .
  • Ограничения экономии заряда батареи / приложений не были изменены по сравнению с состоянием «из коробки».

Право на тестирование

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

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

  1. Напишите тестовое предложение: разработчик приложения отправляет тестовое предложение с помощью Google Issue Tracker , описывая обнаруженную проблему и предлагая тест для ее проверки. Предложение должно включать связанный идентификатор требования CDD . Команда Android рассматривает предложение.
  2. Разработайте тест CTS: после утверждения предложения отправитель создает тест CTS на AOSP в основной (AOSP/главной) ветке. Команда Android проверяет код.
  3. Публикация теста: отправьте свой CL на AOSP/master , а затем выберите его в последней 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 .
  • Обработайте все предупреждения и предложения, связанные с build_error.log errorprone
  • Перебазируйте свои изменения в head . Сюда входят планы тестирования cts-developer.xml и cts-developer-exclude.xml .
  • Свяжитесь со своим инженером Google, чтобы определить, можно ли включить ваш тестовый пример в существующий модуль CTS. Если это невозможно, они помогут вам создать новый модуль.
  • Для каждого нового созданного тестового модуля создайте файл OWNERS в каталоге нового тестового модуля.
    • Ваш файл OWNERS должен содержать следующую информацию, полученную от владельца теста Google, с которым вы работаете:
    • # Bug component: xxx
    • LDAP владельца теста Google
  • В 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 см. в разделе График выпуска и информация о ветках.