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
.