AOSP включает шаблоны тестирования для тестовых модулей, которые не являются подклассом Python на стороне хоста для BaseTest средства запуска VTS.
Разработчики могут использовать эти шаблоны, чтобы упростить интеграцию таких тестов. В этом разделе рассказывается, как настраивать и использовать шаблоны тестов (находящиеся в каталоге 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 поддерживает следующие варианты конфигурации:
| Название варианта | Тип значения | Описание |
|---|---|---|
| binary-test-source | струны | Пути к исходным файлам тестов в двоичном формате относительно каталога тестовых случаев VTS на хосте. Пример: DATA/nativetest/test |
| binary-test-working-directory | струны | Рабочие каталоги (путь на устройстве). Пример: /data/local/tmp/testing/ |
| binary-test-envp | струны | Переменные среды для двоичного файла. Пример: PATH=/new:$PATH |
| binary-test-args | струны | Аргументы или флаги теста. Пример: --gtest_filter=test1 |
| binary-test-ld-library-path | струны | переменной среды LD_LIBRARY_PATH.Пример: /data/local/tmp/lib |
| binary-test-disable-framework | Логическое значение | Выполните команду adb stop, чтобы отключить Android Framework перед тестированием.
Пример: true |
| binary-test-stop-native-servers | Логическое значение | Во время тестирования остановите все правильно настроенные собственные серверы. Пример:
true |
| binary-test-type | строка | Тип шаблона. Другие типы шаблонов расширяют этот шаблон, но вам не нужно указывать этот параметр для этого шаблона, поскольку вы уже указали 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. Чтобы интегрировать тесты на целевом устройстве, сначала нужно передать на него файлы тестов, выполнить тесты с помощью команд оболочки, а затем проанализировать результаты с помощью скриптов 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:
| Название варианта | Тип значения | Описание |
|---|---|---|
| binary-test-type | строка | Тип шаблона. Используется значение gtest. |
| gtest-batch-mode | Логическое значение | Запускать исполняемые файлы Gtest в пакетном режиме. Пример: true |
В целом, если для параметра gtest-batch-mode задать значение true, производительность повысится, а надежность немного снизится. В тестах на соответствие VTS многие модули используют пакетный режим для повышения производительности. Однако для обеспечения надежности, если режим не указан, по умолчанию используется режим без пакетной обработки.
Режим без пакетной обработки
В режиме без пакета выполняются отдельные вызовы двоичного файла GTest для каждого тестового примера. Для Например, если исполняемый файл GTest содержит 10 отчетов о тестировании (после фильтрации по конфигурации на стороне хоста), исполняемый файл вызывается 10 раз в оболочке устройства каждый раз с другим тестовым фильтром. Для каждого тестового случая создается уникальный XML-файл с результатами GTest, который обрабатывается шаблоном.
Преимущества использования режима без пакетной обработки:
- Изоляция тестовых случаев. Сбой или зависание в одном тестовом случае не влияет на другие.
- Детализация. Проще получить профилирование/покрытие для каждого тестового случая измерение, systrace, bugreport, logcat и т. д. Результаты тестов и журналы извлекаются сразу после завершения каждого тестового случая.
Недостатки использования режима без пакетной обработки:
- Избыточная загрузка. Каждый раз, когда вызывается двоичный файл GTest, он загружает связанные библиотеки и выполняет начальную настройку класса.
- Служебный трафик. После завершения теста хост и целевое устройство обмениваются данными для анализа результатов и выполнения следующих команд (в будущем возможна оптимизация).
Пакетный режим
В пакетном режиме GTest исполняемый файл теста вызывается только один раз с длинным значением фильтра test, содержащим все тестовые случаи, отфильтрованные конфигурацией на стороне хоста (это позволяет избежать проблемы избыточной загрузки в непакетном режиме). Результаты тестирования GTest можно анализировать с помощью файла output.xml или вывода в терминале.
При использовании файла output.xml (по умолчанию):
Как и в случае с непакетным режимом, результат теста анализируется с помощью выходного XML-файла GTest. Однако поскольку выходной XML-файл создается после завершения всех тестов, если в результате тестирования произошел сбой исполняемого файла или устройства, XML-файл с результатами не создается.
При использовании вывода терминала:
Во время выполнения GTest выводит в терминал журнал тестирования и информацию о ходе выполнения в формате, который можно проанализировать с помощью фреймворка для получения данных о статусе, результатах и журналах тестирования.
Преимущества пакетного режима:
- Изоляция тестовых случаев. Обеспечивает такой же уровень изоляции тестовых случаев, как и режим без пакетов, если после сбоя фреймворк перезапускает двоичный файл или устройство с уменьшенным фильтром тестирования (исключая завершенные и аварийные тестовые случаи).
- Детализация. Обеспечивает такую же детализацию отчетов о тестировании, как и в обычном режиме.
Недостатки пакетного режима:
- Стоимость обслуживания. Если формат журнала GTest изменится, все тесты будут нарушены.
- Замешательство. Тестовый случай может выводить данные в формате, похожем на формат GTest, что может привести к путанице.
Поэтому мы временно убрали возможность использовать вывод командной строки. Мы вернемся к этому варианту в будущем, чтобы повысить надежность функции.
Шаблон HostBinaryTest
Шаблон HostBinaryTest содержит исполняемые файлы на стороне хоста, которых нет в других каталогах или скриптах Python. В частности, мы проводим следующие тесты:
- Скомпилированные исполняемые файлы тестов на хосте
- исполняемые скрипты на языке Shell, Python или других языках;
Пример: VTS Security SELinux policy host-side test.
<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 имеют следующие расширения:
Разработчики могут расширять существующие шаблоны в соответствии с требованиями к тестированию. Распространенные причины для расширения шаблонов:
- Специальные процедуры тестирования, например подготовка устройства с помощью специальных команд.
- Генерировать разные тестовые сценарии и названия тестов.
- Анализ результатов путем чтения результата выполнения команды или использования других условий.
Чтобы упростить расширение существующих шаблонов, в них содержатся методы, предназначенные для каждой функции. Если у вас есть улучшенные варианты дизайна для существующих шаблонов, мы рекомендуем вам внести свой вклад в базу кода VTS.