AOSP включает набор тестов графического процессора drawElements Quality Program (deqp) по адресу https://android.googlesource.com/platform/external/deqp . На этой странице подробно описано, как развернуть набор тестов deqp в новой среде.
Для работы с последним отправленным кодом используйте ветку deqp-dev . Для кода, соответствующего определённому выпуску Android CTS, используйте ветку release-code-name -release (например, для Android 6.0 используйте ветку marshmallow-release ).
Исходный макет
Исходный код тестовых модулей deqp и вспомогательных библиотек представлен в таблице ниже (список не является полным, но выделяет наиболее важные каталоги).
| Каталог | Описание |
|---|---|
android | Исходные коды и скрипты сборки для Android-тестеров |
data | Файлы тестовых данных |
modules | Исходные тексты тестовых модулей |
modules/egl | Модуль EGL |
modules/gles2 | Модуль GLES2 |
modules/gles3 | Модуль GLES3 |
modules/gles31 | Модуль GLES3.1 |
modules/gles32 | Модуль GLES3.2 |
targets | Файлы конфигурации сборки для конкретных целей |
framework | фреймворк и утилиты тестового модуля deqp |
framework/delibs | Базовая переносимость и библиотеки сборки |
framework/platform | Платформенные порты |
framework/qphelper | Библиотека интеграции тестовых программ (C) |
framework/common | Фреймворк Deqp (C++) |
framework/opengl, framework/egl | API-специфичные утилиты |
execserver | Источник ExecServer на стороне устройства |
executor | Инструмент и утилиты оболочки тестового исполнителя на стороне хоста |
external | Создать каталог-заглушку для внешних библиотек libpng и zlib |
Компоненты с открытым исходным кодом
Deqp использует libpng и zlib , которые можно загрузить с помощью скрипта platform/external/deqp/external/fetch_sources.py или через git из platform/external/[libpng,zlib] .
Создание тестовых программ
Тестовый фреймворк разработан с учётом переносимости. Единственными обязательными требованиями являются полная поддержка C++ и стандартные системные библиотеки для ввода-вывода, потоков и сокетов.
Система сборки CMake
Исходные коды deqp содержат скрипты сборки для CMake, который является предпочтительным инструментом для компиляции тестовых программ.
CMake — это система сборки с открытым исходным кодом, поддерживающая множество платформ и наборов инструментов. CMake генерирует собственные make-файлы или файлы проектов IDE из файлов конфигурации, не зависящих от целевой платформы. Подробнее о CMake см. в документации CMake .
CMake поддерживает и рекомендует сборку вне исходного дерева, то есть всегда следует создавать make-файлы или файлы проекта в отдельном каталоге сборки вне исходного дерева. В CMake нет цели distclean, поэтому удаление любых файлов, созданных CMake, необходимо выполнять вручную.
Параметры конфигурации передаются CMake с помощью синтаксиса -D OPTION_NAME = VALUE . Некоторые часто используемые параметры deqp перечислены ниже.
| Вариант конфигурации | Описание |
|---|---|
DEQP_TARGET | Имя цели, например: «android» Скрипты deqp CMake будут включать файл |
CMAKE_TOOLCHAIN_FILE | Путь к файлу набора инструментов для CMake. Используется для кросс-компиляции. |
CMAKE_BUILD_TYPE | Тип сборки для целей makefile. Допустимые значения: «Debug» и «Release». Обратите внимание, что интерпретация и тип по умолчанию зависят от целевой системы сборки. Подробности см. в документации CMake. |
Создайте целевой файл сборки
Система сборки deqp настраивается для новых целевых платформ с помощью целевых файлов сборки. Целевой файл сборки определяет, какие функции поддерживает платформа, а также какие библиотеки или дополнительные пути include необходимы. Имена целевых файлов имеют формат targets/ NAME / NAME .cmake , а целевой сервер выбирается с помощью параметра сборки DEQP_TARGET .
Пути к файлам в целевых файлах указываются относительно базового каталога deqp , а не каталога targets/ NAME . В файле целевой сборки могут быть заданы следующие стандартные переменные.
| Переменная | Описание |
|---|---|
DEQP_TARGET_NAME | Имя цели (будет включено в журналы тестирования) |
DEQP_SUPPORT_GLES2 | Поддерживается ли GLES2 (по умолчанию: ВЫКЛ) |
DEQP_GLES2_LIBRARIES | Библиотеки GLES2 (оставьте пустыми, если не поддерживаются или используется динамическая загрузка) |
DEQP_SUPPORT_GLES3 | Поддерживается ли GLES3.x (по умолчанию: ВЫКЛ) |
DEQP_GLES3_LIBRARIES | Библиотеки GLES3.x (оставьте пустыми, если не поддерживаются или используется динамическая загрузка) |
DEQP_SUPPORT_VG | Поддерживается ли OpenVG (по умолчанию: ВЫКЛ) |
DEQP_OPENVG_LIBRARIES | Библиотеки OpenVG (оставьте пустым, если не поддерживаются или используется динамическая загрузка) |
DEQP_SUPPORT_EGL | Поддерживается ли EGL (по умолчанию: ВЫКЛ) |
DEQP_EGL_LIBRARIES | Библиотеки EGL (оставьте пустым, если не поддерживаются или используется динамическая загрузка) |
DEQP_PLATFORM_LIBRARIES | Для компоновки требуются дополнительные библиотеки, специфичные для платформы |
DEQP_PLATFORM_COPY_LIBRARIES | Список библиотек, копируемых в каждый каталог сборки тестовых двоичных файлов. Может использоваться для копирования библиотек, необходимых для запуска тестов, но отсутствующих в пути поиска по умолчанию. |
TCUTIL_PLATFORM_SRCS | Список источников портов платформы. Источники по умолчанию определяются на основе возможностей и ОС. Примечание: пути указаны относительно: |
В целевой файл сборки можно добавлять дополнительные пути включения или ссылки с помощью функций CMake include_directories() и link_directories() .
Сборка Win32
Самый простой способ собрать модули deqp для Windows — использовать систему сборки CMake. Вам потребуется CMake 2.6.12 или более поздняя версия и компилятор Microsoft Visual C/C++. Модуль deqp протестирован в Visual Studio 2013.
Файлы проекта Visual Studio можно создать с помощью следующей команды:
cmake path\to\src\deqp -G "Visual Studio 12"
64-битную сборку можно создать, выбрав «Visual Studio VERSION Win64» в качестве генератора сборки:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Вы также можете сгенерировать make-файлы NMake с помощью параметра -G "NMake Makefiles" , а также типа сборки ( -DCMAKE_BUILD_TYPE="Debug" или "Release" ).
Создание контекста рендеринга
Контекст рендеринга можно создать либо с помощью WGL, либо с помощью EGL в Windows.
Поддержка WGL
Все исполняемые файлы Win32 поддерживают создание контекста GL с помощью WGL, поскольку для этого требуются только стандартные библиотеки. Контекст WGL можно выбрать с помощью аргумента командной строки --deqp-gl-context-type=wgl . В режиме WGL deqp использует расширение WGL_EXT_create_context_es_profile для создания контекстов OpenGL ES. Это протестировано на совместимость с последними драйверами NVIDIA и Intel. Драйверы AMD не поддерживают требуемое расширение.
Поддержка EGL
Deqp собирается с динамической загрузкой EGL в Windows, если DEQP_SUPPORT_EGL включен. Это значение по умолчанию для большинства целевых платформ. Если на хосте доступны библиотеки EGL, можно запустить тесты с ними, используя параметр командной строки: --deqp-gl-context-type=egl
Сборка Android
Сборка Android использует скрипты сборки CMake для сборки нативного тестового кода. Компоненты Java, такие как Test Execution Server и Test Application Stub, компилируются с помощью стандартных инструментов сборки Android.
Для компиляции тестовых программ deqp для Android с предоставленными скриптами сборки вам понадобится:
- Последняя версия Android NDK ; в файле
android/scripts/common.pyуказана необходимая версия. - Автономный SDK Android с установленными пакетами API 13, SDK Tools, SDK Platform-tools и SDK Build-tools
- Apache Ant 1.9.4 (требуется для сборки кода Java)
- CMake 2.8.12 или новее
- Python 2.6 или новее в серии 2.x; Python 3.x не поддерживается
- Для Windows: NMake или JOM в
PATH- JOM обеспечивает более быструю сборку
- Дополнительно: Ninja make также поддерживается в Linux.
Бинарные файлы Ant и SDK находятся в соответствии с переменной окружения PATH с некоторыми переопределяющими значениями по умолчанию. Логика контролируется файлом android/scripts/common.py .
Каталог NDK должен быть либо ~/android-ndk- VERSION , либо C:/android/android-ndk- VERSION , либо определен через переменную среды ANDROID_NDK_PATH .
Компоненты Deqp на устройстве, служба выполнения тестов и тестовые программы собираются с помощью скрипта android/scripts/build.py . Финальный APK-файл создаётся в каталоге android/package/bin и может быть установлен скриптом install.py . При использовании исполняемого файла командной строки служба ExecService запускается скриптом launch.py на устройстве через ADB. Скрипты можно запускать из любого каталога.
Сборка Linux
Тестовые исполняемые файлы и утилиты командной строки можно собрать для Linux, создав make-файлы с помощью CMake. Существует множество предопределённых целей сборки, которые полезны при сборке для Linux.
| Цель сборки | Описание |
|---|---|
default | Цель по умолчанию, которая использует интроспекцию платформы CMake для определения поддержки различных API. |
x11_glx | Использует GLX для создания контекстов OpenGL (ES). |
x11_egl | Использует EGL для создания контекстов OpenGL (ES). |
x11_egl_glx | Поддерживает GLX и EGL с X11. |
Всегда используйте -DCMAKE_BUILD_TYPE=<Debug|Release> для определения типа сборки. Release — хороший вариант по умолчанию. Без него будет создана стандартная, неоптимизированная сборка release.
Аргументы командной строки -DCMAKE_C_FLAGS и -DCMAKE_CXX_FLAGS можно использовать для передачи дополнительных аргументов компилятору. Например, 32- или 64-битную сборку можно выполнить, установив -DCMAKE_C(XX)_FLAGS="-m32" или "-m64" соответственно. Если не указано иное, используется собственная архитектура набора инструментов, обычно 64-битная в 64-битном наборе инструментов.
Аргументы -DCMAKE_LIBRARY_PATH и -DCMAKE_INCLUDE_PATH можно использовать для CMake, чтобы предоставить CMake дополнительную библиотеку или включить пути поиска.
Ниже приведен пример полной командной строки, используемой для выполнения 32-битной отладочной сборки с использованием заголовков и библиотек драйверов в пользовательском расположении:
cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32" -DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_LIBRARY_PATH="PATH_TO_DRIVER/lib" -DCMAKE_INCLUDE_PATH="PATH_TO_DRIVER/inc"make -j4
Кросс-компиляция
Кросс-компиляция может быть реализована с помощью файла набора инструментов CMake. В файле набора инструментов указан используемый компилятор, а также пути поиска библиотек и заголовочных файлов. Несколько файлов набора инструментов для распространённых сценариев включены в пакет релиза в каталоге framework/delibs/cmake .
Помимо стандартных переменных CMake, файл цепочки инструментов может установить следующие специфичные для deqp переменные. CMake обычно корректно определяет DE_OS , DE_COMPILER и DE_PTR_SIZE , но DE_CPU должен быть установлен в файле цепочки инструментов.
| Переменная | Описание |
|---|---|
DE_OS | Операционная система. Поддерживаемые значения: |
DE_COMPILER | Тип компилятора. Поддерживаемые значения: |
DE_CPU | Тип процессора. Поддерживаемые значения: |
DE_PTR_SIZE | sizeof(void*) на платформе. Поддерживаемые значения: 4 и 8. |
Файл набора инструментов можно выбрать с помощью параметра сборки CMAKE_TOOLCHAIN_FILE . Например, следующая команда создаст make-файлы для сборки с использованием кросс-компилятора CodeSourcery для ARM/Linux:
cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release" –DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake –DARM_CC_BASE=PATH_TO_CC_DIRECTORY
Связывание библиотек GLES и EGL во время выполнения
Deqp не требует точек входа тестируемого API во время линковки. Тестовый код всегда обращается к API через указатели на функции. Точки входа могут быть загружены динамически во время выполнения, или порт платформы может предоставить их во время линковки.
Если поддержка API включена в настройках сборки, а библиотеки для компоновки не предоставлены, deqp загрузит необходимые точки входа во время выполнения. Если требуется статическая компоновка, укажите необходимые библиотеки для компоновки в переменной конфигурации сборки DEQP_<API>_LIBRARIES .
Перенесите тестовую структуру
Перенос deqp включает три этапа: адаптацию базовых библиотек переносимости, реализацию интерфейсов интеграции платформы тестовой среды и перенос службы выполнения.
В таблице ниже перечислены вероятные места для переноса изменений. Всё, что находится за пределами этих мест, скорее всего, будет экзотикой.
| Расположение | Описание |
|---|---|
framework/delibs/debase | Любые необходимые реализации кода, специфичного для ОС. |
framework/qphelper/qpCrashHandler.c | Необязательно: реализация для вашей ОС. |
framework/qphelper/qpWatchDog.c | Реализация для вашей ОС. Текущая реализация основана на |
framework/platform | Новый порт платформы и заглушка приложения могут быть реализованы, как описано в разделе Порт платформы тестовой среды . |
Базовые библиотеки переносимости
Базовые библиотеки переносимости уже поддерживают Windows, большинство версий Linux, Mac OS, iOS и Android. Если тестовая платформа работает в одной из этих операционных систем, скорее всего, нет необходимости в базовых библиотеках переносимости.
Порт платформы тестового фреймворка
Для порта платформы тестового фреймворка deqp требуются два компонента: точка входа приложения и реализация интерфейса платформы.
Точка входа приложения отвечает за создание объекта платформы, создание объекта командной строки ( tcu::CommandLine ), открытие журнала тестирования ( tcu::TestLog ) и итерацию тестового приложения ( tcu::App ). Если целевая ОС поддерживает стандартную точку входа main() , в качестве реализации точки входа можно использовать tcuMain.cpp .
API платформы deqp подробно описан в следующих файлах.
| Файл | Описание |
|---|---|
framework/common/tcuPlatform.hpp | Базовый класс для всех портов платформы |
framework/opengl/gluPlatform.hpp | Интерфейс платформы OpenGL |
framework/egl/egluPlatform.hpp | Интерфейс платформы EGL |
framework/platform/tcuMain.cpp | Стандартная точка входа приложения |
Базовым классом для всех портов платформы является tcu::Platform . Порт платформы может опционально поддерживать интерфейсы, специфичные для GL и EGL. Обзор необходимых для запуска тестов компонентов см. в таблице ниже.
| Модуль | Интерфейс |
|---|---|
Тестовые модули OpenGL (ES) | Интерфейс платформы GL |
Тестовый модуль EGL | Интерфейс платформы EGL |
Подробные инструкции по реализации портов платформы содержатся в заголовках уровня портирования.
Служба выполнения тестов
Для использования инфраструктуры выполнения тестов deqp или исполнителя командной строки служба выполнения тестов должна быть доступна на целевой системе. Переносимая реализация службы на C++ доступна в каталоге execserver . Отдельный двоичный файл собирается как часть сборки тестового модуля deqp для ПК. Вы можете изменить execserver/CMakeLists.txt чтобы включить сборку на других целевых системах.
Версия C++ службы выполнения тестов принимает два параметра командной строки:
-
--port=<port>задаёт TCP-порт, который прослушивает сервер. Значение по умолчанию — 50016. -
--singleзавершит серверный процесс при отключении клиента. По умолчанию серверный процесс продолжит работу для обслуживания дальнейших запросов на выполнение тестов.
Запустите тесты
На этой странице представлены инструкции по запуску тестов deqp в средах Linux и Windows, использованию аргументов командной строки и работе с пакетом приложений Android.
Среды Linux и Windows
Начните с копирования следующих файлов и каталогов на целевой диск.
| Модуль | Каталог | Цель |
|---|---|---|
| Сервер исполнения | build/execserver/execserver | <dst>/execserver |
| Модуль EGL | build/modules/egl/deqp-egl | <dst>/deqp-egl |
| Модуль GLES2 | build/modules/gles2/deqp-gles2 | <dst>/deqp-gles2 |
data/gles2 | <dst>/gles2 | |
| Модуль GLES3 | build/modules/gles3/deqp-gles3 | <dst>/deqp-gles3 |
data/gles3 | <dst>/gles3 | |
| Модуль GLES3.1 | build/modules/gles31/deqp-gles31 | <dst>/deqp-gles31 |
data/gles31 | <dst>/gles31 | |
| Модуль GLES3.2 | build/modules/gles32/deqp-gles32 | <dst>/deqp-gles32 |
data/gles32 | <dst>/gles32 |
Вы можете развернуть службу выполнения и тестовые исполняемые файлы в любом месте целевой файловой системы; однако тестовые исполняемые файлы ожидают найти каталоги данных в текущем рабочем каталоге. Когда всё будет готово, запустите службу выполнения теста на целевом устройстве. Подробную информацию о запуске службы см. в разделе Служба выполнения теста .
Аргументы командной строки
В следующей таблице перечислены аргументы командной строки, влияющие на выполнение всех тестовых программ.
| Аргумент | Описание |
|---|---|
--deqp-case=<casename> | Запускайте случаи, соответствующие заданному шаблону. Поддерживается подстановочный знак (*). |
--deqp-log-filename=<filename> | Запишите результаты теста в файл, имя которого вы укажете. Служба выполнения тестов установит имя файла при запуске теста. |
--deqp-stdin-caselist | Прочитать список вариантов из стандартного ввода (stdin) или из заданного аргумента. Служба выполнения теста установит аргумент в соответствии с полученным запросом на выполнение. Описание формата списка вариантов см. в следующем разделе. |
--deqp-test-iteration-count=<count> | Переопределить количество итераций для тестов, поддерживающих переменное количество итераций. |
--deqp-base-seed=<seed> | Базовое значение для тестовых случаев, использующих рандомизацию. |
Аргументы, специфичные для GLES2 и GLES3
В следующей таблице перечислены аргументы, специфичные для GLES2 и GLES3.| Аргумент | Описание |
|---|---|
--deqp-gl-context-type=<type> | Тип контекста OpenGL. Доступные типы контекста зависят от платформы. На платформах, поддерживающих EGL, значение egl можно использовать для выбора контекста EGL. |
--deqp-gl-config-id=<id> | Выполнить тесты для предоставленного идентификатора конфигурации GL. Интерпретация зависит от платформы. На платформе EGL это идентификатор конфигурации EGL. |
--deqp-gl-config-name=<name> | Запустите тесты для именованной конфигурации GL. Интерпретация зависит от платформы. Для EGL формат: rgb(a)<bits>d<bits>s<bits> . Например, значение rgb888s8 выберет первую конфигурацию, в которой цветовой буфер — RGB888, а буфер трафарета — 8 бит. |
--deqp-gl-context-flags=<flags> | Создаёт контекст. Укажите значение robust или debug . |
--deqp-surface-width=<width> | Попробуйте создать поверхность заданного размера. Поддержка этой функции необязательна. |
--deqp-surface-type=<type> | Использовать заданный тип поверхности в качестве основной целевой тестовой поверхности. Возможные типы: window , pixmap , pbuffer и fbo . |
--deqp-screen-rotation=<rotation> | Ориентация экрана с шагом 90 градусов для платформ, которые ее поддерживают. |
Формат списка тестовых случаев
Список тестовых случаев можно представить в двух форматах. Первый вариант — указать полное название каждого теста на отдельной строке в стандартном ASCII-файле. По мере роста тестовых наборов повторяющиеся префиксы могут создавать неудобства. Чтобы избежать повторения префиксов, используйте синтаксис префиксного дерева (trie), показанный ниже.
{nodeName{firstChild{…},…lastChild{…}}}
Например:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Переводится в следующие два тестовых случая:
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Андроид
Пакет приложения для Android содержит все необходимые компоненты, включая службу выполнения тестов, тестовые исполняемые файлы и файлы данных. Тестовое действие представляет собой NativeActivity , использующее EGL (требуется Android 3.2 или выше).
Пакет приложения можно установить с помощью следующей команды (указанное имя — это имя APK в пакете Android CTS; имя зависит от сборки):
adb –d install –r com.drawelements.deqp.apk
Для запуска службы выполнения тестов и настройки переадресации портов используйте следующее:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Отладочные распечатки можно включить, выполнив следующие действия перед началом тестов:
adb –d shell setprop log.tag.dEQP DEBUG
Выполнение тестов на Android без Android CTS
Чтобы вручную запустить активность выполнения теста, создайте намерение Android, нацеленное на android.app.NativeActivity . Действия находятся в пакете com.drawelements.deqp . Командная строка должна быть указана как дополнительная строка с ключом "cmdLine" в намерении.
Журнал теста записывается в /sdcard/dEQP-log.qpa . Если тест не запускается нормально, дополнительная отладочная информация доступна в журнале устройства.
Вы можете запустить активность из командной строки с помощью утилиты am . Например, для запуска тестов dEQP-GLES2.info на платформе, поддерживающей NativeActivity, используйте следующие команды.
adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ 'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'
Отладка на Android
Чтобы запустить тесты под отладчиком GDB на Android, сначала скомпилируйте и установите отладочную сборку, выполнив следующие два скрипта:
python android/scripts/build.py --native-build-type=Debugpython android/scripts/install.py
После установки отладочной сборки на устройство, чтобы запустить тесты под управлением GDB, работающего на хосте, выполните следующую команду:
python android/scripts/debug.py \ --deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"
Командная строка deqp зависит от тестовых случаев, которые необходимо выполнить, и других необходимых параметров. Скрипт добавляет точку останова по умолчанию в начале выполнения deqp ( tcu::App::App ).
Скрипт debug.py принимает несколько аргументов командной строки для таких действий, как установка точек останова для отладки, параметры подключения к gdbserver и пути к дополнительным исполняемым файлам для отладки (используйте debug.py --help для всех аргументов и пояснений). Скрипт также копирует некоторые библиотеки по умолчанию с целевого устройства для получения списков символов.
Для пошагового выполнения кода драйвера (например, когда GDB требуется знать расположение исполняемых файлов с полной отладочной информацией) добавьте дополнительные библиотеки через параметры командной строки debug.py . Этот скрипт записывает файл конфигурации для GDB, начиная со строки 132 файла скрипта. Вы можете указать дополнительные пути к исполняемым файлам и т.д., но корректных параметров командной строки должно быть достаточно.
Примечание: В Windows для двоичного файла GDB требуется libpython2.7.dll . Перед запуском debug.py добавьте <path-to-ndk>/prebuilt/windows/bin в переменную PATH.
Примечание: Отладка собственного кода не работает в стандартной версии Android 4.3. Обходные пути см. в этой общедоступной статье об ошибке . В Android 4.4 и более поздних версиях эта ошибка отсутствует.
Автоматизируйте тесты
Тестовые модули Deqp можно интегрировать в автоматизированные тестовые системы различными способами. Оптимальный подход зависит от существующей тестовой инфраструктуры и целевой среды.
Основным результатом выполнения теста всегда является файл журнала теста, то есть файл с расширением .qpa . Полные результаты теста можно проанализировать из журнала теста. Вывод на консоль содержит только отладочную информацию и может быть доступен не на всех платформах.
Тестовые исполняемые файлы можно вызывать непосредственно из системы автоматизации тестирования. Тестовый исполняемый файл можно запустить для конкретного случая, для тестового набора или для всех доступных тестов. Если во время выполнения возникнет фатальная ошибка (например, определённые ошибки API или сбой), выполнение теста будет прервано. Для регрессионного тестирования наилучшим подходом является вызов тестовых исполняемых файлов для отдельных случаев или небольших тестовых наборов по отдельности, чтобы иметь частичные результаты даже в случае серьёзного сбоя.
Deqp поставляется с инструментами командной строки для выполнения тестов, которые можно использовать в сочетании со службой выполнения для достижения более надёжной интеграции. Исполнитель обнаруживает завершение процесса тестирования и возобновляет его выполнение при следующем доступном случае. По результатам всего сеанса тестирования создаётся один файл журнала. Такая конфигурация идеально подходит для лёгких тестовых систем, не предоставляющих возможности восстановления после сбоев.
Инструменты выполнения тестов из командной строки
Текущий набор инструментов командной строки включает в себя инструмент удаленного выполнения тестов, генератор сравнения тестовых журналов для регрессионного анализа, конвертер test-log-to-CSV, конвертер test-log-to-XML и конвертер testlog-to-JUnit.
Исходный код этих инструментов находится в каталоге executor , а двоичные файлы собраны в каталоге <builddir>/executor .
Исполнитель теста командной строки
Исполняющий тест командной строки — это переносимый инструмент на C++ для запуска тестового прогона на устройстве и сбора журналов по протоколу TCP/IP. Исполняющий тест взаимодействует со службой выполнения (execserver) на целевом устройстве. Вместе они обеспечивают такие функции, как восстановление после сбоев тестового процесса. В следующих примерах показано, как использовать исполняющий тест командной строки (для получения более подробной информации используйте --help ):
Пример 1: Запуск функциональных тестов GLES2 на устройстве Android
executor --connect=127.0.0.1 --port=50016 --binaryname= com.drawelements.deqp/android.app.NativeActivity --caselistdir=caselists --testset=dEQP-GLES2.* --out=BatchResult.qpa --cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable --deqp-gl-config-name=rgba8888d24s8"
Пример 2: Продолжить частичный тест OpenGL ES 2 локально
executor --start-server=execserver/execserver --port=50016 --binaryname=deqp-gles2 --workdir=modules/opengl --caselistdir=caselists --testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa --out=BatchResult.qpa
Экспорт и сравнение тестового журнала в CSV-файл
В deqp есть инструмент для преобразования журналов тестирования (файлов . qpa ) в CSV-файлы. Вывод CSV-файла содержит список тестовых случаев и их результатов. Инструмент также может сравнивать результаты двух или более пакетов и выводить только те тестовые случаи, коды статуса которых отличаются во входных результатах пакета. В результате сравнения также будет выведено количество совпадающих случаев.
Вывод в формате CSV очень удобен для дальнейшей обработки стандартными утилитами командной строки или редактором электронных таблиц. Дополнительный, удобный для восприятия текстовый формат можно выбрать с помощью следующего аргумента командной строки: --format=text
Пример 1: Экспорт журнала тестирования в формат CSV
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Пример 2: Перечислите различия в результатах тестирования между двумя журналами тестирования.
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Примечание: Аргумент --value=code выводит код результата теста, например, «Pass» или «Fail». Аргумент --value=details выбирает дополнительное пояснение результата или числового значения, полученного в ходе теста производительности, возможностей или точности.
Экспорт тестового журнала в XML
Файлы журнала тестирования можно преобразовать в корректные XML-документы с помощью утилиты testlog-to-xml . Поддерживаются два режима вывода:
- Режим отдельных документов, в котором каждый тестовый случай и сводный документ
caselist.xmlзаписываются в целевой каталог. - Режим одного файла, в котором все результаты в файле
.qpaзаписываются в один XML-документ.
Экспортированные файлы журнала тестирования можно просматривать в браузере с помощью XML-таблицы стилей. Примеры документов таблиц стилей ( testlog.xsl и testlog.css ) находятся в каталоге doc/testlog-stylesheet . Чтобы отобразить файлы журнала в браузере, скопируйте оба файла таблиц стилей в тот же каталог, где находятся экспортированные XML-документы.
Если вы используете Google Chrome, доступ к файлам должен осуществляться по HTTP, так как Chrome ограничивает доступ к локальным файлам из соображений безопасности. Стандартная установка Python включает в себя базовый HTTP-сервер, который можно запустить для обслуживания текущего каталога с помощью команды python –m SimpleHTTPServer 8000 После запуска сервера просто укажите в браузере Chrome адрес http://localhost:8000 чтобы просмотреть журнал тестирования.
Преобразование в журнал тестов JUnit
Многие системы автоматизации тестирования могут генерировать отчёты о результатах тестовых прогонов из выходных данных JUnit. Файлы журнала тестирования deqp можно преобразовать в формат выходных данных JUnit с помощью инструмента testlog-tojunit.
В настоящее время инструмент поддерживает только преобразование вердикта тестового случая. Поскольку JUnit поддерживает только результаты «pass» и «fail», пройденный результат deqp сопоставляется с «JUnit pass», а все остальные результаты считаются неудачными. Исходный код результата deqp доступен в выходных данных JUnit. Другие данные, такие как сообщения журнала и изображения результатов, при преобразовании не сохраняются.
Используйте специальные тестовые группы
Некоторые тестовые группы могут нуждаться в специальных параметрах командной строки или поддерживать их, а также требовать особой осторожности при использовании в определенных системах.
Стресс-тесты распределения памяти
Стресс-тесты распределения памяти проверяют условия нехватки памяти путем многократного выделения определенных ресурсов до тех пор, пока драйвер не сообщит об ошибке нехватки памяти.
На некоторых платформах, таких как Android и большинство версий Linux, может произойти следующее: операционная система может завершить тестовый процесс, вместо того чтобы позволить драйверу обработать или иным образом сообщить об ошибке нехватки памяти. На таких платформах тесты, предназначенные для вызова ошибок нехватки памяти, по умолчанию отключены и должны быть включены с помощью аргумента командной строки --deqp-test-oom=enable . Рекомендуется запускать такие тесты вручную, чтобы проверить корректность работы системы в условиях нехватки ресурсов. Однако в такой ситуации сбой тестового процесса следует интерпретировать как прохождение теста.
Тестовые группы
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Длительные стресс-тесты рендеринга
Стресс-тесты рендеринга предназначены для выявления проблем с надёжностью при длительной нагрузке. По умолчанию тесты выполняют всего несколько итераций, но их можно настроить на неограниченное количество итераций, указав аргумент командной строки --deqp-test-iteration-count=-1 . При длительном выполнении этих тестов сторожевой таймер следует отключить ( --deqp-watchdog=disable ).
Тестовые группы
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-10-10 UTC.