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 | модуль ЭГЛ |
modules/gles2 | Модуль ГЛЕС2 |
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 создает собственные файлы Makefile или файлы проекта IDE из файлов конфигурации, независимых от целевого объекта. Дополнительные сведения о CMake см. в документации CMake .
CMake поддерживает и рекомендует сборки вне дерева исходного кода, т. е. вам всегда следует создавать файлы makefile или файлы проекта в отдельном каталоге сборки вне дерева исходного кода. CMake не имеет какой-либо цели «distclean», поэтому удаление любых файлов, созданных CMake, необходимо выполнять вручную.
Параметры конфигурации передаются CMake с использованием синтаксиса -D OPTION_NAME = VALUE . Ниже перечислены некоторые часто используемые параметры deqp.
| Вариант конфигурации | Описание |
|---|---|
DEQP_TARGET | Целевое имя, например: «android» Сценарии deqp CMake будут включать файлы |
CMAKE_TOOLCHAIN_FILE | Путь к файлу набора инструментов для CMake. Используется для кросс-компиляции. |
CMAKE_BUILD_TYPE | Тип сборки для целевых файлов makefile. Допустимые значения: «Отладка» и «Выпуск». Обратите внимание, что интерпретация и тип по умолчанию зависят от целевой системы сборки. Подробности смотрите в документации CMake. |
Создайте целевой файл сборки
Система сборки deqp настраивается для новых целей с использованием файлов целевой сборки. Целевой файл сборки определяет, какие функции поддерживает платформа и какие библиотеки или дополнительные пути включения требуются. Имена целевых файлов соответствуют формату 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"
Вы также можете создавать файлы Makefile 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 не поддерживают необходимое расширение.
поддержка ЕГЛ
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 . Например, следующим образом будут созданы файлы makefile для сборки с использованием кросс-компилятора 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 |
| Модуль ЭГЛ | 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. По мере роста наборов тестов повторяющиеся префиксы могут стать громоздкими. Чтобы избежать повторения префиксов, используйте синтаксис дерева (также известный как дерево префиксов), показанный ниже.
{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 поставляется с инструментами выполнения тестов командной строки, которые можно использовать в сочетании со службой выполнения для достижения более надежной интеграции. Исполнитель обнаруживает завершение процесса тестирования и возобновляет выполнение теста при следующем доступном случае. По результатам полного сеанса тестирования создается один файл журнала. Эта установка идеальна для легких тестовых систем, которые не предоставляют средств восстановления после сбоя.
Инструменты выполнения тестов из командной строки
Текущий набор инструментов командной строки включает в себя инструмент удаленного выполнения тестов, генератор сравнения журналов испытаний для регрессионного анализа, преобразователь журналов испытаний в CSV, преобразователь журналов испытаний в XML и преобразователь журналов испытаний в JUnit. .
Исходный код этих инструментов находится в каталоге executor , а двоичные файлы встроены в каталог <builddir>/executor .
Исполнитель тестов из командной строки
Исполнитель тестов командной строки — это портативный инструмент C++ для запуска тестового прогона на устройстве и сбора полученных с него журналов через TCP/IP. Исполнитель взаимодействует со службой выполнения (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.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 выводит код результата теста, например «Прошел» или «Не прошел». Аргумент --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 и ее аффилированных лиц.
Последнее обновление: 2024-03-18 UTC.