Тестирование программы качества drawElements (deqp)

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 будут включать файлы targets/ DEQP_TARGET / DEQP_TARGET .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

Список источников портов платформы. Источники по умолчанию определяются исходя из возможностей и ОС.

Примечание. Пути относятся к: framework/platform

В целевой файл сборки можно добавить дополнительные пути включения или ссылки с помощью функций 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_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS

DE_COMPILER

Тип компилятора. Поддерживаемые значения: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG

DE_CPU

Тип процессора. Поддерживаемые значения: DE_CPU_ARM, DE_CPU_X86 .

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/delibs/dethread
framework/delibs/deutil

Любые необходимые реализации кода, специфичного для ОС.

framework/qphelper/qpCrashHandler.c

Необязательно: Реализация для вашей ОС.

framework/qphelper/qpWatchDog.c

Реализация для вашей ОС. Текущий основан на dethread и стандартной библиотеке 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-caselist=<caselist>
--deqp-caselist-file=<filename>
Чтение списка случаев из стандартного ввода или из заданного аргумента. Служба выполнения тестов установит аргумент в соответствии с полученным запросом на выполнение. См. следующий раздел для описания формата списка дел.
--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-height=<height>
Попробуйте создать поверхность заданного размера. Поддержка этого не является обязательной.
--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.*