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

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 и вспомогательных библиотек показана в таблице ниже (список не является исчерпывающим, но выделены наиболее важные каталоги).

Компоненты с открытым исходным кодом

В 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 настраивается для новых целей с использованием файлов целевой сборки. Целевой файл сборки определяет, какие функции поддерживает платформа и какие библиотеки или дополнительные пути включения требуются. Имена целевых файлов соответствуют формату targets/ NAME / NAME .cmake , а цель выбирается с помощью параметра сборки DEQP_TARGET .

Пути к файлам в целевых файлах указаны относительно базового каталога deqp , а не каталога targets/ NAME . Следующие стандартные переменные могут быть установлены в целевом файле сборки.

В целевой файл сборки можно добавлять дополнительные пути включения или ссылки с помощью функций 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.

Всегда используйте -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 должен быть установлен в файле цепочки инструментов.

Файл цепочки инструментов можно выбрать с помощью параметра сборки 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 включает в себя три этапа: адаптацию базовых библиотек переносимости, реализацию интерфейсов интеграции платформы с тестовой платформой и портирование службы выполнения.

В таблице ниже перечислены места вероятных изменений при переносе. Все, что выходит за их рамки, скорее всего, будет экзотикой.

Базовые библиотеки переносимости

Базовые библиотеки переносимости уже поддерживают Windows, большинство вариантов Linux, Mac OS, iOS и Android. Если объект тестирования работает на одной из этих операционных систем, скорее всего, вообще нет необходимости трогать базовые библиотеки переносимости.

Тестовый порт платформы платформы

Порт платформы платформы тестирования deqp требует двух компонентов: точки входа приложения и реализации интерфейса платформы.

Точка входа приложения отвечает за создание объекта платформы, создание объекта командной строки ( tcu::CommandLine ), открытие журнала тестирования ( tcu::TestLog ) и итерацию тестового приложения ( tcu::App ). Если целевая ОС поддерживает стандартную точку входа main() , в качестве реализации точки входа можно использовать tcuMain.cpp .

API платформы deqp подробно описан в следующих файлах.

Базовым классом для всех портов платформы является tcu::Platform . Порт платформы может дополнительно поддерживать интерфейсы, специфичные для GL и EGL. В следующей таблице представлен обзор того, что необходимо реализовать для запуска тестов.

Подробные инструкции по реализации портов платформы находятся в заголовках уровня портирования.

Служба выполнения тестов

Чтобы использовать инфраструктуру выполнения тестов deqp или исполнитель командной строки, служба выполнения тестов должна быть доступна на целевом объекте. Портативная реализация службы на C++ находится в каталоге execserver . Автономный двоичный файл создается как часть сборки тестового модуля deqp для ПК. Вы можете изменить execserver/CMakeLists.txt чтобы включить сборку на других целях.

Версия службы выполнения тестов C++ принимает два параметра командной строки:

• --port=<port> установит TCP-порт, который прослушивает сервер. По умолчанию — 50016.
• --single завершит серверный процесс, когда клиент отключится. По умолчанию серверный процесс продолжает обслуживать дальнейшие запросы на выполнение тестов.

Запустите тесты

На этой странице представлены инструкции по запуску тестов deqp в средах Linux и Windows, использованию аргументов командной строки и работе с пакетом приложений Android.

Среды Linux и Windows

Начните с копирования следующих файлов и каталогов в цель.

Вы можете развернуть службу выполнения и протестировать двоичные файлы в любом месте целевой файловой системы; однако тестовые двоичные файлы ожидают найти каталоги данных в текущем рабочем каталоге. Когда все будет готово, запустите службу выполнения тестов на целевом устройстве. Подробности о запуске службы см. в разделе Служба выполнения тестов .

Аргументы командной строки

В следующей таблице перечислены аргументы командной строки, которые влияют на выполнение всех тестовых программ.

Аргументы, специфичные для GLES2 и GLES3

Формат списка тестовых примеров

Список тестовых примеров может быть задан в двух форматах. Первый вариант — указать полное название каждого теста в отдельной строке стандартного файла 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: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" в намерении.

Журнал тестирования записывается в /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 .

Исполнитель тестов из командной строки

Исполнитель тестов командной строки — это портативный инструмент 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.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.*