Kiểm tra chương trình chất lượng drawElements

AOSP bao gồm bộ thử nghiệm GPU Chương trình chất lượng 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 sang môi trường mới.

Để làm việc với mã được gửi mới nhất, hãy sử dụng nhánh deqp-dev . Đối với mã phù hợp với bản phát hành Android CTS 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 tra deqp và các thư viện hỗ trợ được hiển thị trong bảng bên dưới (danh sách không đầy đủ nhưng nêu bật các thư mục quan trọng nhất).

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 thử nghiệm

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

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

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

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 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 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 việc xóa mọi tệp do CMake tạo ra phải được thực hiện thủ công.

Các tùy chọn cấu hình được cung cấp cho CMake bằng cú pháp -D OPTION_NAME = VALUE . Một số tùy chọn thường được sử dụng cho deqp được liệt kê bên dưới.

Tạo một tập tin xây 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 xây 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 bổ sung nào được yêu cầu. 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 có liên quan đến thư mục deqp cơ sở, không phải thư mục targets/ NAME . Các biến tiêu chuẩn sau có thể được đặt bởi tệp xây dựng mục tiêu.

Tệp xây 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 để xây dựng 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 thử nghiệm với Visual Studio 2013.

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

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

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 tạo tệp NMake bằng tùy chọn -G "NMake Makefiles" cũng như loại bản dựng ( -DCMAKE_BUILD_TYPE="Debug" hoặc "Release" ).

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

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

Hỗ trợ WGL

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

Hỗ trợ EGL

Deqp được xây dựng bằng tính năng tải động cho EGL trên Windows nếu DEQP_SUPPORT_EGL được BẬT. Đây là mặc định trong hầu hết các mục tiêu. Sau đó, nếu máy chủ có sẵn thư viện EGL, có thể chạy thử nghiệm với chúng 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 tra gốc. Các phần Java, tức là Máy chủ thực thi thử nghiệm và Sơ khai ứng dụng thử nghiệm, đượ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 thử nghiệm deqp cho Android bằng các tập lệnh xây 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 được yêu cầu
• SDK độc lập của Android đã cài đặt API 13, Công cụ SDK, Công cụ nền tảng SDK và gói Công cụ xây dựng SDK
• Apache Ant 1.9.4 (được yêu cầu bởi bản dựng mã Java)
• CMake 2.8.12 hoặc mới hơn
• Python 2.6 hoặc mới hơ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 cho phép xây dựng nhanh hơn
• Tùy chọn: Ninja make cũng được hỗ trợ trên Linux

Các tệp nhị phân Ant và SDK được định vị dựa trên biến môi trường PATH với các giá trị mặc định ghi đè nhất định. Logic được điều khiển bởi android/scripts/common.py .

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

Bản dựng Linux

Các tệp nhị phân thử nghiệm và tiện ích dòng lệnh có thể được xây dựng cho Linux bằng cách tạo tệp tạo tệp bằng CMake. Có nhiều mục tiêu xây dựng được xác định trước, rất hữu ích khi xây 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à một mặc định tốt. Không có nó, một bản phát hành mặc định, không được tối ưu hóa sẽ được tạo.

Các đối số dòng lệnh -DCMAKE_C_FLAGS và -DCMAKE_CXX_FLAGS có thể được sử dụng để truyền các đối số bổ sung cho 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 được chỉ định, 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.

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

Ví dụ về dòng lệnh đầy đủ được sử dụng để xây dựng 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í tùy 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

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. Tệp chuỗi công cụ chỉ định trình biên dịch sẽ sử dụng, cùng với các đường dẫn tìm kiếm tùy chỉnh cho thư viện và tiêu đề. Một số tệp chuỗi công cụ cho các tình huống phổ biến được bao gồm trong gói phát hành trong 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 có thể được đặt bằng tệp chuỗi công cụ. 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 đặt bằng tệp chuỗi công cụ.

Có thể chọn tệp chuỗi công cụ bằng cách sử dụng tham số xây dựng CMAKE_TOOLCHAIN_FILE . Ví dụ: phần sau đây sẽ tạo tệp tạo tệp cho 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 vào của API được kiểm tra trong quá trình liên kết. Mã kiểm tra luôn truy cập các API thông qua các con trỏ hàm. Sau đó, các điểm vào 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 chúng tại thời điểm liên kết.

Nếu hỗ trợ cho API được bật trong 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 nhậ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 biến cấu hình bản dựng DEQP_<API>_LIBRARIES .

Chuyển khung kiểm tra

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

Bảng bên dưới liệt kê các vị trí có thể xảy ra các thay đổi khi chuyển. Bất cứ điều gì ngoài chúng đều có thể là kỳ lạ.

Thư viện di động cơ sở

Các thư viện di động 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 thử nghiệm chạy trên một trong những hệ điều hành đó, rất có thể không cần phải chạm vào các thư viện tính di động cơ bản.

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

Cổng nền tảng khung thử nghiệm deqp yêu cầu hai thành phần: Điểm vào ứng dụng và triển khai giao diện nền tảng.

Điểm vào ứ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 tra ( tcu::TestLog ) và lặp lại ứng dụng kiểm tra ( tcu::App ). Nếu hệ điều hành đích hỗ trợ điểm vào main() tiêu chuẩn, tcuMain.cpp có thể được sử dụng làm triển khai điểm vào.

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ác cổng nền tảng là tcu::Platform . Cổng nền tảng có thể tùy chọn hỗ trợ các giao diện dành riêng cho GL và EGL. Xem bảng sau để biết tổng quan về những gì cần triển khai để chạy thử nghiệm.

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

Dịch vụ thực hiện thử nghiệm

Để 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ó sẵn trên mục tiêu. Việc triển khai dịch vụ C++ di động được cung cấp trong thư mục execserver . Tệp nhị phân độc lập được xây dựng như một phần của bản dựng mô-đun thử nghiệm deqp cho các mục tiêu PC. Bạn có thể sửa đổi execserver/CMakeLists.txt để cho phép xây dựng trên các mục tiêu khác.

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

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

Chạy thử nghiệm

Trang này cung cấp hướng dẫn để chạy thử nghiệm 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 tin 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 tra 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 thử nghiệm mong muốn tìm thấy các thư mục dữ liệu trong thư mục làm việc hiện tại. Khi sẵn sàng, hãy khởi động Dịch vụ thực thi thử nghiệm trên thiết bị đích. Để biết chi tiết về cách bắt đầu dịch vụ, hãy xem Dịch vụ thực hiện thử nghiệm .

Đối số dòng lệnh

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

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

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

Danh sách trường hợp thử nghiệm có thể được đưa ra ở hai định dạng. Tùy 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 tra phát triển, các tiền tố lặp đi lặp lại có thể trở nên cồng kềnh. Để tránh lặp lại 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ị bên dưới.

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

Ví dụ:

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

Chuyển thành hai trường hợp thử nghiệm 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 hiện 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).

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 Android CTS; tên nào tùy 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 hiện kiểm tra và thiết lập chuyển tiếp cổng, hãy sử dụng 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 bản in gỡ lỗi bằng cách thực hiện các thao tác sau trước khi bắt đầu kiểm tra:

adb –d shell setprop log.tag.dEQP DEBUG

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

Để bắt đầu hoạt động thực thi thử nghiệm theo cách thủ công, hãy xây dựng một ý định Android nhắm mục tiêu android.app.NativeActivity . Các hoạt động này có thể đượ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 có khóa "cmdLine" trong Intent.

Nhật ký kiểm tra đượ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, thông tin gỡ lỗi bổ sung sẽ có trong nhật ký thiết bị.

Bạn có thể khởi chạy một hoạt động từ dòng lệnh bằng tiện ích am . Ví dụ: để chạy thử nghiệm dEQP-GLES2.info trên 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 thử nghiệm 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 dựng 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 dựng gỡ lỗi trên thiết bị, để khởi chạy thử nghiệm 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 thử nghiệm sẽ được thực thi và các tham số bắt buộc khác. Tập lệnh thêm một điểm dừng mặc định khi bắt đầu 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 hành động như đặt điểm dừng để 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ả các đối số và giải thích). Tập lệnh cũng sao chép một số thư viện mặc định từ thiết bị đích để lấy danh sách biểu tượng.

Để xem qua 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 nhiều thư viện hơn thông qua các tham số dòng lệnh debug.py . Tập lệnh này ghi 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 tới 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 khởi chạy debug.py , hãy thêm <path-to-ndk>/prebuilt/windows/bin vào biến PATH.

Lưu ý: Gỡ lỗi mã gốc không hoạt động trên Android 4.3 gốc; để biết cách giải quyết, 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 hóa các bài kiểm tra

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

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

Các tệp nhị phân thử nghiệm có thể được gọi trực tiếp từ hệ thống tự động hóa thử nghiệm. Tệp nhị phân thử nghiệm có thể được khởi chạy cho một trường hợp cụ thể, cho một bộ thử nghiệm hoặc cho tất cả cá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ố lỗi API nhất định hoặc sự cố), quá trình thực thi kiểm thử sẽ bị hủy bỏ. Đối với thử nghiệm hồi quy, cách tiếp cận tốt nhất là gọi các tệp nhị phân thử nghiệm cho từng trường hợp riêng lẻ hoặc các bộ thử nghiệm nhỏ riêng biệt, để có sẵn một phần kết quả ngay cả trong trường hợp có lỗi nghiêm trọng.

Deqp đi kèm với các công cụ thực thi kiểm tra dòng lệnh có thể được sử dụng kết hợp với dịch vụ thực thi để đạt được sự tích hợp mạnh mẽ hơn. Người thực thi phát hiện việc chấm dứt quá trình kiểm tra và sẽ tiếp tục thực hiện kiểm tra trong trường hợp có sẵn tiếp theo. Một tệp nhật ký duy nhất được tạo ra từ phiên kiểm tra đầy đủ. Thiết lập này lý tưởng cho các hệ thống thử nghiệm nhẹ không cung cấp phương tiện khắc phục sự cố.

Công cụ thực hiện kiểm tra 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 tra từ xa, trình tạo so sánh nhật ký kiểm tra để phân tích hồi quy, bộ chuyển đổi nhật ký kiểm tra sang CSV, bộ chuyển đổi kiểm tra-log-sang-XML và bộ chuyển đổi kiểm tra-sang-JUnit .

Mã nguồn của 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 .

Người thực hiện kiểm tra dòng lệnh

Trình thực thi kiểm tra dòng lệnh là một công cụ C++ di động để khởi chạy quá trình chạy thử nghiệm trên một thiết bị và thu thập nhật ký kết quả từ thiết bị đó qua TCP/IP. Executor giao tiếp với dịch vụ thực thi (máy chủ thực thi) trên thiết bị đích. Họ cùng nhau cung cấp chức năng như phục hồi sau sự cố trong quá trình thử nghiệm. Các ví dụ sau đây minh họa cách sử dụng dòng lệnh Test Executor (sử dụng --help để biết thêm chi tiết):

Ví dụ 1: Chạy thử nghiệm 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 thử nghiệm OpenGL ES 2 một phần 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

Kiểm tra nhật ký xuất CSV và so sánh

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

Đầu ra ở định dạng CSV rất thiết thự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. Có thể chọn một định dạng văn bản thuần túy, dễ đọc, bổ sung 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ê sự khác biệt về kết quả kiểm tra giữa hai nhật ký kiểm tra

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

Lưu ý: Đối số --value=code xuất ra mã kết quả kiểm tra, 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ị số được tạo ra bởi bài kiểm tra hiệu suất, khả năng hoặc độ chính xác.

Xuất XML nhật ký kiểm tra

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

• Chế độ tài liệu riêng biệt, trong đó mỗi trường hợp thử nghiệm và tài liệu tóm tắt caselist.xml được ghi vào 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.

Có thể xem các tệp nhật ký kiểm tra đã xuất trong trình duyệt bằng 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 . Để hiển thị 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 chứa các 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 vì Chrome giới hạn quyền truy cập tệp cục bộ 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ục vụ thư mục hiện tại bằng 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 tra JUnit

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

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

Một số nhóm thử nghiệm có thể cần hoặc hỗ trợ các tùy chọn dòng lệnh đặc biệt 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 tra căng thẳng phân bổ bộ nhớ

Các bài kiểm tra căng thẳng về 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ể hủy quá trình kiểm tra 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, các bài kiểm tra đượ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 cách sử dụng đối số dòng lệnh --deqp-test-oom=enable . Bạn nên chạy thử nghiệm 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 tình huống như vậy, sự cố trong quá trình kiểm tra sẽ được hiểu là đã vượt qua.

Nhóm kiểm tra

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

Kiểm tra căng thẳng kết xuất trong thời gian dài

Các bài kiểm tra sức chịu đựng của kết xuất được thiết kế để phát hiện các vấn đề về độ bền dưới tải kết xuất liên tục. Theo mặc định, các thử nghiệm sẽ chỉ thực hiện một vài lần lặp, nhưng chúng có thể được 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 . Cơ quan giám sát kiểm tra phải bị tắt ( --deqp-watchdog=disable ) khi chạy các kiểm tra này trong một thời gian dài.

Nhóm kiểm tra

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