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 | 廢氣處理模組 |
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 使用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 腳本將包含檔案 |
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 | 平台連接埠來源列表。預設來源是根據功能和作業系統決定的。 注意:路徑相對於: |
目標建置檔案可以使用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 建立渲染上下文。
工作小組支持
所有 Win32 二進位檔案都支援使用 WGL 建立 GL 上下文,因為它只需要標準函式庫。可以使用--deqp-gl-context-type=wgl
命令列參數選擇 WGL 上下文。在 WGL 模式下,deqp 使用WGL_EXT_create_context_es_profile
擴充功能來建立 OpenGL ES 上下文。已過測試,可與 NVIDIA 和 Intel 的最新驅動程式搭配使用。 AMD 驅動程式不支援所需的擴充功能。
東瀛GL支持
如果 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或更高版本
- 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 時非常有用。
建立目標 | 描述 |
---|---|
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_COMPILER | 編譯器類型。支援的值為: |
DE_CPU | CPU 類型。支援的值為: |
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/qphelper/qpCrashHandler.c | 可選:針對您的作業系統的實作。 |
framework/qphelper/qpWatchDog.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 測試執行基礎架構或命令列執行器,測試執行服務必須在目標上可用。 execserver
目錄中提供了該服務的可移植 C++ 實作。獨立的二進位檔案是作為 PC 目標的 deqp 測試模組建構的一部分而建構的。您可以修改execserver/CMakeLists.txt
以啟用在其他目標上的建置。
C++ 版本的測試執行服務接受兩個命令列參數:
-
--port=<port>
將設定伺服器偵聽的 TCP 連接埠。預設值為 50016。 -
--single
將在客戶端斷開連線時終止伺服器程序。預設情況下,伺服器進程將保持運行狀態以服務進一步的測試執行請求。
運行測試
本頁提供有關在 Linux 和 Windows 環境中執行 deqp 測試、使用命令列參數以及使用 Android 應用程式套件的說明。
Linux 與 Windows 環境
首先將以下檔案和目錄複製到目標。
模組 | 目錄 | 目標 |
---|---|---|
執行伺服器 | build/execserver/execserver | <dst>/execserver |
廢氣處理模組 | 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-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-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 意圖。這些活動可以在com.drawelements.deqp
套件中找到。命令列必須作為額外字串提供,並在 Intent 中使用鍵"cmdLine"
。
測試日誌寫入/sdcard/dEQP-log.qpa
。如果測試運行未正常啟動,設備日誌中會提供其他偵錯資訊。
您可以使用am
實用程式從命令列啟動活動。例如,要在支援 NativeActivity 的平台上執行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 上的 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 收集結果日誌。 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=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 樣式表在瀏覽器中查看匯出的測試日誌檔案。 doc/testlog-stylesheet
目錄中提供了一個範例樣式表文件( testlog.xsl
和testlog.css
)。若要在瀏覽器中呈現日誌文件,請將兩個樣式表文件複製到已匯出的 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.*
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2024-04-29 (世界標準時間)。