Тест

Atest - это инструмент командной строки, который позволяет пользователям создавать, устанавливать и запускать тесты Android локально, что значительно ускоряет повторные запуски тестов, не требуя знания параметров командной строки средства тестирования Trade Federation . На этой странице объясняется, как использовать Atest для запуска тестов Android.

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

Для получения информации об общей структуре Atest см. Руководство разработчика Atest .

Для получения информации о запуске тестов в файлах TEST_MAPPING через Atest см. Запуск тестов в файлах TEST_MAPPING .

А чтобы добавить функцию в Atest, следуйте Atest Developer Workflow .

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

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

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

Установите test_suite для Soong или LOCAL_COMPATIBILITY_SUITE для правил сценария сборки Make per 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` файла `module-info.json` .
`-w`	`--wait-for-debugger`	Ожидает отладчика перед выполнением. Только для инструментальных испытаний.
`-v`	`--verbose`	Отображает ведение журнала уровня DEBUG.
	`--iterations`	Зацикливает тесты, пока не будет достигнута максимальная итерация. (По умолчанию 10)
	`--rerun-until-failure`	Повторно выполняет все тесты до тех пор, пока не произойдет сбой или не будет достигнута максимальная итерация. (По умолчанию 10)
	`--retry-any-failure`	Повторяет неудачные тесты до тех пор, пока не будет пройден или не будет достигнута максимальная итерация. (По умолчанию 10)
	`--start-avd`	Автоматически создает AVD и запускает тесты на виртуальном устройстве.
	`--acloud-create`	Создает AVD с помощью команды `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 с именем модуля теста, Module: Class, именем класса, тестом интеграции TF, путем к файлу или именем пакета.

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

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

Примеры:

atest FrameworksServicesTests
atest CtsVideoTestCases

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

Чтобы запустить отдельный класс в модуле, используйте Module: 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 по пути

Запускаем модуль из repo-root Android:
```
atest cts/tests/video
```
Из repo-root Android / cts / tests / video:
```
atest .
```

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

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

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

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

Имя пакета

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

Примеры:

atest com.android.server.wm
atest android.jank.cts

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

Вы можете указать, какие шаги выполнять, используя параметры -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 найти тест намного быстрее:

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

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Из repo-root Android

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 (32-разрядная версия ARM) и arm64-v8a (64-разрядная версия ARM).

Примеры:

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

atest -a libinput_tests inputflinger_tests

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

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

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

atest inputflinger_tests:InputDispatcherTest

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

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

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

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

Примеры:

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

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

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

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

Остановитесь, когда произойдет сбой или итерация достигнет 10-го (по умолчанию) раунда.
```
atest test-to-run --rerun-until-failure
```
Остановитесь, когда произойдет сбой или итерация достигнет сотого раунда.
```
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 и запускать тесты после acloud create AVD.

Примеры:

Запустите AVD перед запуском тестов на этом вновь созданном устройстве:
```
acloud create && atest test-to-run
```
Теперь это можно упростить:
```
atest test-to-run --start-avd
```
Запустите AVD, acloud create аргументы acloud create и запустите тесты на этом вновь созданном устройстве.
```
atest test-to-run --acloud-create "--build-id 6509363 --build-target aosp_cf_x86_phone-userdebug --branch aosp_master"
```

Чтобы получить подробную информацию об использовании аргумента, запустите acloud create --help .