pengujian Program Kualitas drawElements

AOSP menyertakan rangkaian pengujian GPU drawElements Quality Program (deqp) di https://android.googlesource.com/platform/external/deqp . Halaman ini merinci cara menyebarkan 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 pendukungnya ditunjukkan pada tabel di bawah (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 pengujian

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

Sistem pembangunan CMake

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

CMake adalah sistem pembangunan sumber terbuka yang mendukung berbagai platform dan rantai alat. CMake menghasilkan makefile asli atau file proyek IDE dari file konfigurasi yang tidak bergantung pada target. Untuk informasi selengkapnya tentang CMake, silakan lihat dokumentasi CMake .

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

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

Buat file pembangunan 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 berdasarkan file build target.

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

Pembuatan Win32

Cara termudah untuk membuat modul deqp untuk Windows adalah dengan menggunakan sistem build CMake. Anda memerlukan CMake 2.6.12 atau 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 makefile NMake dengan opsi -G "NMake Makefiles" serta tipe build ( -DCMAKE_BUILD_TYPE="Debug" atau "Release" ).

Render pembuatan konteks

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

dukungan WGL

Semua biner Win32 mendukung pembuatan konteks GL dengan WGL karena hanya memerlukan perpustakaan 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 dibuat dengan pemuatan dinamis untuk EGL di Windows jika DEQP_SUPPORT_EGL AKTIF. Ini adalah default di sebagian besar target. Kemudian, jika host memiliki pustaka EGL yang tersedia, pengujian dengan pustaka tersebut dapat dilakukan dengan parameter baris perintah: --deqp-gl-context-type=egl

Pembuatan Android

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 mengkompilasi 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 terinstal
• Apache Ant 1.9.4 (diperlukan oleh pembuatan kode Java)
• CMake 2.8.12 atau lebih baru
• Python 2.6 atau lebih baru dalam seri 2.x; Python 3.x tidak didukung
• Untuk Windows: NMake atau JOM di PATH
  • JOM memungkinkan pembangunan yang lebih cepat
• Opsional: Ninja make juga didukung di Linux

Biner Ant dan SDK ditempatkan 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 Deqp pada perangkat, layanan eksekusi pengujian, dan program pengujian dibuat dengan mengeksekusi skrip android/scripts/build.py . .apk terakhir dibuat di android/package/bin dan dapat diinstal dengan skrip install.py . Jika pelaksana baris perintah digunakan, ExecService diluncurkan dengan skrip launch.py ​​pada perangkat melalui ADB. Skrip dapat dijalankan dari direktori mana pun.

Pembuatan Linux

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

Selalu gunakan -DCMAKE_BUILD_TYPE=<Debug|Release> untuk menentukan tipe build. Release adalah standar 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 rantai alat, biasanya 64-bit pada rantai alat 64-bit, akan digunakan.

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

Contoh baris perintah lengkap yang digunakan untuk melakukan build debug 32-bit terhadap header dan pustaka 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 rantai alat CMake. File toolchain menentukan kompiler yang akan digunakan, bersama dengan jalur pencarian khusus untuk perpustakaan 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 diatur oleh file toolchain. CMake biasanya dapat mendeteksi DE_OS , DE_COMPILER dan DE_PTR_SIZE dengan benar tetapi DE_CPU harus disetel oleh file toolchain.

File toolchain dapat dipilih menggunakan parameter build 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 runtime perpustakaan GLES dan EGL

Deqp tidak memerlukan titik masuk API yang sedang diuji selama penautan. Kode pengujian selalu mengakses API melalui penunjuk fungsi. Titik masuk kemudian dapat dimuat secara dinamis pada waktu proses 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 build DEQP_<API>_LIBRARIES .

Port 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 mencantumkan lokasi kemungkinan perubahan porting. Apa pun di luar mereka kemungkinan besar bersifat eksotik.

Perpustakaan portabilitas dasar

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

Port platform kerangka uji

Port platform kerangka 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 gambaran umum tentang apa yang perlu diterapkan untuk menjalankan pengujian.

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

Layanan eksekusi uji

Untuk menggunakan infrastruktur eksekusi pengujian deqp atau pelaksana 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 pengujian deqp yang dibuat untuk target PC. Anda dapat memodifikasi execserver/CMakeLists.txt untuk mengaktifkan pembangunan 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 up untuk melayani permintaan eksekusi pengujian lebih lanjut.

Jalankan tes

Halaman ini memberikan petunjuk 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 dalam sistem file target; namun, binari pengujian berharap menemukan direktori data di direktori kerja saat ini. Jika sudah siap, mulai Test Execution Service pada perangkat target. Untuk detail tentang memulai layanan, lihat Menguji layanan eksekusi .

Argumen baris perintah

Tabel berikut mencantumkan argumen baris perintah yang mempengaruhi 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 pengujian pada baris terpisah dalam file ASCII standar. Seiring bertambahnya set pengujian, prefiks 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{…}}}

Misalnya:

{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 bergantung pada build):

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

Untuk meluncurkan layanan eksekusi pengujian dan mengatur penerusan port, 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 hal berikut sebelum memulai pengujian:

adb –d shell setprop log.tag.dEQP DEBUG

Jalankan tes di Android tanpa Android CTS

Untuk memulai aktivitas eksekusi pengujian secara manual, buatlah maksud Android yang menargetkan android.app.NativeActivity . Aktivitasnya 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 pada 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 pada perangkat, untuk meluncurkan pengujian pada GDB yang berjalan pada 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 dieksekusi dan parameter lain yang diperlukan. Skrip menambahkan breakpoint default di awal eksekusi deqp ( tcu::App::App ).

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

Untuk menelusuri kode driver (seperti ketika GDB perlu mengetahui lokasi biner dengan informasi debug lengkap), tambahkan lebih banyak perpustakaan 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 biner, 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: Proses debug kode asli tidak berfungsi pada stok Android 4.3; untuk solusinya, lihat bug publik ini . Android 4.4 dan lebih tinggi tidak mengandung bug ini.

Otomatiskan pengujian

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

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

Biner pengujian dapat dijalankan langsung dari sistem otomasi pengujian. Biner pengujian dapat diluncurkan untuk kasus tertentu, untuk set pengujian, atau untuk semua pengujian yang tersedia. Jika terjadi kesalahan fatal selama eksekusi (seperti kesalahan API tertentu atau crash), eksekusi pengujian akan dibatalkan. Untuk pengujian regresi, pendekatan terbaik adalah dengan memanggil biner pengujian untuk kasus individual atau set pengujian kecil secara terpisah, agar hasil parsial tersedia bahkan jika terjadi kegagalan besar.

Deqp dilengkapi dengan alat eksekusi pengujian baris perintah 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 penuh. Penyiapan ini 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, pengonversi log pengujian ke CSV, pengonversi log pengujian ke XML, dan pengonversi log pengujian ke JUnit .

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

Pelaksana pengujian baris perintah

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

Contoh 1: Jalankan pengujian fungsi GLES2 pada 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 pengujian parsial OpenGL ES 2 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 log CSV 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 pengujian yang memiliki kode status berbeda dalam hasil input batch. Perbandingannya 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 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: 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 menampilkan kode hasil tes, seperti "Lulus" atau "Gagal". Argumen --value=details memilih penjelasan lebih lanjut tentang 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 utilitas 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, arahkan saja browser Chrome ke http://localhost:8000 untuk melihat log pengujian.

Konversi ke log pengujian JUnit

Banyak sistem otomasi pengujian dapat menghasilkan laporan hasil pengujian yang dijalankan dari keluaran JUnit. File log pengujian deqp dapat dikonversi ke format keluaran JUnit menggunakan alat testlog-to-junit.

Alat tersebut saat ini hanya mendukung penerjemahan putusan kasus uji. 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.

Gunakan kelompok tes khusus

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

Tes stres alokasi memori

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

Pada platform tertentu, seperti Android dan sebagian besar varian Linux, hal berikut dapat terjadi: Sistem operasi mungkin 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 pengujian tersebut secara manual untuk memeriksa apakah sistem berperilaku benar di bawah tekanan sumber daya. Namun, dalam situasi seperti ini, kegagalan proses pengujian harus diartikan sebagai kelulusan.

Kelompok uji

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

Tes stres rendering yang berjalan lama

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

Kelompok uji

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