drawElements 品質計劃測試

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 測試模組和支援庫的原始程式碼佈局如下表所示（該列表並不全面，但突出顯示了最重要的目錄）。

開源元件

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 建置系統。目標建置檔案定義平台支援哪些功能以及需要哪些程式庫或其他包含路徑。目標檔名遵循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"

可以透過選擇「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 時非常有用。

始終使用-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必須由工具鏈檔案設定。

可以使用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++ 實作。獨立的二進位檔案是作為 PC 目標的 deqp 測試模組建構的一部分而建構的。您可以修改execserver/CMakeLists.txt以啟用在其他目標上的建置。

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

• --port=<port>將設定伺服器偵聽的 TCP 連接埠。預設值為 50016。
• --single將在客戶端斷開連線時終止伺服器程序。預設情況下，伺服器進程將保持運行狀態以服務進一步的測試執行請求。

運行測試

本頁提供有關在 Linux 和 Windows 環境中執行 deqp 測試、使用命令列參數以及使用 Android 應用程式套件的說明。

Linux 與 Windows 環境

首先將以下檔案和目錄複製到目標。

您可以將執行服務和測試二進位檔案部署在目標檔案系統中的任何位置；但是，測試二進位檔案期望在目前工作目錄中找到資料目錄。準備好後，在目標裝置上啟動測試執行服務。有關啟動服務的詳細信息，請參閱測試執行服務。

命令列參數

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

GLES2 和 GLES3 特定參數

測試用例清單格式

測試用例清單可以以兩種格式給出。第一個選項是在標準 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.*