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

AOSP включает набор тестов GPU 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"

Вы также можете сгенерировать файлы сборки NMake с помощью параметра -G "NMake Makefiles" , а также типа сборки ( -DCMAKE_BUILD_TYPE="Debug" или "Release" ).

Создание контекста рендеринга

Контекст рендеринга можно создать либо с помощью WGL, либо с помощью EGL в Windows.

Поддержка WGL

Все двоичные файлы Win32 поддерживают создание контекста GL с помощью WGL, поскольку для этого требуются только стандартные библиотеки. Контекст WGL можно выбрать с помощью аргумента командной строки --deqp-gl-context-type=wgl . В режиме WGL deqp использует расширение WGL_EXT_create_context_es_profile для создания контекстов OpenGL ES. Это было протестировано для работы с последними драйверами NVIDIA и Intel. Драйверы AMD не поддерживают требуемое расширение.

Поддержка EGL

Deqp создается с динамической загрузкой для EGL в Windows, если DEQP_SUPPORT_EGL включен. Это значение по умолчанию для большинства целей. Затем, если на хосте есть доступные библиотеки EGL, можно запустить тесты с ними с помощью параметра командной строки: --deqp-gl-context-type=egl

Сборка Android

Сборка Android использует скрипты сборки CMake для сборки собственного тестового кода. Части Java, то есть Test Execution Server и Test Application Stub, компилируются с использованием стандартных инструментов сборки Android.

Для компиляции тестовых программ deqp для Android с предоставленными скриптами сборки вам понадобится:

• Последняя версия Android NDK ; в файле android/scripts/common.py указана необходимая версия
• Автономный Android SDK с установленными пакетами 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 путем генерации makefiles с помощью CMake. Существует несколько предопределенных целей сборки, которые полезны при сборке для Linux.

Всегда используйте -DCMAKE_BUILD_TYPE=<Debug|Release> для определения типа сборки. Release — это хорошее значение по умолчанию. Без него создается неоптимизированная сборка release по умолчанию.

Аргументы командной строки -DCMAKE_C_FLAGS и -DCMAKE_CXX_FLAGS могут использоваться для передачи дополнительных аргументов компилятору. Например, 32- или 64-битную сборку можно выполнить, установив -DCMAKE_C(XX)_FLAGS="-m32" или "-m64" соответственно. Если не указано иное, используется собственная архитектура toolchain, обычно 64-битная в 64-битной toolchain.

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

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

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

Текущий набор инструментов командной строки включает в себя инструмент удаленного выполнения тестов, генератор сравнения тестовых журналов для регрессионного анализа, конвертер test-log-to-CSV, конвертер test-log-to-XML и конвертер testlog-to-JUnit.

Исходный код этих инструментов находится в каталоге executor , а двоичные файлы встроены в каталог <builddir>/executor .

Исполняющий тест командной строки

Командная строка тестового исполнителя — это переносимый инструмент C++ для запуска тестового прогона на устройстве и сбора результирующих журналов с него по TCP/IP. Исполнитель взаимодействует со службой выполнения (execserver) на целевом устройстве. Вместе они обеспечивают такие функции, как восстановление после сбоев тестового процесса. В следующих примерах показано, как использовать командную строку тестового исполнителя (используйте --help для получения более подробной информации):

Пример 1: Запуск функциональных тестов GLES2 на устройстве Android

executor --connect=127.0.0.1 --port=50016 --binaryname=
com.drawelements.deqp/android.app.NativeActivity
--caselistdir=caselists
--testset=dEQP-GLES2.* --out=BatchResult.qpa
--cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable
--deqp-gl-config-name=rgba8888d24s8"

Пример 2: Продолжить частичный тестовый запуск OpenGL ES 2 локально

executor --start-server=execserver/execserver --port=50016
--binaryname=deqp-gles2 --workdir=modules/opengl
--caselistdir=caselists
--testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa
--out=BatchResult.qpa

Экспорт и сравнение тестового журнала в CSV-файл

В deqp есть инструмент для преобразования журналов тестирования (файлы . qpa ) в файлы CSV. Вывод CSV содержит список тестовых случаев и их результаты. Инструмент также может сравнивать два или более результатов партии и перечислять только тестовые случаи, имеющие разные коды статуса во входных результатах партии. Сравнение также выведет количество совпадающих случаев.

Вывод в формате CSV очень удобен для дальнейшей обработки с помощью стандартных утилит командной строки или редактора электронных таблиц. Дополнительный, читаемый человеком, текстовый формат может быть выбран с помощью следующего аргумента командной строки: --format=text

Пример 1: Экспорт журнала тестирования в формат CSV

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.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 выводит код результата теста, например "Pass" или "Fail". Аргумент --value=details выбирает дальнейшее объяснение результата или числового значения, полученного в результате теста производительности, возможностей или точности.

Экспорт тестового журнала в XML

Файлы журнала тестирования можно преобразовать в действительные XML-документы с помощью утилиты testlog-to-xml . Поддерживаются два режима вывода:

• Режим отдельных документов, в котором каждый тестовый случай и сводный документ caselist.xml записываются в целевой каталог.
• Режим одного файла, в котором все результаты в файле .qpa записываются в один XML-документ.

Экспортированные файлы журнала тестирования можно просматривать в браузере с помощью таблицы стилей XML. Образцы документов таблиц стилей ( testlog.xsl и testlog.css ) находятся в каталоге doc/testlog-stylesheet . Чтобы отобразить файлы журнала в браузере, скопируйте два файла таблиц стилей в тот же каталог, где находятся экспортированные документы XML.

Если вы используете Google Chrome, доступ к файлам должен осуществляться через HTTP, поскольку Chrome ограничивает локальный доступ к файлам по соображениям безопасности. Стандартная установка Python включает базовый HTTP-сервер, который можно запустить для обслуживания текущего каталога с помощью команды python –m SimpleHTTPServer 8000 После запуска сервера просто укажите браузеру Chrome адрес http://localhost:8000 чтобы просмотреть журнал тестирования.

Преобразование в журнал тестирования JUnit

Многие системы автоматизации тестирования могут генерировать отчеты о результатах тестовых запусков из выходных данных JUnit. Файлы журнала тестирования deqp можно преобразовать в выходной формат JUnit с помощью инструмента testlog-tojunit.

В настоящее время инструмент поддерживает только перевод вердикта тестового случая. Поскольку JUnit поддерживает только результаты "pass" и "fail", пройденный результат deqp сопоставляется с "JUnit pass", а другие результаты считаются неудачными. Исходный код результата deqp доступен в выходных данных JUnit. Другие данные, такие как сообщения журнала и изображения результатов, не сохраняются при преобразовании.

Используйте специальные тестовые группы

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

Стресс-тесты распределения памяти

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

На некоторых платформах, таких как Android и большинство вариантов Linux, может произойти следующее: операционная система может завершить процесс тестирования вместо того, чтобы позволить драйверу обработать или иным образом предоставить ошибку нехватки памяти. На таких платформах тесты, которые разработаны для того, чтобы вызывать ошибки нехватки памяти, по умолчанию отключены и должны быть включены с помощью аргумента командной строки --deqp-test-oom=enable . Рекомендуется запускать такие тесты вручную, чтобы проверить, правильно ли ведет себя система при нехватке ресурсов. Однако в такой ситуации сбой процесса тестирования следует интерпретировать как прохождение.

Тестовые группы

dEQP-GLES2.stress.memory.*
dEQP-GLES3.stress.memory.*

Длительные стресс-тесты рендеринга

Стресс-тесты рендеринга предназначены для выявления проблем надежности при постоянной нагрузке рендеринга. По умолчанию тесты будут выполнять только несколько итераций, но их можно настроить на бесконечный запуск, указав аргумент командной строки --deqp-test-iteration-count=-1 . Тестовый сторожевой таймер должен быть отключен ( --deqp-watchdog=disable ) при запуске этих тестов в течение длительного периода времени.

Тестовые группы

dEQP-GLES2.stress.long.*
dEQP-GLES3.stress.long.*