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.

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 cho một môi trường mới.

Để xử lý mã mới nhất đã gửi, 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à 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ành phần nguồn mở

deqp sử dụng libpng và zlib, bạn có thể tìm nạp bằ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 kiểm thử được thiết kế để dễ dàng di chuyển. Yêu cầu bắt buộc duy nhất là hỗ trợ đầy đủ C++ 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, đâ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 xây dựng nguồn mở hỗ trợ nhiều nền tảng và chuỗi công cụ. CMake tạo tệp dự án IDE hoặc tệp makefile gốc 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 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ó bất kỳ 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 tuỳ 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ố tuỳ chọn thường dùng cho deqp.

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 cần thiết. Tên tệp mục tiêu tuân theo định dạng targets/NAME/NAME.cmake và mục tiêu được chọn bằng tham số bản dựng DEQP_TARGET.

Đường dẫn tệp trong tệp đích tương ứng với thư mục deqp cơ sở, 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 mục tiêu.

Tệp bản dựng mục tiêu có thể thêm các đường dẫn liên kết hoặc bao gồm 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 hệ thống xây dựng 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 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 makefile NMake bằng tuỳ chọn -G "NMake Makefiles" cũng như loại bản dựng (-DCMAKE_BUILD_TYPE="Debug" hoặc "Release").

Tạo ngữ 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ợ việc tạo ngữ cảnh GL bằng WGL vì chỉ yêu cầu 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. Tính năng này đã được kiểm thử để hoạt động với các 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à giá trị mặc định trong hầu hết các mục tiêu. Sau đó, nếu máy chủ có thư viện EGL, bạn có thể chạy kiểm thử bằng các thư viện đó với 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ụ xây dựng 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 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 Android độc lập đã cài đặt các gói API 13, Công cụ SDK, Công cụ nền tảng SDK và Công cụ bản dựng SDK
• Apache Ant 1.9.4 (bản dựng mã Java bắt buộc phải có)
• CMake 2.8.12 trở lên
• Python 2.6 trở lên trong dòng 2.x; không hỗ trợ Python 3.x
• Đố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

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 sử 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 tệp nhị phân kiểm thử và tiện ích dòng lệnh 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.

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ó tệp này, 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ể sử dụng đối số dòng lệnh -DCMAKE_C_FLAGS và -DCMAKE_CXX_FLAGS để truyền các đối số bổ sung đến 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 -DCMAKE_C(XX)_FLAGS="-m32" hoặc "-m64" tương ứng. Nếu không được chỉ định, 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, sẽ được sử dụng.

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

Sau đây là ví dụ về 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 ở 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 do tệp chuỗi công cụ thiết lập.

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ụ: nội dung sau đây sẽ tạo tệp makefile cho một bản dựng bằng cách sử dụng trình biên dịch đa nền tảng 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 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 độ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 đó tại thời điểm liên kết.

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

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ê các vị trí có thể xảy ra thay đổi khi chuyển đổi. Mọi thứ ngoài những điều này đều có thể là ngoại lai.

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

Các thư viện khả năng di chuyển cơ sở đã 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 các hệ điều hành đó, thì rất có thể bạn không cần phải chạm vào thư viện khả năng di chuyển cơ sở.

Cổng nền tảng khung kiểm thử

Cổng nền tảng khung kiểm thử deqp yêu cầu hai thành phần: Điểm truy cập ứng dụng 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 đố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() chuẩn, thì bạn có thể sử 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.

Lớp cơ sở cho tất 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 đây để biết thông tin tổng quan về những gì cần triển khai để chạy các chương trình kiểm thử.

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

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, bạn phải có dịch vụ thực thi kiểm thử trên mục tiêu. Thư mục execserver cung cấp một phương thức triển khai dịch vụ C++ di động. Tệp nhị phân độc lập được tạo trong bản dựng mô-đun kiểm thử deqp 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 tham số dòng lệnh:

• --port=<port> sẽ đặt cổng TCP mà máy chủ nghe. Giá trị mặc định là 50016.
• --single sẽ chấm dứt quá trình máy chủ khi ứng dụng khách ngắt kết nối. Theo mặc định, quy trình máy chủ sẽ vẫn hoạt động để phân phát 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 về cách chạy 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 mục tiêu.

Bạn có thể triển khai dịch vụ thực thi và kiểm thử tệp nhị phân ở bất kỳ đâu trong hệ thống tệp mục tiêu; tuy nhiên, tệp nhị phân kiểm thử dự kiến sẽ tìm thấy thư mục dữ liệu trong thư mục đang hoạt động. 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 khởi động dịch vụ, hãy xem phần Kiểm thử 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 ảnh hưởng đến việc thực thi tất cả chương trình kiểm thử.

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

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

Danh sách trường hợp kiểm thử có thể được cung cấp theo hai định dạng. Lựa chọn đầu tiên là liệt kê tên đầy đủ của từng chương trình kiểm thử trên một dòng riêng biệt trong tệp ASCII chuẩn. Khi các tập hợp kiểm thử phát triển, các tiền tố lặp lại có thể gây phiền toái. Để 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ư bên dưới.

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

Ví dụ:

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

Dịch thành hai 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ử, 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 tệp APK trong gói Android CTS; 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 tính năng chuyển tiếp cổng, hãy sử dụng nội dung 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 các lệnh sau trước khi bắt đầu kiểm thử:

adb –d shell setprop log.tag.dEQP DEBUG

Thực thi 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 Android nhắm đến android.app.NativeActivity. Bạn có thể tìm thấy các hoạt động trong gói com.drawelements.deqp. Bạn phải cung cấp dòng lệnh 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 kiểm 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 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 sử 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 chương trình 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 cài đặt bản gỡ lỗi trên thiết bị, để chạy các chương trình kiểm thử trong GDB chạy trên máy chủ, 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 tham số bắt buộc khác. Tập lệnh này thêm một đ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, 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ả đố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 để nhận 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 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 sẽ 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 thêm đường dẫn đến tệp nhị phân, v.v., nhưng chỉ cần cung cấp đúng tham số dòng lệnh 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 ý: Tính 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, 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 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 kết quả kiểm thử đầy đủ từ nhật ký kiểm thử. Kết quả đầu ra của bảng điều khiển chỉ là thông tin gỡ lỗi và có thể không có trên một số nền tảng.

Bạn có thể gọi tệp nhị phân kiểm thử trực tiếp từ hệ thống tự động 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 chương trình 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 tốt nhất là gọi các tệp nhị phân kiểm thử cho từng trường hợp hoặc nhóm kiểm thử nhỏ riêng biệt để có kết quả một phần ngay cả trong trường hợp 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 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 kiểm thử bị chấm dứt và sẽ tiếp tục thực thi kiểm thử trên trường hợp tiếp theo có sẵn. Một tệp nhật ký duy nhất được tạo từ phiên kiểm thử đầy đủ. Cấu hình này lý tưởng cho các hệ thống kiểm thử gọn nhẹ không cung cấp cơ sở khôi phục 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ích hợp vào 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 lần chạy kiểm thử trên một 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ác lớp này cùng nhau cung cấp chức năng 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 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 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 nhật ký kiểm thử CSV

deqp có một công cụ để chuyển đổi nhật ký kiểm thử (tệp .qpa) thành tệp CSV. Kết quả 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 kiểm thử đó. 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ê các 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. Quá trình so sánh cũng sẽ in số lượng trường hợp trùng khớp.

Kết quả ở định dạng CSV rất hữu ích để 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 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 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 sẽ 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 nội dung giải thích thêm về kết quả hoặc giá trị số do kiểm thử hiệu suất, khả năng hoặc độ chính xác tạo ra.

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

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ó hai 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ế độ tệp đơn, trong đó tất cả kết quả trong tệp .qpa đượ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 trang kiểu XML. Tài liệu mẫu về bảng định kiểu (testlog.xsl và testlog.css) được cung cấp trong thư mục doc/testlog-stylesheet. Để hiển thị các tệp nhật ký trong trình duyệt, hãy sao chép hai tệp trang tính kiểu vào cùng một thư mục chứa các tài liệu XML đã xuất.

Nếu bạn đang sử dụng Google Chrome, bạn phải truy cập vào các tệp qua HTTP vì Chrome hạn chế quyền truy cập vào tệp cục bộ vì lý do bảo mật. Quá trình 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 hiện tại bằng lệnh python –m SimpleHTTPServer 8000. Sau khi khởi 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 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 "đạt JUnit" và các kết quả khác được coi là không đạt. Mã kết quả deqp gốc có trong đầu ra JUnit. Các dữ liệu khác, chẳng hạn như thông điệp nhật ký và hình ảnh kết quả, sẽ không được giữ lại trong lượt chuyển đổi.

Sử dụng 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 tuỳ chọn dòng lệnh đặc biệt hoặc yêu cầu phải cẩn thận đặ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ớ

Kiểm thử tình trạng áp lực phân bổ bộ nhớ thực hiện các điều kiện hết bộ nhớ bằng cách liên tục 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 nhất định, chẳng hạn như Android và hầu hết các biến thể Linux, điều sau có thể xảy ra: Hệ điều hành có thể chấm dứt quy trình kiểm thử thay vì cho phép trình điều khiển xử lý hoặc báo lỗi hết bộ nhớ. Trên các nền tảng như vậy, các chương trình kiểm thử được thiết kế để gây ra lỗi hết bộ nhớ sẽ bị tắt theo mặc định 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 chương trình kiểm thử như vậy 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 tài nguyên hay không. Tuy nhiên, trong trường hợp như vậy, sự cố trong quá trình kiểm thử sẽ được hiểu là vượt qua.

Nhóm thử nghiệm

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

Kiểm thử cường độ kết xuất trong thời gian dài

Kiểm thử tải trọng kết xuất được thiết kế để phát hiện các vấn đề về độ ổn định khi tải kết xuất liên tục. Theo mặc định, các chương trình 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 các chương trình kiểm thử này để 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.*