Тестирование программы качества 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 генерирует собственные make-файлы или файлы проектов 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 не поддерживают необходимое расширение.

поддержка 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: в PATH должны быть либо NMake, либо JOM.
  • 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 . Итоговый Android Package Kit (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 дополнительные пути поиска библиотек или включаемых файлов.

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

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

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

Базовые библиотеки переносимости уже поддерживают 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 для целевых платформ PC. Вы можете изменить execserver/CMakeLists.txt , чтобы включить сборку на других целевых платформах.

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

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

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

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

Среды Linux и Windows

Для начала скопируйте следующие файлы и папки в целевую папку.

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

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

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

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

В таблице ниже перечислены аргументы, специфичные для 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

Пакет 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

Для запуска тестов в отладчике GNU (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) на целевом устройстве. Вместе они обеспечивают такие функции, как восстановление после сбоев тестового процесса. Следующие примеры демонстрируют использование инструмента командной строки для запуска тестов (для получения более подробной информации используйте --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.*