Bu sayfa, Cloud Translation API ile çevrilmiştir.

PaintElements Kalite Programı testi

AOSP, şuradadrawElements Kalite Programı (deqp) GPU test paketini içerir: https://android.googlesource.com/platform/external/deqp adresini ziyaret edin. Bu sayfada, deqp test paketinin yeni bir ortama nasıl dağıtılacağı açıklanmaktadır.

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

Kaynak düzeni

deqp test modüllerinin ve destekleyici kitaplıkların kaynak kodu düzeni aşağıdaki tabloda gösterilmiştir (liste, kapsamlı olmasa da en önemli dizinleri içerir).

Dizin	Açıklama
`android`	Android test kullanıcısı kaynakları ve derleme komut dosyalarını
`data`	Test verisi dosyaları
`modules`	Test modülü kaynakları
`modules/egl`	EGL modülü
`modules/gles2`	GLES2 modülü
`modules/gles3`	GLES3 modülü
`modules/gles31`	GLES3.1 modülü
`modules/gles32`	GLES3.2 modülü
`targets`	Hedefe özel derleme yapılandırma dosyaları
`framework`	deqp test modülü çerçevesi ve yardımcı programları
`framework/delibs`	Temel taşınabilirlik ve derleme kitaplıkları
`framework/platform`	Platform bağlantı noktaları
`framework/qphelper`	Test programı entegrasyon kitaplığı (C)
`framework/common`	Deqp çerçevesi (C++)
`framework/opengl, framework/egl`	API'ye özel yardımcı programlar
`execserver`	Cihaz tarafı ExecServer kaynağı
`executor`	Ana makine tarafı test yürütücü kabuğu aracı ve yardımcı programlar
`external`	Harici libpng ve zlib için saplama dizini oluşturun

Açık kaynak bileşenleri

Deqp, getirilebilecek libpng ve zlib değerini kullanır komut dosyasını kullanarak platform/external/deqp/external/fetch_sources.py veya git aracılığıyla kalkış: platform/external/[libpng,zlib].

Test programları oluşturma

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

CMake derleme sistemi

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

CMake, birden fazla platformu destekleyen açık kaynak bir derleme sistemidir. araç zincirleri olarak düşünebilirsiniz. CMake, yerel oluşturma dosyalarını veya IDE proje dosyalarını şuradan oluşturur: hedeften bağımsız yapılandırma dosyaları. CMake hakkında daha fazla bilgi için lütfen CMake belgeleri.

CMake, kaynak dışı ağaç derlemelerini destekler ve önerir. Diğer bir deyişle, oluşturma dosyalarını veya proje dosyalarını her zaman ayrı bir derleme dizininde oluşturun bulunur. CMake'de herhangi bir "distclean" değeri yoktur. hedef, o yüzden CMake tarafından oluşturulan tüm dosyaların kaldırılması manuel olarak yapılmalıdır.

Yapılandırma seçenekleri CMake'e -DOPTION_NAME=VALUE kullanılarak verilir söz dizimine uygun olmalıdır. Deqp için yaygın olarak kullanılan bazı seçenekler aşağıda listelenmiştir.

Yapılandırma seçeneği Açıklama

Yapılandırma seçeneği	Açıklama
`DEQP_TARGET`	Hedef ad, ör. "android" deqp CMake komut dosyaları, dosyayı `targets/DEQP_TARGET/DEQP_TARGET.cmake` ve yakında farklı derleme seçeneklerini göreceksiniz.
`CMAKE_TOOLCHAIN_FILE`	CMake için araç zinciri dosyasının yolu. Çapraz derleme için kullanılır.
`CMAKE_BUILD_TYPE`	Makefile hedefleri için derleme türü. Geçerli değerler şunlardır: "Hata ayıkla" ve "Release" (Serbest) Yorumlama ve varsayılan türün hedeflenen derleme sistemine bağlı olduğunu unutmayın. Ayrıntılar için CMake belgelerine bakın.

DEQP_TARGET

Hedef ad, ör. "android"

deqp CMake komut dosyaları, dosyayı targets/DEQP_TARGET/DEQP_TARGET.cmake ve yakında farklı derleme seçeneklerini göreceksiniz.

CMAKE_TOOLCHAIN_FILE

CMake için araç zinciri dosyasının yolu. Çapraz derleme için kullanılır.

CMAKE_BUILD_TYPE

Makefile hedefleri için derleme türü. Geçerli değerler şunlardır: "Hata ayıkla" ve "Release" (Serbest)

Yorumlama ve varsayılan türün hedeflenen derleme sistemine bağlı olduğunu unutmayın. Ayrıntılar için CMake belgelerine bakın.

Hedef derleme dosyası oluşturma

deqp derleme sistemi, hedef derleme dosyalarını kullanan yeni hedefler için yapılandırılır. Hedef derleme dosyası, platformun hangi özellikleri desteklediğini ve hangi kitaplıkların veya daha fazla dahil etme yolu gerekiyor. Hedef dosya adları targets/NAME/NAME.cmake kullanır biçimi belirlenir ve hedef, DEQP_TARGET derleme parametresi kullanılarak seçilir.

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

Değişken	Açıklama
`DEQP_TARGET_NAME`	Hedef adı (test günlüklerine eklenecek)
`DEQP_SUPPORT_GLES2`	GLES2'nin desteklenip desteklenmediği (varsayılan: KAPALI)
`DEQP_GLES2_LIBRARIES`	GLES2 kitaplıkları (desteklenmiyorsa veya dinamik yükleme kullanılıyorsa boş bırakın)
`DEQP_SUPPORT_GLES3`	GLES3.x'in desteklenip desteklenmediği (varsayılan: KAPALI)
`DEQP_GLES3_LIBRARIES`	GLES3.x kitaplıkları (desteklenmiyorsa veya dinamik yükleme kullanılıyorsa boş bırakın)
`DEQP_SUPPORT_VG`	OpenVG'nin desteklenip desteklenmediği (varsayılan: KAPALI)
`DEQP_OPENVG_LIBRARIES`	OpenVG kitaplıkları (desteklenmiyorsa veya dinamik yükleme kullanılıyorsa boş bırakın)
`DEQP_SUPPORT_EGL`	EGL'nin desteklenip desteklenmediği (varsayılan: KAPALI)
`DEQP_EGL_LIBRARIES`	EGL kitaplıkları (desteklenmiyorsa veya dinamik yükleme kullanılıyorsa boş bırakın)
`DEQP_PLATFORM_LIBRARIES`	Bağlantı oluşturmak için platforma özel ek kitaplıklar gerekiyor
`DEQP_PLATFORM_COPY_LIBRARIES`	Her test ikili programı derleme dizinine kopyalanan kitaplıkların listesi. Olabilir testleri çalıştırmak için gerekli olan ancak varsayılan olmayan kitaplıkları kopyalamak amacıyla kullanılır anlamına gelir.
`TCUTIL_PLATFORM_SRCS`	Platform bağlantı noktası kaynak listesi. Varsayılan kaynaklar, özellikleri ve işletim sistemi. Not: Yollar, `framework/platform` ile görelidir.

Hedef derleme dosyası, include_directories() ve link_directories() CMake işlevleri.

Win32 derlemesi

Windows için deqp modülleri oluşturmanın en kolay yolu CMake derlemesini kullanmaktır bahsedeceğim. CMake 2.6.12 veya daha yeni bir sürümüne ve Microsoft Visual C/C++ derleyici olarak da adlandırılı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"

"Visual Studio VERSION Win64" seçilerek 64 bit derleme yapılabilir. ilk adımıdır oluşturucu:

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

-G "NMake Makefiles" seçeneğiyle NMake dosyaları da oluşturabilirsiniz olarak değiştirin (-DCMAKE_BUILD_TYPE="Debug" veya "Release").

Bağlam oluşturma

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

WGL desteği

Tüm Win32 ikili programları, yalnızca gerekli olduğu için WGL ile GL bağlamı oluşturmayı destekler standart kitaplıklar var. WGL bağlamı, --deqp-gl-context-type=wgl kullanılarak seçilebilir komut satırı bağımsız değişkeni. WGL modunda, deqp WGL_EXT_create_context_es_profile kullanır uzantısına sahiptir. Bu test, en yeni NVIDIA ve Intel sürücülerini kullanıyor. AMD sürücüleri, uzantısına sahip olur.

EGL desteği

Deqp, Windows'da EGL için dinamik yükleme ile oluşturulur (DEQP_SUPPORT_EGL) AÇIK. Bu, çoğu hedef için varsayılan değerdir. Bu durumda, ana makinede EGL kitaplıkları komut satırını kullanarak bunlarla testler yapmak parametre: --deqp-gl-context-type=egl

Android derlemesi

Android derlemesi, yerel test kodunu oluşturmak için CMake derleme komut dosyalarını kullanır. Test Yürütme Sunucusu ve Test Uygulaması Stub gibi Java parçaları standart Android derleme araçları kullanılarak derlendi.

Sağlanan derlemeyle Android için deqp test programlarını derlemek ihtiyacınız olacak:

En son sürümü Android NDK; android/scripts/common.py dosyasında gerekli sürüm listeleniyor
API 13, SDK Araçları, SDK Platform araçları ve SDK ile Android bağımsız SDK'sı Yüklü derleme araçları paketleri
Apache Karınca 1.9.4 (Java kodu 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 desteklenmiyor
Windows için: PATH dilinde NMake veya JOM
- JOM daha hızlı derlemelere olanak tanır
İsteğe bağlı: Ninja markası Linux'ta da desteklenir

Ant ve SDK ikili programları, PATH ortam değişkenine göre varsayılan değerler oluşturabilirsiniz. Mantık, android/scripts/common.py tarafından kontrol ediliyor.

NDK dizini ~/android-ndk-VERSION veya C:/android/android-ndk-VERSION veya ANDROID_NDK_PATH aracılığıyla tanımlanmıştır ortam değişkeni

Cihaz üzerindeki bileşenlerin, test yürütme hizmetinin ve test programlarının android/scripts/build.py komut dosyası yürütülerek oluşturulur. Nihai .apk şurada oluşturulur: android/package/bin ve install.py komut dosyası tarafından yüklenebilir. Öğe komut satırı yürütücü kullanıldığında, ExecService başlatılır cihazda ADB üzerinden launch.py komut dosyası ile. Komut dosyaları herhangi bir dizinden yürütülebilir.

Linux derlemesi

CMake. Linux için geliştirme yaparken kullanışlı olabilecek, önceden tanımlanmış birden fazla derleme hedefi vardır.

Hedef oluştur	Açıklama
`default`	Çeşitli API'lere yönelik desteği belirlemek için CMake platform iç gözlemini kullanan varsayılan hedef.
`x11_glx`	OpenGL (ES) bağlamları oluşturmak için GLX'i kullanır.
`x11_egl`	OpenGL (ES) bağlamları oluşturmak için EGL'yi kullanır.
`x11_egl_glx`	X11 ile hem GLX hem de EGL'yi destekler.

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 ekstra bağımsız değişkenler iletmek için kullanılır. Örneğin, 32 bit veya 64 bit derlemesi -DCMAKE_C(XX)_FLAGS="-m32" veya "-m64" ayarlanıyor. Değilse genellikle 64 bit araç zincirinde 64 bit olan araç zinciri yerel mimarisi kullanılır.

-DCMAKE_LIBRARY_PATH ve -DCMAKE_INCLUDE_PATH bağımsız değişkenleri kullanılabilir eklemek için CMake işlevini kullanabilirsiniz.

32 bit hata ayıklama derlemesi yapmak için kullanılan tam komut satırı örneği sürücü başlıkları ve kitaplıkları aşağıdaki gibidir:

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 işlemi, bir CMake araç zinciri dosyası kullanarak gerçekleştirilebilir. Araç zinciri dosyası, kullanılacak derleyiciyi ve emin olmanız gerekir. Sık karşılaşılan senaryolara yönelik çeşitli araç zinciri dosyaları framework/delibs/cmake dizinindeki sürüm paketine eklenir.

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

Değişken	Açıklama
`DE_OS`	İşletim sistemi. Desteklenen değerler: `DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS`
`DE_COMPILER`	Derleyici türü. Desteklenen değerler: `DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG`
`DE_CPU`	CPU türü. Desteklenen değerler: `DE_CPU_ARM, DE_CPU_X86`.
`DE_PTR_SIZE`	sizeof(boş*) değeri ekler. Desteklenen değerler: 4 ve 8

Araç zinciri dosyası, CMAKE_TOOLCHAIN_FILE derleme parametresi kullanılarak seçilebilir. Örneğin, aşağıda ARM/Linux için CodeSourcery çapraz derleyici kullanılarak bir derleme için makefiles oluşturulur:

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ı bağlama

Deqp, bağlantı oluşturma sırasında test edilen API'nin giriş noktalarına ihtiyaç duymaz. İlgili içeriği oluşturmak için kullanılan test kodunun API'lere her zaman işlev işaretçileri yoluyla erişmesi gerekir. Giriş noktaları sonra dinamik olarak yüklenir veya platform bağlantı noktası bunları sağlayabilir. bağlantı zamanı.

Derleme ayarlarında API desteği etkinleştirildiyse ve bağlantı kitaplıkları sağlanmazsa deqp, çalışma zamanında gerekli giriş noktalarını yükler. Öğe statik bağlantı isteniyorsa DEQP_<API>_LIBRARIES içinde gerekli bağlantı kitaplıklarını sağlayın derleme yapılandırması değişkeni

Test çerçevesini taşıma

Deqp'nin taşınması üç adımdan oluşur: temel taşınabilirlik kitaplıklarını uyarlama, test çerçevesi platform entegrasyonu arayüzlerinin uygulanması ve yürütmenizi sağlar.

Aşağıdaki tabloda, olası taşıma değişiklikleri için konumlar listelenmiştir. Şundan daha fazlası: egzotik olma olasılıkları yüksektir.

Konum	Açıklama
`framework/delibs/debase framework/delibs/dethread framework/delibs/deutil`	İşletim sistemine özgü kodun tüm gerekli uygulamaları.
`framework/qphelper/qpCrashHandler.c`	İsteğe bağlı: İşletim sisteminiz için uygulama.
`framework/qphelper/qpWatchDog.c`	İşletim sisteminiz için uygulama. Mevcut sürüm, `dethread` ve standart C kitaplığına dayalıdır.
`framework/platform`	Yeni platform bağlantı noktası ve uygulama sapı şurada açıklandığı gibi uygulanabilir: Test çerçevesi platform bağlantı noktası.

Temel taşınabilirlik kitaplıkları

Temel taşınabilirlik kitaplıkları şu anda Windows'u, çoğu Linux varyantını, Mac OS ve ve Android'de kullanılabilir. Test hedefi bu işletim sistemlerinden birinde çalışıyorsa temel taşınabilirlik kitaplıklarına dokunmaya gerek yoktur.

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

deqp test çerçevesi platform bağlantı noktası iki bileşen gerektirir: Uygulama bir platform arayüzü uygulaması anlatacağım.

Uygulama giriş noktası, platform nesnesini oluşturmaktan sorumludur. komut satırı (tcu::CommandLine) nesnesi oluşturma, test günlüğü açma (tcu::TestLog) ve test uygulamasını yineleme (tcu::App). Öğe hedef işletim sistemi standart main() giriş noktasını destekler, tcuMain.cpp kullanılabilir giriş noktası uygulaması olarak ele alacağız.

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

Dosya	Açıklama
`framework/common/tcuPlatform.hpp`	Tüm platform bağlantı noktaları için temel sınıf
`framework/opengl/gluPlatform.hpp`	OpenGL platform arayüzü
`framework/egl/egluPlatform.hpp`	EGL platform arayüzü
`framework/platform/tcuMain.cpp`	Standart uygulama giriş noktası

Tüm platform bağlantı noktaları için temel sınıf tcu::Platform. Platform bağlantı noktası isteğe bağlı olarak GL ve EGL'ye özel arayüzleri destekler. Görüntüleyin aşağıdaki tabloda, başarılı bir proje için nelerin yapılması gerektiğine yapmanız gerekir.

Modül	Arabirim
OpenGL (ES) test modülleri	GL platformu arayüzü
EGL test modülü	EGL platform arayüzü

Platform bağlantı noktalarının uygulanmasıyla ilgili ayrıntılı talimatları şurada bulabilirsiniz: katman üstbilgilerini devre dışı bırakabilirsiniz.

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 test yürütme hizmeti hedefte kullanılabilir olmalıdır. Taşınabilir C++ hizmet uygulaması execserver dizininde sağlanır. Bağımsız ikili program, deqp test modülünün bir parçası olarak derlenir geliştirmeyi deneyin. Üzerinde bir derleme etkinleştirmek için execserver/CMakeLists.txt üzerinde değişiklik yapabilirsiniz yardımcı olur.

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

--port=<port>, sunucunun dinlediği TCP bağlantı noktasını ayarlar. Varsayılan değer 50016'dır.
--single, istemcinin bağlantısı kesildiğinde sunucu işlemini sonlandırır. Varsayılan olarak diğer test yürütme isteklerini yerine getirmek üzere çalışmaya devam eder.

Testleri yapın

Bu sayfada, Linux ve Windows'da deqp testlerini çalıştırma talimatları yer almaktadır. ortamlarda, komut satırı bağımsız değişkenlerini kullanarak ve Android ile çalışma uygulama paketinden yararlanın.

Linux ve Windows ortamları

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

Modül	Dizin	Hedef
Yürütme Sunucusu	`build/execserver/execserver`	`<dst>/execserver`
EGL Modülü	`build/modules/egl/deqp-egl`	`<dst>/deqp-egl`
GLES2 Modülü	`build/modules/gles2/deqp-gles2`	`<dst>/deqp-gles2`
GLES2 Modülü	`data/gles2`	`<dst>/gles2`
GLES3 Modülü	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
GLES3 Modülü	`data/gles3`	`<dst>/gles3`
GLES3.1 Modülü	`build/modules/gles31/deqp-gles31`	`<dst>/deqp-gles31`
GLES3.1 Modülü	`data/gles31`	`<dst>/gles31`
GLES3.2 Modülü	`build/modules/gles32/deqp-gles32`	`<dst>/deqp-gles32`
GLES3.2 Modülü	`data/gles32`	`<dst>/gles32`

Yürütme hizmetini dağıtabilir ve ikili programları hedefin herhangi bir yerinde test edebilirsiniz dosya sistemi; ancak test ikili programları mevcut çalışma dizinine ekleyin. Hazır olduğunda Test Yürütme Hizmeti'ni hedef cihaz Hizmeti başlatmayla ilgili ayrıntılar için bkz. Test etme hizmet.

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

Aşağıdaki tabloda, tüm test programlarında yer alır.

Bağımsız değişken	Açıklama
`--deqp-case=<casename>`	Belirli bir kalıpla eşleşen çalıştırma durumları. Joker karakter (*) desteklenir.
`--deqp-log-filename=<filename>`	Test sonuçlarını, adını belirttiğiniz dosyaya yazın. Test yürütme hizmeti, test başlatırken dosya adını ayarlar.
`--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>`	Durum listesini stdin'den veya belirli bir bağımsız değişkenden okuyun. Test yürütme hizmeti, bağımsız değişkeni alınan yürütme isteğine göre ayarlar. Görüntüleyin destek kaydı listesi biçiminin açıklaması için bir sonraki bölüme bakın.
`--deqp-test-iteration-count=<count>`	Belirli sayıda değişkeni destekleyen testler için yineleme sayısını geçersiz kıl iterasyonlar ile yürütüldüğü anlamına gelir.
`--deqp-base-seed=<seed>`	Rastgele hale getirme kullanan test durumları için temel başlangıç noktasıdır.

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

Aşağıdaki tabloda GLES2 ve GLES3'e özgü bağımsız değişkenler listelenmiştir.

Bağımsız değişken	Açıklama
`--deqp-gl-context-type=<type>`	OpenGL bağlam türü. Kullanılabilir bağlam türleri platforma bağlıdır. Şu tarihte: destekleyen platformlar için `egl` değeri kullanılabilir. EGL bağlamı.
`--deqp-gl-config-id=<id>`	Sağlanan GL yapılandırma kimliği için testler çalıştırın. Yorumlama olduğunu da görebilirsiniz. EGL platformunda EGL yapılandırma kimliğidir.
`--deqp-gl-config-name=<name>`	Adlandırılmış bir GL yapılandırması için testler çalıştırın. Yorumlama olduğunu da görebilirsiniz. EGL için biçim `rgb(a)<bits>d<bits>s<bits>` Örneğin, `rgb888s8` değeri, renk arabelleği RGB888'dir ve şablon arabelleği 8 bite sahiptir.
`--deqp-gl-context-flags=<flags>`	Bağlam oluşturur. `robust` veya `debug` değerini belirtin.
`--deqp-surface-width=<width> --deqp-surface-height=<height>`	Belirli bir boyutta bir yüzey oluşturmaya çalışın. Bunun için destek isteğe bağlıdır.
`--deqp-surface-type=<type>`	Belirli bir yüzey türünü ana test oluşturma hedefi olarak kullanın. Mümkün türler: `window`, `pixmap`, `pbuffer`, ve `fbo`.
`--deqp-screen-rotation=<rotation>`	Şu özelliklere sahip platformlar için: 90 derecelik artışlarla ekran yönü o yüzden ona destek olabilirim.

Test durumu liste biçimi

Test durumu listesi iki biçimde verilebilir. İlk seçenek, standart bir ASCII dosyasında ayrı bir satırda her testin tam adı yer alır. tekrarlayan önekler zahmetli olabiliyor. Tekrarlamamak için kullanıyorsanız aşağıda gösterilen bir trie (önek ağacı olarak da bilinir) söz dizimini kullanın.

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

Örnek:

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

Aşağıdaki iki test durumuna dönüştürülür:

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

Android

Android uygulama paketi, aşağıdakiler dahil gerekli tüm bileşenleri içerir: test yürütme hizmeti, test ikili programları ve veri dosyaları. Test etkinliği, EGL kullanan bir NativeActivity (Android 3.2 veya sonraki sürümü gerektirir).

Uygulama paketi şu komutla (ad: Android CTS paketindeki APK'nın adı gösterilmiştir; Bu ad, bakın):

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

Test yürütme hizmetini başlatmak ve bağlantı noktası yönlendirmeyi ayarlamak için takip etmek için:

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

Hata ayıklama baskıları, testler:

adb –d shell setprop log.tag.dEQP DEBUG

Android CTS'si olmadan Android'de testler yürütme

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

/sdcard/dEQP-log.qpa adresine bir test günlüğü yazılır. Test çalıştırıldığında normal şekilde başlamıyor, cihazda ek hata ayıklama bilgileri mevcut .

am kullanarak komut satırından bir etkinlik başlatabilirsiniz yardımcı olur. Örneğin, bir platformda dEQP-GLES2.info testleri çalıştırmak için NativeActivity, 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

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

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

Hata ayıklama derlemesi cihaza yüklendikten sonra, GDB'yi çalıştırmak için ana makinede 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ı, yürütülecek test durumlarına ve diğer gerekli parametrelerdir. Komut dosyası, deqp yürütme (tcu::App::App).

debug.py komut dosyası, hata ayıklama için kesme noktaları ayarlama, gdbserver bağlantısı gibi işlemler parametrelerini ve hata ayıklamak için ek ikili programlara giden yolları (tüm bağımsız değişkenler ve açıklamalar için debug.py --help kullanın). Komut dosyası ayrıca, hedef cihazdaki varsayılan kitaplıkları kullanın.

Sürücü kodunu adım adım uygulamak (ör. GDB'nin konumları bilmesi gerektiğinde) tam hata ayıklama bilgileri içeren ikili programların listesi) kullanıyorsanız debug.py komut satırı parametresi. Bu komut dosyası, komut dosyası dosyasının 132. satırından başlayarak GDB için yapılandırma dosyası oluşturun. Siz ikili programlar vb. için ek yollar sağlayabilir ancak doğru komutu sağlayarak yeterli olacaktır.

Not: Windows'da GDB ikili programı libpython2.7.dll. debug.py uygulamasını başlatmadan önce şunu ekleyin: PATH değişkenine <path-to-ndk>/prebuilt/windows/bin.

Not: Yerel kodda hata ayıklama işlevi stok Android 4.3; geçici çözümler için bkz. hatadan kurtardı. Android 4.4 ve sonraki sürümler bu hatayı içermez.

Testleri otomatikleştirme

Deqp test modülleri, otomatik test sistemlerine çeşitli şekillerde entegre edilebilir. En iyi yaklaşım, mevcut test altyapısına ve hedefe bahsedeceğim.

Bir test çalıştırmasının birincil çıktısı her zaman test günlük dosyasıdır (yani .qpa sonekiyle. Tam test sonuçları, test günlüğünden ayrıştırılabilir. Konsol çıkışı: tüm platformlarda kullanıma sunulmamış olabilir.

Test ikili programları, doğrudan bir test otomasyon sisteminden çağrılabilir. Test ikili program belirli bir durum, bir test kümesi veya tüm test edebilirsiniz. Yürütme sırasında önemli bir hata oluşursa (ör. belirli API'ler) hatalar veya kilitlenme varsa test işlemi iptal edilir. Regresyon testi için en iyi yaklaşım, tek durumlar veya küçük testler için test ikili programlarını çağırmaktır. olayda bile kısmi sonuçların bulunması için neden olabilir.

deqp, Google Cloud'da kullanılabilecek komut satırı testi yürütme yürütme hizmetiyle birlikte daha güçlü bir entegrasyon sağlar. Yürütücü test işleminin sonlandırıldığını tespit eder ve test yürütülmesine hazırlamış olursunuz. Tam testten tek bir günlük dosyası üretilir kabul edilir. Bu kurulum, yüksek performans sağlamayan hafif test sistemleri için idealdir. kilitlenmelerini gidermeye yardımcı olur.

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

Mevcut komut satırı aracı kümesinde bir uzaktan test yürütme aracı, bir test Regresyon analizi için günlük karşılaştırma oluşturucu, test günlüğü-CSV dönüştürücü bir test günlüğü-XML dönüştürücü ve bir testlog'dan JUnit'e dönüştürücü.

Bu araçların kaynak kodu executor dizinindedir ve ikili programlar <builddir>/executor dizininde yerleşik olarak bulunur.

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

Komut satırı test yürütücüsü, test çalıştırması başlatmak için kullanılan taşınabilir bir C++ aracıdır ve bu günlüklerin TCP/IP üzerinden toplanmasıyla ilgili bilgi ediniriz. Yürütücü hedef cihazdaki yürütme hizmetiyle (yürütücü) iletişim kurar. Birlikte, test işlemi kilitlenmelerinden kurtarma gibi işlevler sağlarlar. Aşağıdaki örnekler, Test Yürütücü komut satırının nasıl kullanılacağını gösterir (daha fazla ayrıntı için --help kullanın):

1. Örnek: Android cihazda GLES2 işlevsel testlerini ç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

Günlük CSV dosyasını dışa aktarma ve karşılaştırma

deqp, test günlüklerini (.qpa dosyaları) CSV dosyalarına dönüştürmek için bir araç içerir. CSV çıkış, test durumlarının bir listesini içerir ve sonuç. Ayrıca araç, iki veya daha fazla toplu sonucu karşılaştırabilir ve yalnızca giriş grubu sonuçlarında farklı durum kodlarına sahip olan test durumları. İlgili içeriği oluşturmak için kullanılan karşılaştırması da eşleşen vakaların sayısını yazdırır.

CSV biçimindeki çıktı, standart CSV biçiminde daha fazla işlem için çok kullanışlıdır. komut satırı yardımcı programlarıyla veya e-tablo düzenleyicisiyle çalışır. Ek, kullanıcılar tarafından okunabilen Düz metin biçimi, şu komut satırı bağımsız değişkeni kullanılarak 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ı 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 sonucunu verir sonuç kodu, örneğin "Pass" veya "Başarısız". --value=details bağımsız değişkeni daha fazla sonucun ya da performans, yetenek veya doğruluk testinin ürettiği sayısal değerin açıklaması.

Test günlüğü XML dışa aktarımı

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

Her test durumunun ve caselist.xml özetinin yer aldığı ayrı dokümanlar modu doküman bir hedef dizine yazılır.
.qpa dosyasındaki tüm sonuçların tek bir XML dokümanına yazıldığı tek dosya modu.

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

Google Chrome kullanıyorsanız dosyalara Chrome gibi HTTP üzerinden erişilmelidir. . Standart Python kurulumu geçerli sunucu oluşturmak için başlatılabilecek temel bir HTTP python –m SimpleHTTPServer 8000 komutuyla dizin. Sunucuyu başlattıktan sonra, test günlüğünü görüntülemek için Chrome tarayıcıyı http://localhost:8000 adresine yönlendirin.

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

Birçok test otomasyon sistemi, JUnit'ten test çalıştırması sonuç raporları oluşturabilir çıktı. deqp test günlük dosyaları, JUnit çıkış biçimine dönüştürülebilir aracını kullanabilirsiniz.

Araç şu anda yalnızca test durumu kararının çevrilmesini desteklemektedir. JUnit olarak yalnızca "pass"i destekler ve "fail" deqp'nin geçen bir sonucu eşlenir "JUnit Pass"e diğer sonuçlar da başarısız olarak değerlendirilir. Orijinal sunum sonuç kodu JUnit çıkışında bulunur. Günlük mesajları gibi diğer veriler ve sonuç resimleri dönüştürmede saklanmaz.

Özel test gruplarını kullanma

Bazı test grupları, özel komut satırı seçeneklerine ihtiyaç duyabilir veya bunları destekleyebilir özel bir bakıma ihtiyaç duyabilir.

Bellek ayırma stres testleri

Bellek ayırma stres testleri, bellek dışı durumları sürekli olarak uygular Sürücü, bellek dışı hatası bildirene kadar belirli kaynakları ayırmaya çalışıyor.

Android ve çoğu Linux varyantı gibi belirli platformlarda aşağıdakiler kullanılabilir: meydana gelebilir: İşletim sistemi bir veya bellek dışı hatası vermelidir. Böyle bir tarihte platformlarda, bellek dışı hatalara neden olmak üzere tasarlanmış testler devre dışı bırakılır ve varsayılan olarak kullanılır ve --deqp-test-oom=enable komut satırı bağımsız değişkeni kullanılarak etkinleştirilmelidir. Bu tür testleri manuel olarak yapmanız önerilir: sistemin kaynak baskısı altında doğru şekilde davranıp davranmadığını kontrol etmek. Ancak, bu tür durumlarda test sürecinde yaşanan kilitlenme başarılı 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 uygulanan dayanıklılık sorunlarını ortaya çıkarmak için tasarlanmıştır oluşturma yükü. Testler varsayılan olarak yalnızca birkaç yineleme gerçekleştirir ancak --deqp-test-iteration-count=-1 sağlanmasıyla süresiz olarak çalışacak şekilde yapılandırılabilirler komut satırı bağımsız değişkeni. Test güvenlik zamanlayıcısı devre dışı bırakılmalıdır (--deqp-watchdog=disable) uzun süre devam etmesi gerekir.

Test grupları

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