Google 致力于为黑人社区推动种族平等。查看具体举措

drawElements 质量计划 (deqp) 测试

AOSP 包含 drawElements 质量计划 (deqp) GPU 测试套件,该套件位于 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 测试模块框架和实用工具

framework/delibs

基础可移植性库和构建库

framework/platform

平台端口

framework/qphelper

测试程序集成库 (C)

framework/common

Deqp 框架 (C++)

framework/opengl, framework/egl

API 专用实用工具

execserver

设备端 ExecServer 源代码

executor

主机端测试执行器 shell 工具和实用工具

external

适用于外部库 libpng 和 zlib 的构建存根目录

开放源代码组件

deqp 使用 libpngzlib,您可以使用脚本 platform/external/deqp/external/fetch_sources.py 或通过 platform/external/[libpng,zlib] 中的 git 获取它们。

构建测试程序

相关人员在设计测试框架时考虑到了可移植性。仅有的强制性要求是针对 I/O、线程和套接字的全面 C++ 支持和标准系统库。

CMake 构建系统

deqp 来源具有适用于 CMake 的构建脚本,这是编译测试程序的首选工具。

CMake 是一个开放源代码构建系统,支持多种平台和工具链。CMake 从与目标无关的配置文件生成原生 Makefile 或 IDE 项目文件。如需详细了解 CMake,请参阅 CMake 文档。

CMake 支持且建议在源代码树之外进行构建,也就是说,您应该始终在源代码树之外的独立构建目录中创建 Makefile 或项目文件。CMake 没有任何类型的“distclean”目标,因此,您必须手动移除 CMake 生成的所有文件。

您可以使用 -DOPTION_NAME=VALUE 语法为 CMake 提供配置选项。deqp 的一些常用选项如下所示。

配置选项 说明
DEQP_TARGET

目标名称,例如“android”

deqp CMake 脚本将包含文件 targets/DEQP_TARGET/DEQP_TARGET.cmake,而且在此文件中应该可以找到针对特定目标的构建选项。

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(默认值:OFF)

DEQP_GLES2_LIBRARIES

GLES2 库(如果不受支持或使用的是动态加载,则留空)

DEQP_SUPPORT_GLES3

是否支持 GLES3.x(默认值:OFF)

DEQP_GLES3_LIBRARIES

GLES3.x 库(如果不受支持或使用的是动态加载,则留空)

DEQP_SUPPORT_VG

是否支持 OpenVG(默认值:OFF)

DEQP_OPENVG_LIBRARIES

OpenVG 库(如果不受支持或使用的是动态加载,则留空)

DEQP_SUPPORT_EGL

是否支持 EGL(默认值:OFF)

DEQP_EGL_LIBRARIES

EGL 库(如果不受支持或使用的是动态加载,则留空)

DEQP_PLATFORM_LIBRARIES

进行链接所需的特定于平台的附加库

DEQP_PLATFORM_COPY_LIBRARIES

复制到每个测试二进制文件构建目录的库列表。可用于复制运行测试所需但不在默认搜索路径中的库。

TCUTIL_PLATFORM_SRCS

平台端口来源列表。默认来源取决于功能和操作系统。

注意:路径是相对于 framework/platform 的相对路径

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

Win32 build

为 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 位 build:

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

您还可以通过 -G "NMake Makefiles" 选项以及构建类型(-DCMAKE_BUILD_TYPE="Debug""Release")生成 NMake Makefile。

渲染上下文的创建

渲染上下文可通过 WGL 或 Windows 上的 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”(这是大多数目标中的默认状态),则通过动态加载为 Windows 上的 EGL 构建 deqp。接下来,如果主机有可用的 EGL 库,则可以通过命令行参数 --deqp-gl-context-type=egl 对其运行测试。

Android build

Android build 使用 CMake 构建脚本来构建原生测试代码。 Java 部分(即测试执行服务器和测试应用桩)使用标准的 Android 构建工具进行编译。

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

  • 最新版本的 Android NDKandroid/scripts/common.py 文件中列出了所需的版本
  • Android 独立 SDK(已安装 API 13、SDK 工具、SDK 平台工具和 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-VERSIONC:/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 构建很有帮助。

构建目标 说明
default

默认目标;使用 CMake 平台自省来确定是否支持各种 API。

x11_glx

使用 GLX 创建 OpenGL (ES) 上下文。

x11_egl

使用 EGL 创建 OpenGL (ES) 上下文。

x11_egl_glx

同时支持带有 X11 的 GLX 和 EGL。

始终使用 -DCMAKE_BUILD_TYPE=<Debug|Release> 来定义构建类型。Release 是一个很实用的默认值。如果没有该值,则默认创建未优化的发布 build。

-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 位调试 build 的完整命令行示例如下:

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_OSDE_COMPILERDE_PTR_SIZE,但 DE_CPU 必须由工具链文件设置。

变量 说明
DE_OS

操作系统。支持的值包括:DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS

DE_COMPILER

编译器类型。支持的值包括:DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG

DE_CPU

CPU 类型。支持的值包括:DE_CPU_ARM, DE_CPU_X86

DE_PTR_SIZE

平台上的 sizeof(void*)。支持的值包括:4 和 8

可使用 CMAKE_TOOLCHAIN_FILE 构建参数选择工具链文件。 例如,以下代码将使用适用于 ARM/Linux 的 CodeSourcery 交叉编译器为 build 创建 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 需要三个步骤:调整基础可移植性库,实现测试框架平台集成接口以及移植执行服务。

下表列出了可能发生移植更改的位置。在此范围之外的位置很可能是有异常情况。

位置 说明
framework/delibs/debase
framework/delibs/dethread
framework/delibs/deutil

操作系统专用代码的任何必要实现。

framework/qphelper/qpCrashHandler.c

可选:针对操作系统的实现。

framework/qphelper/qpWatchDog.c

针对操作系统的实现。当前的实现以 dethread 和 C 语言的标准库为基础。

framework/platform

新的平台端口和应用桩可按照测试框架平台端口中的说明来实现。

基础可移植性库

基础可移植性库已支持 Windows、大多数 Linux 变体、Mac OS、iOS 和 Android。若测试目标在其中一个操作系统上运行,很可能根本无需动用基础可移植性库。

测试框架平台端口

deqp 测试框架平台端口需要两个组件:应用入口点和平台接口实现。

应用入口点负责创建平台对象、创建命令行 (tcu::CommandLine) 对象、打开测试日志 (tcu::TestLog) 以及迭代测试应用 (tcu::App)。若目标操作系统支持标准的 main() 入口点,则可以将 tcuMain.cpp 用作入口点实现。

以下文件详细说明了 deqp 平台 API。

文件 说明
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 测试模块 build 的一部分构建的。您可以修改 execserver/CMakeLists.txt 以便在其他目标中启用 build。

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

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

运行测试

本页介绍了如何在 Linux 和 Windows 环境中运行 deqp 测试、如何使用命令行参数,以及如何使用 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
--deqp-caselist=<caselist>
--deqp-caselist-file=<filename>
通过 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 配置 ID 运行测试。解译取决于平台。在 EGL 平台上,该配置 ID 为 EGL 配置 ID。
--deqp-gl-config-name=<name> 对已命名的 GL 配置运行测试。解译取决于平台。对于 EGL,格式为 rgb(a)<bits>d<bits>s<bits>。例如,值 rgb888s8 会选择第一个配置,其中颜色缓冲区为 RGB888,模板缓冲区为 8 位。
--deqp-gl-context-flags=<flags> 创建一个上下文。指定 robustdebug
--deqp-surface-width=<width>
--deqp-surface-height=<height>
尝试使用指定的尺寸创建表面。对这项功能的支持为可选项。
--deqp-surface-type=<type> 将指定的表面类型用作主测试渲染目标。可能的值包括 windowpixmappbufferfbo
--deqp-screen-rotation=<rotation> 对于支持该参数的平台,屏幕方向的旋转增量为 90 度。

测试用例列表格式

测试用例列表有两种格式。第一种选项是在标准 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 应用包软件包含所需的所有组件,包括测试执行服务、测试二进制文件和数据文件。测试 Activity 是使用 EGL 的 NativeActivity(需要 Android 3.2 或更高版本)。

应用软件包可使用以下命令安装(所示名称为 Android CTS 软件包中 APK 的名称;该名称因 build 而异):

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 设备上执行测试

如需手动启动测试执行 Activity,请构建一个目标为 android.app.NativeActivity 的 Android intent。可在 com.drawelements.deqp 软件包中找到这些 Activity。在 intent 中,命令行必须以含 "cmdLine" 键的额外字符串形式提供。

测试日志会写入 /sdcard/dEQP-log.qpa。若测试运行无法正常启动,请查看设备日志,了解其他调试信息。

您可使用 am 实用程序从命令行启动 Activity。例如,如需在支持 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 变量中。

注意:原生代码调试不适用于 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.xsltestlog.css)位于 doc/testlog-stylesheet 目录中。若要在浏览器中查看日志文件,可将两个样式表文件复制到导出的 XML 文档所在的同一目录。

如果您使用的是 Google Chrome,则必须通过 HTTP 访问这些文件,因为 Chrome 出于安全考虑,会限制对本地文件的访问。标准的 Python 安装包括一个基本的 HTTP 服务器,该服务器可通过 python –m SimpleHTTPServer 8000 命令启动,以作为当前目录。启动服务器后,只需将 Chrome 浏览器指向 http://localhost: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.*