Pengujian Program Kualitas drawElements

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

Untuk menggunakan kode yang terakhir dikirim, gunakan cabang deqp-dev. Untuk kode yang cocok dengan rilis Android CTS 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 adalah yang ditampilkan dalam tabel di bawah (listingan ini tidak komprehensif tetapi menyoroti direktori terpenting).

Direktori Deskripsi
android

Sumber penguji Android dan skrip build
data

Menguji file data
modules

Sumber modul pengujian
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

utilitas dan framework modul pengujian deqp
framework/delibs

Portabilitas dasar dan library build
framework/platform

Port platform
framework/qphelper

Menguji library integrasi program (C)
framework/common

Framework decoder (C++)
framework/opengl, framework/egl

Utilitas khusus API
execserver

Sumber ExecServer sisi perangkat
executor

Utilitas dan alat shell eksekutor pengujian sisi host
external

Bangun direktori stub untuk libs 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].

Membuat program pengujian

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

Sistem build CMake

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

CMake adalah sistem build {i>open source<i} yang mendukung beberapa platform dan toolchain. CMake menghasilkan makefile native atau file project IDE dari file konfigurasi independen target. Untuk informasi selengkapnya tentang CMake, lihat CMake.

CMake mendukung dan merekomendasikan build pohon {i>out-of-source<i}, yaitu, Anda harus selalu membuat makefile atau file proyek di direktori build yang terpisah di luar hierarki sumber. CMake tidak memiliki "distclean" apa pun target, sehingga menghapus file apa pun yang dihasilkan oleh CMake harus dilakukan secara manual.

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

Opsi konfigurasi Deskripsi
DEQP_TARGET

Nama target, misalnya: "android"

Skrip CMake deqp akan menyertakan file targets/DEQP_TARGET/DEQP_TARGET.cmake dan memperkirakan akan 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 mana yang didukung platform dan library atau jalur penyertaan tambahan diperlukan. Nama file target mengikuti targets/NAME/NAME.cmake dan target dipilih menggunakan parameter build DEQP_TARGET.

Jalur file dalam file target relatif dengan 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 ke 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 (biarkan kosong 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 akan digunakan)
DEQP_PLATFORM_LIBRARIES

Library khusus platform tambahan diperlukan untuk penautan
DEQP_PLATFORM_COPY_LIBRARIES

Daftar library yang disalin ke setiap direktori build biner pengujian. Bisa digunakan untuk menyalin library yang diperlukan untuk menjalankan pengujian tetapi tidak secara default {i>search path<i}.
TCUTIL_PLATFORM_SRCS

Daftar sumber port platform. Sumber default ditentukan berdasarkan kemampuan dan OS kami.

Catatan: Jalur terkait dengan: framework/platform

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

Build Win32

Cara termudah untuk membangun modul deqp untuk Windows adalah dengan menggunakan build CMake sistem file. Anda akan memerlukan CMake 2.6.12 atau yang lebih baru dan Microsoft Visual C/C++ compiler. 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 build generator:

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

Anda juga dapat membuat makefile NMake dengan opsi -G "NMake Makefiles" sebagai 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 --deqp-gl-context-type=wgl argumen command line. Dalam mode WGL, deqp menggunakan WGL_EXT_create_context_es_profile untuk membuat konteks OpenGL ES. Ini telah diuji agar dapat bekerja dengan {i>driver<i} terbaru dari NVIDIA dan Intel. Driver AMD tidak mendukung .

Dukungan EGL

Deqp dibuat dengan pemuatan dinamis untuk EGL di Windows jika DEQP_SUPPORT_EGL AKTIF. Ini adalah setelan default pada sebagian besar target. Kemudian, jika host memiliki library EGL tersedia, Anda dapat menjalankan pengujian dengan menggunakan baris perintah parameter: --deqp-gl-context-type=egl

build Android

Build Android menggunakan skrip build CMake untuk membangun kode pengujian native. Bagian Java, yaitu, {i>Test Execution Server<i} dan {i>Test Application Stub<i}, dikompilasi menggunakan alat build Android standar.

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

  • Versi terbaru Android NDK; file android/scripts/common.py mencantumkan versi yang diperlukan
  • SDK mandiri Android dengan API 13, SDK Tools, alat SDK Platform, dan SDK Paket alat build telah diinstal
  • 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 ditempatkan berdasarkan variabel lingkungan PATH dengan {i>default<i} pengganti tertentu. Logika dikontrol oleh android/scripts/common.py.

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

Deqp komponen pada perangkat, layanan eksekusi uji, dan program pengujian yang dibuat dengan menjalankan skrip android/scripts/build.py. .apk akhir dibuat di android/package/bin dan dapat diinstal oleh skrip install.py. Jika eksekutor command line digunakan, lalu 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 versi yang telah ditetapkan sebelumnya yang berguna saat membangun untuk Linux.

Target build Deskripsi
default

Target default yang menggunakan introspeksi platform CMake guna menentukan dukungan untuk 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. Tanpanya, build rilis default yang tidak dioptimalkan akan dibuat.

Argumen command line -DCMAKE_C_FLAGS dan -DCMAKE_CXX_FLAGS dapat berupa yang 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 yang ditetapkan, arsitektur native toolchain, biasanya 64-bit pada toolchain 64-bit, akan digunakan.

Argumen -DCMAKE_LIBRARY_PATH dan -DCMAKE_INCLUDE_PATH dapat digunakan agar CMake memberi CMake library tambahan atau menyertakan jalur penelusuran.

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. Toolchain menentukan compiler yang akan digunakan, bersama dengan jalur penelusuran khusus untuk library, library, dan header. Beberapa file toolchain untuk skenario umum adalah disertakan dalam paket rilis di direktori framework/delibs/cmake.

Selain variabel CMake standar, variabel spesifik deqp berikut dapat disetel 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, kode berikut akan membuat makefile untuk build menggunakan compiler silang 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. Tujuan kode pengujian selalu mengakses API melalui pointer fungsi. Titik entri dapat dimuat secara dinamis saat runtime. atau port platform dapat menyediakannya di waktu penautan.

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

Melakukan porting framework pengujian

Porting deqp melibatkan tiga langkah: mengadaptasi library portabilitas dasar, menerapkan antarmuka integrasi platform kerangka kerja pengujian, dan dan menjalankan layanan eksekusi.

Tabel di bawah mencantumkan lokasi untuk kemungkinan perubahan transfer. Apa pun di luar mereka cenderung eksotis.

Lokasi Deskripsi
framework/delibs/debase
framework/delibs/dethread
framework/delibs/deutil

Implementasi kode khusus OS yang diperlukan.
framework/qphelper/qpCrashHandler.c

Opsional: Implementasi 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 dan stub aplikasi baru dapat diimplementasikan seperti yang dijelaskan di Menguji port platform framework.

Library portabilitas dasar

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

Uji port platform framework

Port platform framework pengujian deqp memerlukan dua komponen: Aplikasi titik entri, dan implementasi 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 ini untuk gambaran umum tentang apa yang perlu diimplementasikan dalam menjalankan pengujian.

Modul Antarmuka

Modul pengujian OpenGL (ES)

Antarmuka platform GL

Modul pengujian EGL

Antarmuka platform EGL

Petunjuk terperinci untuk menerapkan porta platform dapat dilihat di {i>porting layer header<i}.

Layanan eksekusi uji

Untuk menggunakan infrastruktur eksekusi uji deqp atau eksekutor baris perintah, layanan eksekusi uji harus tersedia pada target. C++ portabel implementasi layanan ini disediakan dalam direktori execserver. Mandiri biner dibangun sebagai bagian dari modul pengujian deqp untuk target PC. Anda dapat mengubah execserver/CMakeLists.txt untuk mengaktifkan build di target lain.

Versi C++ layanan eksekusi uji menerima dua command line parameter:

  • --port=<port> akan menetapkan port TCP yang didengarkan oleh server. Defaultnya adalah 50016.
  • --single akan menghentikan proses server saat klien memutuskan koneksi. Secara default, server akan tetap aktif untuk melayani permintaan eksekusi uji lebih lanjut.

Menjalankan pengujian

Halaman ini berisi petunjuk untuk menjalankan pengujian deqp di Linux dan Windows lingkungan, penggunaan argumen baris perintah, dan bekerja dengan Android paket aplikasi Google Cloud.

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 target sistem file; Namun, biner pengujian berharap menemukan direktori data di direktori kerja saat ini. Jika sudah siap, mulai Test Execution Service pada perangkat target. Untuk detail tentang cara memulai layanan, lihat Uji coba layanan eksekusi.

Argumen command line

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

Argumen Deskripsi
--deqp-case=<casename> Jalankan kasus yang cocok dengan pola tertentu. Karakter pengganti (*) didukung.
--deqp-log-filename=<filename> Tulis hasil pengujian ke file yang namanya Anda berikan. Eksekusi uji 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. Eksekusi uji akan menetapkan argumen sesuai dengan permintaan eksekusi yang diterima. Lihat bagian berikutnya untuk deskripsi format daftar kasus.
--deqp-test-iteration-count=<count> Ganti jumlah iterasi untuk pengujian yang mendukung jumlah variabel iterasi sebelumnya.
--deqp-base-seed=<seed> Seed 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. Aktif platform yang mendukung EGL, nilai egl dapat digunakan untuk memilih konteks EGL.
--deqp-gl-config-id=<id> Jalankan pengujian untuk ID konfigurasi GL yang disediakan. Interpretasi adalah bergantung pada platform. Di platform EGL, ini adalah ID konfigurasi EGL.
--deqp-gl-config-name=<name> Menjalankan pengujian untuk konfigurasi GL yang telah diberi nama. Interpretasi adalah bergantung pada platform. Untuk EGL, formatnya adalah rgb(a)<bits>d<bits>s<bits>. Sebagai contoh, 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 platform dengan ukuran tertentu. Dukungan untuk hal ini bersifat opsional.
--deqp-surface-type=<type> Menggunakan jenis platform tertentu sebagai target rendering pengujian utama. Mungkin jenisnya adalah window, pixmap, pbuffer, dan fbo.
--deqp-screen-rotation=<rotation> Orientasi layar dengan kelipatan 90 derajat untuk platform yang mendukungnya.

Format daftar kasus pengujian

Daftar kasus pengujian dapat diberikan dalam dua format. Opsi pertama adalah membuat daftar nama lengkap dari setiap pengujian pada baris terpisah dalam file ASCII standar. Sebagai set pengujian bertambah, awalan berulang bisa menjadi rumit. Untuk menghindari pengulangan gunakan sintaks trie (juga dikenal sebagai pohon awalan) yang ditunjukkan di bawah ini.

{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 uji, biner pengujian, dan file data. Aktivitas pengujiannya adalah NativeActivity yang menggunakan EGL (memerlukan Android 3.2 atau yang lebih baru).

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

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

Untuk meluncurkan layanan eksekusi uji dan menyiapkan penerusan port, gunakan metode 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 tes:

adb –d shell setprop log.tag.dEQP DEBUG

Menjalankan pengujian di Android tanpa Android CTS

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

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

Anda dapat meluncurkan aktivitas dari command line menggunakan am utilitas. Misalnya, untuk menjalankan pengujian dEQP-GLES2.info pada 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"'

Debug di Android

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

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

Setelah build debug diinstal pada perangkat, untuk meluncurkan pengujian di 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.*"

Baris perintah deqp bergantung pada kasus pengujian yang akan dijalankan dan parameter 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, koneksi dbserver parameter, dan jalur ke biner tambahan yang akan di-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 menyusuri kode driver (seperti saat GDB perlu mengetahui lokasi biner dengan informasi debug lengkap), tambahkan lebih banyak pustaka melalui Parameter command line debug.py. Skrip ini menulis sebuah file konfigurasi untuk GDB mulai dari baris 132 file skrip. Anda dapat menyediakan jalur tambahan ke biner, dll., tetapi memberikan perintah yang benar parameter baris seharusnya 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; untuk solusi, lihat bug publik ini. Android 4.4 dan yang lebih tinggi tidak memuat bug ini.

Mengotomatiskan pengujian

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

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

Biner pengujian dapat dipanggil langsung dari sistem otomatisasi pengujian. Tes biner dapat diluncurkan untuk kasus tertentu, untuk set pengujian, atau untuk semua pengujian yang tersedia. Jika error fatal terjadi selama eksekusi (seperti API tertentu error atau error), eksekusi uji akan dibatalkan. Untuk pengujian regresi, pendekatan terbaik adalah memanggil biner pengujian untuk kasus individu atau pengujian kecil ditetapkan secara terpisah, untuk menyediakan hasil parsial, bahkan jika terjadi kegagalan keras.

Deqp dilengkapi dengan alat eksekusi uji coba baris perintah yang dapat digunakan di dengan layanan eksekusi untuk mencapai integrasi yang lebih tangguh. Eksekutor mendeteksi penghentian proses pengujian dan akan melanjutkan eksekusi uji pada kasus yang tersedia berikutnya. Satu file log dihasilkan dari pengujian lengkap sesi. Pengaturan ini ideal untuk sistem pengujian ringan yang tidak menyediakan fasilitas pemulihan dari bencana.

Alat eksekusi uji command line

Serangkaian alat command line saat ini mencakup alat eksekusi uji jarak jauh, yakni generator perbandingan log untuk analisis regresi, pengonversi {i>test-log<i}-ke-CSV, pengonversi {i>test-log<i}-ke-XML, dan pengonversi {i>testlog<i}-ke-JUnit.

Kode sumber untuk alat ini ada dalam direktori executor, dan binernya adalah yang dibuat ke dalam direktori <builddir>/executor.

Eksekutor uji command line

Eksekutor pengujian command line adalah alat C++ portabel untuk meluncurkan pengujian pada perangkat dan mengumpulkan log yang dihasilkan melalui TCP/IP. Eksekutor berkomunikasi dengan layanan eksekusi (execserver) pada 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 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 pengujian OpenGL ES 2 sebagian yang dijalankan 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

Uji ekspor CSV log dan bandingkan

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

{i>Output<i} dalam format CSV sangat praktis untuk diproses lebih lanjut dengan utilitas baris perintah atau dengan editor {i>spreadsheet<i}. Tambahan informasi yang dapat dibaca manusia, Format teks biasa 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: Cantumkan perbedaan hasil pengujian antara dua log pengujian
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Catatan: Argumen --value=code menghasilkan pengujian kode hasil, seperti "Lulus" atau "Gagal". Argumen --value=details memilih argumen berikutnya penjelasan hasil atau nilai numerik yang dihasilkan oleh uji kinerja, kemampuan, atau akurasi.

Uji ekspor XML log

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

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

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

Jika Anda menggunakan Google Chrome, file harus diakses melalui HTTP sebagai Chrome membatasi akses file lokal untuk alasan keamanan. Penginstalan Python standar mencakup server HTTP dasar yang dapat diluncurkan untuk melayani aliran 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 yang dapat menghasilkan laporan hasil pengujian dari JUnit {i>output<i} tersebut. File log pengujian deqp dapat dikonversi ke format output JUnit menggunakan alat {i> testlog-to-junit<i}.

Saat ini alat ini hanya mendukung penerjemahan verdict kasus pengujian. Sebagai JUnit hanya mendukung "lulus" dan "gagal" hasil, hasil penerusan dari deqp dipetakan ke "JUnit pass" dan hasil lainnya dianggap gagal. Deqp asli kode hasil ini tersedia dalam output JUnit. Data lain, seperti pesan log dan gambar yang dihasilkan, tidak dipertahankan dalam konversi.

Menggunakan grup pengujian khusus

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

Uji daya tahan alokasi memori

Uji daya tahan alokasi memori latihan kondisi kehabisan memori dengan berulang mengalokasikan resource tertentu hingga driver melaporkan error kehabisan memori.

Pada platform tertentu, seperti Android dan sebagian besar varian Linux, dapat terjadi: Sistem operasi dapat mematikan proses pengujian alih-alih mengizinkan {i>driver<i} untuk menangani atau menyebabkan {i>error<i} kehabisan memori. Pada platform ini, pengujian yang dirancang untuk menyebabkan error kehabisan memori 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 sumber daya. Namun, dengan situasi, {i>error<i} dalam proses pengujian harus dianggap sebagai lulus.

Grup pengujian

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

Pengujian daya tahan rendering yang berjalan lama

Uji daya tahan rendering dirancang untuk mengungkapkan masalah keandalan dalam kondisi oleh beban rendering. Secara {i>default<i}, pengujian hanya akan mengeksekusi beberapa iterasi, tetapi layanan tersebut dapat dikonfigurasi untuk berjalan tanpa batas waktu dengan menyediakan --deqp-test-iteration-count=-1 argumen command line. Watchdog pengujian harus dinonaktifkan (--deqp-watchdog=disable) jika menjalankan pengujian dalam waktu yang lama.

Grup pengujian

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