Testowanie w ramach programu jakości drawElements

Ostrzeżenie: ta strona nie jest aktualizowana i zostanie wycofana. Aktualne informacje znajdziesz w tych artykułach:

• Wiki VK-GL-CTS dla członków Khronos
• Wiki VK-GL-CTS dla osób spoza Khronos

AOSP zawiera pakiet testów GPU drawElements Quality Program (deqp) dostępny pod adresem https://android.googlesource.com/platform/external/deqp. Na tej stronie znajdziesz szczegółowe informacje o wdrażaniu pakietu testów deqp w nowym środowisku.

Aby pracować z najnowszym przesłanym kodem, użyj gałęzi deqp-dev. W przypadku kodu, który pasuje do konkretnej wersji CTS na Androida, użyj gałęzi release-code-name-release (np. w przypadku Androida 6.0 użyj gałęzi marshmallow-release).

Układ źródłowy

Układ kodu źródłowego modułów testowych deqp i bibliotek pomocniczych przedstawiono w tabeli poniżej (lista nie jest wyczerpująca, ale zawiera najważniejsze katalogi).

Katalog	Opis
android	Źródła testerów Androida i skrypty kompilacji
data	Pliki danych testowych
modules	Źródła modułu testowego
modules/egl	Moduł EGL
modules/gles2	Moduł GLES2
modules/gles3	Moduł GLES3
modules/gles31	Moduł GLES3.1
modules/gles32	Moduł GLES3.2
targets	Pliki konfiguracji kompilacji dotyczące konkretnego elementu docelowego
framework	platforma i narzędzia modułu testowego deqp,
framework/delibs	Podstawowa przenośność i biblioteki kompilacji
framework/platform	Porty platformy
framework/qphelper	Biblioteka integracji programu testów (C)
framework/common	Deqp framework (C++)
framework/opengl, framework/egl	Narzędzia związane z interfejsem API
execserver	Źródło ExecServer po stronie urządzenia
executor	Narzędzie powłoki wykonawcy testów po stronie hosta i narzędzia
external	Utwórz katalog stub dla bibliotek zewnętrznych libpng i zlib.

Komponenty open source

Pakiet deqp korzysta z plików libpng i zlib, które można pobrać za pomocą skryptu platform/external/deqp/external/fetch_sources.py lub za pomocą Gita z platform/external/[libpng,zlib].

Tworzenie programów testowych

Platforma testowa została zaprojektowana z myślą o możliwości przenoszenia. Jedynymi obowiązkowymi wymaganiami są pełna obsługa C++ i standardowe biblioteki systemowe do obsługi wejścia/wyjścia, wątków i gniazd.

System kompilacji CMake

Źródła deqp zawierają skrypty kompilacji dla CMake, które są preferowanym narzędziem do kompilowania programów testowych.

CMake to system kompilacji typu open source, który obsługuje wiele platform i zestawów narzędzi. CMake generuje natywne pliki makefile lub pliki projektu IDE z niezależnych od platformy plików konfiguracyjnych. Więcej informacji o CMake znajdziesz w dokumentacji CMake.

CMake obsługuje i zaleca kompilacje poza drzewem źródłowym, tzn. pliki makefile lub pliki projektu należy zawsze tworzyć w osobnym katalogu kompilacji poza drzewem źródłowym. CMake nie ma żadnego rodzaju celu „distclean”, więc usuwanie plików wygenerowanych przez CMake musi być wykonywane ręcznie.

Opcje konfiguracji są przekazywane do CMake za pomocą składni -DOPTION_NAME=VALUE. Poniżej znajdziesz niektóre z najczęściej używanych opcji deqp.

Opcja konfiguracji	Opis
DEQP_TARGET	Nazwa platformy docelowej, np. „android” Skrypty CMake deqp będą zawierać plik targets/DEQP_TARGET/DEQP_TARGET.cmake i oczekiwać, że znajdą w nim opcje kompilacji specyficzne dla danego urządzenia.
CMAKE_TOOLCHAIN_FILE	Ścieżka do pliku łańcucha narzędzi dla CMake. Używany do kompilacji krzyżowej.
CMAKE_BUILD_TYPE	Typ kompilacji dla celów pliku makefile. Prawidłowe wartości to: „Debug” i „Release”. Interpretacja i domyślny typ zależą od docelowego systemu kompilacji. Szczegółowe informacje znajdziesz w dokumentacji CMake.

Tworzenie docelowego pliku kompilacji

System kompilacji deqp jest konfigurowany dla nowych platform za pomocą plików kompilacji platformy. Plik docelowej wersji określa, które funkcje są obsługiwane przez platformę oraz jakie biblioteki lub dodatkowe ścieżki dołączania są wymagane. Nazwy plików docelowych mają format targets/NAME/NAME.cmake, a element docelowy jest wybierany za pomocą parametru kompilacji DEQP_TARGET.

Ścieżki plików w plikach docelowych są względne względem katalogu podstawowego deqp, a nie katalogu targets/NAME. W pliku kompilacji docelowej można ustawić te standardowe zmienne:

Zmienna	Opis
DEQP_TARGET_NAME	Nazwa elementu docelowego (zostanie uwzględniona w dziennikach testu)
DEQP_SUPPORT_GLES2	Określa, czy GLES2 jest obsługiwany (domyślnie: WYŁ.).
DEQP_GLES2_LIBRARIES	Biblioteki GLES2 (pozostaw puste, jeśli nie są obsługiwane lub używane jest dynamiczne wczytywanie)
DEQP_SUPPORT_GLES3	Określa, czy obsługiwany jest interfejs GLES3.x (domyślnie: WYŁ.).
DEQP_GLES3_LIBRARIES	Biblioteki GLES3.x (pozostaw puste, jeśli nie są obsługiwane lub używane jest ładowanie dynamiczne)
DEQP_SUPPORT_VG	Określa, czy OpenVG jest obsługiwany (domyślnie: WYŁ.).
DEQP_OPENVG_LIBRARIES	Biblioteki OpenVG (pozostaw puste, jeśli nie są obsługiwane lub używane jest ładowanie dynamiczne)
DEQP_SUPPORT_EGL	Określa, czy EGL jest obsługiwany (domyślnie: WYŁ.).
DEQP_EGL_LIBRARIES	Biblioteki EGL (pozostaw puste, jeśli nie są obsługiwane lub używane jest dynamiczne wczytywanie)
DEQP_PLATFORM_LIBRARIES	Dodatkowe biblioteki wymagane do łączenia na poszczególnych platformach
DEQP_PLATFORM_COPY_LIBRARIES	Lista bibliotek, które są kopiowane do każdego katalogu kompilacji binarnej testu. Może służyć do kopiowania bibliotek potrzebnych do przeprowadzania testów, ale nieznajdujących się w domyślnej ścieżce wyszukiwania.
TCUTIL_PLATFORM_SRCS	Lista źródeł portów platformy. Domyślne źródła są określane na podstawie możliwości i systemu operacyjnego. Uwaga: ścieżki są wyświetlane względem: framework/platform

Docelowy plik kompilacji może dodawać dodatkowe ścieżki dołączania lub łączenia za pomocą funkcji CMake include_directories() i link_directories().

Wersja Win32

Najprostszym sposobem tworzenia modułów deqp dla systemu Windows jest użycie systemu kompilacji CMake. Wymagane są CMake 2.6.12 lub nowszy oraz kompilator Microsoft Visual C/C++. Biblioteka deqp została przetestowana w Visual Studio 2013.

Pliki projektu Visual Studio można wygenerować za pomocą tego polecenia:

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

Aby utworzyć kompilację 64-bitową, wybierz „Visual Studio VERSION Win64” jako generator kompilacji:

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

Możesz też wygenerować pliki makefile NMake za pomocą opcji -G "NMake Makefiles" oraz typu kompilacji (-DCMAKE_BUILD_TYPE="Debug" lub "Release").

Tworzenie kontekstu renderowania

Kontekst renderowania można utworzyć za pomocą WGL lub EGL w systemie Windows.

Obsługa WGL

Wszystkie pliki binarne Win32 obsługują tworzenie kontekstu GL za pomocą WGL, ponieważ wymaga to tylko standardowych bibliotek. Kontekst WGL można wybrać za pomocą argumentu wiersza poleceń --deqp-gl-context-type=wgl. W trybie WGL deqp używa rozszerzenia WGL_EXT_create_context_es_profiledo tworzenia kontekstów OpenGL ES. Zostało to przetestowane pod kątem działania z najnowszymi sterownikami NVIDIA i Intel. Sterowniki AMD nie obsługują wymaganego rozszerzenia.

Obsługa EGL

Biblioteka deqp jest kompilowana z dynamicznym ładowaniem EGL w systemie Windows, jeśli DEQP_SUPPORT_EGL jest włączone. Jest to domyślne ustawienie w przypadku większości miejsc docelowych. Jeśli host ma dostępne biblioteki EGL, można uruchomić testy z ich użyciem za pomocą parametru wiersza poleceń: --deqp-gl-context-type=egl

Kompilacja Androida

W przypadku kompilacji na Androida do tworzenia natywnego kodu testowego używane są skrypty kompilacji CMake. Części w języku Java, czyli serwer wykonywania testów i stub aplikacji testowej, są kompilowane za pomocą standardowych narzędzi do kompilacji na Androida.

Aby skompilować programy testowe deqp na Androida za pomocą podanych skryptów kompilacji, potrzebujesz:

• Najnowsza wersja Android NDK. W pliku android/scripts/common.py znajduje się lista wymaganych wersji.
• Zainstalowane pakiety samodzielnego pakietu SDK na Androida z API 13, narzędziami SDK, narzędziami platformy SDK i narzędziami do kompilacji SDK.
• Apache Ant 1.9.4 (wymagany do kompilacji kodu w Javie)
• CMake 2.8.12 lub nowszy
• Python 2.6 lub nowszy z serii 2.x; Python 3.x nie jest obsługiwany
• W systemie Windows: NMake lub JOM w PATH
  • JOM umożliwia szybsze kompilowanie
• Opcjonalnie: Ninja make jest też obsługiwany w systemie Linux.

Pliki binarne Ant i pakietu SDK są lokalizowane na podstawie zmiennej środowiskowej PATH z określonymi domyślnymi ustawieniami zastępującymi. Logika jest kontrolowana przez android/scripts/common.py.

Katalog NDK musi być określony jako ~/android-ndk-VERSION lub C:/android/android-ndk-VERSION albo zdefiniowany za pomocą zmiennej środowiskowej ANDROID_NDK_PATH.

Komponenty Deqp na urządzeniu, usługa wykonywania testów i programy testowe są tworzone przez wykonanie skryptu android/scripts/build.py. Ostateczny plik APK jest tworzony w katalogu android/package/bin i może zostać zainstalowany przez skrypt install.py. Jeśli używany jest wykonawca wiersza poleceń, usługa ExecService jest uruchamiana za pomocą skryptu launch.py na urządzeniu przez ADB. Skrypty można uruchamiać z dowolnego katalogu.

Wersja Linuksa

Pliki binarne testów i narzędzia wiersza poleceń można tworzyć na potrzeby systemu Linux, generując pliki makefile za pomocą CMake. Podczas tworzenia aplikacji na Linuksa możesz używać wielu wstępnie zdefiniowanych celów kompilacji.

Kompilowanie elementu docelowego	Opis
default	Domyślny element docelowy, który używa introspekcji platformy CMake do określania obsługi różnych interfejsów API.
x11_glx	Używa GLX do tworzenia kontekstów OpenGL (ES).
x11_egl	Używa EGL do tworzenia kontekstów OpenGL (ES).
x11_egl_glx	Obsługuje GLX i EGL z X11.

Zawsze używaj -DCMAKE_BUILD_TYPE=<Debug|Release> do określania typu kompilacji. Dobrą wartością domyślną jest Release. Bez niego tworzona jest domyślna, niezoptymalizowana wersja.

Argumenty wiersza poleceń -DCMAKE_C_FLAGS i -DCMAKE_CXX_FLAGS można wykorzystać do przekazywania dodatkowych argumentów do kompilatora. Na przykład kompilację 32-bitową lub 64-bitową można przeprowadzić, ustawiając odpowiednio -DCMAKE_C(XX)_FLAGS="-m32" lub "-m64". Jeśli nie zostanie określona, używana jest natywna architektura łańcucha narzędzi, zwykle 64-bitowa w przypadku 64-bitowego łańcucha narzędzi.

Argumenty -DCMAKE_LIBRARY_PATH i -DCMAKE_INCLUDE_PATH mogą być używane w CMake do podawania dodatkowych ścieżek wyszukiwania bibliotek lub plików nagłówkowych.

Oto przykład pełnego wiersza poleceń używanego do tworzenia 32-bitowej wersji debugowania na podstawie plików nagłówkowych i bibliotek sterowników w niestandardowej lokalizacji:

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

Kompilacja skrośna

Kompilację krzyżową można przeprowadzić za pomocą pliku łańcucha narzędzi CMake. Plik łańcucha narzędzi określa kompilator, którego należy użyć, oraz niestandardowe ścieżki wyszukiwania bibliotek i plików nagłówkowych. W pakiecie wersji w katalogu framework/delibs/cmake znajduje się kilka plików łańcucha narzędzi dla typowych scenariuszy.

Oprócz standardowych zmiennych CMake w pliku łańcucha narzędzi można ustawić te zmienne specyficzne dla deqp: CMake zwykle prawidłowo wykrywa DE_OS, DE_COMPILER i DE_PTR_SIZE, ale DE_CPU musi być ustawiony przez plik łańcucha narzędzi.

Zmienna	Opis
DE_OS	System operacyjny. Obsługiwane wartości: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS
DE_COMPILER	Typ kompilatora. Obsługiwane wartości: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG
DE_CPU	Typ procesora. Obsługiwane wartości to: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE	sizeof(void*) na platformie. Obsługiwane wartości to: 4 i 8

Plik łańcucha narzędzi można wybrać za pomocą parametru kompilacji CMAKE_TOOLCHAIN_FILE. Na przykład to polecenie utworzy pliki makefile na potrzeby kompilacji z użyciem kompilatora krzyżowego CodeSourcery dla platformy ARM/Linux:

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

Łączenie bibliotek GLES i EGL w czasie działania

Podczas łączenia deqp nie potrzebuje punktów wejścia testowanego interfejsu API. Kod testowy zawsze uzyskuje dostęp do interfejsów API za pomocą wskaźników funkcji. Punkty wejścia można następnie wczytywać dynamicznie w czasie działania lub port platformy może je udostępniać w czasie łączenia.

Jeśli obsługa interfejsu API jest włączona w ustawieniach kompilacji, a biblioteki linków nie są dostępne, deqp wczyta potrzebne punkty wejścia w czasie działania. Jeśli chcesz użyć linkowania statycznego, podaj potrzebne biblioteki linków w zmiennej konfiguracji kompilacji DEQP_<API>_LIBRARIES.

Przenoszenie platformy testowej

Przenoszenie deqp obejmuje 3 etapy: dostosowanie podstawowych bibliotek przenośności, wdrożenie interfejsów integracji platformy z ramami testowymi i przeniesienie usługi wykonywania.

W tabeli poniżej znajdziesz lokalizacje, w których prawdopodobnie nastąpią zmiany w przenoszeniu numerów. Wszystko, co wykracza poza te zakresy, jest prawdopodobnie egzotyczne.

Lokalizacja	Opis
framework/delibs/debase framework/delibs/dethread framework/delibs/deutil	Wszelkie niezbędne implementacje kodu specyficznego dla systemu operacyjnego.
framework/qphelper/qpCrashHandler.c	Opcjonalnie: implementacja dla Twojego systemu operacyjnego.
framework/qphelper/qpWatchDog.c	Implementacja dla Twojego systemu operacyjnego. Obecna wersja opiera się na dethread i standardowej bibliotece C.
framework/platform	Nowy port platformy i szablon aplikacji można wdrożyć zgodnie z opisem w sekcji Port platformy struktury testowej.

Podstawowe biblioteki przenoszenia

Podstawowe biblioteki przenośności obsługują już systemy Windows, większość odmian Linuxa, macOS, iOS i Android. Jeśli platforma testowa działa w jednym z tych systemów operacyjnych, najprawdopodobniej nie musisz w ogóle modyfikować podstawowych bibliotek przenośności.

Port platformy struktury testowej

Port platformy struktury testowej deqp wymaga 2 komponentów: punktu wejścia aplikacji i implementacji interfejsu platformy.

Punkt wejścia aplikacji jest odpowiedzialny za utworzenie obiektu platformy, utworzenie obiektu wiersza poleceń (tcu::CommandLine), otwarcie dziennika testu (tcu::TestLog) i iterowanie aplikacji testowej (tcu::App). Jeśli docelowy system operacyjny obsługuje standardowy punkt wejścia main(), można użyć tcuMain.cpp jako implementacji punktu wejścia.

Interfejs API platformy deqp jest szczegółowo opisany w tych plikach.

Plik	Opis
framework/common/tcuPlatform.hpp	Klasa bazowa dla wszystkich portów platformy
framework/opengl/gluPlatform.hpp	Interfejs platformy OpenGL
framework/egl/egluPlatform.hpp	Interfejs platformy EGL
framework/platform/tcuMain.cpp	Standardowy punkt wejścia aplikacji

Klasą bazową wszystkich portów platformy jest tcu::Platform. Port platformy może opcjonalnie obsługiwać interfejsy specyficzne dla GL i EGL. W tabeli poniżej znajdziesz omówienie elementów, które należy wdrożyć, aby przeprowadzić testy.

Moduł	Interfejs
Moduły testowe OpenGL (ES)	Interfejs platformy GL
Moduł testowy EGL	Interfejs platformy EGL

Szczegółowe instrukcje dotyczące implementacji portów platformy znajdziesz w plikach nagłówkowych warstwy przenoszenia.

Usługa wykonywania testów

Aby korzystać z infrastruktury wykonywania testów deqp lub narzędzia do wykonywania wiersza poleceń, usługa wykonywania testów musi być dostępna na urządzeniu docelowym. Przenośna implementacja usługi w języku C++ jest dostępna w katalogu execserver. Samodzielny plik binarny jest tworzony w ramach kompilacji modułu testowego deqp na potrzeby komputerów. Możesz zmodyfikować execserver/CMakeLists.txt, aby umożliwić tworzenie na innych platformach.

Wersja usługi wykonywania testów w C++ akceptuje 2 parametry wiersza poleceń:

• --port=<port> ustawi port TCP, na którym nasłuchuje serwer. Wartość domyślna to 50016.
• --single zakończy proces serwera, gdy klient się rozłączy. Domyślnie proces serwera pozostanie aktywny, aby obsługiwać kolejne żądania wykonania testu.

Przeprowadzanie testów

Na tej stronie znajdziesz instrukcje uruchamiania testów deqp w środowiskach Linux i Windows, używania argumentów wiersza poleceń oraz pracy z pakietem aplikacji na Androida.

Środowiska Linux i Windows

Zacznij od skopiowania tych plików i katalogów do miejsca docelowego.

Moduł	Katalog	Target
Serwer wykonawczy	build/execserver/execserver	<dst>/execserver
Moduł EGL	build/modules/egl/deqp-egl	<dst>/deqp-egl
Moduł GLES2	build/modules/gles2/deqp-gles2	<dst>/deqp-gles2
	data/gles2	<dst>/gles2
Moduł GLES3	build/modules/gles3/deqp-gles3	<dst>/deqp-gles3
	data/gles3	<dst>/gles3
Moduł GLES3.1	build/modules/gles31/deqp-gles31	<dst>/deqp-gles31
	data/gles31	<dst>/gles31
Moduł GLES3.2	build/modules/gles32/deqp-gles32	<dst>/deqp-gles32
	data/gles32	<dst>/gles32

Usługę wykonywania i testowe pliki binarne możesz wdrożyć w dowolnym miejscu w docelowym systemie plików. Testowe pliki binarne oczekują jednak, że katalogi danych będą znajdować się w bieżącym katalogu roboczym. Gdy wszystko będzie gotowe, uruchom usługę wykonywania testów na urządzeniu docelowym. Więcej informacji o uruchamianiu usługi znajdziesz w artykule Usługa wykonywania testów.

Argumenty wiersza poleceń

W tabeli poniżej znajdziesz argumenty wiersza poleceń, które wpływają na wykonywanie wszystkich programów testowych.

Argument	Opis
--deqp-case=<casename>	Uruchamiaj testy pasujące do danego wzorca. Symbol wieloznaczny (*) jest obsługiwany.
--deqp-log-filename=<filename>	Zapisz wyniki testu w pliku o podanej nazwie. Usługa wykonywania testów ustawi nazwę pliku podczas rozpoczynania testu.
--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>	Odczytuje listę zgłoszeń ze standardowego wejścia lub z podanego argumentu. Usługa wykonania testu ustawi argument zgodnie z otrzymanym żądaniem wykonania. Opis formatu listy spraw znajdziesz w następnej sekcji.
--deqp-test-iteration-count=<count>	Zastąp liczbę iteracji w przypadku testów, które obsługują zmienną liczbę iteracji.
--deqp-base-seed=<seed>	Podstawowy punkt początkowy dla przypadków testowych, które korzystają z randomizacji.

Argumenty specyficzne dla GLES2 i GLES3

W tabeli poniżej znajdziesz argumenty specyficzne dla GLES2 i GLES3.

Argument	Opis
--deqp-gl-context-type=<type>	Typ kontekstu OpenGL. Dostępne typy kontekstu zależą od platformy. Na platformach obsługujących EGL wartość egl może służyć do wybierania kontekstu EGL.
--deqp-gl-config-id=<id>	Przeprowadź testy dla podanego identyfikatora konfiguracji GL. Interpretacja zależy od platformy. Na platformie EGL jest to identyfikator konfiguracji EGL.
--deqp-gl-config-name=<name>	Uruchamia testy dla konfiguracji GL o określonej nazwie. Interpretacja zależy od platformy. W przypadku EGL format to rgb(a)<bits>d<bits>s<bits>. Na przykład wartość rgb888s8 wybierze pierwszą konfigurację, w której bufor kolorów ma format RGB888, a bufor szablonu ma 8 bitów.
--deqp-gl-context-flags=<flags>	Tworzy kontekst. Określ robust lub debug.
--deqp-surface-width=<width> --deqp-surface-height=<height>	Spróbuj utworzyć powierzchnię o określonym rozmiarze. Obsługa tego parametru jest opcjonalna.
--deqp-surface-type=<type>	Użyj danego typu powierzchni jako głównego miejsca renderowania testu. Możliwe typy to window, pixmap, pbuffer i fbo.
--deqp-screen-rotation=<rotation>	Orientacja ekranu w krokach co 90 stopni na platformach, które ją obsługują.

Format listy przypadków testowych

Listę przypadków testowych można podać w 2 formatach. Pierwsza opcja to umieszczenie pełnej nazwy każdego testu w osobnym wierszu w standardowym pliku ASCII. W miarę powiększania się zestawów testowych powtarzające się prefiksy mogą być uciążliwe. Aby uniknąć powtarzania prefiksów, użyj składni drzewa trie (znanego też jako drzewo prefiksowe) pokazanej poniżej.

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

Na przykład:

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

Przekłada się to na te 2 przypadki testowe:

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

Android

Pakiet aplikacji na Androida zawiera wszystkie wymagane komponenty, w tym usługę wykonywania testów, pliki binarne testów i pliki danych. Aktywność testowa to NativeActivity korzystająca z EGL (wymaga Androida 3.2 lub nowszego).

Pakiet aplikacji można zainstalować za pomocą tego polecenia (nazwa pokazana to nazwa pliku APK w pakiecie Android CTS; nazwa zależy od kompilacji):

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

Aby uruchomić usługę wykonywania testów i skonfigurować przekierowanie portów, użyj tego polecenia:

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

Drukowanie debugowania można włączyć, wykonując przed rozpoczęciem testów to polecenie:

adb –d shell setprop log.tag.dEQP DEBUG

Przeprowadzanie testów na Androidzie bez pakietu Android CTS

Aby ręcznie rozpocząć działanie związane z wykonywaniem testu, utwórz intencję Androida, która jest kierowana na android.app.NativeActivity. Działania można znaleźć w pakiecie com.drawelements.deqp. Wiersz poleceń musi być podany jako dodatkowy ciąg znaków z kluczem "cmdLine" w obiekcie Intent.

Log testowy jest zapisywany w /sdcard/dEQP-log.qpa. Jeśli test nie rozpocznie się normalnie, dodatkowe informacje do debugowania będą dostępne w dzienniku urządzenia.

Aktywność możesz uruchomić z poziomu wiersza poleceń za pomocą narzędzia am. Aby na przykład uruchomić testy dEQP-GLES2.info na platformie obsługującej NativeActivity,, użyj tych poleceń.

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

Debugowanie na Androidzie

Aby uruchomić testy w debugerze GDB na Androidzie, najpierw skompiluj i zainstaluj kompilację debugowania, uruchamiając te 2 skrypty:

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

Po zainstalowaniu na urządzeniu wersji debugowania, aby uruchomić testy w GDB działającym na hoście, wykonaj to polecenie:

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

Wiersz poleceń deqp zależy od testów do wykonania i innych wymaganych parametrów. Skrypt dodaje domyślny punkt przerwania na początku wykonywania deqp (tcu::App::App).

Skrypt debug.py akceptuje wiele argumentów wiersza poleceń dotyczących działań takich jak ustawianie punktów przerwania na potrzeby debugowania, parametry połączenia z gdbserverem i ścieżki do dodatkowych plików binarnych do debugowania (użyj debug.py --help, aby wyświetlić wszystkie argumenty i wyjaśnienia). Skrypt kopiuje też niektóre domyślne biblioteki z urządzenia docelowego, aby uzyskać listę symboli.

Aby przejść przez kod sterownika (np. gdy GDB musi znać lokalizacje plików binarnych z pełnymi informacjami do debugowania), dodaj więcej bibliotek za pomocą parametrów wiersza poleceńdebug.py. Ten skrypt zapisuje plik konfiguracji GDB, zaczynając od wiersza 132 pliku skryptu. Możesz podać dodatkowe ścieżki do plików binarnych itp., ale wystarczy podać prawidłowe parametry wiersza poleceń.

Uwaga: w systemie Windows plik binarny GDB wymaga libpython2.7.dll. Przed uruchomieniem debug.py dodaj <path-to-ndk>/prebuilt/windows/bin do zmiennej PATH.

Uwaga: debugowanie kodu natywnego nie działa w przypadku standardowej wersji Androida 4.3. Aby znaleźć obejścia tego problemu, zapoznaj się z  tym publicznym zgłoszeniem błędu. Ten błąd nie występuje w Androidzie 4.4 i nowszym.

Automatyzacja testów

Moduły testowe Deqp można zintegrować z automatycznymi systemami testowymi na wiele sposobów. Najlepsze podejście zależy od istniejącej infrastruktury testowej i środowiska docelowego.

Głównym wynikiem testu jest zawsze plik dziennika testu, czyli plik z przyrostkiem .qpa. Pełne wyniki testu można przeanalizować na podstawie dziennika testu. Dane wyjściowe konsoli to tylko informacje debugowania, które mogą nie być dostępne na wszystkich platformach.

Pliki binarne testów można wywoływać bezpośrednio z systemu automatyzacji testów. Plik binarny testu można uruchomić w przypadku konkretnego przypadku, zestawu testów lub wszystkich dostępnych testów. Jeśli podczas wykonywania testu wystąpi błąd krytyczny (np. niektóre błędy API lub awaria), test zostanie przerwany. W przypadku testów regresji najlepszym rozwiązaniem jest wywoływanie plików binarnych testów dla poszczególnych przypadków lub małych zestawów testów oddzielnie, aby mieć dostępne częściowe wyniki nawet w przypadku poważnej awarii.

Pakiet deqp zawiera narzędzia do wykonywania testów w wierszu poleceń, które można stosować w połączeniu z usługą wykonywania, aby uzyskać bardziej niezawodną integrację. Wykonawca wykrywa zakończenie procesu testowania i wznawia wykonywanie testu w przypadku następnego dostępnego testu. Z całej sesji testowej powstaje jeden plik dziennika. Ta konfiguracja jest idealna w przypadku lekkich systemów testowych, które nie zapewniają możliwości przywracania po awarii.

Narzędzia do wykonywania testów w wierszu poleceń

Obecny zestaw narzędzi wiersza poleceń obejmuje narzędzie do zdalnego wykonywania testów, generator porównania dzienników testów do analizy regresji, konwerter dzienników testów na CSV, konwerter dzienników testów na XML i konwerter dzienników testów na JUnit.

Kod źródłowy tych narzędzi znajduje się w katalogu executor, a pliki binarne są tworzone w katalogu <builddir>/executor.

Wykonawca testów wiersza poleceń

Wykonawca testów wiersza poleceń to przenośne narzędzie w C++ do uruchamiania testów na urządzeniu i zbierania z niego dzienników przez TCP/IP. Wykonawca komunikuje się z usługą wykonywania (execserver) na urządzeniu docelowym. Razem zapewniają funkcje takie jak przywracanie po awariach procesu testowania. Poniższe przykłady pokazują, jak używać narzędzia Test Executor w wierszu poleceń (więcej informacji znajdziesz w --help):

Przykład 1. Uruchamianie testów funkcjonalnych GLES2 na urządzeniu z Androidem

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"

Przykład 2. Kontynuowanie częściowego testu OpenGL ES 2 lokalnie

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

Eksportowanie i porównywanie dziennika testów w formacie CSV

Pakiet deqp zawiera narzędzie do konwertowania dzienników testów (plików .qpa) na pliki CSV. Plik CSV zawiera listę przypadków testowych i ich wyników. Narzędzie może też porównać co najmniej 2 zestawy wyników i wyświetlić tylko te przypadki testowe, które mają różne kody stanu w zestawach wyników wejściowych. Porównanie będzie też zawierać liczbę pasujących zgłoszeń.

Dane wyjściowe w formacie CSV są bardzo przydatne do dalszego przetwarzania za pomocą standardowych narzędzi wiersza poleceń lub edytora arkuszy kalkulacyjnych. Dodatkowy, czytelny dla człowieka format w postaci zwykłego tekstu można wybrać za pomocą tego argumentu wiersza poleceń: --format=text

Przykład 1. Eksportowanie dziennika testu w formacie CSV

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

Przykład 2. Wymień różnice w wynikach testów między 2 logami testów.

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

Uwaga: argument --value=code zwraca kod wyniku testu, np. „Pass” (Zdany) lub „Fail” (Niezdany). Argument --value=details wybiera dalsze wyjaśnienie wyniku lub wartości liczbowej uzyskanej w teście wydajności, możliwości lub dokładności.

Testowanie eksportu dziennika do pliku XML

Pliki dziennika testów można przekonwertować na prawidłowe dokumenty XML za pomocą narzędzia testlog-to-xml. Obsługiwane są 2 tryby wyjściowe:

• Tryb oddzielnych dokumentów, w którym każdy przypadek testowy i dokument caselist.xmlpodsumowaniacaselist.xml są zapisywane w katalogu docelowym.
• Tryb pojedynczego pliku, w którym wszystkie wyniki w pliku .qpa są zapisywane w jednym dokumencie XML.

Wyeksportowane pliki dziennika testu można wyświetlić w przeglądarce za pomocą arkusza stylów XML. Przykładowe dokumenty arkusza stylów (testlog.xsl i testlog.css) znajdują się w katalogu doc/testlog-stylesheet. Aby wyświetlić pliki dziennika w przeglądarce, skopiuj 2 pliki arkusza stylów do tego samego katalogu, w którym znajdują się wyeksportowane dokumenty XML.

Jeśli używasz Google Chrome, dostęp do plików musi być możliwy przez protokół HTTP, ponieważ Chrome ogranicza dostęp do plików lokalnych ze względów bezpieczeństwa. Standardowa instalacja Pythona zawiera podstawowy serwer HTTP, który można uruchomić, aby obsługiwać bieżący katalog za pomocą polecenia python –m SimpleHTTPServer 8000. Po uruchomieniu serwera wystarczy skierować przeglądarkę Chrome na adres http://localhost:8000, aby wyświetlić dziennik testu.

Konwersja na dziennik testu JUnit

Wiele systemów automatyzacji testów może generować raporty z wynikami testów na podstawie danych wyjściowych JUnit. Pliki logów testów deqp można przekonwertować na format wyjściowy JUnit za pomocą narzędzia testlog-to-junit.

Obecnie narzędzie obsługuje tylko tłumaczenie wyniku testu. JUnit obsługuje tylko wyniki „pass” i „fail”, więc wynik „pass” testu deqp jest mapowany na „JUnit pass”, a pozostałe wyniki są traktowane jako błędy. Oryginalny kod wyniku deqp jest dostępny w danych wyjściowych JUnit. Inne dane, takie jak wiadomości z dziennika i obrazy wyników, nie są zachowywane podczas konwersji.

Korzystanie ze specjalnych grup testowych

Niektóre grupy testowe mogą wymagać specjalnych opcji wiersza poleceń lub je obsługiwać, a także wymagać szczególnej uwagi podczas używania w określonych systemach.

Testy obciążeniowe alokacji pamięci

Testy obciążeniowe przydzielania pamięci sprawdzają warunki braku pamięci, wielokrotnie przydzielając określone zasoby, dopóki sterownik nie zgłosi błędu braku pamięci.

Na niektórych platformach, takich jak Android i większość wariantów systemu Linux, może wystąpić następująca sytuacja: system operacyjny może zakończyć proces testowy zamiast zezwolić sterownikowi na obsługę błędu braku pamięci lub jego zgłoszenie. Na takich platformach testy, które mają powodować błędy braku pamięci, są domyślnie wyłączone i muszą być włączane za pomocą argumentu wiersza poleceń --deqp-test-oom=enable. Zalecamy ręczne przeprowadzanie takich testów, aby sprawdzić, czy system działa prawidłowo przy dużym obciążeniu zasobów. W takiej sytuacji awarię procesu testowego należy jednak interpretować jako zaliczenie.

Grupy testowe

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

Długotrwałe testy obciążeniowe renderowania

Testy przeciążeniowe renderowania mają na celu wykrycie problemów z wytrzymałością podczas ciągłego obciążenia renderowaniem. Domyślnie testy wykonują tylko kilka iteracji, ale można je skonfigurować tak, aby działały w nieskończoność, podając argument wiersza poleceń --deqp-test-iteration-count=-1. Podczas przeprowadzania tych testów przez dłuższy czas należy wyłączyć funkcję nadzoru testu (--deqp-watchdog=disable).

Grupy testowe

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