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. Допустимые значения: «Отладка» и «Выпуск». Обратите внимание, что интерпретация и тип по умолчанию зависят от целевой системы сборки. Дополнительные сведения см. в документации по CMake. |
Создание целевого файла сборки
Система сборки deqp настраивается для новых целей с использованием целевых файлов сборки. Целевой файл сборки определяет, какие функции поддерживает платформа и какие библиотеки или дополнительные пути включения требуются. Имена целевых файлов соответствуют формату target targets/ NAME / NAME .cmake
, и цель выбирается с помощью параметра сборки DEQP_TARGET
.
Пути к файлам в целевых файлах относятся к базовому deqp
, а не к каталогу target 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 | Список источников портов платформы. Источники по умолчанию определяются исходя из возможностей и ОС. Примечание. Пути относятся к: |
В целевой файл сборки можно добавить дополнительные пути включения или ссылки с помощью функций include_directories()
и link_directories()
CMake.
Сборка 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, т. е. сервер выполнения тестов и заглушка тестового приложения, компилируются с использованием стандартных инструментов сборки 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
— хороший вариант по умолчанию. Без него делается дефолтная, неоптимизированная сборка релиза.
Аргументы командной строки -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 test framework требуется два компонента: точка входа приложения и реализация интерфейса платформы.
Точка входа приложения отвечает за создание объекта платформы, создание объекта командной строки ( 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 | Чтение списка случаев из стандартного ввода или из заданного аргумента. Служба выполнения тестов установит аргумент в соответствии с полученным запросом на выполнение. См. следующий раздел для описания формата списка дел. |
--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:50016
adb –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"
в Intent.
Журнал тестирования записывается в /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=Debug
python 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 поставляется с инструментами выполнения тестов из командной строки, которые можно использовать в сочетании со службой выполнения для достижения более надежной интеграции. Исполнитель обнаруживает завершение процесса тестирования и возобновляет выполнение теста в следующем доступном случае. Один файл журнала создается из полного тестового сеанса. Эта установка идеальна для облегченных тестовых систем, которые не предоставляют средства восстановления после сбоев.
Инструменты выполнения тестов командной строки
Текущий набор инструментов командной строки включает в себя инструмент удаленного выполнения тестов, генератор сравнения журналов тестов для регрессионного анализа, преобразователь тестового журнала в CSV, преобразователь тестового журнала в XML и преобразователь тестового журнала в JUnit. .
Исходный код этих инструментов находится в каталоге executor
, а двоичные файлы встроены в <builddir>/executor
.
Командная строка Test Executor
Командная строка Test Executor — это портативный инструмент C++ для запуска тестового прогона на устройстве и сбора полученных журналов с него по TCP/IP. Executor связывается со службой выполнения (execserver) на целевом устройстве. Вместе они обеспечивают такие функции, как восстановление после сбоев процесса тестирования. В следующих примерах показано, как использовать Test Executor из командной строки (используйте --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.csv
testlog-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
выводит код результата теста, например «Пройдено» или «Не пройдено». Аргумент --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-to-junit.
В настоящее время инструмент поддерживает перевод только вердикта тестового примера. Поскольку JUnit поддерживает только результаты «пройдено» и «не пройдено», пройденный результат deqp сопоставляется с «пройденным JUnit», а другие результаты считаются неудачными. Исходный код результата 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 и ее аффилированных лиц.
Последнее обновление: 2022-08-03 UTC.