Эта страница переведена с помощью Cloud Translation API.

Шаблоны тестов

AOSP включает тестовые шаблоны для тестовых модулей, которые не являются подклассом Python на стороне хоста BaseTest VTS runner.

Рисунок 1. Архитектура тестового шаблона.

Разработчики могут использовать эти шаблоны, чтобы свести к минимуму усилия по интеграции таких тестов. В этом разделе описывается настройка и использование шаблонов тестов (расположенных в каталоге VTS testcases/template ) и приводятся примеры часто используемых шаблонов.

Шаблон BinaryTest

Используйте шаблон BinaryTest для интеграции тестов, которые выполняются на целевом устройстве в VTS. Целевые тесты включают в себя:

Тесты на основе C++ скомпилированы и отправлены на устройство
Целевые тесты Python , скомпилированные в виде двоичных файлов
Сценарии оболочки, исполняемые на устройствах

Эти тесты можно интегрировать в VTS с помощью шаблона BinaryTest или без него.

Интеграция целевых тестов с шаблоном BinaryTest

Шаблон BinaryTest разработан, чтобы помочь разработчикам легко интегрировать тесты на стороне цели. В большинстве случаев вы можете добавить несколько простых строк конфигурации в AndroidTest.xml . Пример конфигурации из VtsDeviceTreeEarlyMountTest :

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

В этой конфигурации:

binary-test-source и binary-test-type зависят от шаблона.
Указание относительного пути к хосту тестового двоичного источника позволяет шаблону выполнять подготовку, отправку файлов, выполнение теста, анализ результатов и очистку.
Шаблон содержит методы, связанные с созданием тестового примера, для переопределения подклассов.
Шаблон предполагает наличие одного тестового примера на каждый тестовый двоичный модуль, а имя двоичного исходного файла используется в качестве имени тестового набора по умолчанию.

Варианты конфигурации

Шаблон BinaryTest поддерживает следующие параметры конфигурации:

Название опции	Тип значения	Описание
двоичный тестовый источник	струны	Пути к двоичным источникам тестов относительно каталога тестовых случаев vts на хосте. Пример: `DATA/nativetest/test`
двоичный-тестовый-рабочий-каталог	струны	Рабочие каталоги (путь на стороне устройства). Пример: `/data/local/tmp/testing/`
бинарный тест-envp	струны	Переменные среды для двоичного файла. Пример: `PATH=/new:$PATH`
бинарные-тестовые-аргументы	струны	Тестовые аргументы или флаги. Пример: `--gtest_filter=test1`
двоичный-тест-ld-библиотека-путь	струны	Переменная среды `LD_LIBRARY_PATH` . Пример: `/data/local/tmp/lib`
двоичный-тест-отключить-фреймворк	логический	Запустите `adb stop` , чтобы отключить Android Framework перед тестом. Пример: `true`
бинарные-тестовые-остановить-родные-серверы	логический	Остановите все правильно настроенные собственные серверы во время тестирования. Пример: `true`
двоичный тип теста	нить	Тип шаблона. Другие типы шаблонов являются производными от этого шаблона, но вам не нужно указывать эту опцию для этого шаблона, поскольку вы уже указали `binary-test-source` .

Для параметров со strings типами значений можно добавить несколько значений, повторив параметры в конфигурации. Например, дважды установите binary-test-source (как показано в примере VtsDeviceTreeEarlyMountTest ).

Тестовые теги

Вы можете добавить тестовые теги, поставив перед ними префикс со strings значениями и используя :: в качестве разделителя. Тестовые теги особенно полезны при включении бинарных источников с одинаковым именем, но с разной разрядностью или родительскими каталогами. Например, чтобы избежать отправки файлов или конфликта имен результатов для источников с одинаковым именем, но из разных исходных каталогов, вы можете указать разные теги для этих источников.

Как показано в примере VtsDeviceTreeEarlyMountTest с двумя источниками dt_early_mount_test , тестовые теги представляют собой _32bit:: и _64bit:: в binary-test-source . Теги, оканчивающиеся на 32bit или 64bit , автоматически помечают тесты как доступные для одной разрядности ABI; т.е. тесты с тегом _32bit не выполняются на 64-битном ABI. Отсутствие указания тега равносильно использованию тега с пустой строкой.

Опции с одинаковыми тегами группируются и изолируются от других тегов. Например, binary-test-args с тегом _32bit применяются только к binary-test-source с тем же тегом и выполняются в binary-test-working-directory с тем же тегом. Параметр binary-test-working-directory является необязательным для бинарных тестов, позволяя указать один рабочий каталог для тега. Если параметр binary-test-working-directory не указан, для каждого тега используются каталоги по умолчанию.

Имя тега непосредственно добавляется к имени тестового примера в отчете о результатах. Например, тестовый набор testcase1 с тегом _32bit отображается в отчете о результатах как testcase1_32bit .

Интеграция целевых тестов без шаблона BinaryTest

В VTS формат тестов по умолчанию — это тесты Python на стороне хоста, расширенные из BaseTest в VTS runner. Чтобы интегрировать тесты на стороне цели, вы должны сначала отправить тестовые файлы на устройство, выполнить тесты с помощью команд оболочки, а затем проанализировать результаты с помощью скриптов Python на стороне хоста.

Отправка тестовых двоичных файлов

Мы рекомендуем отправлять файлы с помощью средства подготовки цели VtsFilePusher . Пример:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

VtsFilePusher делает следующее:

Проверяет подключение устройства.
Определяет абсолютный путь к исходному файлу.
Отправляет файлы с помощью команды adb push .
Удаляет файлы после завершения тестов.

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

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

После отправки файлов на устройство запустите тест с помощью команд оболочки в тестовом сценарии Python на стороне хоста. Пример:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

Шаблон GtestBinaryTest

Шаблон GtestBinaryTest содержит двоичные файлы тестов GTest, каждый из которых обычно содержит несколько тестовых случаев. Этот шаблон расширяет шаблон BinaryTest, переопределяя настройку, создание тестового набора и методы синтаксического анализа результатов, поэтому все конфигурации BinaryTest наследуются.

GtestBinaryTest добавляет опцию gtest-batch-mode :

Название опции	Тип значения	Описание
двоичный тип теста	нить	Тип шаблона. Использует значение `gtest` .
gtest-пакетный режим	логический	Запустите двоичные файлы Gtest в пакетном режиме. Пример: `true`

В общем, установка gtest-batch-mode в true увеличивает производительность, но немного снижает надежность. В тестах на соответствие VTS многие модули используют пакетный режим для повышения производительности. Однако для надежности, если режим не указан, по умолчанию используется непакетный режим.

Непакетный режим

Непакетный режим делает отдельные вызовы двоичного файла GTest для каждого тестового случая. Например, если двоичный файл GTest содержит 10 тестовых случаев (после фильтрации по конфигурации на стороне хоста), двоичный файл вызывается 10 раз в оболочке устройства каждый раз с другим тестовым фильтром. Для каждого теста генерируется и анализируется шаблоном уникальный выходной XML-файл результатов GTest.

Рисунок 2. Непакетный режим.

К преимуществам использования непакетного режима относятся:

Изоляция тестовых случаев . Сбой или зависание в одном тестовом примере не влияет на другие тестовые случаи.
Гранулярность . Легче получить профилирование/измерение покрытия для каждого тестового случая, системную трассировку, отчет об ошибках, logcat и т. д. Результаты тестирования и журналы извлекаются сразу после завершения каждого тестового случая.

К недостаткам использования непакетного режима относятся:

Избыточная загрузка . Каждый раз, когда вызывается бинарный файл GTest, он загружает связанные библиотеки и выполняет начальную настройку класса.
Накладные расходы на связь . После завершения теста хост и целевое устройство обмениваются данными для анализа результатов и следующих команд (возможны будущие оптимизации).

Пакетный режим

В пакетном режиме GTest двоичный файл теста вызывается только один раз с длинным значением тестового фильтра, содержащим все тестовые случаи, отфильтрованные конфигурацией на стороне хоста (это позволяет избежать избыточной загрузки в непакетном режиме). Вы можете анализировать результаты теста для GTest, используя output.xml или используя вывод терминала.

При использовании output.xml (по умолчанию):

Рис. 3. Пакетный режим, output.xml.

Как и в непакетном режиме, результат теста анализируется через выходной XML-файл GTest. Однако, поскольку выходной XML-файл генерируется после завершения всех тестов, в случае сбоя в тестовом примере двоичного файла или устройства не создается результирующий XML-файл.

При использовании терминального вывода:

Рисунок 4. Пакетный режим, вывод терминала.

Во время работы GTest он печатает журнал тестирования и ход выполнения на терминал в формате, который может быть проанализирован платформой для определения статуса теста, результатов и журналов.

К преимуществам использования пакетного режима относятся:

Изоляция тестовых случаев . Обеспечивает тот же уровень изоляции тестовых случаев, что и непакетный режим, если инфраструктура перезапускает двоичный файл/устройство после сбоя с уменьшенным фильтром тестов (за исключением завершенных и аварийных тестовых случаев).
Гранулярность . Обеспечивает ту же степень детализации тестов, что и непакетный режим.

К недостаткам использования пакетного режима относятся:

Стоимость обслуживания . Если формат журнала GTest изменится, все тесты сломаются.
Путаница . Тестовый пример может печатать что-то похожее на формат прогресса GTest, что может запутать формат.

Из-за этих недостатков мы временно удалили возможность использования вывода командной строки. Мы вернемся к этому варианту в будущем, чтобы повысить надежность этой функции.

Шаблон HostBinaryTest

Шаблон HostBinaryTest включает исполняемые файлы на стороне хоста, которых нет в других каталогах или сценариях Python. Эти тесты включают в себя:

Скомпилированные тестовые двоичные файлы, исполняемые на хосте
Исполняемые сценарии в оболочке, Python или других языках

Одним из примеров является проверка политики VTS Security SELinux на стороне хоста :

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest не расширяет шаблон BinaryTest, но использует аналогичные тестовые конфигурации. В приведенном выше примере параметр binary-test-source указывает относительный путь на стороне хоста к исполняемому файлу теста, а binary-test-type — host_binary_test . Как и в случае с шаблоном BinaryTest, имя двоичного файла по умолчанию используется в качестве имени тестового примера.

Расширение существующих шаблонов

Вы можете использовать шаблоны непосредственно в конфигурации теста, чтобы включить тесты, отличные от Python, или расширить их в подклассе для обработки конкретных требований к тесту. Шаблоны в репозитории VTS имеют следующие расширения:

Рисунок 5. Расширение существующих шаблонов в репозитории VTS.

Разработчикам рекомендуется расширить любой существующий шаблон для любых конкретных тестовых требований. Общие причины для расширения шаблонов включают в себя:

Специальные процедуры настройки теста, такие как подготовка устройства с помощью специальных команд.
Создание различных тестовых случаев и названий тестов.
Анализ результатов путем чтения вывода команды или использования других условий.

Чтобы упростить расширение существующих шаблонов, шаблоны содержат методы, специализированные для каждой функции. Если вы улучшили дизайн существующих шаблонов, мы рекомендуем вам внести свой вклад в кодовую базу VTS.