Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Kiểm thử Chương trình chất lượng drawElements

AOSP bao gồm bộ kiểm thử GPU drawElements Quality Program (deqp) tại https://android.googlesource.com/platform/external/deqp. Trang này trình bày chi tiết cách triển khai bộ kiểm thử deqp vào một môi trường mới.

Để làm việc với mã được gửi gần đây nhất, hãy sử dụng nhánh deqp-dev. Đối với mã khớp với một bản phát hành CTS Android cụ thể, hãy sử dụng nhánh release-code-name-release (ví dụ: đối với Android 6.0, hãy sử dụng nhánh marshmallow-release).

Bố cục nguồn

Bố cục mã nguồn cho các mô-đun kiểm thử deqp và các thư viện hỗ trợ được trình bày trong bảng dưới đây (danh sách này không đầy đủ nhưng nêu bật các thư mục quan trọng nhất).

Thư mục	Mô tả
`android`	Nguồn và tập lệnh bản dựng của trình kiểm thử Android
`data`	Tệp dữ liệu kiểm thử
`modules`	Nguồn mô-đun kiểm thử
`modules/egl`	Mô-đun EGL
`modules/gles2`	Mô-đun GLES2
`modules/gles3`	Mô-đun GLES3
`modules/gles31`	Mô-đun GLES3.1
`modules/gles32`	Mô-đun GLES3.2
`targets`	Tệp cấu hình bản dựng dành riêng cho mục tiêu
`framework`	Tiện ích và khung mô-đun kiểm thử deqp
`framework/delibs`	Khả năng di chuyển cơ sở và thư viện bản dựng
`framework/platform`	Cổng nền tảng
`framework/qphelper`	Kiểm thử thư viện tích hợp chương trình (C)
`framework/common`	Khung deqp (C++)
`framework/opengl, framework/egl`	Tiện ích dành riêng cho API
`execserver`	Nguồn ExecServer phía thiết bị
`executor`	Tiện ích và công cụ shell của trình thực thi kiểm thử phía máy chủ lưu trữ
`external`	Tạo thư mục stub cho các thư viện bên ngoài libpng và zlib

Các thành phần nguồn mở

deqp sử dụng libpng và zlib, có thể được tìm nạp bằng tập lệnh platform/external/deqp/external/fetch_sources.py hoặc thông qua git từ platform/external/[libpng,zlib].

Xây dựng chương trình kiểm thử

Khung kiểm thử được thiết kế chú trọng đến tính di động. Yêu cầu bắt buộc duy nhất là hỗ trợ đầy đủ C++ và các thư viện hệ thống tiêu chuẩn cho I/O, luồng và ổ cắm.

Hệ thống xây dựng CMake

Các nguồn deqp có tập lệnh bản dựng cho CMake, đây là công cụ ưu tiên để biên dịch các chương trình kiểm thử.

CMake là một hệ thống bản dựng nguồn mở hỗ trợ nhiều nền tảng và chuỗi công cụ. CMake tạo các tệp makefile gốc hoặc tệp dự án IDE từ các tệp cấu hình độc lập với mục tiêu. Để biết thêm thông tin về CMake, vui lòng xem tài liệu về CMake.

CMake hỗ trợ và đề xuất các bản dựng ngoài cây nguồn, tức là bạn phải luôn tạo các tệp makefile hoặc tệp dự án trong một thư mục bản dựng riêng biệt bên ngoài cây nguồn. CMake không có loại mục tiêu "distclean" nào, vì vậy, bạn phải xoá mọi tệp do CMake tạo theo cách thủ công.

Các lựa chọn cấu hình được cung cấp cho CMake bằng cú pháp -DOPTION_NAME=VALUE. Dưới đây là một số lựa chọn thường dùng cho deqp.

Lựa chọn cấu hình Mô tả

Lựa chọn cấu hình	Mô tả
`DEQP_TARGET`	Tên mục tiêu, ví dụ: "android" Các tập lệnh CMake deqp sẽ bao gồm tệp `targets/DEQP_TARGET/DEQP_TARGET.cmake` và dự kiến sẽ tìm thấy các lựa chọn bản dựng dành riêng cho mục tiêu từ đó.
`CMAKE_TOOLCHAIN_FILE`	Đường dẫn đến tệp chuỗi công cụ cho CMake. Được dùng để biên dịch chéo.
`CMAKE_BUILD_TYPE`	Loại bản dựng cho các mục tiêu makefile. Các giá trị hợp lệ là: "Debug" và "Release" Xin lưu ý rằng cách diễn giải và loại mặc định phụ thuộc vào hệ thống bản dựng mục tiêu. Hãy xem tài liệu CMake để biết thông tin chi tiết.

DEQP_TARGET

Tên mục tiêu, ví dụ: "android"

Các tập lệnh CMake deqp sẽ bao gồm tệp targets/DEQP_TARGET/DEQP_TARGET.cmake và dự kiến sẽ tìm thấy các lựa chọn bản dựng dành riêng cho mục tiêu từ đó.

CMAKE_TOOLCHAIN_FILE

Đường dẫn đến tệp chuỗi công cụ cho CMake. Được dùng để biên dịch chéo.

CMAKE_BUILD_TYPE

Loại bản dựng cho các mục tiêu makefile. Các giá trị hợp lệ là: "Debug" và "Release"

Xin lưu ý rằng cách diễn giải và loại mặc định phụ thuộc vào hệ thống bản dựng mục tiêu. Hãy xem tài liệu CMake để biết thông tin chi tiết.

Tạo tệp bản dựng mục tiêu

Hệ thống xây dựng deqp được định cấu hình cho các mục tiêu mới bằng cách sử dụng tệp bản dựng mục tiêu. Tệp bản dựng mục tiêu xác định những tính năng mà nền tảng hỗ trợ và những thư viện hoặc đường dẫn bao gồm bổ sung nào là bắt buộc. Tên tệp đích tuân theo định dạng targets/NAME/NAME.cmake và đích được chọn bằng cách sử dụng tham số bản dựng DEQP_TARGET.

Đường dẫn tệp trong các tệp đích tương ứng với thư mục cơ sở deqp, chứ không phải thư mục targets/NAME. Bạn có thể đặt các biến chuẩn sau đây theo tệp bản dựng đích.

Biến	Mô tả
`DEQP_TARGET_NAME`	Tên mục tiêu (sẽ được đưa vào nhật ký kiểm thử)
`DEQP_SUPPORT_GLES2`	GLES2 có được hỗ trợ hay không (mặc định: TẮT)
`DEQP_GLES2_LIBRARIES`	Thư viện GLES2 (để trống nếu không được hỗ trợ hoặc sử dụng tính năng tải động)
`DEQP_SUPPORT_GLES3`	GLES3.x có được hỗ trợ hay không (mặc định: TẮT)
`DEQP_GLES3_LIBRARIES`	Thư viện GLES3.x (để trống nếu không được hỗ trợ hoặc sử dụng tính năng tải động)
`DEQP_SUPPORT_VG`	Có hỗ trợ OpenVG hay không (mặc định: TẮT)
`DEQP_OPENVG_LIBRARIES`	Thư viện OpenVG (để trống nếu không được hỗ trợ hoặc sử dụng tính năng tải động)
`DEQP_SUPPORT_EGL`	Có hỗ trợ EGL hay không (mặc định: TẮT)
`DEQP_EGL_LIBRARIES`	Thư viện EGL (để trống nếu không được hỗ trợ hoặc sử dụng tính năng tải động)
`DEQP_PLATFORM_LIBRARIES`	Bắt buộc phải có các thư viện dành riêng cho nền tảng khác để liên kết
`DEQP_PLATFORM_COPY_LIBRARIES`	Danh sách các thư viện được sao chép vào từng thư mục bản dựng nhị phân kiểm thử. Có thể dùng để sao chép các thư viện cần thiết để chạy kiểm thử nhưng không có trong đường dẫn tìm kiếm mặc định.
`TCUTIL_PLATFORM_SRCS`	Danh sách nguồn cổng nền tảng. Các nguồn mặc định được xác định dựa trên các chức năng và hệ điều hành. Lưu ý: Đường dẫn tương ứng với: `framework/platform`

Tệp bản dựng đích có thể thêm các đường dẫn liên kết hoặc đường dẫn bao gồm bổ sung bằng cách sử dụng các hàm include_directories() và link_directories() CMake.

Bản dựng Win32

Cách dễ nhất để tạo các mô-đun deqp cho Windows là sử dụng hệ thống tạo CMake. Bạn sẽ cần CMake 2.6.12 trở lên và trình biên dịch Microsoft Visual C/C++. deqp đã được kiểm thử bằng Visual Studio 2013.

Bạn có thể tạo các tệp dự án Visual Studio bằng lệnh sau:

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

Bạn có thể tạo bản dựng 64 bit bằng cách chọn "Visual Studio VERSION Win64" làm trình tạo bản dựng:

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

Bạn cũng có thể tạo tệp make NMake bằng lựa chọn -G "NMake Makefiles" cũng như loại bản dựng (-DCMAKE_BUILD_TYPE="Debug" hoặc "Release").

Tạo bối cảnh kết xuất

Bạn có thể tạo ngữ cảnh kết xuất bằng WGL hoặc EGL trên Windows.

Hỗ trợ WGL

Tất cả các tệp nhị phân Win32 đều hỗ trợ việc tạo bối cảnh GL bằng WGL vì chỉ yêu cầu các thư viện tiêu chuẩn. Bạn có thể chọn ngữ cảnh WGL bằng đối số dòng lệnh --deqp-gl-context-type=wgl. Ở chế độ WGL, deqp sử dụng tiện ích WGL_EXT_create_context_es_profile để tạo ngữ cảnh OpenGL ES. Thư viện này đã được kiểm chứng là hoạt động với trình điều khiển mới nhất của NVIDIA và Intel. Trình điều khiển AMD không hỗ trợ tiện ích bắt buộc.

Hỗ trợ EGL

deqp được tạo bằng tính năng tải động cho EGL trên Windows nếu DEQP_SUPPORT_EGL ở trạng thái BẬT. Đây là chế độ mặc định trong hầu hết các mục tiêu. Sau đó, nếu máy chủ có sẵn các thư viện EGL, bạn có thể chạy các bài kiểm thử bằng các thư viện này bằng tham số dòng lệnh: --deqp-gl-context-type=egl

Bản dựng Android

Bản dựng Android sử dụng tập lệnh bản dựng CMake để tạo mã kiểm thử gốc. Các phần Java (tức là Máy chủ thực thi kiểm thử và Trình mô phỏng ứng dụng kiểm thử) được biên dịch bằng các công cụ tạo Android tiêu chuẩn.

Để biên dịch các chương trình kiểm thử deqp cho Android bằng các tập lệnh bản dựng được cung cấp, bạn sẽ cần:

Phiên bản mới nhất của Android NDK; tệp android/scripts/common.py liệt kê phiên bản bắt buộc
SDK độc lập của Android có API 13, Công cụ SDK, Công cụ nền tảng SDK và các gói Công cụ tạo SDK đã cài đặt
Apache Ant 1.9.4 (bắt buộc đối với bản dựng mã Java)
CMake 2.8.12 trở lên
Python 2.6 trở lên trong dòng 2.x; Python 3.x không được hỗ trợ
Đối với Windows: NMake hoặc JOM trong PATH
- JOM giúp tạo bản dựng nhanh hơn
Không bắt buộc: Ninja make cũng được hỗ trợ trên Linux

Các tệp nhị phân Ant và SDK được đặt dựa trên biến môi trường PATH với một số giá trị mặc định ghi đè nhất định. Logic này do android/scripts/common.py kiểm soát.

Thư mục NDK phải là ~/android-ndk-VERSION hoặc C:/android/android-ndk-VERSION hoặc được xác định thông qua biến môi trường ANDROID_NDK_PATH.

Các thành phần trên thiết bị deqp, dịch vụ thực thi kiểm thử và chương trình kiểm thử được tạo bằng cách thực thi tập lệnh android/scripts/build.py. Tệp .apk cuối cùng được tạo trong android/package/bin và có thể được cài đặt bằng tập lệnh install.py. Nếu bạn dùng trình thực thi dòng lệnh, thì ExecService sẽ được khởi chạy bằng tập lệnh launch.py trên thiết bị thông qua ADB. Bạn có thể thực thi tập lệnh từ bất kỳ thư mục nào.

Bản dựng Linux

Bạn có thể tạo các tiện ích dòng lệnh và tệp nhị phân kiểm thử cho Linux bằng cách tạo tệp makefile bằng CMake. Có nhiều mục tiêu bản dựng được xác định trước, hữu ích khi tạo bản dựng cho Linux.

Mục tiêu xây dựng	Mô tả
`default`	Mục tiêu mặc định sử dụng tính năng tự kiểm tra nền tảng CMake để xác định khả năng hỗ trợ cho nhiều API.
`x11_glx`	Sử dụng GLX để tạo ngữ cảnh OpenGL (ES).
`x11_egl`	Sử dụng EGL để tạo ngữ cảnh OpenGL (ES).
`x11_egl_glx`	Hỗ trợ cả GLX và EGL bằng X11.

Luôn sử dụng -DCMAKE_BUILD_TYPE=<Debug|Release> để xác định loại bản dựng. Release là giá trị mặc định phù hợp. Nếu không có, một bản phát hành mặc định, chưa được tối ưu hoá sẽ được tạo.

Bạn có thể dùng các đối số dòng lệnh -DCMAKE_C_FLAGS và -DCMAKE_CXX_FLAGS để truyền các đối số bổ sung cho trình biên dịch. Ví dụ: bạn có thể tạo bản dựng 32 bit hoặc 64 bit bằng cách đặt lần lượt -DCMAKE_C(XX)_FLAGS="-m32" hoặc "-m64". Nếu không được chỉ định, hệ thống sẽ sử dụng cấu trúc gốc của chuỗi công cụ, thường là 64 bit trên chuỗi công cụ 64 bit.

Bạn có thể dùng các đối số -DCMAKE_LIBRARY_PATH và -DCMAKE_INCLUDE_PATH để cung cấp cho CMake các đường dẫn tìm kiếm thư viện hoặc đường dẫn tìm kiếm bao gồm bổ sung.

Sau đây là ví dụ về dòng lệnh đầy đủ được dùng để tạo bản gỡ lỗi 32 bit dựa trên các tiêu đề và thư viện trình điều khiển ở một vị trí tuỳ chỉnh:

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

Biên dịch chéo

Bạn có thể biên dịch chéo bằng cách sử dụng tệp chuỗi công cụ CMake. Tệp chuỗi công cụ chỉ định trình biên dịch cần sử dụng, cùng với các đường dẫn tìm kiếm tuỳ chỉnh cho thư viện và tiêu đề. Một số tệp chuỗi công cụ cho các trường hợp phổ biến được đưa vào gói phát hành trong thư mục framework/delibs/cmake.

Ngoài các biến CMake tiêu chuẩn, tệp chuỗi công cụ có thể đặt các biến dành riêng cho deqp sau đây. CMake thường có thể phát hiện chính xác DE_OS, DE_COMPILER và DE_PTR_SIZE nhưng DE_CPU phải được thiết lập bằng tệp chuỗi công cụ.

Biến	Mô tả
`DE_OS`	Hệ điều hành. Sau đây là các giá trị được hỗ trợ: `DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS`
`DE_COMPILER`	Loại trình biên dịch. Sau đây là các giá trị được hỗ trợ: `DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG`
`DE_CPU`	Loại CPU. Các giá trị được hỗ trợ là: `DE_CPU_ARM, DE_CPU_X86`.
`DE_PTR_SIZE`	sizeof(void*) trên nền tảng. Giá trị được hỗ trợ là: 4 và 8

Bạn có thể chọn tệp chuỗi công cụ bằng cách sử dụng tham số bản dựng CMAKE_TOOLCHAIN_FILE. Ví dụ: lệnh sau đây sẽ tạo các tệp makefile cho bản dựng bằng cách sử dụng trình biên dịch chéo CodeSourcery cho ARM/Linux:

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

Liên kết thời gian chạy của các thư viện GLES và EGL

deqp không cần các điểm truy cập của API đang được kiểm thử trong quá trình liên kết. Mã kiểm thử luôn truy cập vào các API thông qua con trỏ hàm. Sau đó, các điểm truy cập có thể được tải linh động trong thời gian chạy hoặc cổng nền tảng có thể cung cấp các điểm truy cập này tại thời gian liên kết.

Nếu chế độ hỗ trợ cho một API được bật trong chế độ cài đặt bản dựng và không có thư viện liên kết, thì deqp sẽ tải các điểm truy cập cần thiết vào thời gian chạy. Nếu bạn muốn liên kết tĩnh, hãy cung cấp các thư viện liên kết cần thiết trong biến cấu hình bản dựng DEQP_<API>_LIBRARIES.

Chuyển khung kiểm thử

Việc chuyển deqp bao gồm 3 bước: điều chỉnh các thư viện tính di động cơ bản, triển khai các giao diện tích hợp nền tảng khung kiểm thử và chuyển dịch vụ thực thi.

Bảng dưới đây liệt kê các vị trí có thể xảy ra thay đổi khi chuyển. Bất cứ thứ gì vượt quá những điều này đều có khả năng là ngoại lai.

Vị trí	Mô tả
`framework/delibs/debase framework/delibs/dethread framework/delibs/deutil`	Mọi hoạt động triển khai cần thiết đối với mã dành riêng cho hệ điều hành.
`framework/qphelper/qpCrashHandler.c`	Không bắt buộc: Triển khai cho hệ điều hành của bạn.
`framework/qphelper/qpWatchDog.c`	Triển khai cho hệ điều hành của bạn. Phiên bản hiện tại dựa trên `dethread` và thư viện C chuẩn.
`framework/platform`	Bạn có thể triển khai cổng nền tảng và ứng dụng gốc mới như mô tả trong phần Cổng nền tảng của khung kiểm thử.

Thư viện tính di động cơ bản

Các thư viện di động cơ bản đã hỗ trợ Windows, hầu hết các biến thể Linux, Mac OS, iOS và Android. Nếu mục tiêu kiểm thử chạy trên một trong những hệ điều hành đó, thì rất có thể bạn không cần phải chỉnh sửa các thư viện khả năng tương thích cơ bản.

Cổng nền tảng khung thử nghiệm

Cổng nền tảng khung kiểm thử deqp yêu cầu 2 thành phần: Điểm truy cập ứng dụng và quá trình triển khai giao diện nền tảng.

Điểm truy cập ứng dụng chịu trách nhiệm tạo đối tượng nền tảng, tạo đối tượng dòng lệnh (tcu::CommandLine), mở nhật ký kiểm thử (tcu::TestLog) và lặp lại ứng dụng kiểm thử (tcu::App). Nếu hệ điều hành mục tiêu hỗ trợ điểm truy cập main() tiêu chuẩn, thì tcuMain.cpp có thể được dùng làm cách triển khai điểm truy cập.

API nền tảng deqp được mô tả chi tiết trong các tệp sau.

Tệp	Mô tả
`framework/common/tcuPlatform.hpp`	Lớp cơ sở cho tất cả các cổng nền tảng
`framework/opengl/gluPlatform.hpp`	Giao diện nền tảng OpenGL
`framework/egl/egluPlatform.hpp`	Giao diện nền tảng EGL
`framework/platform/tcuMain.cpp`	Điểm truy cập tiêu chuẩn vào ứng dụng

Lớp cơ sở cho tất cả các cổng nền tảng là tcu::Platform. Cổng nền tảng có thể hỗ trợ các giao diện dành riêng cho GL và EGL (không bắt buộc). Hãy xem bảng sau để biết thông tin tổng quan về những nội dung cần triển khai để chạy các thử nghiệm.

Mô-đun	Giao diện
Mô-đun kiểm thử OpenGL (ES)	Giao diện nền tảng GL
Mô-đun kiểm thử EGL	Giao diện nền tảng EGL

Hướng dẫn chi tiết về cách triển khai các cổng nền tảng nằm trong tiêu đề lớp chuyển.

Dịch vụ thực thi kiểm thử

Để sử dụng cơ sở hạ tầng thực thi kiểm thử deqp hoặc trình thực thi dòng lệnh, dịch vụ thực thi kiểm thử phải có trên mục tiêu. Một chế độ triển khai C++ di động của dịch vụ được cung cấp trong thư mục execserver. Tệp nhị phân độc lập được tạo như một phần của bản dựng mô-đun kiểm thử deqp cho các mục tiêu trên máy tính. Bạn có thể sửa đổi execserver/CMakeLists.txt để bật bản dựng trên các mục tiêu khác.

Phiên bản C++ của dịch vụ thực thi kiểm thử chấp nhận 2 tham số dòng lệnh:

--port=<port> sẽ đặt cổng TCP mà máy chủ theo dõi. Giá trị mặc định là 50016.
--single sẽ chấm dứt quá trình máy chủ khi ứng dụng ngắt kết nối. Theo mặc định, quy trình máy chủ sẽ tiếp tục hoạt động để phục vụ các yêu cầu thực thi kiểm thử khác.

Chạy kiểm thử

Trang này cung cấp hướng dẫn chạy các kiểm thử deqp trong môi trường Linux và Windows, sử dụng đối số dòng lệnh và làm việc với gói ứng dụng Android.

Môi trường Linux và Windows

Bắt đầu bằng cách sao chép các tệp và thư mục sau vào đích đến.

Mô-đun	Thư mục	Mục tiêu
Máy chủ thực thi	`build/execserver/execserver`	`<dst>/execserver`
Mô-đun EGL	`build/modules/egl/deqp-egl`	`<dst>/deqp-egl`
Mô-đun GLES2	`build/modules/gles2/deqp-gles2`	`<dst>/deqp-gles2`
Mô-đun GLES2	`data/gles2`	`<dst>/gles2`
Mô-đun GLES3	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
Mô-đun GLES3	`data/gles3`	`<dst>/gles3`
Mô-đun GLES3.1	`build/modules/gles31/deqp-gles31`	`<dst>/deqp-gles31`
Mô-đun GLES3.1	`data/gles31`	`<dst>/gles31`
Mô-đun GLES3.2	`build/modules/gles32/deqp-gles32`	`<dst>/deqp-gles32`
Mô-đun GLES3.2	`data/gles32`	`<dst>/gles32`

Bạn có thể triển khai dịch vụ thực thi và kiểm thử các tệp nhị phân ở bất kỳ đâu trong hệ thống tệp đích; tuy nhiên, các tệp nhị phân kiểm thử dự kiến sẽ tìm thấy các thư mục dữ liệu trong thư mục đang hoạt động hiện tại. Khi đã sẵn sàng, hãy bắt đầu Dịch vụ thực thi kiểm thử trên thiết bị mục tiêu. Để biết thông tin chi tiết về cách bắt đầu dịch vụ, hãy xem phần Dịch vụ thực thi kiểm thử.

Đối số dòng lệnh

Bảng sau đây liệt kê các đối số dòng lệnh ảnh hưởng đến quá trình thực thi của tất cả các chương trình kiểm thử.

Đối số	Mô tả
`--deqp-case=<casename>`	Chạy các trường hợp khớp với một mẫu nhất định. Hỗ trợ ký tự đại diện (*).
`--deqp-log-filename=<filename>`	Ghi kết quả kiểm thử vào tệp có tên mà bạn cung cấp. Dịch vụ thực thi kiểm thử sẽ đặt tên tệp khi bắt đầu kiểm thử.
`--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>`	Đọc danh sách trường hợp từ stdin hoặc từ một đối số nhất định. Dịch vụ thực thi kiểm thử sẽ đặt đối số theo yêu cầu thực thi nhận được. Hãy xem phần tiếp theo để biết nội dung mô tả về định dạng danh sách trường hợp.
`--deqp-test-iteration-count=<count>`	Ghi đè số lần lặp lại cho các kiểm thử hỗ trợ số lần lặp lại có thể thay đổi.
`--deqp-base-seed=<seed>`	Dữ liệu gốc cơ sở cho các trường hợp kiểm thử sử dụng phương pháp ngẫu nhiên hoá.

Đối số dành riêng cho GLES2 và GLES3

Bảng sau đây liệt kê các đối số dành riêng cho GLES2 và GLES3.

Đối số	Mô tả
`--deqp-gl-context-type=<type>`	Loại ngữ cảnh OpenGL. Các loại bối cảnh có sẵn tuỳ thuộc vào nền tảng. Trên các nền tảng hỗ trợ EGL, bạn có thể dùng giá trị `egl` để chọn bối cảnh EGL.
`--deqp-gl-config-id=<id>`	Chạy kiểm thử cho mã nhận dạng cấu hình GL đã cung cấp. Việc diễn giải phụ thuộc vào nền tảng. Trên nền tảng EGL, đây là mã cấu hình EGL.
`--deqp-gl-config-name=<name>`	Chạy kiểm thử cho một cấu hình GL có tên. Việc diễn giải phụ thuộc vào nền tảng. Đối với EGL, định dạng là `rgb(a)<bits>d<bits>s<bits>`. Ví dụ: giá trị `rgb888s8` sẽ chọn cấu hình đầu tiên trong đó vùng đệm màu là RGB888 và vùng đệm khuôn tô có 8 bit.
`--deqp-gl-context-flags=<flags>`	Tạo một ngữ cảnh. Chỉ định `robust` hoặc `debug`.
`--deqp-surface-width=<width> --deqp-surface-height=<height>`	Hãy thử tạo một bề mặt có kích thước nhất định. Bạn không bắt buộc phải hỗ trợ tính năng này.
`--deqp-surface-type=<type>`	Sử dụng một loại nền tảng nhất định làm mục tiêu kết xuất thử nghiệm chính. Các loại có thể có là `window`, `pixmap`, `pbuffer` và `fbo`.
`--deqp-screen-rotation=<rotation>`	Hướng màn hình theo gia số 90 độ cho những nền tảng hỗ trợ hướng này.

Định dạng danh sách trường hợp kiểm thử

Bạn có thể cung cấp danh sách trường hợp kiểm thử theo hai định dạng. Lựa chọn đầu tiên là liệt kê tên đầy đủ của từng bài kiểm tra trên một dòng riêng biệt trong tệp ASCII tiêu chuẩn. Khi các bộ kiểm thử tăng lên, các tiền tố lặp lại có thể trở nên rườm rà. Để tránh lặp lại các tiền tố, hãy sử dụng cú pháp trie (còn gọi là cây tiền tố) như minh hoạ bên dưới.

{nodeName{firstChild{…},…lastChild{…}}}

Ví dụ:

{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}

Chuyển thành 2 trường hợp kiểm thử sau:

dEQP-EGL.config_list
dEQP-EGL.create_context.rgb565_depth_stencil

Android

Gói ứng dụng Android chứa tất cả các thành phần bắt buộc, bao gồm cả dịch vụ thực thi kiểm thử, các tệp nhị phân kiểm thử và tệp dữ liệu. Hoạt động kiểm thử là một NativeActivity sử dụng EGL (yêu cầu Android 3.2 trở lên).

Bạn có thể cài đặt gói ứng dụng bằng lệnh sau (tên hiển thị là tên của APK trong gói CTS Android; tên này phụ thuộc vào bản dựng):

adb –d install –r com.drawelements.deqp.apk

Để chạy dịch vụ thực thi kiểm thử và thiết lập chuyển tiếp cổng, hãy dùng lệnh sau:

adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter

Bạn có thể bật tính năng in gỡ lỗi bằng cách thực thi lệnh sau đây trước khi bắt đầu kiểm thử:

adb –d shell setprop log.tag.dEQP DEBUG

Thực thi các kiểm thử trên Android mà không cần Android CTS

Để bắt đầu hoạt động thực thi kiểm thử theo cách thủ công, hãy tạo một ý định trên Android nhắm đến android.app.NativeActivity. Bạn có thể tìm thấy các hoạt động này trong gói com.drawelements.deqp. Dòng lệnh phải được cung cấp dưới dạng một chuỗi bổ sung có khoá "cmdLine" trong Ý định.

Nhật ký kiểm thử được ghi vào /sdcard/dEQP-log.qpa. Nếu quá trình chạy thử không bắt đầu bình thường, bạn có thể xem thêm thông tin gỡ lỗi trong nhật ký thiết bị.

Bạn có thể chạy một hoạt động từ dòng lệnh bằng cách sử dụng tiện ích am. Ví dụ: để chạy kiểm thử dEQP-GLES2.info trên một nền tảng hỗ trợ NativeActivity,, hãy dùng các lệnh sau.

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"'

Gỡ lỗi trên Android

Để chạy các kiểm thử trong trình gỡ lỗi GDB trên Android, trước tiên, hãy biên dịch và cài đặt bản gỡ lỗi bằng cách chạy 2 tập lệnh sau:

python android/scripts/build.py --native-build-type=Debug
python android/scripts/install.py

Sau khi bản gỡ lỗi được cài đặt trên thiết bị, để chạy các kiểm thử trong GDB đang chạy trên máy chủ lưu trữ, hãy chạy lệnh sau:

python android/scripts/debug.py \
--deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"

Dòng lệnh deqp phụ thuộc vào các trường hợp kiểm thử sẽ được thực thi và các tham số bắt buộc khác. Tập lệnh này sẽ thêm một điểm ngắt mặc định vào đầu quá trình thực thi deqp (tcu::App::App).

Tập lệnh debug.py chấp nhận nhiều đối số dòng lệnh cho các thao tác như thiết lập điểm ngắt để gỡ lỗi, các tham số kết nối gdbserver và đường dẫn đến các tệp nhị phân bổ sung để gỡ lỗi (sử dụng debug.py --help cho tất cả các đối số và nội dung giải thích). Tập lệnh này cũng sao chép một số thư viện mặc định từ thiết bị mục tiêu để lấy danh sách biểu tượng.

Để từng bước thực hiện mã trình điều khiển (chẳng hạn như khi GDB cần biết vị trí của các tệp nhị phân có đầy đủ thông tin gỡ lỗi), hãy thêm các thư viện khác thông qua tham số dòng lệnh debug.py. Tập lệnh này ghi một tệp cấu hình cho GDB bắt đầu từ dòng 132 của tệp tập lệnh. Bạn có thể cung cấp các đường dẫn bổ sung đến các tệp nhị phân, v.v., nhưng việc cung cấp các tham số dòng lệnh chính xác là đủ.

Lưu ý: Trên Windows, tệp nhị phân GDB yêu cầu libpython2.7.dll. Trước khi chạy debug.py, hãy thêm <path-to-ndk>/prebuilt/windows/bin vào biến PATH.

Lưu ý: Chức năng gỡ lỗi mã gốc không hoạt động trên Android 4.3 gốc; để biết các giải pháp thay thế, hãy tham khảo lỗi công khai này. Android 4.4 trở lên không có lỗi này.

Tự động hoá các kiểm thử

Bạn có thể tích hợp các mô-đun kiểm thử deqp vào hệ thống kiểm thử tự động theo nhiều cách. Phương pháp tốt nhất sẽ phụ thuộc vào cơ sở hạ tầng kiểm thử hiện có và môi trường mục tiêu.

Đầu ra chính của một lần chạy kiểm thử luôn là tệp nhật ký kiểm thử, tức là tệp có hậu tố .qpa. Bạn có thể phân tích cú pháp toàn bộ kết quả kiểm thử từ nhật ký kiểm thử. Đầu ra trên bảng điều khiển chỉ là thông tin gỡ lỗi và có thể không có trên tất cả các nền tảng.

Bạn có thể gọi trực tiếp các tệp nhị phân kiểm thử từ hệ thống tự động hoá kiểm thử. Bạn có thể chạy tệp nhị phân kiểm thử cho một trường hợp cụ thể, cho một bộ kiểm thử hoặc cho tất cả các kiểm thử có sẵn. Nếu xảy ra lỗi nghiêm trọng trong quá trình thực thi (chẳng hạn như một số lỗi API hoặc sự cố), quá trình thực thi kiểm thử sẽ bị huỷ. Đối với kiểm thử hồi quy, phương pháp hay nhất là gọi các tệp nhị phân kiểm thử cho từng trường hợp hoặc các tập hợp kiểm thử nhỏ riêng biệt, để có kết quả một phần ngay cả trong trường hợp xảy ra lỗi nghiêm trọng.

deqp đi kèm với các công cụ thực thi kiểm thử dòng lệnh có thể dùng kết hợp với dịch vụ thực thi để đạt được khả năng tích hợp mạnh mẽ hơn. Trình thực thi phát hiện quá trình kết thúc kiểm thử và sẽ tiếp tục thực thi kiểm thử trên trường hợp có sẵn tiếp theo. Một tệp nhật ký duy nhất được tạo từ phiên kiểm thử đầy đủ. Thiết lập này phù hợp với các hệ thống kiểm thử có dung lượng nhỏ và không cung cấp các cơ chế khôi phục sau sự cố.

Công cụ thực thi kiểm thử dòng lệnh

Bộ công cụ dòng lệnh hiện tại bao gồm một công cụ thực thi kiểm thử từ xa, một trình tạo so sánh nhật ký kiểm thử để phân tích hồi quy, một trình chuyển đổi nhật ký kiểm thử sang CSV, một trình chuyển đổi nhật ký kiểm thử sang XML và một trình chuyển đổi nhật ký kiểm thử sang JUnit.

Mã nguồn cho các công cụ này nằm trong thư mục executor và các tệp nhị phân được tạo trong thư mục <builddir>/executor.

Trình thực thi kiểm thử dòng lệnh

Trình thực thi kiểm thử dòng lệnh là một công cụ C++ di động để chạy một quy trình kiểm thử trên thiết bị và thu thập nhật ký kết quả từ thiết bị đó qua TCP/IP. Trình thực thi giao tiếp với dịch vụ thực thi (execserver) trên thiết bị mục tiêu. Cả hai cùng cung cấp các chức năng như khôi phục sau sự cố quy trình kiểm thử. Các ví dụ sau đây minh hoạ cách sử dụng Trình thực thi kiểm thử dòng lệnh (sử dụng --help để biết thêm thông tin chi tiết):

Ví dụ 1: Chạy kiểm thử chức năng GLES2 trên thiết bị Android

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"

Ví dụ 2: Tiếp tục chạy một phần quy trình kiểm thử OpenGL ES 2 cục bộ

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

Xuất và so sánh tệp CSV nhật ký kiểm thử

deqp có một công cụ để chuyển đổi nhật ký kiểm thử (tệp .qpa) thành tệp CSV. Đầu ra CSV chứa danh sách các trường hợp kiểm thử và kết quả của các trường hợp đó. Công cụ này cũng có thể so sánh hai hoặc nhiều kết quả hàng loạt và chỉ liệt kê những trường hợp kiểm thử có mã trạng thái khác nhau trong kết quả hàng loạt đầu vào. Phép so sánh này cũng sẽ in số lượng trường hợp trùng khớp.

Đầu ra ở định dạng CSV rất hữu ích cho việc xử lý thêm bằng các tiện ích dòng lệnh tiêu chuẩn hoặc bằng trình chỉnh sửa bảng tính. Bạn có thể chọn một định dạng văn bản thuần tuý, dễ đọc khác bằng cách dùng đối số dòng lệnh sau: --format=text

Ví dụ 1: Xuất nhật ký kiểm thử ở định dạng CSV

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

Ví dụ 2: Liệt kê sự khác biệt về kết quả kiểm thử giữa hai nhật ký kiểm thử

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Lưu ý: Đối số --value=code xuất mã kết quả kiểm thử, chẳng hạn như "Đạt" hoặc "Không đạt". Đối số --value=details chọn phần giải thích thêm về kết quả hoặc giá trị bằng số do một thử nghiệm về hiệu suất, khả năng hoặc độ chính xác tạo ra.

Xuất tệp XML nhật ký kiểm thử

Bạn có thể chuyển đổi tệp nhật ký kiểm thử thành tài liệu XML hợp lệ bằng tiện ích testlog-to-xml. Có 2 chế độ đầu ra được hỗ trợ:

Chế độ tài liệu riêng biệt, trong đó mỗi trường hợp kiểm thử và tài liệu tóm tắt caselist.xml được ghi vào một thư mục đích
Chế độ một tệp, trong đó tất cả kết quả trong tệp .qpa đều được ghi vào một tài liệu XML duy nhất.

Bạn có thể xem các tệp nhật ký kiểm thử đã xuất trong trình duyệt bằng cách sử dụng một biểu định kiểu XML. Các tài liệu biểu định kiểu mẫu (testlog.xsl và testlog.css) được cung cấp trong thư mục doc/testlog-stylesheet. Để kết xuất các tệp nhật ký trong trình duyệt, hãy sao chép hai tệp biểu định kiểu vào cùng một thư mục nơi có các tài liệu XML đã xuất.

Nếu bạn đang sử dụng Google Chrome, thì các tệp phải được truy cập qua HTTP vì Chrome giới hạn quyền truy cập vào tệp cục bộ vì lý do bảo mật. Quy trình cài đặt Python tiêu chuẩn bao gồm một máy chủ HTTP cơ bản có thể khởi chạy để phân phát thư mục hiện tại bằng lệnh python –m SimpleHTTPServer 8000. Sau khi chạy máy chủ, bạn chỉ cần trỏ trình duyệt Chrome đến http://localhost:8000 để xem nhật ký kiểm thử.

Chuyển đổi sang nhật ký kiểm thử JUnit

Nhiều hệ thống tự động hoá kiểm thử có thể tạo báo cáo kết quả chạy kiểm thử từ đầu ra JUnit. Bạn có thể chuyển đổi các tệp nhật ký kiểm thử deqp sang định dạng đầu ra JUnit bằng công cụ testlog-to-junit.

Công cụ này hiện chỉ hỗ trợ dịch kết quả của trường hợp kiểm thử. Vì JUnit chỉ hỗ trợ kết quả "đạt" và "không đạt", nên kết quả đạt của deqp được liên kết với "JUnit đạt" và các kết quả khác được coi là không đạt. Mã kết quả deqp ban đầu có trong đầu ra JUnit. Các dữ liệu khác, chẳng hạn như thông báo nhật ký và hình ảnh kết quả, sẽ không được giữ lại trong quá trình chuyển đổi.

Sử dụng các nhóm kiểm thử đặc biệt

Một số nhóm kiểm thử có thể cần hoặc hỗ trợ các lựa chọn đặc biệt trên dòng lệnh, hoặc cần được chăm sóc đặc biệt khi sử dụng trên một số hệ thống nhất định.

Kiểm thử tình trạng áp lực phân bổ bộ nhớ

Các bài kiểm thử tình trạng áp lực phân bổ bộ nhớ sẽ thực hiện các điều kiện hết bộ nhớ bằng cách phân bổ lặp đi lặp lại một số tài nguyên nhất định cho đến khi trình điều khiển báo cáo lỗi hết bộ nhớ.

Trên một số nền tảng, chẳng hạn như Android và hầu hết các biến thể Linux, có thể xảy ra trường hợp sau: Hệ điều hành có thể huỷ quy trình kiểm thử thay vì cho phép trình điều khiển xử lý hoặc cung cấp lỗi hết bộ nhớ. Trên các nền tảng như vậy, theo mặc định, các kiểm thử được thiết kế để gây ra lỗi hết bộ nhớ sẽ bị vô hiệu hoá và phải được bật bằng đối số dòng lệnh --deqp-test-oom=enable. Bạn nên chạy các kiểm thử như vậy theo cách thủ công để kiểm tra xem hệ thống có hoạt động đúng cách khi chịu áp lực về tài nguyên hay không. Tuy nhiên, trong trường hợp như vậy, sự cố quy trình kiểm thử sẽ được coi là đã vượt qua.

Nhóm thử nghiệm

dEQP-GLES2.stress.memory.*
dEQP-GLES3.stress.memory.*

Kiểm thử hiệu suất kết xuất trong thời gian dài

Các bài kiểm tra hiệu suất kết xuất được thiết kế để phát hiện các vấn đề về độ ổn định trong quá trình kết xuất liên tục. Theo mặc định, các kiểm thử sẽ chỉ thực thi một vài lần lặp lại, nhưng bạn có thể định cấu hình để chạy vô thời hạn bằng cách cung cấp đối số dòng lệnh --deqp-test-iteration-count=-1. Bạn nên tắt trình giám sát kiểm thử (--deqp-watchdog=disable) khi chạy các kiểm thử này trong một khoảng thời gian dài.

Nhóm thử nghiệm

dEQP-GLES2.stress.long.*
dEQP-GLES3.stress.long.*

Kiểm thử Chương trình chất lượng drawElements Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Bố cục nguồn

Các thành phần nguồn mở

Xây dựng chương trình kiểm thử

Hệ thống xây dựng CMake

Tạo tệp bản dựng mục tiêu

Bản dựng Win32

Tạo bối cảnh kết xuất

Hỗ trợ WGL

Hỗ trợ EGL

Bản dựng Android

Bản dựng Linux

Biên dịch chéo

Liên kết thời gian chạy của các thư viện GLES và EGL

Chuyển khung kiểm thử

Thư viện tính di động cơ bản

Cổng nền tảng khung thử nghiệm

Dịch vụ thực thi kiểm thử

Chạy kiểm thử

Môi trường Linux và Windows

Đối số dòng lệnh

Đối số dành riêng cho GLES2 và GLES3

Định dạng danh sách trường hợp kiểm thử

Android

Thực thi các kiểm thử trên Android mà không cần Android CTS

Gỡ lỗi trên Android

Tự động hoá các kiểm thử

Công cụ thực thi kiểm thử dòng lệnh

Trình thực thi kiểm thử dòng lệnh

Ví dụ 1: Chạy kiểm thử chức năng GLES2 trên thiết bị Android

Ví dụ 2: Tiếp tục chạy một phần quy trình kiểm thử OpenGL ES 2 cục bộ

Xuất và so sánh tệp CSV nhật ký kiểm thử

Ví dụ 1: Xuất nhật ký kiểm thử ở định dạng CSV

Ví dụ 2: Liệt kê sự khác biệt về kết quả kiểm thử giữa hai nhật ký kiểm thử

Xuất tệp XML nhật ký kiểm thử

Chuyển đổi sang nhật ký kiểm thử JUnit

Sử dụng các nhóm kiểm thử đặc biệt

Kiểm thử tình trạng áp lực phân bổ bộ nhớ

Nhóm thử nghiệm

Kiểm thử hiệu suất kết xuất trong thời gian dài

Nhóm thử nghiệm

Kiểm thử Chương trình chất lượng drawElements