drawElements Quality Program testi

Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

AOSP, https://android.googlesource.com/platform/external/deqp adresindeki drawElements Quality Program (deqp) GPU test paketini içerir. Bu sayfada, deqp test paketinin yeni bir ortama nasıl dağıtılacağı ayrıntılı olarak açıklanmaktadır.

Gönderilen en son kodla çalışmak için deqp-dev şubesini kullanın. Belirli bir Android CTS sürümüyle eşleşen kod için release-code-name-release şubesini kullanın (ör. Android 6.0 için marshmallow-release şubesini kullanın).

Kaynak düzeni

deqp test modüllerinin ve destekleyici kitaplıkların kaynak kodu düzeni aşağıdaki tabloda gösterilmektedir (listeleme kapsamlı değildir ancak en önemli dizinleri vurgulamaktadır).

Açık kaynak bileşenler

deqp, libpng ve zlib dosyalarını kullanır. Bu dosyalar, platform/external/deqp/external/fetch_sources.py komut dosyası kullanılarak veya platform/external/[libpng,zlib] adresinden git aracılığıyla getirilebilir.

Test programları oluşturma

Test çerçevesi, taşınabilirlik göz önünde bulundurularak tasarlanmıştır. Tek zorunlu şart, tam C++ desteği ve G/Ç, iş parçacığı ve soket için standart sistem kitaplıklarıdır.

CMake derleme sistemi

deqp kaynaklarında, test programlarını derlemek için tercih edilen araç olan CMake için derleme komut dosyaları bulunur.

CMake, birden fazla platformu ve araç zincirini destekleyen açık kaynaklı bir derleme sistemidir. CMake, hedefe bağımsız yapılandırma dosyalarından yerel makefile'ler veya IDE proje dosyaları oluşturur. CMake hakkında daha fazla bilgi için lütfen CMake belgelerine bakın.

CMake, kaynak ağacı dışında derlemeleri destekler ve önerir. Yani, her zaman kaynak ağacının dışında ayrı bir derleme dizininde makefile'ler veya proje dosyaları oluşturmanız gerekir. CMake'de herhangi bir "distclean" hedefi yoktur. Bu nedenle, CMake tarafından oluşturulan dosyaların kaldırılması manuel olarak yapılmalıdır.

Yapılandırma seçenekleri, -DOPTION_NAME=VALUE sentaksı kullanılarak CMake'e verilir. deqp için yaygın olarak kullanılan bazı seçenekler aşağıda listelenmiştir.

Hedef derleme dosyası oluşturma

deqp derleme sistemi, hedef derleme dosyaları kullanılarak yeni hedefler için yapılandırılır. Hedef derleme dosyası, platformun hangi özellikleri desteklediğini ve hangi kitaplıkların veya ek dahil etme yollarının gerekli olduğunu tanımlar. Hedef dosya adları targets/NAME/NAME.cmake biçimini izler ve hedef, DEQP_TARGET derleme parametresi kullanılarak seçilir.

Hedef dosyalardaki dosya yolları, targets/NAME dizine değil, temel deqp dizine göredir. Aşağıdaki standart değişkenler hedef derleme dosyasına göre ayarlanabilir.

Hedef derleme dosyası, include_directories() ve link_directories() CMake işlevlerini kullanarak ek dahil etme veya bağlantı yolları ekleyebilir.

Win32 derlemesi

Windows için deqp modüllerini derlemenin en kolay yolu CMake derleme sistemini kullanmaktır. CMake 2.6.12 veya daha yeni bir sürüme ve Microsoft Visual C/C++ derleyicisine ihtiyacınız vardır. deqp, Visual Studio 2013 ile test edilmiştir.

Visual Studio proje dosyaları aşağıdaki komutla oluşturulabilir:

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

Derleme oluşturucu olarak "Visual Studio VERSION Win64" seçilerek 64 bit derleme yapılabilir:

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

Derleme türü (-DCMAKE_BUILD_TYPE="Debug" veya "Release") ile birlikte -G "NMake Makefiles" seçeneğini kullanarak da NMake makefile'leri oluşturabilirsiniz.

Oluşturma bağlamı oluşturma

Oluşturma bağlamı, Windows'ta WGL veya EGL ile oluşturulabilir.

WGL desteği

Yalnızca standart kitaplıklar gerektirdiğinden tüm Win32 ikili dosyaları, WGL ile GL bağlamı oluşturmayı destekler. WGL bağlamı, --deqp-gl-context-type=wgl komut satırı bağımsız değişkeni kullanılarak seçilebilir. WGL modunda deqp, OpenGL ES bağlamları oluşturmak için WGL_EXT_create_context_es_profile uzantılarını kullanır. Bu, NVIDIA ve Intel'in en son sürücüleriyle çalıştığı test edilmiştir. AMD sürücüleri, gerekli uzantıyı desteklemiyor.

EGL desteği

DEQP_SUPPORT_EGL AÇIK ise deqp, Windows'ta EGL için dinamik yüklemeyle oluşturulur. Bu, çoğu hedefte varsayılan ayardır. Ardından, ana makinede EGL kitaplıkları varsa komut satırı parametresi ile bunlarla test çalıştırılabilir: --deqp-gl-context-type=egl

Android derlemesi

Android derlemesi, yerel test kodunu derlemek için CMake derleme komut dosyalarını kullanır. Java parçaları (ör. Test Çalıştırma Sunucusu ve Test Uygulama Stub'u) standart Android derleme araçları kullanılarak derlenir.

Android için deqp test programlarını sağlanan derleme komut dosyalarıyla derlemek üzere şunları yapmanız gerekir:

• Android NDK'nın en son sürümü; android/scripts/common.py dosyası gerekli sürümü listeler
• API 13, SDK Tools, SDK Platform-tools ve SDK Build-tools paketlerinin yüklü olduğu Android bağımsız SDK'sı
• Apache Ant 1.9.4 (Java kod derlemesi için gereklidir)
• CMake 2.8.12 veya daha yeni bir sürüm
• 2.x serisinde Python 2.6 veya daha yeni sürümler; Python 3.x desteklenmez
• Windows için: PATH'de NMake veya JOM
  • JOM daha hızlı derlemeler sağlar
• İsteğe bağlı: Ninja make, Linux'ta da desteklenir.

Ant ve SDK ikili dosyaları, belirli geçersiz kılma varsayılanlarıyla PATH ortam değişkenine göre bulunur. Mantık android/scripts/common.py tarafından kontrol edilir.

NDK dizini ~/android-ndk-VERSION veya C:/android/android-ndk-VERSION olmalıdır ya da ANDROID_NDK_PATH ortam değişkeni üzerinden tanımlanmalıdır.

Deqp cihaz üzerinde bileşenleri, test yürütme hizmeti ve test programları android/scripts/build.py komut dosyası çalıştırılarak oluşturulur. Nihai .apk dosyası android/package/bin içinde oluşturulur ve install.py komut dosyası tarafından yüklenebilir. Komut satırı yürütücü kullanılıyorsa ExecService, ADB aracılığıyla cihazda launch.py komut dosyasıyla başlatılır. Komut dosyaları herhangi bir dizinden çalıştırılabilir.

Linux derlemesi

Test ikili dosyaları ve komut satırı yardımcı programları, CMake kullanılarak makefile'ler oluşturularak Linux için derlenebilir. Linux için derleme yaparken faydalı olan birden fazla önceden tanımlanmış derleme hedefi vardır.

Derleme türünü tanımlamak için her zaman -DCMAKE_BUILD_TYPE=<Debug|Release> kullanın. Release iyi bir varsayılan değerdir. Bu olmadan, varsayılan, optimize edilmemiş bir sürüm derlemesi oluşturulur.

-DCMAKE_C_FLAGS ve -DCMAKE_CXX_FLAGS komut satırı bağımsız değişkenleri, derleyiciye ek bağımsız değişkenler iletmek için kullanılabilir. Örneğin, 32 bit veya 64 bit derleme, sırasıyla -DCMAKE_C(XX)_FLAGS="-m32" veya "-m64" ayarlanarak yapılabilir. Belirtilmezse 64 bit araç zincirinde genellikle 64 bit olan araç zinciri yerel mimarisi kullanılır.

-DCMAKE_LIBRARY_PATH ve -DCMAKE_INCLUDE_PATH bağımsız değişkenleri, CMake'in ek kitaplık vermesi veya arama yolları eklemesi için kullanılabilir.

Özel bir konumdaki sürücü üstbilgileri ve kitaplıkları için 32 bit hata ayıklama derlemesi yapmak üzere kullanılan tam komut satırı örneği aşağıda verilmiştir:

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

Çapraz derleme

Çapraz derleme, CMake araç zinciri dosyası kullanılarak yapılabilir. Araç zinciri dosyası, kitaplıklar ve başlıklar için özel arama yollarının yanı sıra kullanılacak derleyiciyi belirtir. Yaygın senaryolar için çeşitli araç zinciri dosyaları, framework/delibs/cmake dizininde bulunan sürüm paketine dahil edilmiştir.

Standart CMake değişkenlerine ek olarak, aşağıdaki deqp'ye özgü değişkenler de araç zinciri dosyası tarafından ayarlanabilir. CMake genellikle DE_OS, DE_COMPILER ve DE_PTR_SIZE öğelerini doğru şekilde algılayabilir ancak DE_CPU, araç zinciri dosyası tarafından ayarlanmalıdır.

Araç zinciri dosyası, CMAKE_TOOLCHAIN_FILE derleme parametresi kullanılarak seçilebilir. Örneğin, aşağıdaki komut ARM/Linux için CodeSourcery çapraz derleyicisini kullanarak bir derleme için makefile'ler oluşturur:

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

GLES ve EGL kitaplıklarının çalışma zamanında bağlanması

deqp, bağlantı sırasında test edilen API'nin giriş noktalarına ihtiyaç duymaz. Test kodu, API'lere her zaman işlev işaretçileri aracılığıyla erişir. Giriş noktaları daha sonra çalışma zamanında dinamik olarak yüklenebilir veya platform bağlantı noktası bunları bağlantı sırasında sağlayabilir.

Derleme ayarlarında bir API desteği etkinleştirilirse ve bağlantı kitaplıkları sağlanmazsa deqp, gerekli giriş noktalarını çalışma zamanında yükler. Statik bağlantı kullanılacaksa DEQP_<API>_LIBRARIESmake configuration değişkeninde gerekli bağlantı kitaplıklarını sağlayın.

Test çerçevesini taşıma

deqp'yi taşımak üç adımdan oluşur: temel taşınabilirlik kitaplıklarını uyarlama, test çerçevesi platform entegrasyon arayüzlerini uygulama ve yürütme hizmetini taşıma.

Aşağıdaki tabloda, olası taşıma değişikliklerinin bulunduğu konumlar listelenmiştir. Bunların dışındaki her şey muhtemelen egzotiktir.

Temel taşınabilirlik kitaplıkları

Temel taşınabilirlik kitaplıkları Windows, çoğu Linux varyantı, Mac OS, iOS ve Android'i zaten desteklemektedir. Test hedefi bu işletim sistemlerinden birinde çalışıyorsa büyük olasılıkla temel taşınabilirlik kitaplıklarına dokunmanız gerekmez.

Test çerçevesi platform bağlantı noktası

deqp test çerçevesi platform bağlantı noktası için iki bileşen gerekir: Bir uygulama giriş noktası ve platform arayüzü uygulaması.

Uygulama giriş noktası, platform nesnesini oluşturmaktan, komut satırı (tcu::CommandLine) nesnesi oluşturmaktan, test günlüğünü (tcu::TestLog) açmaktan ve test uygulamasını (tcu::App) iterasyondan sorumludur. Hedef işletim sistemi standart bir main() giriş noktasını destekliyorsa giriş noktası uygulaması olarak tcuMain.cpp kullanılabilir.

deqp platform API'si aşağıdaki dosyalarda ayrıntılı olarak açıklanmıştır.

Tüm platform bağlantı noktaları için temel sınıf tcu::Platform'tür. Platform bağlantı noktası isteğe bağlı olarak GL ve EGL'ye özgü arayüzleri destekleyebilir. Testleri çalıştırmak için uygulanması gerekenlere genel bakış için aşağıdaki tabloya bakın.

Platform bağlantı noktalarını uygulamayla ilgili ayrıntılı talimatlar, taşıma katmanı başlıklarında yer alır.

Test yürütme hizmeti

deqp test yürütme altyapısını veya komut satırı yürütücüsünü kullanmak için hedefte test yürütme hizmetinin kullanılabilir olması gerekir. Hizmetin taşınabilir bir C++ uygulaması execserver dizininde sağlanır. Bağımsız ikili, PC hedefleri için deqp test modülü derlemesinin bir parçası olarak oluşturulur. Diğer hedeflerde derlemeyi etkinleştirmek için execserver/CMakeLists.txt değerini değiştirebilirsiniz.

Test yürütme hizmetinin C++ sürümü iki komut satırı parametresini kabul eder:

• --port=<port>, sunucunun dinlediği TCP bağlantı noktasını ayarlar. Varsayılan değer 50016'dır.
• --single, istemci bağlantısını kestikten sonra sunucu işlemini sonlandırır. Varsayılan olarak sunucu işlemi, daha fazla test yürütme isteği sunmak için açık kalır.

Testleri çalıştırma

Bu sayfada, Linux ve Windows ortamlarında deqp testlerini çalıştırma, komut satırı bağımsız değişkenlerini kullanma ve Android uygulama paketiyle çalışma talimatları verilmiştir.

Linux ve Windows ortamları

Aşağıdaki dosya ve dizinleri hedefe kopyalayarak başlayın.

Yürütme hizmetini ve test ikililerini hedef dosya sisteminin herhangi bir yerine dağıtabilirsiniz. Ancak test ikilileri, mevcut çalışma dizininde veri dizinleri bulmayı bekler. Hazır olduğunuzda hedef cihazda Test Yürütme Hizmeti'ni başlatın. Hizmeti başlatma hakkında ayrıntılı bilgi için Test yürütme hizmetini inceleyin.

Komut satırı bağımsız değişkenleri

Aşağıdaki tabloda, tüm test programlarının yürütülmesini etkileyen komut satırı bağımsız değişkenleri listelenmiştir.

GLES2 ve GLES3'e özgü bağımsız değişkenler

Test durumu listesi biçimi

Test kaydı listesi iki biçimde verilebilir. İlk seçenek, her testin tam adını standart bir ASCII dosyasında ayrı bir satırda listelemek olacaktır. Test grupları büyüdükçe tekrarlanan ön ekler can sıkıcı olabilir. Önekleri tekrarlamayı önlemek için aşağıda gösterilen bir Trie (ön ek ağacı olarak da bilinir) söz dizimini kullanın.

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

Örnek:

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

Bu, aşağıdaki iki test senaryosuna dönüşür:

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

Android

Android uygulama paketi, test yürütme hizmeti, test ikili dosyaları ve veri dosyaları dahil olmak üzere gerekli tüm bileşenleri içerir. Test etkinliği, EGL kullanan bir NativeActivity'tir (Android 3.2 veya daha yeni sürümler gerekir).

Uygulama paketi aşağıdaki komutla yüklenebilir (gösterilen ad, Android CTS paketindeki APK'nın adıdır; bu ad derlemeye bağlıdır):

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

Test yürütme hizmetini başlatmak ve bağlantı noktası yönlendirmeyi ayarlamak için aşağıdakileri kullanın:

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

Hata ayıklama yazdırmaları, testleri başlatmadan önce aşağıdakiler uygulanarak etkinleştirilebilir:

adb –d shell setprop log.tag.dEQP DEBUG

Android CTS olmadan Android'de test çalıştırma

Test yürütme etkinliğini manuel olarak başlatmak için android.app.NativeActivity'ü hedefleyen bir Android intent'i oluşturun. Etkinlikler com.drawelements.deqp paketinde bulunabilir. Komut satırı, Intent'te "cmdLine" anahtarıyla birlikte ek bir dize olarak sağlanmalıdır.

/sdcard/dEQP-log.qpa adresine bir test günlüğü yazılır. Test çalışması normal şekilde başlamazsa cihaz günlükünde ek hata ayıklama bilgileri bulunur.

am yardımcı programını kullanarak komut satırından etkinlik başlatabilirsiniz. Örneğin, NativeActivity,'ü destekleyen bir platformda dEQP-GLES2.info testleri çalıştırmak için aşağıdaki komutları kullanın.

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

Android'de hata ayıklama

Android'de GDB hata ayıklayıcısı altında testleri çalıştırmak için önce aşağıdaki iki komut dosyasını çalıştırarak hata ayıklama derlemesini derleyin ve yükleyin:

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

Hata ayıklama derlemesi cihaza yüklendikten sonra, ana makinede çalışan GDB altında testleri başlatmak için aşağıdaki komutu çalıştırın:

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

deqp komut satırı, çalıştırılacak test durumlarına ve diğer gerekli parametrelere bağlıdır. Komut dosyası, deqp yürütmesinin başına varsayılan bir kesme noktası ekler (tcu::App::App).

debug.py komut dosyası, hata ayıklama için kesme noktaları ayarlama, gdbserver bağlantı parametreleri ve hata ayıklama için ek ikili dosyaların yolları gibi işlemler için birden fazla komut satırı bağımsız değişkeni kabul eder (tüm bağımsız değişkenler ve açıklamalar için debug.py --help kullanın). Komut dosyası, simge girişlerini almak için hedef cihazdaki bazı varsayılan kitaplıkları da kopyalar.

Sürücü kodunda adım adım ilerlemek için (ör. GDB'nin tam hata ayıklama bilgileriyle ikili dosyaların konumlarını bilmesi gerektiğinde) debug.py komut satırı parametreleri aracılığıyla daha fazla kitaplık ekleyin. Bu komut dosyası, komut dosyası 132. satırından itibaren GDB için bir yapılandırma dosyası yazar. İkili dosyalar vb. için ek yollar sağlayabilirsiniz ancak doğru komut satırı parametrelerini sağlamak yeterli olacaktır.

Not: Windows'ta GDB ikili dosyası için libpython2.7.dll gerekir. debug.py'ü başlatmadan önce PATH değişkenine <path-to-ndk>/prebuilt/windows/bin ekleyin.

Not: Yerel kod hata ayıklama, stok Android 4.3'te çalışmaz. Geçici çözümler için bu herkese açık hataya bakın. Android 4.4 ve sonraki sürümlerde bu hata yoktur.

Testleri otomatikleştirme

Deqp test modülleri, otomatik test sistemlerine birden fazla şekilde entegre edilebilir. En iyi yaklaşım, mevcut test altyapısına ve hedef ortama bağlıdır.

Test çalıştırmasının birincil çıktısı her zaman test günlük dosyasıdır (.qpa son eki içeren dosya). Test günlüğünden test sonuçlarının tamamı ayrıştırılabilir. Konsol çıkışı yalnızca hata ayıklama bilgileridir ve tüm platformlarda kullanılamayabilir.

Test ikili dosyaları doğrudan bir test otomasyonu sisteminden çağrılabilir. Test ikili dosyası, belirli bir durum, test grubu veya mevcut tüm testler için başlatılabilir. Yürütme sırasında önemli bir hata (ör. belirli API hataları veya kilitlenme) oluşursa test yürütme işlemi iptal edilir. Geriye dönük test için en iyi yaklaşım, ciddi bir hata durumunda bile kısmi sonuçlara sahip olmak amacıyla test ikililerini ayrı ayrı test durumları veya küçük test grupları için ayrı ayrı çağırmaktır.

deqp, daha güçlü bir entegrasyon elde etmek için yürütme hizmetiyle birlikte kullanılabilecek komut satırı test yürütme araçlarıyla birlikte gelir. Yürütücü, test sürecinin sona erdiğini algılar ve test yürütmeyi bir sonraki kullanılabilir durumda devam ettirir. Test oturumunun tamamı tek bir günlük dosyasında saklanır. Bu kurulum, kilitlenme kurtarma olanağı sunmayan hafif test sistemleri için idealdir.

Komut satırı test yürütme araçları

Mevcut komut satırı araç seti; uzak test yürütme aracı, regresyon analizi için test günlüğü karşılaştırma oluşturucu, test günlüğünü CSV'ye dönüştürücü, test günlüğünü XML'e dönüştürücü ve test günlüğünü JUnit'e dönüştürücü içerir.

Bu araçların kaynak kodu executor dizininde, ikili dosyaları ise <builddir>/executor dizininde bulunur.

Komut satırı test yürütücüsü

Komut satırı test yürütücüsü, bir cihazda test çalıştırması başlatmak ve elde edilen günlükleri TCP/IP üzerinden toplamak için kullanılan taşınabilir bir C++ aracıdır. Yürütücü, hedef cihazdaki yürütme hizmetiyle (execserver) iletişim kurar. Bunlar birlikte, test işlemi kilitlenmelerinden kurtarma gibi işlevler sağlar. Aşağıdaki örneklerde, komut satırı Test Yürütücüsünün nasıl kullanılacağı gösterilmektedir (daha fazla bilgi için --help kullanın):

1. örnek: Android cihazda GLES2 işlevsel testleri çalıştırma

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"

2. örnek: Kısmi OpenGL ES 2 test çalıştırmasına yerel olarak devam etme

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

Test günlüğü CSV'sini dışa aktarma ve karşılaştırma

deqp'de test günlüklerini (.qpa dosyaları) CSV dosyalarına dönüştüren bir araç bulunur. CSV çıkışı, test senaryolarının ve sonuçlarının listesini içerir. Araç, iki veya daha fazla toplu sonucu da karşılaştırabilir ve yalnızca giriş toplu sonuçlarında farklı durum kodlarına sahip test durumlarını listeleyebilir. Karşılaştırmada, eşleşen destek kayıtlarının sayısı da yazdırılır.

CSV biçimindeki çıkış, standart komut satırı yardımcı programları veya e-tablo düzenleyiciyle daha fazla işlem yapmak için çok kullanışlıdır. Aşağıdaki komut satırı bağımsız değişkeni kullanılarak kullanıcı tarafından okunabilen ek bir düz metin biçimi seçilebilir: --format=text

1. Örnek: Test günlüğünü CSV biçiminde dışa aktarma

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

2. örnek: İki test günlüğü arasındaki test sonuçlarının farklılıklarını listeleme

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

Not: --value=code bağımsız değişkeni, test sonucu kodunu (ör. "Başarılı" veya "Başarısız") döndürür. --value=details bağımsız değişkeni, performans, özellik veya doğruluk testi tarafından üretilen sonucun veya sayısal değerin daha ayrıntılı açıklamasını seçer.

Test günlüğü XML dışa aktarma

Test günlük dosyaları, testlog-to-xml yardımcı programı kullanılarak geçerli XML dokümanlarına dönüştürülebilir. İki çıkış modu desteklenir:

• Her test senaryosunun ve caselist.xml özet dokümanının bir hedef dizine yazıldığı ayrı dokümanlar modu
• .qpa dosyasındaki tüm sonuçların tek bir XML belgesine yazıldığı tek dosya modu.

Dışa aktarılan test günlük dosyaları, XML stil sayfası kullanılarak tarayıcıda görüntülenebilir. Örnek stil sayfası dokümanları (testlog.xsl ve testlog.css), doc/testlog-stylesheet dizininde sağlanır. Günlük dosyalarını bir tarayıcıda oluşturmak için iki stil sayfası dosyasını, dışa aktarılan XML belgelerinin bulunduğu dizin içine kopyalayın.

Google Chrome kullanıyorsanız Chrome, güvenlik nedeniyle yerel dosya erişimini sınırlandırdığından dosyalara HTTP üzerinden erişilmelidir. Standart Python kurulumu, python –m SimpleHTTPServer 8000 komutuyla geçerli dizini sunmak için başlatılabilen temel bir HTTP sunucusu içerir. Sunucuyu başlattıktan sonra Chrome tarayıcıyı http://localhost:8000 konumuna getirerek test günlüğünü görüntüleyebilirsiniz.

JUnit test günlüğüne dönüştürme

Birçok test otomasyon sistemi, JUnit çıkışından test çalıştırma sonucu raporları oluşturabilir. deqp test günlük dosyaları, testlog-to-junit aracı kullanılarak JUnit çıkış biçimine dönüştürülebilir.

Araç şu anda yalnızca test kaydı sonucunun çevrilmesini desteklemektedir. JUnit yalnızca "geçti" ve "geçmedi" sonuçlarını desteklediğinden, deqp'nin başarılı sonucu "JUnit geçti" ile eşlenir ve diğer sonuçlar başarısızlık olarak kabul edilir. Orijinal deqp sonuç kodu JUnit çıkışında bulunur. Günlük mesajları ve sonuç resimleri gibi diğer veriler dönüşümde korunmaz.

Özel test gruplarını kullanma

Bazı test grupları için özel komut satırı seçenekleri gerekebilir veya desteklenebilir ya da belirli sistemlerde kullanılırken özel dikkat gösterilmesi gerekebilir.

Bellek ayırma stres testleri

Bellek ayırma stres testleri, sürücü bellek yetersizliği hatası bildirene kadar belirli kaynakları tekrar tekrar ayırarak bellek yetersizliği koşullarını uygular.

Android ve çoğu Linux varyantı gibi belirli platformlarda aşağıdakiler gerçekleşebilir: İşletim sistemi, sürücünün bellek sorununu ele almasına izin vermek veya başka bir şekilde bellek sorunu hatası göstermek yerine test sürecini sonlandırabilir. Bu tür platformlarda, bellek yetersizliği hatalarına neden olacak şekilde tasarlanmış testler varsayılan olarak devre dışıdır ve --deqp-test-oom=enable komut satırı bağımsız değişkeni kullanılarak etkinleştirilmelidir. Sistemin kaynak baskısı altında doğru şekilde çalışıp çalışmadığını kontrol etmek için bu tür testleri manuel olarak çalıştırmanız önerilir. Ancak böyle bir durumda, test işlemi kilitlenmesi geçiş olarak yorumlanmalıdır.

Test grupları

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

Uzun süreli oluşturma stres testleri

Oluşturma stres testleri, sürekli oluşturma yükü altındaki sağlamlık sorunlarını ortaya çıkarmak için tasarlanmıştır. Varsayılan olarak testler yalnızca birkaç iterasyon yürütür ancak --deqp-test-iteration-count=-1komut satırı bağımsız değişkeni sağlanarak süresiz olarak çalışacak şekilde yapılandırılabilir. Bu testler uzun süre çalıştırıldığında test gözetmeni devre dışı bırakılmalıdır (--deqp-watchdog=disable).

Test grupları

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