drawElements 质量程序测试

借助收藏集保持井井有条 根据您的偏好保存内容并对其进行分类。

AOSP 在 https://android.googlesource.com/platform/external/deqp 中包含了 drawElements Quality Program (deqp) GPU 测试套件。本页详细介绍了如何将 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++ 支持以及用于 I/O、线程和套接字的标准系统库。

CMake 构建系统

deqp 源代码具有 CMake 的构建脚本，CMake 是编译测试程序的首选工具。

CMake 是一种开源构建系统，支持多个平台和工具链。CMake 从目标无关的配置文件生成本机 makefile 或 IDE 项目文件。有关 CMake 的更多信息，请参阅 CMake 文档。

CMake 支持并建议树外源构建，即，您应始终在源树外部的单独构建目录中创建 makefile 或项目文件。CMake 没有任何“distclean”目标，因此必须手动删除 CMake 生成的任何文件。

配置选项通过 -DOPTION_NAME=VALUE 语法提供给 CMake。下面列出了一些 deqp 常用的选项。

创建目标构建文件

deqp 构建系统配置为使用目标构建文件的新目标。目标构建文件定义了平台支持的功能以及所需的库或附加包含路径。目标文件名遵循 targets/NAME/NAME.cmake 格式，目标使用 DEQP_TARGET 构建参数进行选择。

目标文件中的文件路径是相对于 base deqp 目录的，而不是相对于 targets/NAME 目录。 以下标准变量可以通过目标构建文件进行设置。

目标构建文件可以使用 include_directories() 和 link_directories() CMake 函数添加其他包含或链接路径。

Win32 构建

为 Windows 构建 deqp 模块的最简单方法是使用 CMake 构建系统。 您将需要 CMake 2.6.12 或更高版本以及 Microsoft Visual C/C++ 编译器。 deqp 已在 Visual Studio 2013 上进行过测试。

可以使用以下命令生成 Visual Studio 项目文件

cmake path\to\src\deqp -G "Visual Studio 12"

可以通过选择“Visual Studio VERSION Win64”作为构建生成器来生成 64 位版本

cmake path\to\src\deqp -G "Visual Studio 12 Win64"

您还可以使用 -G "NMake Makefiles" 选项以及构建类型（-DCMAKE_BUILD_TYPE="Debug" 或 "Release"）生成 NMake makefile。

渲染上下文创建

可以在 Windows 上使用 WGL 或 EGL 创建渲染上下文。

WGL 支持

所有 Win32 二进制文件都支持使用 WGL 创建 GL 上下文，因为它只需要标准库。 可以使用 --deqp-gl-context-type=wgl 命令行参数选择 WGL 上下文。 在 WGL 模式下，deqp 使用 WGL_EXT_create_context_es_profile 扩展来创建 OpenGL ES 上下文。 这已在 NVIDIA 和 Intel 的最新驱动程序上测试通过。 AMD 驱动程序不支持所需的扩展。

EGL 支持

如果 DEQP_SUPPORT_EGL 为 ON，则 deqp 在 Windows 上使用 EGL 的动态加载构建。 这是大多数目标中的默认设置。 然后，如果主机具有可用的 EGL 库，则可以使用命令行参数 --deqp-gl-context-type=egl 与它们一起运行测试

Android 构建

Android 构建使用 CMake 构建脚本来构建本机测试代码。 Java 部分，即测试执行服务器和测试应用程序存根，使用标准 Android 构建工具进行编译。

要使用提供的构建脚本为 Android 编译 deqp 测试程序，您将需要

• 最新版本的 Android NDK；android/scripts/common.py 文件列出了所需的版本
• 具有 API 13、SDK 工具、SDK 平台工具和 SDK 构建工具 软件包 的 Android 独立 SDK 已安装
• Apache Ant 1.9.4（Java 代码构建需要）
• CMake 2.8.12 或更高版本
• Python 2.6 或更高版本（2.x 系列）；不支持 Python 3.x
• 对于 Windows：PATH 中的 NMake 或 JOM
  • 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 脚本构建。 最终的 .apk 在 android/package/bin 中创建，并且可以通过 install.py 脚本安装。 如果使用 命令行执行器，则通过 ADB 在设备上使用 launch.py 脚本启动 ExecService。 可以从任何目录执行脚本。

Linux 构建

可以通过使用 CMake 生成 makefile 为 Linux 构建测试二进制文件和命令行实用程序。 当为 Linux 构建时，有多个预定义的构建目标很有用。

始终使用 -DCMAKE_BUILD_TYPE=<Debug|Release> 来定义构建类型。 Release 是一个很好的默认值。 如果没有它，将进行默认的、未优化的发布版本构建。

可以使用 -DCMAKE_C_FLAGS 和 -DCMAKE_CXX_FLAGS 命令行参数将额外的参数传递给编译器。 例如，可以通过分别设置 -DCMAKE_C(XX)_FLAGS="-m32" 或 "-m64" 来完成 32 位或 64 位构建。 如果未指定，则使用工具链本机架构，通常在 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 构建参数选择工具链文件。 例如，以下命令将为使用 CodeSourcery ARM/Linux 交叉编译器的构建创建 makefile

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 作为入口点实现。

以下文件中详细描述了 deqp 平台 API。

所有平台端口的基类是 tcu::Platform。 平台端口可以选择性地支持特定于 GL 和 EGL 的接口。 请参阅下表，了解运行测试需要实现的内容的概述。

平台端口的详细实现说明在移植层头文件中。

测试执行服务

要使用 deqp 测试执行基础架构或命令行执行器，测试执行服务必须在目标上可用。 服务的可移植 C++ 实现位于 execserver 目录中。 独立二进制文件作为 PC 目标的 deqp 测试模块构建的一部分构建。 您可以修改 execserver/CMakeLists.txt 以启用在其他目标上的构建。

C++ 版本的测试执行服务接受两个命令行参数

• --port=<port> 将设置服务器侦听的 TCP 端口。 默认值为 50016。
• --single 将在客户端断开连接时终止服务器进程。 默认情况下，服务器进程将保持运行状态，以服务进一步的测试执行请求。

运行测试

此页面提供了在 Linux 和 Windows 环境中运行 deqp 测试、使用命令行参数以及使用 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

Android 应用程序包包含所有必需的组件，包括测试执行服务、测试二进制文件和数据文件。 测试活动是一个使用 EGL 的 NativeActivity（需要 Android 3.2 或更高版本）。

可以使用以下命令安装应用程序包（显示的名称是 Android CTS 包中 APK 的名称；该名称取决于构建）

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 CTS 的情况下在 Android 上执行测试

要手动启动测试执行活动，请构造一个以 android.app.NativeActivity 为目标的 Android Intent。 活动可以在 com.drawelements.deqp 包中找到。 命令行必须作为 Intent 中键为 "cmdLine" 的额外字符串提供。

测试日志写入 /sdcard/dEQP-log.qpa。 如果测试运行未正常启动，则设备日志中提供其他调试信息。

您可以使用 am 实用程序从命令行启动活动。 例如，要在支持 NativeActivity 的平台上运行 dEQP-GLES2.info 测试，请使用以下命令。

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 上的调试

要在 Android 上的 GDB 调试器下运行测试，请首先通过运行以下两个脚本来编译和安装调试版本

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 命令行参数添加更多库。 此脚本从脚本文件的第 132 行开始为 GDB 编写配置文件。 您可以提供其他二进制文件等的路径，但提供正确的命令行参数应该就足够了。

注意： 在 Windows 上，GDB 二进制文件需要 libpython2.7.dll。 在启动 debug.py 之前，将 <path-to-ndk>/prebuilt/windows/bin 添加到 PATH 变量。

注意： 本机代码调试在 stock Android 4.3 上不起作用；有关解决方法，请参阅 此公共错误。 Android 4.4 及更高版本不包含此错误。

自动化测试

Deqp 测试模块可以通过多种方式集成到自动化测试系统中。 最佳方法取决于现有的测试基础架构和目标环境。

测试运行的主要输出始终是测试日志文件，即带有 .qpa 后缀的文件。 可以从测试日志中解析完整的测试结果。 控制台输出仅是调试信息，可能并非在所有平台上都可用。

可以从测试自动化系统直接调用测试二进制文件。 可以为特定用例、测试集或所有可用测试启动测试二进制文件。 如果在执行期间发生致命错误（例如某些 API 错误或崩溃），测试执行将中止。 对于回归测试，最佳方法是分别调用单个用例或小型测试集的测试二进制文件，以便即使在发生严重故障时也可以获得部分结果。

deqp 附带命令行测试执行工具，可以与执行服务结合使用，以实现更强大的集成。 执行器检测测试进程终止，并将恢复对下一个可用用例的测试执行。 从完整的测试会话生成单个日志文件。 此设置非常适合不提供崩溃恢复功能的轻量级测试系统。

命令行测试执行工具

当前的命令行工具集包括远程测试执行工具、用于回归分析的测试日志比较生成器、测试日志到 CSV 转换器、测试日志到 XML 转换器以及测试日志到 JUnit 转换器。

这些工具的源代码位于 executor 目录中，二进制文件构建到 <builddir>/executor 目录中。

命令行测试执行器

命令行测试执行器是一个可移植的 C++ 工具，用于在设备上启动测试运行并通过 TCP/IP 从设备收集结果日志。 执行器与目标设备上的执行服务 (execserver) 通信。 它们共同提供诸如从测试进程崩溃中恢复的功能。 以下示例演示了如何使用命令行测试执行器（使用 --help 获取更多详细信息）

示例 1：在 Android 设备上运行 GLES2 功能测试

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 导出

可以使用 testlog-to-xml 实用程序将测试日志文件转换为有效的 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 浏览器指向 https://127.0.0.1:8000 即可查看测试日志。

转换为 JUnit 测试日志

许多测试自动化系统可以从 JUnit 输出生成测试运行结果报告。 可以使用 testlog-to-junit 工具将 deqp 测试日志文件转换为 JUnit 输出格式。

该工具当前仅支持转换测试用例判决。 由于 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.*