Тест

Atest это инструмент командной строки , которая позволяет пользователям создавать, устанавливать и запускать Android тесты на местном уровне, что значительно ускоряет тест повторных прогонов без необходимости знания тестов жгутов Торговой Федерации параметров командной строки. На этой странице объясняется, как использовать Atest для запуска тестов Android.

Для получения общей информации о написании тестов для Android см Android платформы тестирования .

Для получения информации об общей структуре ATEST см ATEST Developer Guide .

Для получения информации о выполнении тестов в TEST_MAPPING файлов через ATEST см Выполнение тестов в TEST_MAPPING файлах .

И добавить функцию к ATEST, следовать ATEST Developer Workflow .

Настройка вашей среды

Чтобы запустить Atest, выполните действия, описанные в разделах ниже, чтобы настроить среду.

Установить переменную среды

Набор test_suite для Soong или LOCAL_COMPATIBILITY_SUITE для Make на Packaging правила сборки сценария .

Запустите envsetup.sh

Из корня проверки исходного кода Android запустите:

source build/envsetup.sh

Обед

Запустите lunch команду , чтобы открыть меню поддерживаемых устройств. Найдите устройство и запустите эту команду.

Например, если у вас подключено устройство ARM, выполните следующую команду:

lunch aosp_arm64-eng

Это устанавливает различные переменные окружения , необходимые для запуска ATEST и добавляет команду ATEST в свой $PATH .

Основное использование

Команды Atest имеют следующую форму:

atest test-to-run [optional-arguments]

Необязательные аргументы

Ниже приведены наиболее часто используемые аргументы. Полный список доступен через atest --help .

Вариант Длинный вариант Описание
-b --build Строит тестовые цели. (дефолт)
-i --install Устанавливает тестовые артефакты (APK) на устройство. (дефолт)
-t --test Запускает тесты. (дефолт)
-s --serial Запускает тесты на указанном устройстве. Одновременно можно тестировать одно устройство.
-d --disable-teardown Отключает тестовую разборку и очистку.
--info Показывает соответствующую информацию об указанных целях и выходах.
--dry-run Тестирование всухую без сборки, установки и запуска тестов
-m --rebuild-module-info Силы пересобрать module-info.json файла.
-w --wait-for-debugger Ожидает отладчика перед выполнением. Только для инструментальных испытаний.
-v --verbose Отображает ведение журнала уровня DEBUG.
--iterations Цикл запускает тесты до тех пор, пока не будет достигнута максимальная итерация. (По умолчанию 10)
--rerun-until-failure [COUNT=10] Повторно выполняет все тесты до тех пор, пока не произойдет сбой или не будет достигнута максимальная итерация. (По умолчанию 10)
--retry-any-failure [COUNT=10] Повторяет неудачные тесты до тех пор, пока не будет пройден или не будет достигнута максимальная итерация. (По умолчанию 10)
--start-avd Автоматически создает AVD и запускает тесты на виртуальном устройстве.
--acloud-create Создает AVDS с помощью acloud command.
--[CUSTOM_ARGS] Задает настраиваемые аргументы для участников тестирования.
-a --all-abi Выполняет тесты для всех доступных архитектур устройств.
--host Полностью запускает тест на хосте без устройства.
(Примечание: Запуск теста хоста , который требует устройств с --host не удастся.)
--flakes-info Показывает результат теста с информацией о хлопьях.
--history Показывает результат теста в хронологическом порядке.
--latest-result Печатает последний результат теста.

Для получения дополнительной информации о -b , -i и -t , см Указание действия сборки, установки или запуска.

Тесты для запуска

Вы можете использовать один или несколько тестов с использованием test-to-run . Чтобы запустить несколько тестов, разделите ссылки на тесты пробелами. Например:

atest test-to-run-1 test-to-run-2

Вот некоторые примеры:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Для получения более подробной информации о том , как ссылаться на тест, см Определение тестов.

Идентификационные тесты

Вы можете указать test-to-run аргумент с названием тестом модуля, модуль: класс, именем класса, тестом интеграции TF, путем к файлу или имя пакета.

Название модуля

Чтобы запустить весь тестовый модуль, используйте его имя модуля. Введите имя , как оно появляется в LOCAL_MODULE или LOCAL_PACKAGE_NAME переменных , которые тестируют в Android.mk или Android.bp файл.

Примеры:

atest FrameworksServicesTests
atest CtsVideoTestCases

Модуль: Класс

Для того, чтобы запустить один класс внутри модуля, используйте модуль: Class. Модуль так же , как описано в названии модуля . Класс это имя тестового класса в .java файл и может быть полное имя класса или основным именем.

Примеры:

atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest CtsVideoTestCases:VideoEncoderDecoderTest

Название класса

Чтобы запустить один класс без явного указания имени модуля, используйте имя класса.

Примеры:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Использование модуля: ссылки класса рекомендуется всякий раз , когда это возможно , так как Atest требует больше времени для поиска полного исходного дерева для потенциальных совпадений , если модуль не указан.

Примеры (отсортированы от самого быстрого к самому медленному):

atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest FrameworksServicesTests:ScreenDecorWindowTests
atest ScreenDecorWindowTests

Тест интеграции TF

Для запуска тестов, которые интегрированы непосредственно в TradeFed (не-модули), введите имя , как оно появляется на выходе из tradefed.sh list configs команды. Например:

Чтобы запустить reboot.xml тест :

atest example/reboot

Для запуска native-benchmark.xml теста :

atest native-benchmark

Путь файла

Вы можете запускать как тесты на основе модулей, так и тесты на основе интеграции, указав путь к их тестовым файлам или каталогам в зависимости от ситуации. Вы также можете запустить отдельный класс, указав путь к файлу Java класса. Поддерживаются как относительные, так и абсолютные пути.

Пример: Два способа для запуска CtsVideoTestCases модуля через путь

  1. Запуск модуля из Android repo-root :

    atest cts/tests/video
    
  2. Из Android repo-root / КТС / тесты / видео:

    atest .
    

Пример: Выполнить определенный класс внутри CtsVideoTestCases модуля через путь. Из Android repo-root :

atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

Пример: запустить интеграционный тест по пути. Из Android repo-root :

atest tools/tradefederation/contrib/res/config/example/reboot.xml

Имя пакета

Atest поддерживает поиск тестов по имени пакета.

Примеры:

atest com.android.server.wm
atest com.android.uibench.janktests

Указание шагов: сборка, установка или запуск

Вы можете указать , какие шаги для запуска с помощью -b , -i и -t опции. Если вы не укажете параметр, будут выполнены все шаги.

  • Строительные цели только: atest -b test-to-run
  • Выполнение тестов только: atest -t test-to-run
  • Установить APK и запускать тесты: atest -it test-to-run
  • Построить и запустить, но не устанавливать: atest -bt test-to-run

Atest может заставить тест пропустить этап очистки / разрыва. Многие тесты, такие как CTS, очистка устройства после того, как тест выполняется, поэтому пытаются повторно запустить тест с -t не сможет без --disable-teardown параметра. Используйте -d перед тем -t , чтобы пропустить тест чистый шаг вверх и испытание итеративно.

atest -d test-to-run
atest -t test-to-run

Запуск конкретных методов

Вы можете запускать определенные методы в тестовом классе. Хотя необходимо собрать весь модуль, это сокращает время, необходимое для запуска тестов. Чтобы запустить определенные методы, определите класс, используя любой из способов, поддерживаемых для идентификации класса (модуль: класс, путь к файлу и т. Д.), И добавьте имя метода.

atest reference-to-class#method1

Вы можете указать несколько методов через запятую.

atest reference-to-class#method1,method2,method3

Примеры:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

Следующие два примера показывают предпочтительные способы для запуска одного метода, testFlagChange . Эти примеры предпочтительнее использования только имени класса, потому что указание модуля или местоположения файла Java позволяет Atest найти тест намного быстрее:

  1. Использование модуля: класс

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. Из Android repo-root

    atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
    

Из разных классов и модулей можно запускать несколько методов:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Запуск нескольких классов

Чтобы запустить несколько классов, разделите их пробелами так же, как при запуске нескольких тестов. Atest эффективно создает и запускает классы, поэтому указание подмножества классов в модуле повышает производительность по сравнению с запуском всего модуля.

Примеры:

  • Два класса в одном модуле:

    atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
    
  • Два класса в разных модулях:

    atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
    

Запуск собственных тестов

Atest может запускать собственные тесты. Используйте -a для выполнения тестов для всех доступных архитектур устройств, которые в данном примере являются armeabi-v7a (ARM 32-бит) и arm64-V8A (ARM 64-бит).

Примеры:

  • Входные тесты:

    atest -a libinput_tests inputflinger_tests
    

Чтобы выбрать конкретный собственный тест для запуска, используйте двоеточие (:), чтобы указать имя теста, и хэштег (#), чтобы дополнительно указать отдельный метод. Например, для следующего определения теста:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Вы можете запустить весь тест с использованием

atest inputflinger_tests:InputDispatcherTest

или индивидуальный метод испытания с использованием

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Запуск тестов в TEST_MAPPING

Atest может запускать тесты в файлах TEST_MAPPING.

  1. Неявно запускайте предварительные тесты в файлах TEST_MAPPING в текущем, родительском или определенных каталогах.

    Выполнение тестов presubmit в TEST_MAPPING файлов в текущей и родительских каталогах:

    atest
    

    Выполнение тестов presubmit в TEST_MAPPING файлов в /path/to/project и его родительские каталоги:

    atest --test-mapping /path/to/project
    

  2. Выполнить указанную тестовую группу в TEST_MAPPING файлов; доступные тестовые группы: presubmit ( по умолчанию), postsubmit , mainline-presubmit и all .

    • Выполнение тестов postsubmit в TEST_MAPPING файлов в текущей и родительских каталогах:

      atest :postsubmit
      

    • Выполнение тестов из всех групп в TEST_MAPPING файлов:

      atest :all
      

    • Выполнение тестов postsubmit в TEST_MAPPING файлов в /path/to/project и его родительские каталоги

      atest --test-mapping /path/to/project:postsubmit
      

    • Запуск магистральных тестов в TEST_MAPPING файлов в /path/to/project и его родительские каталоги

      atest --test-mapping /path/to/project:mainline-presubmit
      

  3. Запустите тесты в файлах TEST_MAPPING, включая подкаталоги.

По умолчанию atest ищет тесты только в файлах TEST_MAPPING вверх (от текущего или заданного до его родительских каталогов). Если вы хотите запустить тесты в TEST_MAPPING файлы в подкаталогах, вы можете использовать опцию --include-subdirs , чтобы заставить ATEST включить эти тесты , а также.

Выполнение тестов presubmit в TEST_MAPPING файлы в текущем, родителей и подкаталогов:

atest --include-subdirs /path/to/project

Выполнение тестов в итерации

Для запуска тестов в итерации, просто передать --iterations аргумент. Независимо от того, проходит он или не проходит, atest не остановит тестирование, пока не будет достигнута максимальная итерация.

Примеры:

По умолчанию atest повторяется 10 раз, давая целое число для изменения раунда итерации.

atest test-to-run --iterations
atest test-to-run --iterations 5

Два подхода, которые помогают пользователям обнаруживать нестабильные тесты:

Подход 1. Запускать все тесты до тех пор, пока не произойдет сбой или не будет достигнута максимальная итерация.

  • Остановитесь, когда произойдет сбой или итерация достигнет 10-го (по умолчанию) раунда.
    atest test-to-run --rerun-until-failure
    
  • Остановитесь, когда произойдет сбой или итерация достигнет 100-го раунда.
    atest test-to-run --rerun-until-failure 100
    

Подход 2: запускать только неудачные тесты до тех пор, пока не будет пройдена или не будет достигнута максимальная итерация.

  • Предположим test-to-run пять тестовых случаев и один из тестов не удается. Выполните только неудавшийся тест 10 раз или пока тест не пройдет успешно.
    atest test-to-run --retry-any-failure
    
  • Прекратите выполнение неудавшегося теста, когда он пройдет или достигнет 100-го раунда.
    atest test-to-run --retry-any-failure 100
    

Запуск тестов на AVD

Atest может запускать тесты с недавно созданным AVD. Atest может строить артефакты вместе с запуском acloud create и выполнения тестов после AVD был успешно создан.

Примеры:

  • Запустите AVD перед запуском тестов на этом недавно созданное устройстве:

    acloud create --local-instance --local-image && atest test-to-run
    

  • Начало AVDS по задав acloud create аргументы и запустить тесты на этом недавно созданное устройстве.

    atest test-to-run --acloud-create "--local-instance --local-image"
    

Чтобы получить Применяемость о аргументе, запустить acloud create --help .

Передать параметры в модуль

Atest может передавать параметры модулям. Формат краток в командной строке ATEST добавить TradeFed параметр командной строки является

atest test-to-run -- [CUSTOM_ARGS]
В [CUSTOM_ARGS] должна следовать команда Tradefed форматов опций линии.

Примеры передачи параметров тестового модуля целевым составителям или исполнителям тестов, определенным в файле конфигурации теста:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

Примеры передачи параметров типу или классу бегуна:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

Для получения более подробной информации о тестируемых только варианты, см варианты перейти к модулям