Pengujian Program Kualitas drawElements (deqp)

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

Untuk bekerja dengan kode terbaru yang dikirimkan, 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 pustaka pendukung ditunjukkan pada tabel di bawah ini (daftarnya tidak lengkap tetapi menyoroti direktori yang paling penting).

Komponen sumber terbuka

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 uji

Kerangka uji telah dirancang dengan mempertimbangkan portabilitas. Satu-satunya persyaratan wajib adalah dukungan penuh C++ dan pustaka sistem standar untuk I/O, utas, dan soket.

CMake sistem build

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

CMake adalah sistem pembangunan sumber terbuka yang mendukung banyak platform dan rantai alat. CMake menghasilkan makefile asli atau file proyek IDE dari file konfigurasi target-independen. Untuk informasi lebih lanjut tentang CMake, silakan lihat dokumentasi CMake .

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

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

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 pustaka atau jalur penyertaan tambahan apa yang diperlukan. Nama file target mengikuti format targets/ NAME / NAME .cmake dan target dipilih menggunakan parameter build DEQP_TARGET .

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

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

Membangun Win32

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

File proyek 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 NMake makefiles dengan opsi -G "NMake Makefiles" serta tipe build ( -DCMAKE_BUILD_TYPE="Debug" atau "Release" ).

Membuat pembuatan konteks

Konteks rendering dapat dibuat dengan WGL atau dengan EGL di Windows.

dukungan WGL

Semua binari Win32 mendukung pembuatan konteks GL dengan WGL karena hanya memerlukan pustaka standar. Konteks WGL dapat dipilih menggunakan argumen baris perintah --deqp-gl-context-type=wgl . Dalam mode WGL, deqp menggunakan ekstensi WGL_EXT_create_context_es_profile untuk membuat konteks OpenGL ES. Ini telah diuji untuk bekerja 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 AKTIF. Ini adalah default di sebagian besar target. Kemudian, jika host memiliki library EGL yang tersedia, Anda dapat menjalankan pengujian dengannya dengan parameter baris perintah: --deqp-gl-context-type=egl

Android membangun

Build Android menggunakan skrip build CMake untuk membuat kode pengujian asli. 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
• SDK Android yang berdiri sendiri dengan API 13, SDK Tools, SDK Platform-tools, dan paket SDK Build-tools diinstal
• Apache Ant 1.9.4 (diperlukan oleh kode Java build)
• CMake 2.8.12 atau lebih baru
• Python 2.6 atau yang lebih baru dalam seri 2.x; Python 3.x tidak didukung
• Untuk Windows: Baik NMake atau JOM di PATH
  • JOM memungkinkan pembuatan yang lebih cepat
• Opsional: Ninja make juga didukung di Linux

Binari Ant dan SDK terletak berdasarkan variabel lingkungan PATH dengan default utama tertentu. Logikanya dikendalikan 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 pada perangkat Deqp, layanan eksekusi pengujian, dan program pengujian dibuat dengan menjalankan android/scripts/build.py . .apk terakhir dibuat di android/package/bin dan dapat diinstal dengan skrip install.py . Jika eksekutor baris perintah digunakan, ExecService diluncurkan dengan skrip launch.py ​​pada perangkat melalui ADB. Script dapat dieksekusi dari direktori manapun.

membangun Linux

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

Selalu gunakan -DCMAKE_BUILD_TYPE=<Debug|Release> untuk menentukan tipe build. Release adalah default yang bagus. Tanpanya, build rilis default yang tidak dioptimalkan akan dibuat.

Argumen baris perintah -DCMAKE_C_FLAGS dan -DCMAKE_CXX_FLAGS dapat digunakan untuk meneruskan argumen tambahan ke kompiler. Misalnya build 32-bit atau 64-bit dapat dilakukan dengan mengatur -DCMAKE_C(XX)_FLAGS="-m32" atau "-m64" masing-masing. Jika tidak ditentukan, arsitektur asli toolchain, biasanya 64-bit pada toolchain 64-bit, digunakan.

-DCMAKE_LIBRARY_PATH dan -DCMAKE_INCLUDE_PATH dapat digunakan untuk CMake untuk memberikan pustaka tambahan kepada CMake atau menyertakan jalur pencarian.

Contoh baris perintah lengkap yang digunakan untuk melakukan build debug 32-bit terhadap header driver dan library 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 rantai alat CMake. File rantai alat menentukan kompiler yang akan digunakan, bersama dengan jalur pencarian khusus untuk pustaka dan header. Beberapa file rantai alat untuk skenario umum disertakan dalam paket rilis di direktori framework/delibs/cmake .

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

File rantai alat dapat dipilih menggunakan parameter pembuatan CMAKE_TOOLCHAIN_FILE . Misalnya, berikut ini akan membuat makefile untuk build menggunakan kompiler 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 run-time dari perpustakaan GLES dan EGL

Deqp tidak memerlukan titik masuk API yang sedang diuji selama penautan. Kode pengujian selalu mengakses API melalui pointer fungsi. Titik masuk kemudian dapat dimuat secara dinamis pada waktu berjalan atau port platform dapat menyediakannya pada waktu tautan.

Jika dukungan untuk API diaktifkan di pengaturan build dan pustaka tautan tidak disediakan, deqp akan memuat titik masuk yang diperlukan pada waktu proses. Jika penautan statis diinginkan, sediakan pustaka tautan yang diperlukan dalam variabel konfigurasi pembangunan DEQP_<API>_LIBRARIES .

Memindahkan kerangka pengujian

Porting deqp melibatkan tiga langkah: mengadaptasi pustaka portabilitas dasar, mengimplementasikan antarmuka integrasi platform kerangka uji, dan mem-porting layanan eksekusi.

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

Pustaka portabilitas dasar

Pustaka 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 tidak perlu menyentuh pustaka portabilitas dasar sama sekali.

Uji port platform kerangka kerja

Port platform kerangka kerja pengujian deqp memerlukan dua komponen: Titik masuk aplikasi dan implementasi antarmuka platform.

Titik masuk aplikasi bertanggung jawab untuk membuat objek platform, membuat objek baris perintah ( tcu::CommandLine ), membuka log pengujian ( tcu::TestLog ), dan mengulangi aplikasi pengujian ( tcu::App ). Jika OS target mendukung titik masuk main() standar, tcuMain.cpp dapat digunakan sebagai implementasi titik masuk.

API platform deqp dijelaskan secara rinci dalam file berikut.

Kelas dasar untuk semua port platform adalah tcu::Platform . Port platform secara opsional dapat mendukung antarmuka khusus GL dan EGL. Lihat tabel berikut untuk ikhtisar tentang apa yang perlu diterapkan untuk menjalankan pengujian.

Instruksi terperinci untuk mengimplementasikan port platform ada di header lapisan porting.

Layanan eksekusi tes

Untuk menggunakan infrastruktur eksekusi pengujian deqp atau eksekutor baris perintah, layanan eksekusi pengujian harus tersedia pada target. Implementasi layanan C++ portabel disediakan di direktori execserver . Biner yang berdiri sendiri dibuat sebagai bagian dari modul uji deqp yang dibuat untuk target PC. Anda dapat memodifikasi execserver/CMakeLists.txt untuk mengaktifkan build pada target lain.

Versi C++ dari layanan eksekusi pengujian menerima dua parameter baris perintah:

• --port=<port> akan mengatur port TCP yang didengarkan server. Standarnya adalah 50016.
• --single akan menghentikan proses server ketika klien terputus. Secara default, proses server akan tetap aktif untuk melayani permintaan eksekusi pengujian lebih lanjut.

Menjalankan tes

Halaman ini memberikan instruksi untuk menjalankan pengujian deqp di lingkungan Linux dan Windows, menggunakan argumen baris perintah, dan bekerja dengan paket aplikasi Android.

Lingkungan Linux dan Windows

Mulailah dengan menyalin file dan direktori berikut ke target.

Anda dapat menerapkan layanan eksekusi dan menguji binari di mana saja di sistem file target; namun, binari uji berharap menemukan direktori data di direktori kerja saat ini. Saat siap, mulai Layanan Eksekusi Uji pada perangkat target. Untuk detail tentang memulai layanan, lihat Layanan eksekusi pengujian .

Argumen baris perintah

Tabel berikut mencantumkan argumen baris perintah yang memengaruhi eksekusi semua program pengujian.

Argumen khusus GLES2 dan GLES3

Format daftar kasus uji

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

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

Sebagai contoh:

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

Diterjemahkan ke dalam dua kasus uji 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, biner pengujian, dan file data. Aktivitas pengujian adalah NativeActivity yang menggunakan EGL (memerlukan Android 3.2 atau lebih tinggi).

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

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

Untuk meluncurkan layanan eksekusi pengujian dan untuk menyiapkan penerusan porta, gunakan yang berikut ini:

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

Cetakan debug dapat diaktifkan dengan menjalankan yang berikut ini 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 maksud Android yang menargetkan android.app.NativeActivity . Aktivitas dapat ditemukan di paket com.drawelements.deqp . Baris perintah harus diberikan 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 baris perintah menggunakan utilitas am . 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"'

Men-debug di Android

Untuk menjalankan pengujian di bawah debugger GDB di Android, pertama-tama 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 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.*"

Baris perintah deqp tergantung pada kasus uji yang akan dieksekusi dan parameter lain yang diperlukan. Script menambahkan breakpoint default di awal eksekusi deqp ( tcu tcu::App::App ).

Skrip debug.py menerima beberapa argumen baris perintah untuk tindakan seperti menyetel breakpoint untuk debugging, parameter koneksi gdbserver, dan jalur ke biner tambahan untuk debug (gunakan debug.py --help untuk semua argumen dan penjelasan). Script juga menyalin beberapa pustaka default dari perangkat target untuk mendapatkan daftar simbol.

Untuk menelusuri kode driver (seperti saat GDB perlu mengetahui lokasi biner dengan informasi debug lengkap), tambahkan lebih banyak pustaka melalui parameter baris perintah debug.py . Skrip ini menulis file konfigurasi untuk GDB mulai dari baris 132 file skrip. Anda dapat memberikan jalur tambahan ke binari, dll., tetapi menyediakan parameter baris perintah 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: Debug kode asli tidak berfungsi pada stok Android 4.3; untuk solusi, lihat bug publik ini . Android 4.4 dan lebih tinggi tidak mengandung bug ini.

Mengotomatiskan tes

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

Keluaran utama dari pengujian selalu berupa file log pengujian, yaitu file dengan postfix .qpa . Hasil tes lengkap dapat diuraikan dari log tes. Keluaran konsol hanya merupakan informasi debug 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 kesalahan fatal terjadi selama eksekusi (seperti kesalahan API tertentu atau crash), eksekusi pengujian akan dibatalkan. Untuk pengujian regresi, pendekatan terbaik adalah menggunakan binari pengujian untuk kasus individual atau set pengujian kecil secara terpisah, agar hasil parsial tersedia bahkan jika terjadi kegagalan besar.

Deqp dilengkapi dengan alat eksekusi uji baris perintah yang dapat digunakan dalam kombinasi dengan layanan eksekusi untuk mencapai integrasi yang lebih kuat. Eksekutor mendeteksi penghentian proses pengujian dan akan melanjutkan eksekusi pengujian pada kasus berikutnya yang tersedia. File log tunggal dihasilkan dari sesi pengujian penuh. Pengaturan ini sangat ideal untuk sistem pengujian ringan yang tidak menyediakan fasilitas pemulihan kerusakan.

Alat eksekusi tes baris perintah

Kumpulan alat baris perintah saat ini mencakup alat eksekusi pengujian jarak jauh, generator perbandingan log pengujian untuk analisis regresi, konverter uji-log-ke-CSV, konverter uji-log-ke-XML, dan konverter testlog-ke-JUnit .

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

Pelaksana Tes baris perintah

Baris perintah Test Executor adalah alat C++ portabel untuk meluncurkan uji coba pada perangkat dan mengumpulkan log yang dihasilkan darinya melalui TCP/IP. Pelaksana berkomunikasi dengan layanan eksekusi (execserver) pada perangkat target. Bersama-sama mereka menyediakan fungsionalitas seperti pemulihan dari crash proses pengujian. Contoh berikut menunjukkan cara menggunakan Pelaksana Tes baris perintah (gunakan --help untuk detail selengkapnya):

Contoh 1: Jalankan 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: Lanjutkan uji coba OpenGL ES 2 parsial 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 log CSV ekspor dan bandingkan

Deqp memiliki alat untuk mengonversi log pengujian (file qpa ) menjadi file CSV. Keluaran CSV berisi daftar kasus uji dan hasilnya. Alat ini juga dapat membandingkan dua atau lebih hasil batch dan hanya mencantumkan kasus uji 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 baris perintah standar atau dengan editor spreadsheet. Format teks biasa tambahan yang dapat dibaca manusia dapat dipilih menggunakan argumen baris perintah berikut: --format=text

Contoh 1: Ekspor log uji 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: Buat daftar perbedaan hasil pengujian antara dua log pengujian

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

Catatan: Argumen --value=code mengeluarkan kode hasil tes, seperti "Lulus" atau "Gagal". Argumen --value=details memilih penjelasan lebih lanjut dari hasil atau nilai numerik yang dihasilkan oleh kinerja, kemampuan, atau uji akurasi.

Ekspor log XML uji

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

• Mode dokumen terpisah, di mana setiap kasus uji dan dokumen ringkasan caselist.xml ditulis ke direktori tujuan
• Mode file tunggal, di mana semua hasil dalam file .qpa ditulis ke dokumen XML tunggal.

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

Jika Anda menggunakan Google Chrome, file harus diakses melalui HTTP karena Chrome membatasi akses file lokal untuk alasan keamanan. Instalasi Python standar mencakup server HTTP dasar yang dapat diluncurkan untuk melayani 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 otomasi pengujian dapat menghasilkan laporan hasil uji coba dari keluaran JUnit. File log pengujian deqp dapat dikonversi ke format output JUnit menggunakan alat testlog-ke-junit.

Alat saat ini mendukung penerjemahan putusan kasus uji saja. Karena JUnit hanya mendukung hasil "lulus" dan "gagal", hasil kelulusan deqp dipetakan ke "lulus JUnit" dan hasil lainnya dianggap gagal. Kode hasil deqp asli tersedia di keluaran JUnit. Data lain, seperti pesan log dan gambar hasil, tidak disimpan dalam konversi.

Menggunakan kelompok tes khusus

Beberapa grup uji mungkin memerlukan atau mendukung opsi baris perintah khusus, atau memerlukan perawatan khusus saat digunakan pada sistem tertentu.

Tes stres alokasi memori

Tes stres alokasi memori melatih kondisi kehabisan memori dengan berulang kali mengalokasikan sumber daya tertentu hingga driver melaporkan kesalahan kehabisan memori.

Pada platform tertentu, seperti Android dan sebagian besar varian Linux, hal berikut dapat terjadi: Sistem operasi dapat menghentikan proses pengujian alih-alih mengizinkan driver untuk menangani atau memberikan kesalahan kehabisan memori. Pada platform tersebut, pengujian yang dirancang untuk menyebabkan kesalahan kehabisan memori dinonaktifkan secara default, dan harus diaktifkan menggunakan argumen baris perintah --deqp-test-oom=enable . Disarankan agar Anda menjalankan tes tersebut secara manual untuk memeriksa apakah sistem berperilaku dengan benar di bawah tekanan sumber daya. Namun, dalam situasi seperti itu, crash proses pengujian harus ditafsirkan sebagai lulus.

Kelompok uji

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

Tes stres rendering yang berjalan lama

Tes stres rendering dirancang untuk mengungkapkan masalah ketahanan di bawah beban rendering berkelanjutan. Secara default, pengujian hanya akan mengeksekusi beberapa iterasi, tetapi dapat dikonfigurasi untuk berjalan tanpa batas dengan menyediakan argumen baris perintah --deqp-test-iteration-count=-1 . Pengawas tes harus dinonaktifkan ( --deqp-watchdog=disable ) saat menjalankan tes ini untuk jangka waktu yang lama.

Kelompok uji

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