В AOSP входит набор тестов drawElements Quality Program (deqp) для графических процессоров: https://android.googlesource.com/platform/external/deqp. На этой странице подробно описано, как развернуть набор тестов deqp в новой среде.
Чтобы работать с последним отправленным кодом, используйте ветку deqp-dev.
Для кода, соответствующего определенной версии Android CTS, используйте ветку release-code-name-release (например, для Android 6.0 используйте ветку marshmallow-release).
Макет источника
В таблице ниже показана структура исходного кода для модулей тестирования deqp и вспомогательных библиотек (перечислены не все, а только самые важные каталоги).
| Каталог | Описание |
|---|---|
android |
Исходный код и скрипты сборки для тестирования на Android |
data |
Тестовые файлы данных |
modules |
Источники тестовых модулей |
modules/egl |
Модуль EGL |
modules/gles2 |
Модуль GLES2 |
modules/gles3 |
Модуль GLES3 |
modules/gles31 |
Модуль GLES3.1 |
modules/gles32 |
Модуль GLES3.2 |
targets |
Файлы конфигурации сборки для определенных целей |
framework |
deqp test module framework and utilities |
framework/delibs |
Переносимость базы и создание библиотек |
framework/platform |
Порты платформы |
framework/qphelper |
Библиотека интеграции тестовой программы (C) |
framework/common |
Фреймворк deqp (C++) |
framework/opengl, framework/egl |
Утилиты для работы с API |
execserver |
Источник ExecServer на стороне устройства |
executor |
Оболочка и утилиты для выполнения тестов на стороне хоста |
external |
Создание заглушки каталога для внешних библиотек libpng и zlib |
Компоненты с открытым исходным кодом
В deqp используются libpng и zlib, которые можно получить с помощью скрипта
platform/external/deqp/external/fetch_sources.py или через git из platform/external/[libpng,zlib].
Как создавать тестовые программы
Фреймворк для тестирования разработан с учетом требований к переносимости. Единственные обязательные требования – полная поддержка C++ и стандартные системные библиотеки для ввода-вывода, потоков и сокетов.
Система сборки CMake
Источники deqp имеют скрипты сборки для CMake, который является предпочтительным инструментом для компиляции тестовых программ.
CMake – это система сборки с открытым исходным кодом, которая поддерживает несколько платформ и цепочек инструментов. CMake генерирует нативные make-файлы или файлы проектов IDE из файлов конфигурации, не зависящих от целевой платформы. Дополнительную информацию о CMake можно найти в документации по CMake.
CMake поддерживает и рекомендует сборку вне дерева исходного кода, то есть вы должны всегда создавать файлы makefile или файлы проекта в отдельном каталоге сборки вне дерева исходного кода. В CMake нет цели distclean, поэтому удалять файлы, созданные CMake, нужно вручную.
Параметры конфигурации передаются CMake с помощью синтаксиса -DOPTION_NAME=VALUE. Ниже перечислены некоторые часто используемые параметры deqp.
| Вариант конфигурации | Описание |
|---|---|
DEQP_TARGET |
Название целевой платформы, например "android". Скрипты CMake deqp будут включать файл |
CMAKE_TOOLCHAIN_FILE |
Путь к файлу цепочки инструментов для CMake. Используется для кросс-компиляции. |
CMAKE_BUILD_TYPE |
Тип сборки для целей makefile. Допустимые значения: "Debug" и "Release". Обратите внимание, что интерпретация и тип по умолчанию зависят от целевой системы сборки. Подробная информация приведена в документации 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 (по умолчанию: OFF). |
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 не поддерживают необходимое расширение.
Поддержка 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. - Отдельный пакет 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 позволяет ускорить сборку
- Необязательно: в Linux также поддерживается Ninja Make
Двоичные файлы 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 (APK) создается в android/package/bin и может быть установлен с помощью скрипта install.py. Если используется исполнитель командной строки, ExecService запускается с помощью скрипта launch.py на устройстве через ADB. Скрипты можно выполнять из любого каталога.
Сборка для Linux
Тестовые двоичные файлы и утилиты командной строки можно создать для Linux, сгенерировав файлы makefile с помощью 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. В файле toolchain указывается компилятор, который нужно использовать, а также специальные пути поиска для библиотек и заголовков. В пакет выпуска в каталоге 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, macOS, 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 |
| Модуль EGL | build/modules/egl/deqp-egl |
<dst>/deqp-egl |
| Модуль GLES2 | build/modules/gles2/deqp-gles2 |
<dst>/deqp-gles2 |
data/gles2 |
<dst>/gles2 |
|
| Модуль GLES3 | build/modules/gles3/deqp-gles3 |
<dst>/deqp-gles3 |
data/gles3 |
<dst>/gles3 |
|
| Модуль GLES3.1 | build/modules/gles31/deqp-gles31 |
<dst>/deqp-gles31 |
data/gles31 |
<dst>/gles31 |
|
| Модуль GLES3.2 | build/modules/gles32/deqp-gles32 |
<dst>/deqp-gles32 |
data/gles32 |
<dst>/gles32 |
Вы можете развернуть сервис выполнения и протестировать двоичные файлы в любом месте целевой файловой системы, но двоичные файлы тестов ожидают найти каталоги данных в текущем рабочем каталоге. Когда все будет готово, запустите сервис выполнения тестов на целевом устройстве. Подробнее о том, как запустить сервис выполнения тестов…
Аргументы командной строки
В таблице ниже перечислены аргументы командной строки, которые влияют на выполнение всех тестовых программ.
| Аргумент | Описание |
|---|---|
--deqp-case=<casename> |
Запускать тесты, соответствующие определенному шаблону. Поддерживается подстановочный знак (*). |
--deqp-log-filename=<filename> |
Записывает результаты тестирования в файл с указанным вами названием. Сервис выполнения тестов задаст название файла при запуске теста. |
--deqp-stdin-caselist |
Прочитать список дел из stdin или из заданного аргумента. Сервис выполнения тестов задаст аргумент в соответствии с полученным запросом на выполнение. Формат списка обращений описан в следующем разделе. |
--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
Пакет приложения 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
Чтобы запустить тесты в GNU Debugger (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) на целевом устройстве.
Вместе они обеспечивают такие функции, как восстановление после сбоев в процессе тестирования.
Ниже приведены примеры использования исполнителя тестов в командной строке (подробнее о --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.*