自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。

本頁面由 Cloud Translation API 翻譯而成。

drawElements 質量計劃 (deqp) 測試

AOSP 包括位於https://android.googlesource.com/platform/external/deqp的 drawElements 質量計劃 (deqp) GPU 測試套件。本頁詳細介紹瞭如何將 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`	主機端測試執行器外殼工具和實用程序
`external`	為外部庫 libpng 和 zlib 構建存根目錄

開源組件

deqp 使用libpng和zlib ，可以使用腳本platform/external/deqp/external/fetch_sources.py或通過 git 從platform/external/[libpng,zlib]獲取。

構建測試程序

測試框架的設計考慮到了可移植性。唯一的強制性要求是完整的 C++ 支持和 I/O、線程和套接字的標準系統庫。

CMake 構建系統

deqp 源具有 CMake 的構建腳本，這是編譯測試程序的首選工具。

CMake 是一個支持多種平台和工具鏈的開源構建系統。 CMake 從獨立於目標的配置文件生成本機 makefile 或 IDE 項目文件。有關 CMake 的更多信息，請參閱CMake文檔。

CMake 支持並推薦源代碼樹外構建，即，您應該始終在源代碼樹之外的單獨構建目錄中創建 makefile 或項目文件。 CMake 沒有任何類型的“distclean”目標，因此必須手動刪除 CMake 生成的任何文件。

使用-D OPTION_NAME = VALUE語法為 CMake 提供配置選項。下面列出了 deqp 的一些常用選項。

配置選項描述

配置選項	描述
`DEQP_TARGET`	目標名稱，例如：“android” deqp CMake 腳本將包括文件`targets/ DEQP_TARGET / DEQP_TARGET .cmake`並期望從那裡找到特定於目標的構建選項。
`CMAKE_TOOLCHAIN_FILE`	CMake 工具鏈文件的路徑。用於交叉編譯。
`CMAKE_BUILD_TYPE`	makefile 目標的構建類型。有效值為：“調試”和“發布” 請注意，解釋和默認類型取決於目標構建系統。有關詳細信息，請參閱 CMake 文檔。

DEQP_TARGET

目標名稱，例如：“android”

deqp CMake 腳本將包括文件targets/ DEQP_TARGET / DEQP_TARGET .cmake並期望從那裡找到特定於目標的構建選項。

CMAKE_TOOLCHAIN_FILE

CMake 工具鏈文件的路徑。用於交叉編譯。

CMAKE_BUILD_TYPE

makefile 目標的構建類型。有效值為：“調試”和“發布”

請注意，解釋和默認類型取決於目標構建系統。有關詳細信息，請參閱 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 構建

為 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。

渲染上下文創建

可以使用 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 構建使用 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或更新版本
2.x 系列中的Python 2.6或更新版本；不支持 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 構建時，有多個預定義的構建目標很有用。

構建目標	描述
`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是一個很好的默認設置。沒有它，就會生成一個默認的、未優化的發布版本。

-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必須由工具鏈文件設置。

多變的	描述
`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 交叉編譯器為構建創建 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目錄中提供。獨立二進製文件是作為 PC 目標的 deqp 測試模塊構建的一部分。您可以修改execserver/CMakeLists.txt以啟用在其他目標上的構建。

測試執行服務的 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`
GLES2 模塊	`data/gles2`	`<dst>/gles2`
GLES3 模塊	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
GLES3 模塊	`data/gles3`	`<dst>/gles3`
GLES3.1模塊	`build/modules/gles31/deqp-gles31`	`<dst>/deqp-gles31`
GLES3.1模塊	`data/gles31`	`<dst>/gles31`
GLES3.2模塊	`build/modules/gles32/deqp-gles32`	`<dst>/deqp-gles32`
GLES3.2模塊	`data/gles32`	`<dst>/gles32`

您可以在目標文件系統的任何位置部署執行服務和測試二進製文件；但是，測試二進製文件希望在當前工作目錄中找到數據目錄。準備就緒後，在目標設備上啟動測試執行服務。有關啟動服務的詳細信息，請參閱測試執行服務。

命令行參數

下表列出了影響所有測試程序執行的命令行參數。

爭論	描述
`--deqp-case=<casename>`	運行與給定模式匹配的案例。支持通配符 (*)。
`--deqp-log-filename=<filename>`	將測試結果寫入您提供其名稱的文件。測試執行服務將在開始測試時設置文件名。
`--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>`	從標準輸入或給定參數讀取案例列表。測試執行服務會根據收到的執行請求設置參數。有關案例列表格式的說明，請參見下一節。
`--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 平台上，這是 EGL 配置 ID。
`--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-height=<height>`	嘗試創建一個給定尺寸的表面。對此的支持是可選的。
`--deqp-surface-type=<type>`	使用給定的表麵類型作為主要的測試渲染目標。可能的類型是`window` 、 `pixmap` 、 `pbuffer`和`fbo` 。
`--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 應用程序包包含所有必需的組件，包括測試執行服務、測試二進製文件和數據文件。測試活動是使用 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 上的 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 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 收集結果日誌。 Executor 與目標設備上的執行服務（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 --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 瀏覽器指向http://localhost:8000即可查看測試日誌。

轉換為 JUnit 測試日誌

許多測試自動化系統可以從 JUnit 輸出生成測試運行結果報告。可以使用 testlog-to-junit 工具將 deqp 測試日誌文件轉換為 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.*