Pengujian Program Kualitas drawElements

Peringatan: Halaman ini tidak dikelola dan tidak akan digunakan lagi. Untuk informasi terkini, lihat:

• Wiki VK-GL-CTS untuk anggota Khronos
• Wiki VK-GL-CTS untuk anggota non-Khronos

AOSP menyertakan rangkaian pengujian GPU drawElements Quality Program (deqp) di https://android.googlesource.com/platform/external/deqp. Halaman ini menjelaskan cara men-deploy rangkaian pengujian deqp ke lingkungan baru.

Untuk menggunakan kode yang dikirimkan terbaru, gunakan cabang deqp-dev. Untuk kode yang cocok dengan rilis CTS Android tertentu, gunakan cabang release-code-name-release (misalnya, untuk Android 6.0, gunakan cabang marshmallow-release).

Tata letak sumber

Tata letak kode sumber untuk modul pengujian deqp dan library pendukung ditampilkan dalam tabel di bawah (daftar ini tidak lengkap, tetapi menyoroti direktori yang paling penting).

Direktori	Deskripsi
android	Sumber penguji Android dan skrip build
data	File data pengujian
modules	Menguji sumber modul
modules/egl	Modul EGL
modules/gles2	Modul GLES2
modules/gles3	Modul GLES3
modules/gles31	Modul GLES3.1
modules/gles32	Modul GLES3.2
targets	File konfigurasi build khusus target
framework	Framework dan utilitas modul pengujian deqp
framework/delibs	Library portabilitas dan build dasar
framework/platform	Port platform
framework/qphelper	Library integrasi program pengujian (C)
framework/common	Framework Deqp (C++)
framework/opengl, framework/egl	Utilitas khusus API
execserver	Sumber ExecServer sisi perangkat
executor	Alat dan utilitas shell eksekutor pengujian sisi host
external	Membangun direktori stub untuk lib eksternal libpng dan zlib

Komponen open source

deqp menggunakan libpng dan zlib, yang dapat diambil menggunakan skrip platform/external/deqp/external/fetch_sources.py atau melalui git dari platform/external/[libpng,zlib].

Membangun program pengujian

Framework pengujian telah dirancang dengan mempertimbangkan portabilitas. Satu-satunya persyaratan wajib adalah dukungan C++ penuh dan library sistem standar untuk I/O, thread, dan soket.

Sistem build CMake

Sumber deqp memiliki skrip build untuk CMake, yang merupakan alat pilihan untuk mengompilasi program pengujian.

CMake adalah sistem build open source yang mendukung beberapa platform dan toolchain. CMake membuat file project IDE atau makefile native dari file konfigurasi yang tidak bergantung pada target. Untuk mengetahui informasi selengkapnya tentang CMake, lihat dokumentasi CMake.

CMake mendukung dan merekomendasikan build di luar pohon sumber, yaitu, Anda harus selalu membuat makefile atau file project di direktori build terpisah di luar pohon sumber. CMake tidak memiliki target "distclean" apa pun, sehingga penghapusan file apa pun yang dihasilkan oleh CMake harus dilakukan secara manual.

Opsi konfigurasi diberikan ke CMake menggunakan sintaksis -DOPTION_NAME=VALUE. Beberapa opsi yang umum digunakan untuk deqp tercantum di bawah.

Opsi konfigurasi	Deskripsi
DEQP_TARGET	Nama target, misalnya: "android" Skrip CMake deqp akan menyertakan file targets/DEQP_TARGET/DEQP_TARGET.cmake dan mengharapkan untuk menemukan opsi build khusus target dari sana.
CMAKE_TOOLCHAIN_FILE	Jalur ke file toolchain untuk CMake. Digunakan untuk kompilasi silang.
CMAKE_BUILD_TYPE	Jenis build untuk target makefile. Nilai yang valid adalah: "Debug" dan "Release" Perhatikan bahwa interpretasi dan jenis default bergantung pada sistem build yang ditargetkan. Lihat dokumentasi CMake untuk mengetahui detailnya.

Membuat file build target

Sistem build deqp dikonfigurasi untuk target baru menggunakan file build target. File build target menentukan fitur yang didukung platform dan library atau jalur include tambahan yang diperlukan. Nama file target mengikuti format targets/NAME/NAME.cmake dan target dipilih menggunakan parameter build DEQP_TARGET.

Jalur file dalam file target bersifat relatif terhadap direktori deqp dasar, bukan direktori targets/NAME. Variabel standar berikut dapat ditetapkan oleh file build target.

Variabel	Deskripsi
DEQP_TARGET_NAME	Nama target (akan disertakan dalam log pengujian)
DEQP_SUPPORT_GLES2	Apakah GLES2 didukung (default: NONAKTIF)
DEQP_GLES2_LIBRARIES	Library GLES2 (biarkan kosong jika tidak didukung atau pemuatan dinamis digunakan)
DEQP_SUPPORT_GLES3	Apakah GLES3.x didukung (default: NONAKTIF)
DEQP_GLES3_LIBRARIES	Library GLES3.x (kosongkan jika tidak didukung atau pemuatan dinamis digunakan)
DEQP_SUPPORT_VG	Apakah OpenVG didukung (default: NONAKTIF)
DEQP_OPENVG_LIBRARIES	Library OpenVG (biarkan kosong jika tidak didukung atau pemuatan dinamis digunakan)
DEQP_SUPPORT_EGL	Apakah EGL didukung (default: NONAKTIF)
DEQP_EGL_LIBRARIES	Library EGL (biarkan kosong jika tidak didukung atau pemuatan dinamis digunakan)
DEQP_PLATFORM_LIBRARIES	Library tambahan khusus platform yang diperlukan untuk penautan
DEQP_PLATFORM_COPY_LIBRARIES	Daftar library yang disalin ke setiap direktori build biner pengujian. Dapat digunakan untuk menyalin library yang diperlukan untuk menjalankan pengujian, tetapi tidak ada di jalur penelusuran default.
TCUTIL_PLATFORM_SRCS	Daftar sumber port platform. Sumber default ditentukan berdasarkan kemampuan dan OS. Catatan: Jalur bersifat relatif terhadap: framework/platform

File build target dapat menambahkan jalur link atau include tambahan menggunakan fungsi CMake include_directories() dan link_directories().

Build Win32

Cara termudah untuk mem-build modul deqp untuk Windows adalah dengan menggunakan sistem build CMake. Anda memerlukan CMake 2.6.12 atau yang lebih baru dan compiler Microsoft Visual C/C++. deqp telah diuji dengan Visual Studio 2013.

File project Visual Studio dapat dibuat dengan perintah berikut:

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

Build 64-bit dapat dibuat dengan memilih "Visual Studio VERSION Win64" sebagai generator build:

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

Anda juga dapat membuat file make NMake dengan opsi -G "NMake Makefiles" serta jenis build (-DCMAKE_BUILD_TYPE="Debug" atau "Release").

Pembuatan konteks render

Konteks rendering dapat dibuat dengan WGL atau EGL di Windows.

Dukungan WGL

Semua biner Win32 mendukung pembuatan konteks GL dengan WGL karena hanya memerlukan library standar. Konteks WGL dapat dipilih menggunakan argumen command line --deqp-gl-context-type=wgl. Dalam mode WGL, deqp menggunakan ekstensi WGL_EXT_create_context_es_profile untuk membuat konteks OpenGL ES. Hal ini telah diuji agar berfungsi dengan driver terbaru dari NVIDIA dan Intel. Driver AMD tidak mendukung ekstensi yang diperlukan.

Dukungan EGL

deqp dibangun dengan pemuatan dinamis untuk EGL di Windows jika DEQP_SUPPORT_EGL diaktifkan. Ini adalah default di sebagian besar target. Kemudian, jika host memiliki pustaka EGL yang tersedia, pengujian dapat dijalankan dengan pustaka tersebut menggunakan parameter command line: --deqp-gl-context-type=egl

Build Android

Build Android menggunakan skrip build CMake untuk mem-build kode pengujian native. Bagian Java, yaitu Test Execution Server dan Test Application Stub, dikompilasi menggunakan alat build Android standar.

Untuk mengompilasi program pengujian deqp untuk Android dengan skrip build yang disediakan, Anda memerlukan:

• Versi terbaru Android NDK; file android/scripts/common.py mencantumkan versi yang diperlukan
• Paket Android SDK mandiri dengan API 13, SDK Tools, SDK Platform-tools, dan SDK Build-tools terinstal
• Apache Ant 1.9.4 (diperlukan oleh build kode Java)
• CMake 2.8.12 atau yang lebih baru
• Python 2.6 atau yang lebih baru dalam seri 2.x; Python 3.x tidak didukung
• Untuk Windows: NMake atau JOM di PATH
  • JOM memungkinkan build yang lebih cepat
• Opsional: Ninja make juga didukung di Linux

Biner Ant dan SDK terletak berdasarkan variabel lingkungan PATH dengan default penggantian tertentu. Logika dikontrol oleh android/scripts/common.py.

Direktori NDK harus berupa ~/android-ndk-VERSION atau C:/android/android-ndk-VERSION atau ditentukan melalui variabel lingkungan ANDROID_NDK_PATH.

Komponen di perangkat Deqp, layanan eksekusi pengujian, dan program pengujian dibangun dengan menjalankan skrip android/scripts/build.py. .apk akhir dibuat di android/package/bin dan dapat diinstal oleh skrip install.py. Jika executor command line digunakan, ExecService diluncurkan dengan skrip launch.py di perangkat melalui ADB. Skrip dapat dijalankan dari direktori mana pun.

Build Linux

Biner pengujian dan utilitas command line dapat dibuat untuk Linux dengan membuat makefile menggunakan CMake. Ada beberapa target build yang telah ditentukan sebelumnya dan berguna saat membangun untuk Linux.

Membangun target	Deskripsi
default	Target default yang menggunakan introspeksi platform CMake untuk menentukan dukungan berbagai API.
x11_glx	Menggunakan GLX untuk membuat konteks OpenGL (ES).
x11_egl	Menggunakan EGL untuk membuat konteks OpenGL (ES).
x11_egl_glx	Mendukung GLX dan EGL dengan X11.

Selalu gunakan -DCMAKE_BUILD_TYPE=<Debug|Release> untuk menentukan jenis build. Release adalah default yang baik. Tanpa itu, build rilis default yang tidak dioptimalkan akan dibuat.

Argumen command line -DCMAKE_C_FLAGS dan -DCMAKE_CXX_FLAGS dapat digunakan untuk meneruskan argumen tambahan ke compiler. Misalnya, build 32-bit atau 64-bit dapat dilakukan dengan menetapkan -DCMAKE_C(XX)_FLAGS="-m32" atau "-m64" masing-masing. Jika tidak ditentukan, arsitektur native toolchain, biasanya 64-bit pada toolchain 64-bit, akan digunakan.

Argumen -DCMAKE_LIBRARY_PATH dan -DCMAKE_INCLUDE_PATH dapat digunakan agar CMake memberikan jalur penelusuran library atau include tambahan.

Contoh command line lengkap yang digunakan untuk melakukan build debug 32-bit terhadap header dan library driver di lokasi kustom adalah sebagai berikut:

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

Kompilasi silang

Kompilasi silang dapat dilakukan dengan menggunakan file toolchain CMake. File toolchain menentukan compiler yang akan digunakan, beserta jalur penelusuran kustom untuk library dan header. Beberapa file toolchain untuk skenario umum disertakan dalam paket rilis di direktori framework/delibs/cmake.

Selain variabel CMake standar, variabel khusus deqp berikut dapat ditetapkan oleh file toolchain. CMake biasanya dapat mendeteksi DE_OS, DE_COMPILER, dan DE_PTR_SIZE dengan benar, tetapi DE_CPU harus ditetapkan oleh file toolchain.

Variabel	Deskripsi
DE_OS	Sistem operasi. Nilai yang didukung adalah: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS
DE_COMPILER	Jenis compiler. Nilai yang didukung adalah: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG
DE_CPU	Jenis CPU. Nilai yang didukung adalah: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE	sizeof(void*) di platform. Nilai yang didukung adalah: 4 dan 8

File toolchain dapat dipilih menggunakan parameter build CMAKE_TOOLCHAIN_FILE. Misalnya, perintah berikut akan membuat makefile untuk build menggunakan cross-compiler CodeSourcery untuk 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

Penautan runtime library GLES dan EGL

deqp tidak memerlukan titik entri API yang sedang diuji selama penautan. Kode pengujian selalu mengakses API melalui pointer fungsi. Titik entri kemudian dapat dimuat secara dinamis saat runtime atau port platform dapat menyediakannya saat waktu penautan.

Jika dukungan untuk API diaktifkan di setelan build dan library link tidak disediakan, deqp akan memuat titik entri yang diperlukan saat runtime. Jika penautan statis diinginkan, berikan library link yang diperlukan dalam variabel konfigurasi build DEQP_<API>_LIBRARIES.

Meng-port framework pengujian

Porting deqp melibatkan tiga langkah: menyesuaikan library portabilitas dasar, menerapkan antarmuka integrasi platform framework pengujian, dan mem-porting layanan eksekusi.

Tabel di bawah mencantumkan lokasi untuk kemungkinan perubahan transfer. Apa pun yang berada di luar wilayah tersebut kemungkinan merupakan sesuatu yang eksotis.

Lokasi	Deskripsi
framework/delibs/debase framework/delibs/dethread framework/delibs/deutil	Penerapan kode khusus OS yang diperlukan.
framework/qphelper/qpCrashHandler.c	Opsional: Penerapan untuk OS Anda.
framework/qphelper/qpWatchDog.c	Implementasi untuk OS Anda. Yang saat ini didasarkan pada dethread dan library C standar.
framework/platform	Port platform baru dan stub aplikasi dapat diimplementasikan seperti yang dijelaskan dalam Port platform framework pengujian.

Library portabilitas dasar

Library portabilitas dasar sudah mendukung Windows, sebagian besar varian Linux, Mac OS, iOS, dan Android. Jika target pengujian berjalan di salah satu sistem operasi tersebut, kemungkinan besar Anda tidak perlu menyentuh library portabilitas dasar sama sekali.

Port platform framework pengujian

Port platform framework pengujian deqp memerlukan dua komponen: Titik entri aplikasi dan penerapan antarmuka platform.

Titik entri aplikasi bertanggung jawab untuk membuat objek platform, membuat objek command line (tcu::CommandLine), membuka log pengujian (tcu::TestLog), dan melakukan iterasi aplikasi pengujian (tcu::App). Jika OS target mendukung titik entri main() standar, tcuMain.cpp dapat digunakan sebagai implementasi titik entri.

API platform deqp dijelaskan secara mendetail dalam file berikut.

File	Deskripsi
framework/common/tcuPlatform.hpp	Class dasar untuk semua port platform
framework/opengl/gluPlatform.hpp	Antarmuka platform OpenGL
framework/egl/egluPlatform.hpp	Antarmuka platform EGL
framework/platform/tcuMain.cpp	Titik entri aplikasi standar

Class dasar untuk semua port platform adalah tcu::Platform. Port platform dapat secara opsional mendukung antarmuka khusus GL dan EGL. Lihat tabel berikut untuk mengetahui ringkasan hal yang perlu diterapkan untuk menjalankan pengujian.

Modul	Antarmuka
Modul pengujian OpenGL (ES)	Antarmuka platform GL
Modul pengujian EGL	Antarmuka platform EGL

Petunjuk mendetail untuk menerapkan port platform ada di header lapisan porting.

Layanan eksekusi pengujian

Untuk menggunakan infrastruktur eksekusi pengujian deqp atau executor command line, layanan eksekusi pengujian harus tersedia di target. Implementasi layanan C++ portabel disediakan di direktori execserver. Biner mandiri dibuat sebagai bagian dari build modul pengujian deqp untuk target PC. Anda dapat mengubah execserver/CMakeLists.txt untuk mengaktifkan build pada target lain.

Versi C++ dari layanan eksekusi pengujian menerima dua parameter command line:

• --port=<port> akan menetapkan port TCP yang diproses server. Defaultnya adalah 50016.
• --single akan menghentikan proses server saat klien terputus. Secara default, proses server akan tetap berjalan untuk melayani permintaan eksekusi pengujian lebih lanjut.

Menjalankan pengujian

Halaman ini memberikan petunjuk untuk menjalankan pengujian deqp di lingkungan Linux dan Windows, menggunakan argumen command line, dan bekerja dengan paket aplikasi Android.

Lingkungan Linux dan Windows

Mulai dengan menyalin file dan direktori berikut ke target.

Modul	Direktori	Target
Server Eksekusi	build/execserver/execserver	<dst>/execserver
Modul EGL	build/modules/egl/deqp-egl	<dst>/deqp-egl
Modul GLES2	build/modules/gles2/deqp-gles2	<dst>/deqp-gles2
	data/gles2	<dst>/gles2
Modul GLES3	build/modules/gles3/deqp-gles3	<dst>/deqp-gles3
	data/gles3	<dst>/gles3
Modul GLES3.1	build/modules/gles31/deqp-gles31	<dst>/deqp-gles31
	data/gles31	<dst>/gles31
Modul GLES3.2	build/modules/gles32/deqp-gles32	<dst>/deqp-gles32
	data/gles32	<dst>/gles32

Anda dapat men-deploy layanan eksekusi dan menguji biner di mana saja dalam sistem file target; namun, biner pengujian mengharapkan untuk menemukan direktori data di direktori kerja saat ini. Jika sudah siap, mulai Layanan Eksekusi Pengujian di perangkat target. Untuk mengetahui detail tentang cara memulai layanan, lihat Layanan eksekusi pengujian.

Argumen command line

Tabel berikut mencantumkan argumen command line yang memengaruhi eksekusi semua program pengujian.

Argumen	Deskripsi
--deqp-case=<casename>	Menjalankan kasus yang cocok dengan pola tertentu. Karakter pengganti (*) didukung.
--deqp-log-filename=<filename>	Menulis hasil pengujian ke file yang namanya Anda berikan. Layanan eksekusi pengujian akan menetapkan nama file saat memulai pengujian.
--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>	Membaca daftar kasus dari stdin atau dari argumen tertentu. Layanan eksekusi pengujian akan menetapkan argumen sesuai dengan permintaan eksekusi yang diterima. Lihat bagian berikutnya untuk mengetahui deskripsi format daftar kasus.
--deqp-test-iteration-count=<count>	Mengganti jumlah iterasi untuk pengujian yang mendukung jumlah iterasi yang bervariasi.
--deqp-base-seed=<seed>	Bibit dasar untuk kasus pengujian yang menggunakan pengacakan.

Argumen khusus GLES2 dan GLES3

Tabel berikut mencantumkan argumen khusus GLES2 dan GLES3.

Argumen	Deskripsi
--deqp-gl-context-type=<type>	Jenis konteks OpenGL. Jenis konteks yang tersedia bergantung pada platform. Di platform yang mendukung EGL, nilai egl dapat digunakan untuk memilih konteks EGL.
--deqp-gl-config-id=<id>	Menjalankan pengujian untuk ID konfigurasi GL yang diberikan. Interpretasi bergantung pada platform. Di platform EGL, ini adalah ID konfigurasi EGL.
--deqp-gl-config-name=<name>	Jalankan pengujian untuk konfigurasi GL bernama. Interpretasi bergantung pada platform. Untuk EGL, formatnya adalah rgb(a)<bits>d<bits>s<bits>. Misalnya, nilai rgb888s8 akan memilih konfigurasi pertama tempat buffer warna adalah RGB888 dan buffer stensil memiliki 8 bit.
--deqp-gl-context-flags=<flags>	Membuat konteks. Tentukan robust atau debug.
--deqp-surface-width=<width> --deqp-surface-height=<height>	Coba buat permukaan dengan ukuran tertentu. Dukungan untuk hal ini bersifat opsional.
--deqp-surface-type=<type>	Menggunakan jenis platform tertentu sebagai target rendering pengujian utama. Kemungkinan jenisnya adalah window, pixmap, pbuffer, dan fbo.
--deqp-screen-rotation=<rotation>	Orientasi layar dalam kelipatan 90 derajat untuk platform yang mendukungnya.

Format daftar kasus pengujian

Daftar kasus pengujian dapat diberikan dalam dua format. Opsi pertama adalah mencantumkan nama lengkap setiap pengujian pada baris terpisah dalam file ASCII standar. Seiring bertambahnya set pengujian, awalan yang berulang dapat menjadi rumit. Untuk menghindari pengulangan awalan, gunakan sintaksis trie (juga dikenal sebagai pohon awalan) yang ditunjukkan di bawah.

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

Contoh:

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

Diterjemahkan menjadi dua kasus pengujian berikut:

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

Android

Paket aplikasi Android berisi semua komponen yang diperlukan, termasuk layanan eksekusi pengujian, file biner pengujian, dan file data. Aktivitas pengujian adalah NativeActivity yang menggunakan EGL (memerlukan Android 3.2 atau yang lebih tinggi).

Paket aplikasi dapat diinstal dengan perintah berikut (nama yang ditampilkan adalah nama APK dalam paket CTS Android; nama ini bergantung pada build):

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

Untuk meluncurkan layanan eksekusi pengujian dan menyiapkan penerusan port, gunakan berikut ini:

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

Pencetakan debug dapat diaktifkan dengan menjalankan perintah berikut sebelum memulai pengujian:

adb –d shell setprop log.tag.dEQP DEBUG

Menjalankan pengujian di Android tanpa Android CTS

Untuk memulai aktivitas eksekusi pengujian secara manual, buat intent Android yang menargetkan android.app.NativeActivity. Aktivitas dapat ditemukan dalam paket com.drawelements.deqp. Command line harus disediakan sebagai string tambahan dengan kunci "cmdLine" di Intent.

Log pengujian ditulis ke /sdcard/dEQP-log.qpa. Jika uji coba tidak dimulai secara normal, informasi debug tambahan tersedia di log perangkat.

Anda dapat meluncurkan aktivitas dari command line menggunakan utilitas am. Misalnya, untuk menjalankan pengujian dEQP-GLES2.info di platform yang mendukung NativeActivity,, gunakan perintah berikut.

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

Melakukan proses debug di Android

Untuk menjalankan pengujian di debugger GDB di Android, kompilasi dan instal build debug terlebih dahulu dengan menjalankan dua skrip berikut:

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

Setelah build debug diinstal di perangkat, untuk meluncurkan pengujian di bawah GDB yang berjalan di host, jalankan perintah berikut:

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

Command line deqp bergantung pada kasus pengujian yang akan dieksekusi dan parameter lain yang diperlukan. Skrip menambahkan titik henti sementara default di awal eksekusi deqp (tcu::App::App).

Skrip debug.py menerima beberapa argumen command line untuk tindakan seperti menyetel titik henti sementara untuk proses debug, parameter koneksi gdbserver, dan jalur ke biner tambahan untuk proses debug (gunakan debug.py --help untuk semua argumen dan penjelasan). Skrip ini juga menyalin beberapa library default dari perangkat target untuk mendapatkan listingan simbol.

Untuk menelusuri kode driver (seperti saat GDB perlu mengetahui lokasi biner dengan informasi proses debug lengkap), tambahkan lebih banyak library melalui parameter command line debug.py. Skrip ini menulis file konfigurasi untuk GDB yang dimulai dari baris 132 file skrip. Anda dapat memberikan jalur tambahan ke biner, dll., tetapi memberikan parameter command line yang benar sudah cukup.

Catatan: Di Windows, biner GDB memerlukan libpython2.7.dll. Sebelum meluncurkan debug.py, tambahkan <path-to-ndk>/prebuilt/windows/bin ke variabel PATH.

Catatan: Proses debug kode native tidak berfungsi di Android 4.3 standar; untuk solusi, lihat bug publik ini. Android 4.4 dan yang lebih tinggi tidak berisi bug ini.

Mengotomatiskan pengujian

Modul pengujian Deqp dapat diintegrasikan ke sistem pengujian otomatis dengan berbagai cara. Pendekatan terbaik bergantung pada infrastruktur pengujian dan lingkungan target yang ada.

Output utama dari proses pengujian selalu berupa file log pengujian, yaitu file dengan akhiran .qpa. Hasil pengujian lengkap dapat diuraikan dari log pengujian. Output konsol adalah informasi debug saja dan mungkin tidak tersedia di semua platform.

Biner pengujian dapat dipanggil langsung dari sistem otomatisasi pengujian. Biner pengujian dapat diluncurkan untuk kasus tertentu, untuk set pengujian, atau untuk semua pengujian yang tersedia. Jika terjadi error fatal selama eksekusi (seperti error API tertentu atau error karena aplikasi mengalami error), eksekusi pengujian akan dibatalkan. Untuk pengujian regresi, pendekatan terbaik adalah memanggil biner pengujian untuk setiap kasus atau set pengujian kecil secara terpisah, agar hasil parsial tersedia meskipun terjadi kegagalan berat.

deqp dilengkapi dengan alat eksekusi pengujian command line yang dapat digunakan bersama dengan layanan eksekusi untuk mencapai integrasi yang lebih kuat. Pelaksana mendeteksi penghentian proses pengujian dan akan melanjutkan eksekusi pengujian pada kasus berikutnya yang tersedia. Satu file log dihasilkan dari sesi pengujian lengkap. Penyiapan ini ideal untuk sistem pengujian ringan yang tidak menyediakan fasilitas pemulihan error.

Alat eksekusi pengujian command line

Kumpulan alat command line saat ini mencakup alat eksekusi pengujian jarak jauh, generator perbandingan log pengujian untuk analisis regresi, konverter test-log-to-CSV, konverter test-log-to-XML, dan konverter testlog-to-JUnit.

Kode sumber untuk alat ini ada di direktori executor, dan biner dibangun ke dalam direktori <builddir>/executor.

Eksekutor pengujian command line

Eksekutor pengujian command line adalah alat C++ portabel untuk meluncurkan proses pengujian di perangkat dan mengumpulkan log yang dihasilkan dari perangkat tersebut melalui TCP/IP. Executor berkomunikasi dengan layanan eksekusi (execserver) di perangkat target. Bersama-sama, keduanya menyediakan fungsi seperti pemulihan dari error proses pengujian. Contoh berikut menunjukkan cara menggunakan Test Executor command line (gunakan --help untuk mengetahui detail selengkapnya):

Contoh 1: Menjalankan pengujian fungsional GLES2 di perangkat 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"

Contoh 2: Melanjutkan eksekusi pengujian OpenGL ES 2 sebagian secara lokal

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

Ekspor dan perbandingan CSV log pengujian

DEQP memiliki alat untuk mengonversi log pengujian (file .qpa) menjadi file CSV. Output CSV berisi daftar kasus pengujian dan hasilnya. Alat ini juga dapat membandingkan dua atau beberapa hasil batch dan hanya mencantumkan kasus pengujian yang memiliki kode status berbeda dalam hasil batch input. Perbandingan juga akan mencetak jumlah kasus yang cocok.

Output dalam format CSV sangat praktis untuk diproses lebih lanjut dengan utilitas command line standar atau dengan editor spreadsheet. Format teks biasa tambahan yang mudah dibaca dapat dipilih menggunakan argumen command line berikut: --format=text

Contoh 1: Mengekspor log pengujian dalam format CSV

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

Contoh 2: Mencantumkan perbedaan hasil pengujian antara dua log pengujian

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

Catatan: Argumen --value=code menampilkan kode hasil pengujian, seperti "Lulus" atau "Gagal". Argumen --value=details memilih penjelasan lebih lanjut tentang hasil atau nilai numerik yang dihasilkan oleh pengujian performa, kemampuan, atau akurasi.

Uji ekspor XML log

File log pengujian dapat dikonversi menjadi dokumen XML yang valid menggunakan utilitas testlog-to-xml. Dua mode output didukung:

• Mode dokumen terpisah, tempat setiap kasus pengujian dan dokumen ringkasan caselist.xml ditulis ke direktori tujuan
• Mode file tunggal, tempat semua hasil dalam file .qpa ditulis ke satu dokumen XML.

File log pengujian yang diekspor dapat dilihat di browser menggunakan lembar gaya XML. Dokumen lembar gaya contoh (testlog.xsl dan testlog.css) disediakan di direktori doc/testlog-stylesheet. Untuk merender file log di browser, salin dua file lembar gaya ke direktori yang sama dengan tempat dokumen XML yang diekspor berada.

Jika Anda menggunakan Google Chrome, file harus diakses melalui HTTP karena Chrome membatasi akses file lokal karena alasan keamanan. Penginstalan Python standar mencakup server HTTP dasar yang dapat diluncurkan untuk menayangkan direktori saat ini dengan perintah python –m SimpleHTTPServer 8000. Setelah meluncurkan server, cukup arahkan browser Chrome ke http://localhost:8000 untuk melihat log pengujian.

Konversi ke log pengujian JUnit

Banyak sistem otomatisasi pengujian dapat membuat laporan hasil eksekusi pengujian dari output JUnit. File log pengujian deqp dapat dikonversi ke format output JUnit menggunakan alat testlog-to-junit.

Saat ini, alat ini hanya mendukung penerjemahan hasil kasus pengujian. Karena JUnit hanya mendukung hasil "lulus" dan "gagal", hasil lulus deqp dipetakan ke "lulus JUnit" dan hasil lainnya dianggap gagal. Kode hasil deqp asli tersedia di output JUnit. Data lain, seperti pesan log dan gambar hasil, tidak dipertahankan dalam konversi.

Menggunakan grup pengujian khusus

Beberapa grup pengujian mungkin memerlukan atau mendukung opsi command line khusus, atau memerlukan perhatian khusus saat digunakan pada sistem tertentu.

Stress test alokasi memori

Stress testing alokasi memori melatih kondisi kehabisan memori dengan berulang kali mengalokasikan resource tertentu hingga driver melaporkan error kehabisan memori.

Di platform tertentu, seperti Android dan sebagian besar varian Linux, hal berikut dapat terjadi: Sistem operasi dapat menghentikan proses pengujian, bukan mengizinkan driver menangani atau memberikan error kehabisan memori. Pada platform tersebut, pengujian yang dirancang untuk menyebabkan error kehabisan memori dinonaktifkan secara default, dan harus diaktifkan menggunakan argumen command line --deqp-test-oom=enable. Sebaiknya jalankan pengujian tersebut secara manual untuk memeriksa apakah sistem berperilaku dengan benar di bawah tekanan resource. Namun, dalam situasi seperti itu, error proses pengujian harus ditafsirkan sebagai lulus.

Grup pengujian

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

Uji tekanan rendering yang berjalan lama

Pengujian beban rendering dirancang untuk mengungkap masalah keandalan di bawah beban rendering yang berkelanjutan. Secara default, pengujian hanya akan menjalankan beberapa iterasi, tetapi pengujian dapat dikonfigurasi untuk berjalan tanpa batas dengan memberikan argumen command line --deqp-test-iteration-count=-1. Pengawas pengujian harus dinonaktifkan (--deqp-watchdog=disable) saat menjalankan pengujian ini dalam jangka waktu yang lama.

Grup pengujian

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