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

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

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

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

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

Шаблон бинарного теста

Используйте шаблон 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 `binary-test-source` .

Для параметров со strings типом значения вы можете добавить несколько значений, повторяя параметры в конфигурации. Например, дважды установитеbinary 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 binary-test-working-directory является необязательной для бинарных тестов и позволяет указать для тега один рабочий каталог. Если binary-test-working-directory не указан, для каждого тега используются каталоги по умолчанию.

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

Интегрируйте тесты на целевой стороне без шаблона BinaryTest.

В VTS форматом тестов по умолчанию являются тесты Python на стороне хоста, расширенные из BaseTest в средстве запуска VTS. Чтобы интегрировать тесты на целевой стороне, вы должны сначала отправить тестовые файлы на устройство, выполнить тесты с помощью команд оболочки, а затем проанализировать результаты с помощью сценариев 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 или вывод терминала.

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

Рисунок 3. Пакетный режим, выходной файл.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.