drawElements Quality Program testi

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ı, targets/DEQP_TARGET/DEQP_TARGET.cmake dosyasını içerir ve hedefle ilgili derleme seçeneklerini buradan bulmayı bekler.
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: framework/platform

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_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

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
framework/delibs/dethread
framework/delibs/deutil

İş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, dethread ve standart C kitaplığına dayanmaktadır.
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
--deqp-caselist=<caselist>
--deqp-caselist-file=<filename>		 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>
--deqp-surface-height=<height>		 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.*