AOSP, https://android.googlesource.com/platform/external/deqp adresinde 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.
En son gönderilen 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ını kullanın (ör. Android 6.0 için 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österilmektedir (liste kapsamlı değildir ancak en önemli dizinleri vurgulamaktadır).
Dizin | Açıklama |
---|---|
android |
Android test kullanıcısı kaynakları ve derleme komut dosyaları |
data |
Test verileri 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 özgü derleme yapılandırma dosyaları |
framework |
deqp test modülü çerçevesi ve yardımcı programları |
framework/delibs |
Temel taşınabilirlik ve kitaplık oluşturma |
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ındaki ExecServer kaynağı |
executor |
Ana makine tarafı test yürütücü kabuk aracı ve yardımcı programları |
external |
Harici kitaplıklar libpng ve zlib için sahte dizin oluşturma |
Açık kaynak bileşenler
deqp, libpng
ve zlib
kullanır. Bunlar,
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 koşullar, G/Ç, iş parçacıkları ve soketler için tam C++ desteği ve standart sistem kitaplıklarıdır.
CMake derleme sistemi
deqp kaynaklarında, test programlarını derlemek için tercih edilen araç olan CMake'e yönelik derleme komut dosyaları bulunur.
CMake, birden fazla platformu ve araç zincirini destekleyen açık kaynaklı bir derleme sistemidir. CMake, hedeften bağımsız yapılandırma dosyalarından yerel makefile'lar 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ışı derlemeleri destekler ve önerir. Yani her zaman kaynak ağacının dışında ayrı bir derleme dizininde makefile'lar veya proje dosyaları oluşturmanız gerekir. CMake'te 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
söz dizimi kullanılarak CMake'e verilir. deqp için sık kullanılan bazı seçenekler aşağıda listelenmiştir.
Yapılandırma seçeneği | Açıklama |
---|---|
DEQP_TARGET |
Hedef adı (örneğin: "android") deqp CMake komut dosyaları, |
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: "Debug" ve "Release" Yorumlamanın 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ı kullanılarak yeni hedefler için yapılandırılır.
Hedef derleme dosyası, platformun hangi özellikleri desteklediğini ve hangi kitaplıkların ya da ek dahil etme yollarının gerekli olduğunu tanımlar. Hedef dosya adları targets/NAME/NAME.cmake
biçimindedir ve hedef, DEQP_TARGET
oluşturma parametresi kullanılarak seçilir.
Hedef dosyalardaki dosya yolları deqp
dizinine göre belirlenir, targets/NAME
dizinine göre belirlenmez. Aşağıdaki standart değişkenler hedef derleme dosyası tarafından ayarlanabilir.
Değişken | Açıklama |
---|---|
DEQP_TARGET_NAME |
Hedef adı (test günlüklerine dahil edilir) |
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 özgü ek kitaplıklar gerekir |
DEQP_PLATFORM_COPY_LIBRARIES |
Her test ikili programı derleme dizinine kopyalanan kitaplıkların listesi. Testlerin çalıştırılması için gereken ancak varsayılan arama yolunda bulunmayan kitaplıkları kopyalamak için kullanılabilir. |
TCUTIL_PLATFORM_SRCS |
Platform bağlantı noktası kaynak listesi. Varsayılan kaynaklar, özelliklere ve işletim sistemine göre belirlenir. Not: Yollar şuna göre belirlenir: |
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ülleri oluşturmanın en kolay yolu CMake derleme sistemini kullanmaktır. CMake 2.6.12 veya daha yeni bir sürümün ve Microsoft Visual C/C++ derleyicisinin yüklü olması gerekir. 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 bitlik bir derleme oluşturulabilir:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Ayrıca, -G "NMake Makefiles"
seçeneği ve derleme türü (-DCMAKE_BUILD_TYPE="Debug"
veya "Release"
) ile NMake makefile'ları da oluşturabilirsiniz.
Render bağlamı oluşturma
Render bağlamı, Windows'da WGL veya EGL ile oluşturulabilir.
WGL desteği
Tüm Win32 ikilileri, yalnızca standart kitaplıklar gerektirdiğinden 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ısını kullanır. Bu özellik, NVIDIA ve Intel'in en yeni sürücüleriyle çalışacak şekilde test edilmiştir. AMD sürücüleri, gerekli uzantıyı desteklemiyor.
EGL desteği
DEQP_SUPPORT_EGL
is ON ise deqp, Windows'da EGL için dinamik yükleme ile oluşturulur. Bu, çoğu hedefte varsayılandır. Ardından, ana makinede EGL kitaplıkları varsa komut satırı parametresiyle --deqp-gl-context-type=egl
bu kitaplıklarla testler çalıştırmak mümkündür.
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 bölümleri, standart Android derleme araçları kullanılarak derlenir.
Android için deqp test programlarını sağlanan derleme komut dosyalarıyla derlemek üzere şunlara ihtiyacınız vardır:
-
Android NDK'nın en son sürümü;
android/scripts/common.py
dosyasında gerekli sürüm listelenir. - API 13, SDK Tools, SDK Platform-tools ve SDK Build-tools paketleri yüklü olan bağımsız Android SDK
- Apache Ant 1.9.4 (Java kodu derlemesi için gereklidir)
- CMake 2.8.12 veya sonraki bir sürüm
- 2.x serisinde Python 2.6 veya daha yeni bir sürüm; Python 3.x desteklenmez
- Windows için:
PATH
konumunda NMake veya JOM- JOM, daha hızlı derlemeler yapılmasını sağlar.
- İsteğe bağlı: Ninja make, Linux'ta da desteklenir.
Ant ve SDK ikilileri, PATH ortam değişkenine göre belirli geçersiz kılma varsayılanlarıyla birlikte bulunur. Mantık, android/scripts/common.py
tarafından kontrol edilir.
NDK dizini ~/android-ndk-VERSION
veya C:/android/android-ndk-VERSION
olmalı ya da ANDROID_NDK_PATH
ortam değişkeni üzerinden tanımlanmalıdır.
Cihaz üzerinde deqp bileşenleri, test yürütme hizmeti ve test programları android/scripts/build.py
komut dosyası yürütülerek oluşturulur. Son .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üsü kullanılıyorsa ExecService, ADB aracılığıyla cihazda launch.py
komut dosyasıyla başlatılır. Komut dosyaları herhangi bir dizinden yürütülebilir.
Linux derlemesi
Test ikilileri ve komut satırı yardımcı programları, CMake kullanılarak makefile'lar oluşturularak Linux için derlenebilir. Linux için derleme yaparken kullanabileceğiniz birden fazla önceden tanımlanmış derleme hedefi vardır.
Hedef oluşturma | Açıklama |
---|---|
default |
Çeşitli API'ler için desteği belirlemek üzere CMake platform incelemesini 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ılandır. Bu dosya olmadan varsayılan ve optimize edilmemiş bir sürüm derlemesi oluşturulur.
Derleyiciye ekstra bağımsız değişkenler aktarmak için -DCMAKE_C_FLAGS
ve -DCMAKE_CXX_FLAGS
komut satırı bağımsız değişkenleri kullanılabilir. Örneğin, 32 bit veya 64 bit derleme, sırasıyla -DCMAKE_C(XX)_FLAGS="-m32"
veya "-m64"
ayarlanarak yapılabilir. Belirtilmezse 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, CMake'e ek kitaplık veya dahil etme arama yolları sağlamak için CMake'te kullanılabilir.
Özel bir konumdaki sürücü başlıklarına ve kitaplıklarına karşı 32 bit hata ayıklama derlemesi yapmak için kullanılan tam komut satırına örnek olarak aşağıdakiler verilebilir:
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 gerçekleştirilebilir. Araç zinciri dosyası, kitaplıklar ve başlıklar için özel arama yollarıyla birlikte kullanılacak derleyiciyi belirtir. Sık karşılaşılan senaryolar için çeşitli araç zinciri dosyaları, framework/delibs/cmake
dizinindeki yayın paketine dahil edilmiştir.
Standart CMake değişkenlerine ek olarak, aşağıdaki deqp'ye özgü değişkenler 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
öğesi araç zinciri dosyası tarafından ayarlanmalıdır.
Değişken | Açıklama |
---|---|
DE_OS |
İşletim sistemi. Desteklenen değerler: |
DE_COMPILER |
Derleyici türü. Desteklenen değerler: |
DE_CPU |
CPU türü. Desteklenen değerler: |
DE_PTR_SIZE |
Platformda sizeof(void*). Desteklenen değerler: 4 ve 8 |
Araç zinciri dosyası, CMAKE_TOOLCHAIN_FILE
derleme parametresi kullanılarak seçilebilir.
Örneğin, aşağıdaki komutlar ARM/Linux için CodeSourcery çapraz derleyicisini kullanarak bir derleme için makefile'lar 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ı bağlantısı
deqp'nin bağlama sırasında test edilen API'nin giriş noktalarına ihtiyacı yoktur. 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ı zamanında sağlayabilir.
Derleme ayarlarında bir API'nin desteği etkinleştirilmişse ve bağlantı kitaplıkları sağlanmamışsa deqp, gereken giriş noktalarını çalışma zamanında yükler. Statik bağlantı isteniyorsa DEQP_<API>_LIBRARIES
derleme yapılandırması değişkeninde gerekli bağlantı kitaplıklarını sağlayın.
Test çerçevesini taşıma
deqp'yi taşıma işlemi üç adımdan oluşur: temel taşınabilirlik kitaplıklarını uyarlama, test çerçevesi platformu entegrasyon arayüzlerini uygulama ve yürütme hizmetini taşıma.
Aşağıdaki tabloda, muhtemel taşıma değişikliklerinin yapılacağı konumlar listelenmiştir. Bunların dışındaki her şey egzotik olabilir.
Konum | Açıklama |
---|---|
framework/delibs/debase |
İşletim sistemine özel kodun 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 olan, |
framework/platform |
Yeni platform bağlantı noktası ve uygulama saplaması, Test framework platform bağlantı noktası bölümünde açıklandığı şekilde uygulanabilir. |
Temel taşınabilirlik kitaplıkları
Temel taşınabilirlik kitaplıkları Windows, çoğu Linux çeşidi, Mac OS, iOS ve Android'i zaten desteklemektedir. Test hedefi bu işletim sistemlerinden birinde çalışıyorsa temel taşınabilirlik kitaplıklarına hiç dokunmanız gerekmez.
Test çerçevesi platform bağlantı noktası
deqp test çerçevesi platform bağlantı noktası için iki bileşen gerekir: 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ü açmaktan (tcu::TestLog
) ve test uygulamasını yinelemekten (tcu::App
) sorumludur. Hedef işletim sistemi standart bir main()
giriş noktasını destekliyorsa tcuMain.cpp
, giriş noktası uygulaması olarak kullanılabilir.
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
'dı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 bir bakış için aşağıdaki tabloya bakın.
Modül | Arayüz |
---|---|
OpenGL (ES) test modülleri |
GL platform arayüzü |
EGL test modülü |
EGL platform arayüzü |
Platform bağlantı noktalarını uygulama ile ilgili ayrıntılı talimatlar, bağlantı noktası oluşturma katmanı üstbilgilerinde 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 test yürütme hizmetinin hedefte kullanılabilir olması gerekir. Hizmetin taşınabilir bir C++ uygulaması execserver
dizininde sağlanır. Bağımsız ikili dosya, PC hedefleri için deqp test modülü derlemesinin bir parçası olarak oluşturulur. Diğer hedeflerde derleme oluşturmayı etkinleştirmek için execserver/CMakeLists.txt
öğesini değiştirebilirsiniz.
Test yürütme hizmetinin C++ sürümü iki komut satırı parametresi kabul eder:
-
--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 sürecini sonlandırır. Varsayılan olarak, sunucu işlemi daha fazla test yürütme isteğine hizmet vermek için çalışmaya devam eder.
Testleri çalıştırma
Bu sayfada, komut satırı bağımsız değişkenlerini kullanarak Linux ve Windows ortamlarında deqp testlerini çalıştırma ve Android uygulama paketiyle çalışma talimatları verilmektedir.
Linux ve Windows ortamları
Aşağıdaki dosya ve dizinleri hedef cihaza 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 |
data/gles2 |
<dst>/gles2 |
|
GLES3 Module | build/modules/gles3/deqp-gles3 |
<dst>/deqp-gles3 |
data/gles3 |
<dst>/gles3 |
|
GLES3.1 Modülü | build/modules/gles31/deqp-gles31 |
<dst>/deqp-gles31 |
data/gles31 |
<dst>/gles31 |
|
GLES3.2 Modülü | build/modules/gles32/deqp-gles32 |
<dst>/deqp-gles32 |
data/gles32 |
<dst>/gles32 |
Yürütme hizmetini ve test ikililerini hedef dosya sisteminin herhangi bir yerine dağıtabilirsiniz. Ancak test ikilileri, veri dizinlerini geçerli çalışma dizininde bulmayı bekler. Hazır olduğunuzda hedef cihazda Test Execution Service'i başlatın. Hizmeti başlatma hakkında ayrıntılı bilgi için Test yürütme hizmeti başlıklı makaleyi 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.
Bağımsız değişken | Açıklama |
---|---|
--deqp-case=<casename> |
Belirli bir kalıpla eşleşen test senaryolarını çalıştırın. 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ılırken dosya adını ayarlar. |
--deqp-stdin-caselist |
Vaka listesini stdin'den veya belirli bir bağımsız değişkenden okur. Test yürütme hizmeti, alınan yürütme isteğine göre bağımsız değişkeni ayarlar. Dava listesi biçiminin açıklaması için sonraki bölüme bakın. |
--deqp-test-iteration-count=<count> |
Değişken sayıda yinelemeyi destekleyen testler için yineleme sayısını geçersiz kılın. |
--deqp-base-seed=<seed> |
Rastgeleleştirme kullanan test senaryoları için temel başlangıç değeri. |
GLES2 ve GLES3'e özel 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. EGL'yi destekleyen platformlarda, EGL bağlamını seçmek için egl değeri kullanılabilir. |
--deqp-gl-config-id=<id> |
Belirtilen GL yapılandırma kimliği için testler çalıştırın. Yorumlama platforma bağlıdır. EGL platformunda bu, 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 platforma bağlıdır. EGL için biçim şöyledir:
rgb(a)<bits>d<bits>s<bits> . Örneğin, rgb888s8 değeri, renk arabelleğinin RGB888 olduğu ve şablon arabelleğinin 8 bit olduğu ilk yapılandırmayı seçecektir. |
--deqp-gl-context-flags=<flags> |
Bağlam oluşturur. robust veya debug değerini belirtin. |
--deqp-surface-width=<width> |
Belirli bir boyutta yüzey oluşturmayı deneyin. Bu özellik 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. Olası türler window , pixmap , pbuffer ve fbo 'dür. |
--deqp-screen-rotation=<rotation> |
Destekleyen platformlarda 90 derecelik artışlarla ekran yönü. |
Test durumu listesi biçimi
Test senaryosu listesi iki biçimde verilebilir. İlk seçenek, her testin tam adını standart bir ASCII dosyasında ayrı bir satırda listelemektir. Test kümeleri büyüdükçe tekrarlanan önekler hantal hale gelebilir. Öneklerin tekrarını önlemek için aşağıdaki trie (önek ağacı olarak da bilinir) söz dizimini kullanın.
{nodeName{firstChild{…},…lastChild{…}}}
Örneğin:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Aşağıdaki iki test senaryosuna çevrilir:
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
(Android 3.2 veya sonraki sürümler gerekir).
Uygulama paketi aşağıdaki komutla yüklenebilir (gösterilen ad, Android CTS paketindeki APK'nın adıdır ve 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 çıktıları, testleri başlatmadan önce aşağıdakiler yürütülerek etkinleştirilebilir:
adb –d shell setprop log.tag.dEQP DEBUG
Android CTS olmadan Android'de testler yürütme
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 ek bir dize olarak sağlanmalıdır.
/sdcard/dEQP-log.qpa
adresine bir test günlüğü yazılır. Test çalıştırması normal şekilde başlamazsa cihaz günlüğünde ek hata ayıklama bilgileri bulunur.
am
yardımcı programını kullanarak komut satırından bir etkinlik başlatabilirsiniz. Örneğin, NativeActivity,
destekleyen bir platformda dEQP-GLES2.info
testlerini ç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 derleyip 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ı, yürütülecek test senaryolarına ve diğer gerekli parametrelere bağlıdır. Komut dosyası, deqp yürütme işleminin başında varsayılan bir ayrılma noktası ekler (tcu::App::App
).
debug.py
komut dosyası, hata ayıklama için kesme noktaları ayarlama, gdbserver bağlantı parametreleri ve hata ayıklanacak 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). Ayrıca, sembol listelerini 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 bilgileri içeren 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ı dosyasının 132. satırından başlayarak 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ğlamanız yeterli olacaktır.
Not: Windows'da GDB ikilisi için libpython2.7.dll
gerekir. debug.py
'yı başlatmadan önce PATH değişkenine <path-to-ndk>/prebuilt/windows/bin
ekleyin.
Not: Yerel kodda 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 bulunmaz.
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 hedef ortama bağlıdır.
Test çalıştırmasından elde edilen birincil çıktı her zaman test günlüğü dosyasıdır. Diğer bir deyişle, .qpa
sonekine sahip dosyadır. Test günlüğünden tam test sonuçları ayrıştırılabilir. Konsol çıkışı yalnızca hata ayıklama bilgilerini içerir ve tüm platformlarda kullanılamayabilir.
Test ikilileri doğrudan bir test otomasyonu sisteminden çağrılabilir. Test ikilisi belirli bir durum, test grubu veya mevcut tüm testler için başlatılabilir. Yürütme sırasında ölümcül bir hata oluşursa (ör. belirli API hataları veya kilitlenme) test yürütmesi durdurulur. Regresyon testinde, kısmi sonuçların ciddi bir hata durumunda bile kullanılabilmesi için test ikililerini ayrı ayrı test durumları veya küçük test kümeleri için çağırmak en iyi yaklaşımdır.
Deqp, daha güçlü bir entegrasyon elde etmek için yürütme hizmetiyle birlikte kullanılabilen komut satırı test yürütme araçlarıyla birlikte gelir. Yürütücü, test sürecinin sonlandırıldığını algılar ve test yürütmeye bir sonraki uygun durumda devam eder. Tam test oturumundan tek bir günlük dosyası oluşturulur. 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; uzaktan 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'ye dönüştürücü ve test günlüğünü JUnit'e dönüştürücüyü 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 sonuç günlüklerini TCP/IP üzerinden cihazdan 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.
Birlikte, test süreci çökmelerinden kurtarma gibi işlevler sağlarlar.
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
simgesini 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 bir 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 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 araca sahiptir. CSV çıkışı, test senaryolarının ve sonuçlarının listesini içerir. Araç, iki veya daha fazla toplu sonuç karşılaştırabilir ve yalnızca giriş toplu sonuçlarında farklı durum kodlarına sahip test senaryolarını listeleyebilir. Karşılaştırmada, eşleşen destek kayıtlarının sayısı da yazdırılır.
CSV biçimindeki çıktı, standart komut satırı yardımcı programları veya bir e-tablo düzenleyiciyle daha fazla işleme için çok pratiktir. Aşağıdaki komut satırı bağımsız değişkeni kullanılarak ek bir, insanlar tarafından okunabilir, 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, "Başarılı" veya "Başarısız" gibi test sonucu kodunu verir. --value=details
bağımsız değişkeni, performans, yetenek veya doğruluk testiyle üretilen sonucun ya da sayısal değerin daha ayrıntılı açıklamasını seçer.
Günlük XML'sini dışa aktarma işlemini test etme
Test günlük dosyaları, testlog-to-xml
yardımcı programı kullanılarak geçerli XML belgelerine dönüştürülebilir. İki çıkış modu desteklenir:
- Her test senaryosunun ve
caselist.xml
özet belgesinin bir hedef dizine yazıldığı ayrı belgeler 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ı tarayıcıda oluşturmak için iki stil sayfası dosyasını, dışa aktarılan XML belgelerinin bulunduğu dizine kopyalayın.
Google Chrome kullanıyorsanız Chrome, güvenlik nedeniyle yerel dosya erişimini sınırladığından dosyalara HTTP üzerinden erişilmesi gerekir. Standart Python yüklemesi, geçerli dizine python –m SimpleHTTPServer 8000
komutuyla hizmet vermek için başlatılabilen temel bir HTTP sunucusu içerir. Sunucuyu başlattıktan sonra, test günlüğünü görüntülemek için Chrome tarayıcıyı http://localhost:8000
adresine yönlendirmeniz yeterlidir.
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 senaryosu kararının çevrilmesini desteklemektedir. JUnit yalnızca "geçti" ve "kaldı" sonuçlarını desteklediğinden, deqp'nin başarılı sonucu "JUnit geçti" olarak 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üştürme işleminde korunmaz.
Özel test gruplarını kullanma
Bazı test grupları özel komut satırı seçeneklerine ihtiyaç duyabilir veya bunları destekleyebilir ya da belirli sistemlerde kullanıldığında özel dikkat gerektirebilir.
Bellek ayırma stres testleri
Bellek ayırma stres testleri, sürücü bellek hatası bildirene kadar belirli kaynakları tekrar tekrar ayırarak bellek dışı koşulları uygular.
Android ve çoğu Linux varyantı gibi belirli platformlarda aşağıdakiler meydana gelebilir: İşletim sistemi, sürücünün bellek yetersizliği hatasını işlemesine veya başka bir şekilde sağlamasına izin vermek yerine test sürecini sonlandırabilir. Bu tür platformlarda, bellek yetersizliği hatalarına neden olacak şekilde tasarlanan testler varsayılan olarak devre dışı bırakılı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 sürecinin kilitlenmesi geçme olarak yorumlanmalıdır.
Test grupları
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Uzun süren oluşturma stres testleri
Oluşturma stres testleri, sürekli oluşturma yükü altında sağlamlıkla ilgili sorunları ortaya çıkarmak için tasarlanmıştır. Testler varsayılan olarak yalnızca birkaç yineleme gerçekleştirir ancak --deqp-test-iteration-count=-1
komut 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ılırken test watchdog'u devre dışı bırakılmalıdır (--deqp-watchdog=disable
).
Test grupları
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*