drawElements 品質計畫測試

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

AOSP 包含 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 測試模組和支援程式庫的原始碼版面配置 (清單不完整，但會標示最重要的目錄)。

開放原始碼元件

deqp 會使用 libpng 和 zlib，您可以使用指令碼 platform/external/deqp/external/fetch_sources.py 或透過 platform/external/[libpng,zlib] 中的 git 擷取這些檔案。

建構測試計畫

我們在設計測試架構時，考量到可攜性。唯一的必要條件是完整的 C++ 支援，以及 I/O、執行緒和網路介面卡的標準系統程式庫。

CMake 建構系統

deqp 來源包含 CMake 的建構指令碼，這是編譯測試程式的首選工具。

CMake 是開放原始碼建構系統，支援多個平台和工具鍊。CMake 會從與目標無關的設定檔產生原生 Makefile 或 IDE 專案檔案。如要進一步瞭解 CMake，請參閱 CMake 說明文件。

CMake 支援並建議使用來源樹狀結構外建構，也就是說，您應一律在來源樹狀結構外的個別建構目錄中建立 Makefile 或專案檔案。CMake 沒有任何類型的「distclean」目標，因此必須手動移除 CMake 產生的任何檔案。

使用 -DOPTION_NAME=VALUE 語法將設定選項提供給 CMake。以下列出一些常用的 deqp 選項。

建立目標建構檔案

使用目標建構檔案，為新目標設定 deqp 建構系統。目標建構檔案會定義平台支援哪些功能，以及需要哪些程式庫或其他包含路徑。目標檔案名稱採用 targets/NAME/NAME.cmake 格式，且系統會使用 DEQP_TARGET 建構參數選取目標。

目標檔案中的檔案路徑是相對於基礎 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"

如要建構 64 位元版本，請選取「Visual Studio VERSION Win64」做為建構產生器：

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

您也可以使用 -G "NMake Makefiles" 選項和建構類型 (-DCMAKE_BUILD_TYPE="Debug" 或 "Release") 產生 NMake 製作檔。

算繪內容建立

在 Windows 上，您可以使用 WGL 或 EGL 建立算繪情境。

WGL 支援

所有 Win32 二進位檔都支援使用 WGL 建立 GL 內容，因為 WGL 只需要標準程式庫。您可以使用 --deqp-gl-context-type=wgl 指令列引數選取 WGL 內容。在 WGL 模式中，deqp 會使用 WGL_EXT_create_context_es_profile 擴充功能建立 OpenGL ES 情境。經過測試，此功能可與 NVIDIA 和 Intel 的最新驅動程式搭配使用。AMD 驅動程式不支援必要的擴充功能。

EGL 支援

如果 DEQP_SUPPORT_EGL 已開啟，則在 Windows 上建構 deqp 時會使用 EGL 的動態載入功能。這是大多數目標的預設值。接著，如果主機有可用的 EGL 程式庫，則可以使用指令列參數執行測試：--deqp-gl-context-type=egl

Android 版本

Android 建構作業會使用 CMake 建構指令碼建構原生測試程式碼。Java 部分 (即測試執行伺服器和測試應用程式 Stub) 會使用標準 Android 建構工具進行編譯。

如要使用提供的建構指令碼，為 Android 編譯 deqp 測試程式，您需要：

• 最新版 Android NDK；android/scripts/common.py 檔案會列出所需版本
• 已安裝 API 13、SDK 工具、SDK Platform-Tools 和 SDK Build-tools 套件的 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 環境變數定義。

執行 android/scripts/build.py 指令碼，即可建構 Deqp 裝置端元件、測試執行服務和測試程式。最終的 .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 提供其他程式庫或包含搜尋路徑。

以下是用於針對自訂位置中的驅動程式標頭和程式庫執行 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 建構參數選取工具鍊檔案。舉例來說，以下指令會使用 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 涉及三個步驟：調整基本可攜性程式庫、實作測試架構平台整合介面，以及移植執行服務。

下表列出可能需要移植變更的位置。其他任何內容都可能屬於異國情調。

基本可攜性程式庫

基本移植性程式庫已支援 Windows、大多數 Linux 變化版本、Mac OS、iOS 和 Android。如果測試目標在其中一個作業系統上執行，則很可能完全不需要觸及基本可移植性程式庫。

測試架構平台端口

deqp 測試架構平台端口需要兩個元件：應用程式進入點和平台介面實作。

應用程式進入點負責建立平台物件、建立指令列 (tcu::CommandLine) 物件、開啟測試記錄 (tcu::TestLog)，以及迭代測試應用程式 (tcu::App)。如果目標作業系統支援標準 main() 進入點，tcuMain.cpp 可用於做為進入點實作。

下列檔案詳細說明 deqp 平台 API。

所有平台端口的基本類別為 tcu::Platform。平台端口可選擇支援 GL 和 EGL 專屬介面。請參閱下表，瞭解執行測試時需要實作哪些項目。

如要進一步瞭解如何實作平台端口，請參閱端口轉譯層標頭。

測試執行服務

如要使用 deqp 測試執行基礎架構或指令列執行器，目標上必須提供測試執行服務。execserver 目錄提供服務的可攜式 C++ 實作項目。獨立二進位檔會在為電腦目標建構 deqp 測試模組時一併建構。您可以修改 execserver/CMakeLists.txt，啟用其他目標的建構作業。

測試執行服務的 C++ 版本會接受兩個指令列參數：

• --port=<port> 會設定伺服器監聽的 TCP 通訊埠。預設值為 50016。
• --single 會在用戶端中斷連線時終止伺服器程序。根據預設，伺服器程序會持續運作，以便處理後續的測試執行要求。

執行測試

本頁面提供在 Linux 和 Windows 環境中執行 deqp 測試、使用指令列引數，以及使用 Android 應用程式套件的操作說明。

Linux 和 Windows 環境

請先將下列檔案和目錄複製到目標。

您可以在目標檔案系統的任何位置部署執行服務和測試二進位檔，但測試二進位檔會預期在目前工作目錄中找到資料目錄。準備就緒後，請在目標裝置上啟動測試執行服務。如要進一步瞭解如何啟動服務，請參閱「測試執行服務」。

指令列引數

下表列出會影響所有測試程式執行作業的指令列引數。

GLES2 和 GLES3 專屬引數

測試案例清單格式

測試案例清單可提供兩種格式。第一個選項是在標準 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 以上版本)。

您可以使用下列指令安裝應用程式套件 (顯示的名稱是 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 上執行測試，但不使用 Android CTS

如要手動啟動測試執行活動，請建構鎖定 android.app.NativeActivity 的 Android 意圖。這些活動可在 com.drawelements.deqp 套件中找到。指令列必須以額外字串的形式提供，並在意圖中使用 "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 指令列取決於要執行的測試案例和其他必要參數。指令碼會在中斷點執行作業 (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.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.*