Android 開放原始碼計畫在以下位置提供 DrawElements Quality Program (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 |
主機端測試執行程式殼層工具和公用程式 |
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 產生的任何檔案時,都必須手動完成。
使用 -DOPTION_NAME=VALUE
為 CMake 提供設定選項
語法。下列為 Deqp 的常用選項。
設定選項 | 說明 |
---|---|
DEQP_TARGET |
目標名稱,例如:「android」 deqp CMake 指令碼會包含
|
CMAKE_TOOLCHAIN_FILE |
CMake 的工具鍊檔案路徑。用於跨平台編譯。 |
CMAKE_BUILD_TYPE |
makefile 目標的建構類型。有效值為「Debug」和「發布」 請注意,解讀和預設類型取決於指定建構系統。 詳情請參閱 CMake 說明文件。 |
建立目標建構檔案
已根據目標建構檔案,為新目標設定 deqp 建構系統。
目標建構檔案會定義平台支援哪些功能,以及哪些程式庫或
必須要有額外的 include 路徑目標檔案名稱 (遵循 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 (預設值:關閉) |
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 |
平台通訊埠來源清單。預設來源取決於 這些功能。 注意事項:路徑與 |
目標建構檔案可以使用
include_directories()
和 link_directories()
CMake 函式。
Win32 版本
如要為 Windows 建構 deqp 模組,最簡單的方法就是使用 CMake 版本 有些人會將 Cloud Storage 視為檔案系統 但實際上不是您將需要 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"
選項產生 NMake makefile 檔案
做為建構類型 (-DCMAKE_BUILD_TYPE="Debug"
或 "Release"
)。
建立轉譯結構定義
算繪環境可透過 WGL 或 Windows 上的 EGL 建立。
WGL 支援
所有 Win32 二進位檔都支援透過 WGL 建立 GL 情境,因為只需要
標準程式庫您可以使用 --deqp-gl-context-type=wgl
選取 WGL 情境
指令列引數在 WGL 模式中,解碼器會使用 WGL_EXT_create_context_es_profile
可以建立 OpenGL ES 情境的擴充功能。這項測試已經過測試,
最新的 NVIDIA 和 Intel 的最新驅動程式。AMD 驅動程式不支援所需
。
EGL 支援
如果 DEQP_SUPPORT_EGL 已為 Windows 上的 EGL 建構 Deqp,
已開啟。在大多數指定目標中,這是預設設定。如果主機有 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 以上版本
- 在 2.x 系列中安裝 Python 2.6 以上版本;不支援 Python 3.x
- Windows:
PATH
中的 NMake 或 JOM- JOM 有助於加快建構速度
- 選用:Linux 也支援 Ninja Make
Ant 和 SDK 二進位檔是以含有
某些覆寫預設值邏輯是由 android/scripts/common.py
控制。
NDK 目錄必須是 ~/android-ndk-VERSION
或
C:/android/android-ndk-VERSION
或透過 ANDROID_NDK_PATH
定義
環境變數
裝置端元件、測試執行服務和測試程式
是使用 android/scripts/build.py
指令碼所建構的。最終的 .apk 建立於
android/package/bin
,且可透過 install.py
指令碼安裝。如果
使用了指令列執行程式,然後啟動 ExecService
透過 ADB 在裝置上使用 launch.py
指令碼指令碼可以從任何目錄執行。
Linux 版本
可透過使用以下程式碼產生 makefile,為 Linux 建構測試二進位檔和指令列公用程式 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 工具鍊檔案完成跨程式碼編譯。工具鍊
檔案指定要使用的編譯器,以及
程式庫和標頭以下列舉幾個適用於常見情境的工具鍊檔案:
包含在 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 Cross-compiler 為建構建立 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 程式庫
連結時不需要受測試 API 的進入點。 測試程式碼一律會透過函式指標存取 API。進入點 可在執行階段動態載入 而平台通訊埠則可在 連結時間。
如果版本設定和連結程式庫中開啟了 API 支援功能
如未提供,則 deqp 會在執行階段載入所需的進入點。如果
需要靜態連結,請在 DEQP_<API>_LIBRARIES
中提供必要的連結程式庫
建構設定變數
移植測試架構
移植依附元件的過程包含三個步驟:調整基礎的可攜性程式庫 導入測試架構平台整合介面 執行服務
下表列出可能進行攜碼轉移變更的位置。之後要 很可能是珍奇的
位置 | 說明 |
---|---|
framework/delibs/debase |
任何必要的 OS 特定程式碼實作。 |
framework/qphelper/qpCrashHandler.c |
選用:為 OS 實作。 |
framework/qphelper/qpWatchDog.c |
OS 的實作內容。目前的資料庫採用 |
framework/platform |
您可以按照下列說明,實作新的平台通訊埠和應用程式虛設常式: 測試架構平台通訊埠。 |
基本可攜性程式庫
基本的可攜性程式庫已支援 Windows、多數 Linux 變化版本、Mac OS、 iOS 和 Android如果測試目標是在其中一個作業系統上執行 您很可能完全不需要接觸基礎的可攜性程式庫。
測試架構平台通訊埠
deqp 測試架構平台通訊埠需要兩個元件:應用程式 進入點和平台介面實作
應用程式進入點負責建立平台物件
建立指令列 (tcu::CommandLine
) 物件,開啟測試記錄
(tcu::TestLog
) 並疊代測試應用程式 (tcu::App
)。如果
目標 OS 支援標準 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 專用的介面。詳情請見
下表簡要說明導入哪些指標
並進行測試
Module | 介面 |
---|---|
OpenGL (ES) 測試模組 |
GL 平台介面 |
EGL 測試模組 |
EGL 平台介面 |
如需實作平台通訊埠的詳細操作說明,請參閱 移植層標題
測試執行服務
如要使用 deqp 測試執行基礎架構或指令列執行程式,
測試執行服務必須在目標上提供。可攜式 C++
execserver
目錄中提供了服務的實作內容。使用
做為解碼器測試模組的一部分
打造適合電腦目標的版本您可以修改 execserver/CMakeLists.txt
,藉此啟用建構項目
其他目標。
C++ 版本的測試執行服務接受兩個指令列 參數:
-
--port=<port>
會設定伺服器監聽的 TCP 通訊埠。預設值為 50016。 -
--single
會在用戶端中斷連線時終止伺服器程序。根據預設, 伺服器程序將持續運作,以處理後續的測試執行要求。
執行測試
本頁說明如何在 Linux 和 Windows 中執行 deqp 測試 環境、使用指令列引數,以及與 Android 應用程式套件
Linux 和 Windows 環境
請先將下列檔案和目錄複製到目標。
Module | 目錄 | 目標 |
---|---|---|
執行伺服器 | 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 設定 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 檔案中分行列出每項測試的全名。身為 但重複重複的前置字元可能相當繁瑣避免重複 前置字串,請使用下方所示的檢索 (也稱為前置字串樹狀結構) 語法。
{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 以上版本)。
使用下列指令即可安裝應用程式套件 (name 顯示為 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 意圖
指定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 上偵錯
如要在 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 行開始。個人中心
可提供二進位檔的額外路徑,但提供正確的指令
一行參數應該足夠
注意:在 Windows 中,GDB 二進位檔需要
libpython2.7.dll
。啟動「debug.py
」前,請先新增
將 <path-to-ndk>/prebuilt/windows/bin
變更為 PATH 變數。
注意:原生程式碼偵錯功能無法運作 Android 4.3 或如需解決方法,請參閱 這個公開錯誤。Android 4.4 以上版本不含這個錯誤。
自動測試
解碼器測試模組可以透過多種方式整合至自動化測試系統。 最佳方法取決於現有的測試基礎架構和目標 環境。
測試執行作業的主要輸出內容一律為測試記錄檔 (即
開頭加上 .qpa
後置字串。您可以從測試記錄剖析完整的測試結果。控制台輸出內容為
只有偵錯資訊可用,且可能無法在所有平台上使用。
您可以直接透過測試自動化系統叫用測試二進位檔。測試 您可以針對特定用途、測試集或 可用的測試。如果執行期間發生嚴重錯誤 (例如某些 API) 錯誤或當機情形時,測試執行作業會取消。進行迴歸測試時 最佳做法是叫用個別案例或小測試的測試二進位檔 同時保留部分結果,這樣才能在事件發生時提供部分結果 但真正的失敗。
Deqp 隨附指令列測試執行工具,可用於 與執行服務相輔相成,進而實現更穩固的整合。 此執行程式偵測到測試程序終止,並在下列時間繼續執行測試: 可能的情境完整測試會產生單一記錄檔 會很有幫助這類設定非常適合不提供服務的輕量級測試系統 包括當機復原機制
指令列測試執行工具
目前的指令列工具集包含遠端測試執行工具、 迴歸分析的記錄比較產生器、「test-log-to-CSV 轉換工具」 「test-log-to-XML」轉換器和「testlog-to-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
會輸出測試
結果代碼,例如「票證」或「失敗」引數 --value=details
會進一步選取
解釋結果或準確率測試產生的結果或數值。
測試記錄 XML 匯出
您可以使用 testlog-to-xml
,將測試記錄檔轉換為有效的 XML 文件
公用程式系統支援兩種輸出模式:
- 獨立文件模式,其中每個測試案例和
caselist.xml
摘要 系統會將文件寫入目的地目錄 - 單一檔案模式,其中
.qpa
檔案中的所有結果都會寫入單一 XML 文件。
您可以使用 XML 樣式表,在瀏覽器中檢視匯出的測試記錄檔。
已提供樣式表範例文件 (testlog.xsl
和 testlog.css
)
前往 doc/testlog-stylesheet
目錄如要在瀏覽器中轉譯記錄檔,請複製
如果您使用 Google Chrome,則必須以 Chrome 的身分透過 HTTP 存取檔案
並基於安全考量限製本機檔案存取權。標準 Python 安裝
基本 HTTP 伺服器可啟動,以便將
目錄中使用 python –m SimpleHTTPServer 8000
指令。啟動伺服器後
只要將 Chrome 瀏覽器指向 http://localhost:8000
,即可查看測試記錄。
轉換為 JUnit 測試記錄
許多測試自動化系統可以從 JUnit 產生測試執行結果報告 輸出內容deqp 測試記錄檔可以轉換為 JUnit 輸出格式 使用 testlog-to-junit 工具。
這項工具目前只能翻譯測試案例判定結果。身為 JUnit 僅支援「pass」以及「失敗」結果,系統會對應傳遞的 deqp 結果 「JUnit Pass」而其他結果則會視為失敗原始版本 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.*