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

AOSP bao gồm bộ kiểm thử GPU DrawElements (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ộ thử nghiệm deqp cho một môi trường mới.

Để làm việc với mã đã gửi mới 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 của 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à thư viện hỗ trợ là được trình bày trong bảng bên dưới (danh sách không đầy đủ nhưng nêu bật quan trọng nhất).

Thư mục Mô tả
android

Tập lệnh bản dựng và nguồn của người kiểm thử Android
data

Kiểm thử tệp dữ liệu
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

khung mô-đun kiểm thử deqp và các tiện ích
framework/delibs

Khả năng di chuyển cơ sở và thư viện bản dựng
framework/platform

Cổng của nền tảng
framework/qphelper

Thư viện tích hợp chương trình kiểm thử (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

Công cụ và tiện ích của bộ thực thi kiểm thử phía máy chủ
external

Tạo thư mục mã giả lập cho libs libpng và zlib bên ngoài

Thành phần nguồn mở

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

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

Khung thử nghiệm đã được thiết kế có lưu ý đến tính di động. Chỉ yêu cầu bắt buộc là hỗ trợ C++ đầy đủ và thư viện hệ thống 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, là công cụ ưu tiên cho biên dịch các chương trình kiểm thử.

CMake là một hệ thống xây 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 cây ngoài nguồn, tức là bạn nên luôn tạo tệp makefile hoặc dự án trong một thư mục bản dựng riêng bên ngoài cây nguồn. CMake không có bất kỳ hành vi "không làm sạch" nào mục tiêu, vì vậy việc xoá mọi tệp do CMake tạo phải được thực hiện theo cách thủ công.

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

Tùy 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 nhắm mục tiêu cụ thể bản dựng từ đó.
CMAKE_TOOLCHAIN_FILE

Đường dẫn đến tệp chuỗi công cụ cho CMake. 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à: "Gỡ lỗi" và "Bản phát hành"

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 xây dựng nhắm đến. Xem tài liệu CMake để biết thông tin chi tiết.

Tạo tệp bản dựng đích

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 đích. 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 bắt buộc phải có đường dẫn bao gồm bổ sung. Tên tệp mục tiêu tuân theo targets/NAME/NAME.cmake và mục tiêu đượ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 deqp cơ sở, chứ không phải thư mục Thư mục targets/NAME. Các biến tiêu chuẩn sau đây có thể được thiết lập bằng tệp bản dựng mục tiêu.

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

Liệu 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 bạn sẽ dùng tính năng tải động)
DEQP_SUPPORT_GLES3

Liệu 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 bạn sẽ dùng tính năng tải động)
DEQP_SUPPORT_VG

Liệu OpenVG có được hỗ trợ 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 bạn sử dụng tính năng tải động)
DEQP_SUPPORT_EGL

Liệu EGL có được hỗ trợ 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 bạn dùng tính năng tải động)
DEQP_PLATFORM_LIBRARIES

Bạn cần có thư viện bổ sung dành riêng cho nền tảng để liên kết
DEQP_PLATFORM_COPY_LIBRARIES

Danh sách các thư viện được sao chép vào mỗi 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 ở chế độ mặc định đường dẫn tìm kiếm.
TCUTIL_PLATFORM_SRCS

Danh sách nguồn cổng trên nền tảng. Các nguồn mặc định được xác định dựa trên và hệ điều hành.

Lưu ý: Đường dẫn tương ứng với: framework/platform

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

Bản dựng Win32

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

Bạn có thể tạo 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" dưới dạng bản dựng trình tạo:

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

Bạn cũng có thể tạo tệp makefile NMake bằng tuỳ chọn -G "NMake Makefiles" làm 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ả tệp nhị phân Win32 đều hỗ trợ tạo ngữ cảnh GL bằng WGL vì tệp này chỉ yêu cầu thư viện chuẩn. Bạn có thể chọn ngữ cảnh WGL bằng --deqp-gl-context-type=wgl đối số dòng lệnh. Ở chế độ WGL, deqp sử dụng WGL_EXT_create_context_es_profile để tạo ngữ cảnh OpenGL ES. Tính năng này đã được thử nghiệm để 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ợ các yêu cầu tiện ích.

Hỗ trợ EGL

Deqp được xây dựng với tính năng tải động cho EGL trên Windows nếu DEQP_ HỖ_EGL ĐANG BẬT. Đây là tuỳ chọn mặc định trong hầu hết các mục tiêu. Sau đó, nếu máy chủ lưu trữ có thư viện EGL sẵn có, bạn có thể chạy thử nghiệm với chúng bằng dòng lệnh thông số: --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à Mã kiểm thử ứng dụng kiểm thử biên dịch bằng các công cụ xây dựng Android tiêu chuẩn.

Để biên dịch chương trình kiểm thử deqp cho Android bằng bản dựng được cung cấp tập lệnh, 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 cho Android với API 13, Bộ công cụ SDK, Bộ công cụ nền tảng SDK và SDK Đã cài đặt gói công cụ xây dựng
  • Apache Ant 1.9.4 (bắt buộc phải có trong bản dựng mã Java)
  • CMake 2.8.12 trở lên
  • Python 2.6 trở lên trong chuỗi 2.x; Python 3.x không được hỗ trợ
  • Đối với Windows: NMake hoặc JOM trong PATH
    • JOM cho phép tạo bản dựng nhanh hơn
  • Không bắt buộc: Tên thương hiệu Ninja cũng được hỗ trợ trên Linux

Tệp nhị phân Kiến và SDK được đặt dựa trên biến môi trường PATH với một số mặc định ghi đè nhất định. Logic 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 qua ANDROID_NDK_PATH biến môi trường.

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ử đều 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 trình thực thi dòng lệnh được sử dụng, ExecService được khởi chạy với tập lệnh launch.py trên thiết bị thông qua ADB. Bạn có thể thực thi các tập lệnh từ bất kỳ thư mục nào.

Bản dựng Linux

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

Tạo mục tiêu Mô tả
default

Mục tiêu mặc định sử dụng 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 bối cảnh OpenGL (ES).
x11_egl_glx

Hỗ trợ cả GLX và EGL với X11.

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

Các đối số dòng lệnh -DCMAKE_C_FLAGS và -DCMAKE_CXX_FLAGS có thể là dùng để truyền đối số bổ sung tới trình biên dịch. Ví dụ: bản dựng 32 bit hoặc 64 bit có thể được thực hiện bằng cách đặt -DCMAKE_C(XX)_FLAGS="-m32" hoặc "-m64" tương ứng. Nếu không đã chỉ định, thì kiến 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, sẽ được sử dụng.

Bạn có thể sử dụng các đối số -DCMAKE_LIBRARY_PATH và -DCMAKE_INCLUDE_PATH để CMake cung cấp thêm thư viện cho CMake hoặc thêm các đường dẫn tìm kiếm.

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

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ể thực hiện biên dịch chéo bằng cách sử dụng tệp chuỗi công cụ CMake. Chuỗi công cụ tệp chỉ định trình biên dịch để 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 là có trong gói phát hành ở thư mục framework/delibs/cmake.

Ngoài các biến CMake tiêu chuẩn, các biến dành riêng cho deqp sau đây có thể được thiết lập theo tệp chuỗi công cụ. CMake thường có thể phát hiện DE_OS, DE_COMPILER và DE_PTR_SIZE một cách chính xác, nhưng DE_CPU phải được đặt 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. Sau đây là các giá trị được hỗ trợ: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE

sizeof(void*) trên nền tảng. Các 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ụ: đoạn mã sau đây sẽ tạo tệp makefile cho một bản dựng bằ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 thư viện GLES và EGL

Deqp không cần điểm truy cập của API đang được kiểm thử trong quá trình liên kết. Chiến lược phát hành đĩa đơn mã kiểm thử luôn truy cập API thông qua con trỏ hàm. Điểm truy cập có thể sau đó sẽ được tải động trong thời gian chạy hoặc cổng nền tảng có thể cung cấp các quảng cáo đó tại thời gian liên kết.

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

Chuyển đổi khung kiểm thử

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

Bảng dưới đây liệt kê những vị trí có thể có thay đổi về quy trình chuyển. Mọi thứ vượt quá chúng có thể là kỳ lạ.

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. Thư viện hiện tại dựa trên dethread và thư viện C chuẩn.
framework/platform

Cổng nền tảng mới và mã giả lập ứng dụng có thể được triển khai như mô tả trong Kiểm thử cổng nền tảng khung.

Thư viện cơ sở về khả năng di chuyển

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

Kiểm thử cổng nền tảng khung

Cổng nền tảng khung kiểm thử deqp yêu cầu 2 thành phần: Một ứng dụng điểm truy cập và 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 một đố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 đích hỗ trợ điểm truy cập main() tiêu chuẩn, bạn có thể dùng tcuMain.cpp làm phương thức 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 của 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 của ứng dụng

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

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 để triển khai các cổng nền tảng có trong chuyển đổi tiêu đề lớp.

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, phải có sẵn dịch vụ thực thi kiểm thử trên mục tiêu. Một C++ di động Việc triển khai dịch vụ được cung cấp trong thư mục execserver. Độc lập tệp nhị phân được tạo như một phần của mô-đun kiểm thử deqp dành cho các mục tiêu 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 hai dòng lệnh thông số:

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

Chạy kiểm thử

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

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.

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
data/gles2 <dst>/gles2
Mô-đun GLES3 build/modules/gles3/deqp-gles3 <dst>/deqp-gles3
data/gles3 <dst>/gles3
Mô-đun GLES3.1 build/modules/gles31/deqp-gles31 <dst>/deqp-gles31
data/gles31 <dst>/gles31
Mô-đun GLES3.2 build/modules/gles32/deqp-gles32 <dst>/deqp-gles32
data/gles32 <dst>/gles32

Bạn có thể triển khai dịch vụ thực thi và tệp nhị phân kiểm thử ở bất cứ đâu trong đích hệ thống tệp; tuy nhiên, tệp nhị phân kiểm thử mong muốn tìm thư mục dữ liệu trong thư mục đang làm việc. 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 Thử nghiệm dịch vụ thực thi.

Đối số dòng lệnh

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

Đối số Mô tả
--deqp-case=<casename> Chạy các trường hợp khớp với một mẫu cho trước. 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. Phiên chạy thử nghiệm 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 của stdin hoặc từ một đối số nhất định. Phiên chạy thử nghiệm sẽ đặt đối số theo yêu cầu thực thi đã nhận được. 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 cho các thử nghiệm hỗ trợ số lượng biến lặp lại.
--deqp-base-seed=<seed> Số ngẫu nhiên cơ sở cho các trường hợp kiểm thử sử dụng tính năng 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 ngữ cảnh có sẵn phụ thuộc vào nền tảng. Bật nền tảng hỗ trợ EGL, thì bạn có thể sử dụng giá trị egl để chọn ngữ cảnh EGL.
--deqp-gl-config-id=<id> Chạy thử nghiệm cho mã cấu hình GL được cung cấp. Nội dung diễn giải là 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 cấu hình GL được đặt tên. Nội dung diễn giải là 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ụ: một của rgb888s8 sẽ chọn cấu hình đầu tiên mà trong đó bộ đệm màu là RGB888 và bộ đệm stencil có 8 bit.
--deqp-gl-context-flags=<flags> Tạo một ngữ cảnh. Hãy chỉ định robust hoặc debug.
--deqp-surface-width=<width>
--deqp-surface-height=<height>		 Cố gắng tạo một bề mặt với một 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 kiểm thử chính. Có thể thực hiện là window, pixmap, pbuffer, và fbo.
--deqp-screen-rotation=<rotation> Hướng màn hình tăng dần 90 độ đối với các nền tảng hỗ trợ cuộc trò chuyện.

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

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

{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 dịch vụ thực thi kiểm thử, tệp nhị phân kiểm thử và tệp dữ liệu. Hoạt động thử nghiệm là NativeActivity sử dụng EGL (yêu cầu Android 3.2 trở lên).

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

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

Để khởi chạy dịch vụ thực thi thử nghiệm và để thiết lập chuyển tiếp cổng, hãy sử dụng 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 gỡ lỗi in 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 thử nghiệm 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 trong Android nhắm đến android.app.NativeActivity. Các hoạt động có thể là được tìm thấ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 với khoá "cmdLine" trong Ý định.

Nhật ký kiểm thử được ghi vào /sdcard/dEQP-log.qpa. Nếu thử nghiệm chạy không khởi động bình thường, sẽ có thông tin gỡ lỗi bổ sung trong thiết bị nhật ký của bạn.

Bạn có thể khởi chạy một hoạt động qua dòng lệnh bằng cách sử dụng am tiện ích. 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 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 hai 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ị, để khởi 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ử cần thực thi và các các tham số bắt buộc. Tập lệnh thêm điểm ngắt mặc định ở đầ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ư đặt điểm ngắt để gỡ lỗi, kết nối gdbserver tham số và đường dẫn đến tệp nhị phân bổ sung để gỡ lỗi (sử dụng debug.py --help cho tất cả đối số và nội dung giải thích). Tập lệnh cũng sao chép một số các thư viện mặc định từ thiết bị mục tiêu để tải danh sách biểu tượng.

Thực hiện duyệt qua mã trình điều khiển (chẳng hạn như khi GDB cần biết vị trí tệp nhị phân có thông tin gỡ lỗi đầy đủ), thêm thư viện thông qua Tham số dòng lệnh debug.py. Tập lệnh này sẽ tạo 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 đường dẫn bổ sung đến tệp nhị phân, v.v. nhưng cung cấp đúng lệnh tham số dòng 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 đến biến PATH.

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

Tự động hoá 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 phụ thuộc vào mục tiêu và cơ sở hạ tầng kiểm thử hiện có môi trường.

Đầ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. Có thể phân tích cú pháp kết quả kiểm tra đầy đủ từ nhật ký kiểm tra. Kết quả xuất ra trên bảng điều khiển là thông tin gỡ lỗi và có thể chỉ có trên một số nền tảng.

Bạn có thể gọi trực tiếp tệp nhị phân kiểm thử từ hệ thống tự động hoá kiểm thử. Thử nghiệm tệp nhị phân có thể được khởi chạy cho một trường hợp cụ thể, cho một tập hợp kiểm thử hoặc cho tất cả thử nghiệm 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ố API hoặc sự cố), lần 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 tệp nhị phân kiểm thử cho từng trường hợp riêng lẻ hoặc chương trình kiểm thử nhỏ các nhóm riêng biệt, để có một phần các kết quả ngay cả trong sự kiện 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ể được sử dụng trong kết hợp với dịch vụ thực thi để có được một sự tích hợp mạnh mẽ hơn. Bộ thực thi phát hiện việc chấm dứt quá trình kiểm thử và sẽ tiếp tục chạy kiểm thử vào trường hợp có sẵn tiếp theo. Một tệp nhật ký được tạo từ toàn bộ quá trình kiểm thử phiên hoạt động. Chế độ thiết lập này phù hợp cho các hệ thống thử nghiệm gọn nhẹ không cung cấp cơ sở phục hồi 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 công cụ thực thi kiểm thử từ xa, một công cụ kiểm thử trình tạo so sánh nhật ký cho phân tích hồi quy, công cụ chuyển đổi nhật ký kiểm tra sang CSV, bộ chuyển đổi test-log sang XML và bộ chuyển đổi testlog-to-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 là được tích hợp vào thư mục <builddir>/executor.

Bộ 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 để khởi chạy lần chạy kiểm thử trên một thiết bị rồi thu thập nhật ký kết quả từ thiết bị đó qua TCP/IP. Người 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ác API này cùng nhau cung cấp chức năng, chẳng hạn như khôi phục sau sự cố trong quá trình kiểm thử. Các ví dụ sau đây minh hoạ cách sử dụng Test Executor (Trình thực thi kiểm thử) dòng lệnh (sử dụng --help để biết thêm 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 cục bộ một phần kiểm thử 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

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

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

Dữ liệu đầu ra ở định dạng CSV rất hữu ích cho việc xử lý thêm theo chuẩn tiện ích dòng lệnh hoặc trình chỉnh sửa bảng tính. Một chế độ cài đặt bổ sung mà con người có thể đọc được bạn có thể chọn định dạng văn bản thuần tuý bằng cách sử dụng đối số dòng lệnh sau: --format=text

Ví dụ 1: Xuất nhật ký kiểm tra ở đị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ê những điểm khác biệt về kết quả kiểm thử giữa 2 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 sẽ xuất ra kết quả kiểm thử mã kết quả, chẳng hạn như "Đạt" hoặc "Không đạt". Đối số --value=details chọn phần giải thích kết quả hoặc giá trị số được tạo ra từ bài kiểm tra hiệu suất, chức năng hoặc độ chính xác.

Kiểm thử tính năng xuất nhật ký XML

Có thể chuyển đổi tệp nhật ký kiểm thử thành các tài liệu XML hợp lệ bằng cách sử dụng testlog-to-xml tiện ích. 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à phần tóm tắt caselist.xml tài liệu được ghi vào một thư mục đích
  • Chế độ tệp đơn, trong đó tất cả kết quả trong tệp .qpa được ghi vào 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 biểu định kiểu XML. Đã cung cấp tài liệu biểu định kiểu mẫu (testlog.xsl và testlog.css) trong thư mục doc/testlog-stylesheet. Để hiển thị tệp nhật ký trong trình duyệt, sao chép hai tệp biểu định kiểu vào cùng một thư mục chứa tài liệu XML đã xuất.

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

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

Nhiều hệ thống tự động hoá thử nghiệm có thể tạo báo cáo kết quả chạy thử nghiệm từ JUnit đầu ra. 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ả trường hợp kiểm thử. Như JUnit chỉ hỗ trợ "pass" và "không thành công" kết quả, một kết quả đi qua của deqp được ánh xạ thành "JUnit Pass" và các kết quả khác đều bị coi là không thành công. Phụ thuộc gốc có sẵn mã kết quả trong đầu ra JUnit. Dữ liệu khác, chẳng hạn như thông điệp nhật ký và hình ảnh kết quả không được giữ nguyên trong lượt chuyển đổi.

Sử dụng nhóm thử nghiệm đặc biệt

Một số nhóm kiểm thử có thể cần hoặc hỗ trợ các tuỳ chọn dòng lệnh đặc biệt, hoặc yêu cầu đặc biệt cần thiế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 của quá trình phân bổ bộ nhớ

Kiểm tra tình trạng áp lực của quá trình phân bổ bộ nhớ khi tập thể dục tình trạng hết bộ nhớ bằng cách lặp đi lặp lại phân bổ 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, sau đây có thể xảy ra: Hệ điều hành có thể dừng quá 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ớ. Theo đó nền tảng, các bài kiểm thử được thiết kế để gây ra lỗi hết bộ nhớ bị tắt theo mặc định và phải được bật bằng cách sử dụng đối số dòng lệnh --deqp-test-oom=enable. Bạn nên chạy các bài kiểm thử đó theo cách thủ công để kiểm tra xem hệ thống có hoạt động chính xác dưới áp lực về tài nguyên hay không. Tuy nhiên, trong những trường hợp đó trong một tình huống, sự cố trong quá trình kiểm thử sẽ được hiểu là đạt.

Thử nghiệm nhóm

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

Kiểm thử căng thẳng khi kết xuất lâu dài

Việc kết xuất kiểm thử ứng suất được thiết kế để phát hiện các vấn đề về độ ổn định trong môi trường duy trì tải kết xuất. Theo mặc định, các bài 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úng để chạy vô thời hạn bằng cách cung cấp --deqp-test-iteration-count=-1 đối số dòng lệnh. Bạn nên tắt bộ đếm giờ kiểm thử (--deqp-watchdog=disable) khi chạy các bài kiểm thử này trong một thời gian dài.

Thử nghiệm nhóm

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