AOSP, https://android.googlesource.com/platform/external/deqp adresinde DrawElements Kalite Programı (deqp) GPU test paketini içerir. Bu sayfada deqp test paketinin yeni bir ortama nasıl dağıtılacağı ayrıntılarıyla anlatılmaktadı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 (örneğin, Android 6.0 için, marshmallow-release dalını kullanın).
Kaynak düzeni
Deqp test modülleri ve destekleyici kütüphaneler için kaynak kodu düzeni aşağıdaki tabloda gösterilmektedir (liste kapsamlı değildir ancak en önemli dizinleri vurgulamaktadır).
| Rehber | Tanım |
|---|---|
android | Android test kullanıcısı kaynakları ve derleme komut dosyaları |
data | Veri dosyalarını test edin |
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ıklar 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 özgü yardımcı programlar |
execserver | Cihaz tarafı ExecServer kaynağı |
executor | Ana bilgisayar tarafı test yürütücüsü kabuk aracı ve yardımcı programları |
external | Harici lib'ler libpng ve zlib için saplama dizini oluşturun |
Açık kaynak bileşenleri
Deqp platform/external/deqp/external/fetch_sources.py betiği kullanılarak veya platform/external/[libpng,zlib] adresinden git aracılığıyla getirilebilen libpng ve zlib kullanır.
Test programları oluşturun
Test çerçevesi taşınabilirlik göz önünde bulundurularak tasarlanmıştır. Zorunlu olan tek gereksinim, tam C++ desteği ve G/Ç, iş parçacıkları ve yuvalar için standart sistem kitaplıklarıdır.
CMake derleme sistemi
Deqp kaynakları, test programlarını derlemek için tercih edilen araç olan CMake için derleme komut dosyalarına sahiptir.
CMake, birden fazla platformu ve araç zincirini destekleyen açık kaynaklı bir yapı 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ğaç dışı yapıları destekler ve önerir; yani, makefile dosyalarını veya proje dosyalarını her zaman kaynak ağacın dışında ayrı bir yapı dizininde oluşturmalısınız. CMake'in herhangi bir "distclean" hedefi yoktur, dolayısıyla CMake tarafından oluşturulan dosyaların kaldırılması manuel olarak yapılmalıdır.
Yapılandırma seçenekleri CMake'e -D OPTION_NAME = VALUE sözdizimi kullanılarak verilir. Deqp için yaygın olarak kullanılan bazı seçenekler aşağıda listelenmiştir.
| Yapılandırma seçeneği | Tanım |
|---|---|
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 şunlardır: "Hata Ayıklama" ve "Yayın" 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ını kullanarak yeni hedefler için yapılandırılır. Hedef derleme dosyası, platformun hangi özellikleri desteklediğini ve hangi kitaplıkların veya ek içerme yollarının gerekli olduğunu tanımlar. Hedef dosya adları targets/ NAME / NAME .cmake biçimini takip eder ve hedef, DEQP_TARGET yapı parametresi kullanılarak seçilir.
Hedef dosyalardaki dosya yolları targets/ NAME dizinine değil, temel deqp dizinine göredir. Aşağıdaki standart değişkenler hedef derleme dosyası tarafından ayarlanabilir.
| Değişken | Tanım |
|---|---|
DEQP_TARGET_NAME | Hedef adı (test günlüklerine dahil edilecektir) |
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ı için platforma özel ek kitaplıklar gerekir |
DEQP_PLATFORM_COPY_LIBRARIES | Her test ikili yapı dizinine kopyalanan kitaplıkların listesi. Testleri çalıştırmak için gerekli olan ancak varsayılan arama yolunda olmayan kitaplıkları kopyalamak için kullanılabilir. |
TCUTIL_PLATFORM_SRCS | Platform bağlantı noktası kaynak listesi. Varsayılan kaynaklar, yeteneklere ve işletim sistemine göre belirlenir. Not: Yollar şuna bağlıdır: |
Hedef derleme dosyası, include_directories() ve link_directories() CMake işlevlerini kullanarak ek içerme veya bağlantı yolları ekleyebilir.
Win32 yapısı
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üme ve Microsoft Visual C/C++ derleyicisine ihtiyacınız olacak. 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"
Yapı oluşturucu olarak "Visual Studio VERSION Win64" seçilerek 64 bitlik bir yapı oluşturulabilir:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Ayrıca -G "NMake Makefiles" seçeneğinin yanı sıra yapı türünü ( -DCMAKE_BUILD_TYPE="Debug" veya "Release" ) kullanarak da NMake makefile dosyaları oluşturabilirsiniz.
Render bağlamı oluşturma
İşleme bağlamı WGL veya Windows'ta EGL ile oluşturulabilir.
WGL desteği
Tüm Win32 ikili dosyaları, yalnızca standart kitaplıklar gerektirdiğinden WGL ile GL bağlamı oluşturmayı destekler. WGL içeriği --deqp-gl-context-type=wgl komut satırı argümanı 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. Bunun NVIDIA ve Intel'in en yeni sürücüleri ile ç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şturulmuştur. Bu çoğu hedefte varsayılandır. Daha sonra, eğer ana bilgisayarda EGL kütüphaneleri mevcutsa, komut satırı parametresi ile bunlarla testler çalıştırmak mümkündür: --deqp-gl-context-type=egl
Android yapısı
Android derlemesi, yerel test kodunu oluşturmak için CMake derleme komut dosyalarını kullanır. Java parçaları, yani Test Yürütme Sunucusu ve Test Uygulama Saplaması, standart Android oluşturma araçları kullanılarak derlenir.
Android için deqp test programlarını sağlanan derleme komut dosyalarıyla derlemek için şunlara ihtiyacınız olacak:
- Android NDK'nın en son sürümü;
android/scripts/common.pydosyası gerekli sürümü listeler - API 13, SDK Araçları, SDK Platform araçları ve SDK Oluşturma araçları paketlerinin yüklü olduğu bağımsız Android SDK'sı
- Apache Ant 1.9.4 (Java kod yapısı için gereklidir)
- CMake 2.8.12 veya daha yenisi
- Python 2.6 veya 2.x serisinde daha yenisi; Python 3.x desteklenmiyor
- Windows için:
PATHNMake veya JOM- JOM daha hızlı derlemelere olanak 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 konumlandırılır. Mantık android/scripts/common.py tarafından kontrol edilir.
NDK dizini ~/android-ndk- VERSION veya C:/android/android-ndk- VERSION olmalı veya ANDROID_NDK_PATH ortam değişkeni aracılığıyla tanımlanmalıdır.
Deqp cihaz içi bileşenleri, test yürütme hizmeti ve test programları, android/scripts/build.py betiğinin çalıştırılmasıyla oluşturulur. Son .apk dosyası android/package/bin dosyasında oluşturulur ve install.py betiği tarafından yüklenebilir. Komut satırı yürütücüsü kullanılıyorsa ExecService, ADB aracılığıyla cihazda launch.py betiğiyle başlatılır. Komut dosyaları herhangi bir dizinden çalıştırılabilir.
Linux yapısı
CMake kullanılarak makefile dosyaları oluşturularak Linux için test ikili dosyaları ve komut satırı yardımcı programları oluşturulabilir. Linux için derleme yaparken yararlı olacak, önceden tanımlanmış birden çok derleme hedefi vardır.
| Hedef oluştur | Tanım |
|---|---|
default | Çeşitli API'lere yönelik desteği belirlemek için CMake platformu 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ılandır. Bu olmadan, varsayılan, optimize edilmemiş bir sürüm yapısı 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 yapı sırasıyla -DCMAKE_C(XX)_FLAGS="-m32" veya "-m64" ayarlanarak yapılabilir. Belirtilmediği takdirde, 64 bitlik 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'e ek kitaplık vermek veya arama yollarını dahil etmek için CMake için kullanılabilir.
Özel bir konumdaki sürücü başlıklarına ve kitaplıklara karşı 32 bitlik hata ayıklama derlemesi yapmak için kullanılan tam komut satırı örneği aşağıdadır:
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ının yanı sıra kullanılacak derleyiciyi belirtir. Yaygın senaryolara yönelik ç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 toolchain dosyası tarafından ayarlanabilir. CMake genellikle DE_OS , DE_COMPILER ve DE_PTR_SIZE doğru şekilde algılayabilir ancak DE_CPU araç zinciri dosyası tarafından ayarlanması gerekir.
| Değişken | Tanım |
|---|---|
DE_OS | İşletim sistemi. Desteklenen değerler şunlardır: |
DE_COMPILER | Derleyici türü. Desteklenen değerler şunlardır: |
DE_CPU | CPU türü. Desteklenen değerler şunlardır: |
DE_PTR_SIZE | sizeof(void*) platformda. Desteklenen değerler şunlardır: 4 ve 8 |
Araç zinciri dosyası CMAKE_TOOLCHAIN_FILE yapı parametresi kullanılarak seçilebilir. Örneğin, aşağıdakiler ARM/Linux için CodeSourcery çapraz derleyicisini kullanan bir yapı için makefile dosyaları 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, 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ı zamanında sağlayabilir.
Derleme ayarlarında API desteği açıksa ve bağlantı kitaplıkları sağlanmadıysa deqp, çalışma zamanında gerekli giriş noktalarını yükleyecektir. Statik bağlantı isteniyorsa DEQP_<API>_LIBRARIES yapı yapılandırma değişkeninde gerekli bağlantı kitaplıklarını sağlayın.
Test çerçevesini taşıyın
Deqp'nin taşınması üç adımdan oluşur: temel taşınabilirlik kitaplıklarının uyarlanması, test çerçevesi platform entegrasyonu arayüzlerinin uygulanması ve yürütme hizmetinin taşınması.
Aşağıdaki tabloda olası taşıma değişikliklerinin konumları listelenmektedir. Bunların ötesindeki her şeyin egzotik olması muhtemeldir.
| Konum | Tanım |
|---|---|
framework/delibs/debase | İşletim sistemine özgü 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 çerçevesi platform bağlantı noktası bölümünde açıklandığı gibi uygulanabilir. |
Temel taşınabilirlik kitaplıkları
Temel taşınabilirlik kitaplıkları zaten Windows'u, Linux türlerinin çoğunu, Mac OS'yi, iOS'u ve Android'i desteklemektedir. Test hedefi bu işletim sistemlerinden birinde çalışıyorsa büyük olasılıkla temel taşınabilirlik kitaplıklarına dokunmaya gerek yoktur.
Çerçeve platformu bağlantı noktasını test edin
Deqp test çerçevesi platformu bağlantı noktası iki bileşen gerektirir: Bir uygulama giriş noktası ve bir platform arayüzü uygulaması.
Uygulama giriş noktası, platform nesnesinin oluşturulmasından, bir komut satırı nesnesinin ( tcu::CommandLine ) oluşturulmasından, bir test günlüğünün açılmasından ( tcu::TestLog ) ve test uygulamasının yinelenmesinden ( tcu::App ) sorumludur. Hedef işletim sistemi standart bir main() giriş noktasını destekliyorsa, giriş noktası uygulaması olarak tcuMain.cpp kullanılabilir.
Deqp platformu API'si aşağıdaki dosyalarda ayrıntılı olarak açıklanmaktadır.
| Dosya | Tanım |
|---|---|
framework/common/tcuPlatform.hpp | Tüm platform bağlantı noktaları için temel sınıf |
framework/opengl/gluPlatform.hpp | OpenGL platformu arayüzü |
framework/egl/egluPlatform.hpp | EGL platformu 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 özgü arayüzleri destekleyebilir. Testleri çalıştırmak için nelerin uygulanması gerektiğine ilişkin bir genel bakış için aşağıdaki tabloya bakın.
| Modül | Arayüz |
|---|---|
OpenGL (ES) test modülleri | GL platformu arayüzü |
EGL test modülü | EGL platformu arayüzü |
Platform bağlantı noktalarının uygulanmasına ilişkin ayrıntılı talimatlar, taşıma katmanı başlıklarında bulunmaktadı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 mevcut 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ü yapısının bir parçası olarak oluşturulmuştur. Diğer hedeflerde derlemeyi etkinleştirmek için execserver/CMakeLists.txt dosyasını 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ı ayarlayacaktır. Varsayılan 50016'dır. -
--singleistemcinin bağlantısı kesildiğinde sunucu işlemini sonlandıracaktır. Varsayılan olarak, sunucu işlemi daha fazla test yürütme isteğini yerine getirmeye devam edecektir.
Testleri çalıştırın
Bu sayfada Linux ve Windows ortamlarında deqp testlerinin çalıştırılmasına, komut satırı argümanlarının kullanılmasına ve Android uygulama paketiyle çalışmaya ilişkin talimatlar verilmektedir.
Linux ve Windows ortamları
Aşağıdaki dosya ve dizinleri hedefe kopyalayarak başlayın.
| Modül | Rehber | 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 Modülü | 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 dağıtabilir ve ikili dosyaları hedef dosya sisteminin herhangi bir yerinde test edebilirsiniz; ancak test ikili dosyaları geçerli çalışma dizinindeki veri dizinlerini bulmayı bekler. Hazır olduğunuzda hedef cihazda Test Yürütme Hizmetini başlatın. Hizmeti başlatmayla ilgili ayrıntılar için bkz. Test yürütme hizmeti .
Komut satırı argümanları
Aşağıdaki tabloda tüm test programlarının yürütülmesini etkileyen komut satırı bağımsız değişkenleri listelenmektedir.
| Argüman | Tanım |
|---|---|
--deqp-case=<casename> | Belirli bir kalıpla eşleşen vakaları çalıştırın. Joker karakter (*) desteklenmektedir. |
--deqp-log-filename=<filename> | Test sonuçlarını ismini verdiğiniz dosyaya yazın. Test yürütme hizmeti, bir testi başlatırken dosya adını ayarlayacaktır. |
--deqp-stdin-caselist | Vaka listesini stdin'den veya belirli bir argümandan okuyun. Test yürütme hizmeti, bağımsız değişkeni alınan yürütme isteğine göre ayarlayacaktır. Vaka listesi formatının 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> | Rasgeleleştirme kullanan test senaryoları için temel tohum. |
GLES2 ve GLES3'e özgü argümanlar
Aşağıdaki tabloda GLES2 ve GLES3'e özgü argümanlar listelenmektedir.| Argüman | Tanım |
|---|---|
--deqp-gl-context-type=<type> | OpenGL bağlam türü. Kullanılabilir içerik 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> | Sağlanan GL yapılandırma kimliği için testleri ç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 format rgb(a)<bits>d<bits>s<bits> şeklindedir. Örneğin, rgb888s8 değeri, renk arabelleğinin RGB888 olduğu ve şablon arabelleğinin 8 bitten oluştuğu ilk konfigürasyonu seçecektir. |
--deqp-gl-context-flags=<flags> | Bir bağlam yaratır. robust veya debug belirtin. |
--deqp-surface-width=<width> | Belirli bir boyutta bir yüzey oluşturmaya çalışın. Bunun için destek isteğe bağlıdır. |
--deqp-surface-type=<type> | Ana test oluşturma hedefi olarak belirli bir yüzey türünü kullanın. Olası türler window , pixmap , pbuffer ve fbo . |
--deqp-screen-rotation=<rotation> | Destekleyen platformlar için 90 derecelik artışlarla ekran yönü. |
Test senaryosu listesi formatı
Test senaryosu listesi iki formatta 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 kullanışsız olabilir. Öneklerin tekrarlanmasını önlemek için aşağıda gösterilen trie (önek ağacı olarak da bilinir) sözdizimini kullanın.
{nodeName{firstChild{…},…lastChild{…}}}
Örneğin:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Aşağıdaki iki test senaryosuna çevirir:
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ı da dahil olmak üzere gerekli tüm bileşenleri içerir. Test etkinliği, EGL kullanan bir NativeActivity (Android 3.2 veya üzerini gerektirir).
Uygulama paketi aşağıdaki komutla kurulabilir (gösterilen ad, Android CTS paketindeki APK'nın adıdır; hangi ad yapıya bağlıdır):
adb –d install –r com.drawelements.deqp.apk
Test yürütme hizmetini başlatmak ve bağlantı noktası iletmeyi ayarlamak için aşağıdakileri kullanın:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Hata ayıklama yazdırmaları, testlere başlamadan ö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ütün
Test yürütme etkinliğini manuel olarak başlatmak için android.app.NativeActivity hedefleyen bir Android amacı oluşturun. Etkinlikler com.drawelements.deqp paketinde bulunabilir. Komut satırı, Intent'te "cmdLine" anahtarıyla ekstra bir dize olarak sağlanmalıdır.
/sdcard/dEQP-log.qpa dosyasına bir test günlüğü yazılır. Test çalıştırması normal şekilde başlamazsa cihaz günlüğünde ek hata ayıklama bilgileri mevcuttur.
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
Testleri Android'de GDB hata ayıklayıcısı altında çalıştırmak için öncelikle aşağıdaki iki komut dosyasını çalıştırarak hata ayıklama yapısını derleyin ve yükleyin:
python android/scripts/build.py --native-build-type=Debugpython android/scripts/install.py
Cihaza hata ayıklama yapısı yüklendikten sonra, ana bilgisayarda ç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 gerekli diğer parametrelere bağlıdır. Betik, deqp yürütmesinin başlangıcına varsayılan bir kesme noktası ekler ( tcu::App::App ).
debug.py betiği, hata ayıklama için kesme noktaları ayarlama, gdbserver bağlantı parametreleri ve hata ayıklamak için ek ikili dosyalara giden yollar gibi eylemler için birden fazla komut satırı bağımsız değişkenini kabul eder (tüm bağımsız değişkenler ve açıklamalar için debug.py --help kullanın). Komut dosyası ayrıca sembol listelerini almak için bazı varsayılan kitaplıkları hedef cihazdan kopyalar.
Sürücü kodunda adım adım ilerlemek için (örneğin, GDB'nin tam hata ayıklama bilgileriyle birlikte ikili dosyaların konumlarını bilmesi gerektiğinde), debug.py komut satırı parametreleri aracılığıyla daha fazla kitaplık ekleyin. Bu betik, betik dosyasının 132. satırından başlayarak GDB için bir yapılandırma dosyası yazar. İkili dosyalara vb. ek yollar sağlayabilirsiniz, ancak doğru komut satırı parametrelerinin sağlanması yeterli olacaktır.
Not: Windows'ta GDB ikili dosyası libpython2.7.dll gerektirir. debug.py başlatmadan önce PATH değişkenine <path-to-ndk>/prebuilt/windows/bin ekleyin.
Not: Yerel kod hata ayıklaması stok Android 4.3'te çalışmaz; Geçici çözümler için bu genel hataya bakın. Android 4.4 ve üzeri bu hatayı içermiyor.
Testleri otomatikleştirin
Deqp test modülleri, otomatik test sistemlerine birçok yolla entegre edilebilir. En iyi yaklaşım mevcut test altyapısına ve hedef ortama bağlıdır.
Bir test çalıştırmasının birincil çıktısı her zaman test günlük dosyasıdır, yani .qpa sonekine sahip dosyadır. Tam test sonuçları test günlüğünden ayrıştırılabilir. Konsol çıktısı yalnızca hata ayıklama bilgisidir ve tüm platformlarda mevcut olmayabilir.
Test ikili dosyaları doğrudan bir test otomasyon sisteminden çağrılabilir. Test ikili dosyası belirli bir durum için, bir test seti için veya mevcut tüm testler için başlatılabilir. Yürütme sırasında önemli bir hata meydana gelirse (belirli API hataları veya çökme gibi), test yürütmesi iptal edilir. Regresyon testi için en iyi yaklaşım, kesin başarısızlık durumunda bile kısmi sonuçların elde edilebilmesi amacıyla bireysel durumlar veya küçük test kümeleri için test ikili dosyalarını ayrı ayrı çağırmaktır.
Deqp, daha sağlam bir entegrasyon elde etmek için yürütme hizmetiyle birlikte kullanılabilecek komut satırı testi yürütme araçlarıyla birlikte gelir. Yürütücü, test sürecinin sonlandırıldığını algılar ve bir sonraki uygun durumda testin yürütülmesine devam eder. Tam test oturumundan tek bir günlük dosyası oluşturulur. Bu kurulum, çökme kurtarma olanakları sağlamayan hafif test sistemleri için idealdir.
Komut satırı testi yürütme araçları
Mevcut komut satırı araç seti, bir uzaktan test yürütme aracı, regresyon analizi için bir test günlüğü karşılaştırma oluşturucusu, bir test günlüğünden CSV'ye dönüştürücü, bir test günlüğünden XML'e dönüştürücü ve bir test günlüğünden JUnit'e dönüştürücü içerir .
Bu araçların kaynak kodu executor dizinindedir ve ikili dosyalar <builddir>/executor dizinine yerleştirilmiştir.
Komut satırı testi yürütücüsü
Komut satırı test yürütücüsü, bir aygıtta bir test çalıştırması başlatmak ve sonuçta 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. Birlikte, test süreci çökmelerinden kurtarma gibi işlevler sağlarlar. Aşağıdaki örneklerde Test Yürütücüsü komut satırının nasıl kullanılacağı gösterilmektedir (daha fazla ayrıntı için --help kullanın):
Örnek 1: Bir Android cihazda GLES2 işlevsel testlerini çalıştırın
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"
Örnek 2: Yerel olarak kısmi bir OpenGL ES 2 test çalıştırmasına devam edin
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 dışa aktarımını test edin ve karşılaştırın
Deqp, test günlüklerini ( qpa dosyaları) CSV dosyalarına dönüştürmek için bir araca sahiptir. CSV çıktısı test senaryolarının ve sonuçlarının bir listesini içerir. Araç ayrıca iki veya daha fazla toplu sonucu karşılaştırabilir ve yalnızca girdi toplu sonuçlarında farklı durum kodlarına sahip test senaryolarını listeleyebilir. Karşılaştırma aynı zamanda eşleşen durumların sayısını da yazdıracaktır.
CSV formatındaki çıktı, standart komut satırı yardımcı programları veya bir elektronik tablo düzenleyicisi ile daha ileri işlemler için çok pratiktir. Aşağıdaki komut satırı bağımsız değişkeni kullanılarak ek, insan tarafından okunabilen, düz metin biçimi seçilebilir: --format=text
Örnek 1: Test günlüğünü CSV formatında dışa aktarın
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Örnek 2: İki test günlüğü arasındaki test sonuçlarındaki farkları listeleyin
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Not: --value=code argümanı, "Başarılı" veya "Başarısız" gibi test sonucu kodunun çıktısını verir. --value=details argümanı, bir performans, yetenek 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 aktarımı
Test günlüğü 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 -
.qpadosyasındaki tüm sonuçların tek XML belgesine 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ı belgeleri ( 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 aynı 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 kurulumu, python –m SimpleHTTPServer 8000 komutuyla geçerli dizine hizmet vermek üzere 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ısını http://localhost:8000 adresine yönlendirmeniz yeterlidir.
JUnit test günlüğüne dönüştürme
Birçok test otomasyon sistemi, JUnit çıktısından test çalıştırması sonuç raporları oluşturabilir. Deqp test günlük dosyaları, testlog-to-junit aracı kullanılarak JUnit çıktı formatına dönüştürülebilir.
Araç şu anda yalnızca test senaryosu kararının çevrilmesini desteklemektedir. JUnit yalnızca "geçti" ve "başarısız" sonuçlarını desteklediğinden, deqp'nin geçen sonucu "JUnit pass" ile eşlenir ve diğer sonuçlar başarısızlık olarak kabul edilir. Orijinal deqp sonuç kodu JUnit çıktısında mevcuttur. Günlük mesajları ve sonuç görüntüleri gibi diğer veriler dönüşümde korunmaz.
Özel test gruplarını kullanın
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ü bir yetersiz bellek hatası bildirene kadar belirli kaynakları tekrar tekrar tahsis ederek yetersiz bellek koşullarını uygular.
Android ve Linux türlerinin çoğu gibi belirli platformlarda aşağıdakiler meydana gelebilir: İşletim sistemi, sürücünün bellek yetersiz hatasını işlemesine veya başka şekilde sağlamasına izin vermek yerine test işlemini sonlandırabilir. Bu tür platformlarda, yetersiz bellek hatalarına neden olacak şekilde tasarlanan 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 davranıp davranmadığını kontrol etmek için bu tür testleri manuel olarak çalıştırmanız önerilir. Ancak böyle bir durumda test sürecinin çökmesi başarılı olarak yorumlanmalıdır.
Test grupları
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Uzun süreli görüntü oluşturma stres testleri
İşleme stres testleri, sürekli işleme yükü altında sağlamlık sorunlarını ortaya çıkarmak için tasarlanmıştır. Varsayılan olarak testler yalnızca birkaç yineleme yürütür, ancak --deqp-test-iteration-count=-1 komut satırı argümanı sağlanarak süresiz olarak çalışacak şekilde yapılandırılabilirler. Bu testleri uzun süre çalıştırırken test gözlemcisi --deqp-watchdog=disable ).
Test grupları
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2024-03-18 UTC.