Проект Android Open Source Project (AOSP) предоставляет несколько инструментов и наборов тестов для тестирования различных частей вашей реализации. Перед использованием страниц этого раздела вам следует ознакомиться со следующими терминами:
- Android-совместимое устройство
- Устройство, на котором может запускаться любое стороннее приложение, написанное сторонними разработчиками с использованием Android SDK и NDK. Устройства, совместимые с Android, должны соответствовать требованиям документа определения совместимости (CDD) и проходить набор тестов на совместимость (CTS) . Устройства, совместимые с Android, могут участвовать в экосистеме Android, что включает в себя потенциальное лицензирование Google Play, потенциальное лицензирование набора приложений и API Google Mobile Services (GMS) , а также использование товарного знака Android. Любой может использовать исходный код Android, но для того, чтобы считаться частью экосистемы Android, устройство должно быть совместимым с Android.
- артефакт
- Журнал сборки, позволяющий осуществлять локальный поиск и устранение неисправностей.
- Документ определения совместимости (CDD)
- Документ, в котором перечислены требования к программному и аппаратному обеспечению для Android-совместимого устройства.
- Набор тестов совместимости (CTS)
Бесплатный коммерческий тестовый набор, доступный для загрузки в виде исполняемого файла или исходного кода в AOSP. CTS — это набор модульных тестов, разработанных для интеграции в ваш повседневный рабочий процесс. Цель CTS — выявить несовместимости и обеспечить совместимость программного обеспечения на протяжении всего процесса разработки.
CTS и платформенные тесты не являются взаимоисключающими. Вот несколько общих рекомендаций:
- Если тест подтверждает правильность функций или поведения API фреймворка и его необходимо применять ко всем OEM-партнерам, то его следует включить в CTS.
- Если тест предназначен для выявления регрессий во время разработки платформы и для его проведения могут потребоваться привилегированные разрешения, а также он может зависеть от деталей реализации (опубликованных в AOSP), то это должен быть платформенный тест.
- Мобильные службы Google (GMS)
Коллекция приложений и API Google, которые можно предустановить на устройства.
- GoogleTest (GTest)
Фреймворк тестирования и имитации C++. Двоичные файлы GTest обычно обращаются к низкоуровневым уровням абстракции или выполняют прямое межпроцессное взаимодействие (IPC) с различными системными службами. Подход к тестированию в GTest обычно тесно связан с тестируемой службой. CTS содержит фреймворк GTest.
- инструментальный тест
Специальная среда выполнения тестов, запускаемая командой
am instrument
, в которой целевой процесс приложения перезапускается и инициализируется с базовым контекстом приложения, а внутри виртуальной машины процесса приложения запускается поток инструментирования. CTS содержит тесты инструментирования.- Логкат
Инструмент командной строки, который создает журнал системных сообщений, включая трассировки стека ошибок, выдаваемых устройством, и сообщения, записанные из вашего приложения с помощью класса
Log
.- ведение журнала
Использование журнала для отслеживания событий компьютерной системы, таких как ошибки. Ведение журнала в Android затруднено из-за сочетания различных стандартов, объединенных в инструменте Logcat.
- тест после отправки
Тест Android, выполняемый при добавлении нового патча в общую ветку ядра. Введя
aosp_kernel
в качестве частичного имени ветки, можно увидеть список веток ядра с доступными результатами. Например, результаты дляandroid-mainline
можно найти по адресу https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .- предварительный тест
Тест, используемый для предотвращения появления сбоев в общих ядрах.
- Торговая федерация
Также известный как Tradefed, это фреймворк непрерывного тестирования, разработанный для запуска тестов на устройствах Android. Например, Tradefed используется для запуска тестов Compatibility Test Suite и Vendor Test Suite.
- Тестовый набор поставщика (VTS)
Набор расширенных возможностей для тестирования Android, способствующий процессу разработки через тестирование, а также автоматизации уровня абстракции оборудования (HAL) и тестирования ядра ОС.
Типы платформенных тестов
Тест платформы обычно взаимодействует с одной или несколькими системными службами Android или слоями HAL, проверяет функциональность тестируемого объекта и подтверждает корректность результатов тестирования. Тест платформы может:
- (Тип 1) API-интерфейсы фреймворка, использующие фреймворк Android. Примеры API, которые могут быть реализованы, включают:
- Публичные API, предназначенные для сторонних приложений
- Скрытые API, предназначенные для привилегированных приложений, а именно системные API или частные API (
@hide
илиprotected
,package private
)
- (Тип 2) Вызов системных служб Android напрямую с помощью raw-binder или прокси-серверов IPC.
- (Тип 3) Взаимодействовать напрямую с HAL, используя низкоуровневые API или интерфейсы IPC.
Тесты типа 1 и 2 обычно являются инструментальными тестами, тогда как тесты типа 3 обычно являются GTests.
Что дальше?
Вот список документов, с которыми вы можете ознакомиться для получения более подробной информации:
Если вы не изучали архитектуру Android, см. Обзор архитектуры .
Если вы создаете устройство, совместимое с Android, ознакомьтесь с обзором программ совместимости Android .
Чтобы интегрировать инструментальные, функциональные, метрические и JAR-тесты в службу непрерывного тестирования платформы, см . раздел Рабочий процесс разработки тестов .
Чтобы обнаружить уязвимости и защитить свои устройства от них, см. раздел Тестирование безопасности .
Информацию о тестировании реализаций HAL и ядра см. в разделе Набор тестов поставщика (VTS) и инфраструктура .
Для тестирования приложений ознакомьтесь с разделом «Основы тестирования приложений Android» и проведите тест « Advanced Android in Kotlin 05.1:Testing Basics», используя предоставленные примеры .
Узнайте о базовом тестировании перед отправкой, доступном через хуки репозитория. Эти хуки можно использовать для запуска линтеров, проверки форматирования и запуска модульных тестов перед дальнейшими действиями, такими как загрузка коммита. По умолчанию эти хуки отключены. Подробнее см. в разделе «Хуки предварительной загрузки AOSP» .
Дополнительную информацию о ведении журнала см. в разделе Понимание ведения журнала .
Чтобы понять, как отлаживать код Android, ознакомьтесь со статьей Отладка собственного кода платформы Android .