Testowanie programu jakości DrawElements

AOSP obejmuje pakiet testowania GPU DrawElements Quality Program (deqp) dostępny pod adresem https://android.googlesource.com/platform/external/deqp Na tej stronie dowiesz się, jak wdrożyć pakiet testowania deqp w nowym środowisku.

Aby pracować z ostatnio przesłanym kodem, użyj gałęzi deqp-dev. Jeśli kod pasuje do konkretnej wersji Androida CTS, użyj Gałąź 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 to widoczne w tabeli poniżej (lista nie jest wyczerpująca, ale podkreśla z najważniejszych katalogów).

Katalog Opis
android

Źródła testów i skrypty kompilacji dla testerów Androida
data

Testowe pliki danych
modules

Testowanie źródeł modułu
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 dla danego miejsca docelowego
framework

Struktura modułu testowania deqp i narzędzia
framework/delibs

Podstawowe funkcje przenoszenia i biblioteki kompilacji
framework/platform

Porty platformy
framework/qphelper

Biblioteka integracji programu testowego (C)
framework/common

Platforma Deqp (C++)
framework/opengl, framework/egl

Narzędzia typowe dla interfejsu 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 zewnętrznych bibliotek libpng i zlib

Komponenty open source

Deqp używa parametrów libpng i zlib, które mogą zostać pobrane używając skryptu platform/external/deqp/external/fetch_sources.py lub przez git od platform/external/[libpng,zlib].

Tworzenie programów testowych

Platforma testowa została opracowana z myślą o przenośności. Jedyna wymagane wymagania to pełna obsługa języka C++ i standardowe biblioteki systemowe I/O, nici i gniazda.

System kompilacji CMake

Źródła deqp mają skrypty kompilacji dla CMake, które jest preferowanym narzędziem do tworząc programy testowe.

CMake to system kompilacji typu open source, który obsługuje wiele platform i łańcuchów narzędzi. CMake generuje natywne pliki programu Makefile lub pliki projektu IDE na podstawie plików konfiguracji niezależnych od miejsca docelowego. Więcej informacji o CMake znajdziesz w CMake.

CMake wspiera i rekomenduje kompilacje zewnętrzne, zawsze twórz pliki MakerFile lub pliki projektu w osobnym katalogu kompilacji. poza drzewem źródłowym. CMake nie ma w ogóle żadnych „wyraźnych” docelowy, więc trzeba usunąć pliki wygenerowane przez CMake ręcznie.

Opcje konfiguracji są udostępniane usłudze CMake za pomocą -DOPTION_NAME=VALUE składni. Poniżej znajdziesz niektóre często używane opcje deqp.

Opcja konfiguracji Opis
DEQP_TARGET

Nazwa docelowa, np. „android”

Skrypty deqp CMake będą zawierać plik targets/DEQP_TARGET/DEQP_TARGET.cmake i spodziewaj się znaleźć odpowiednie opcje kompilacji.
CMAKE_TOOLCHAIN_FILE

Ścieżka do pliku łańcucha narzędzi CMake. Używana do kompilacji krzyżowej.
CMAKE_BUILD_TYPE

Typ kompilacji dla elementów docelowych pliku Makefile. Prawidłowe wartości to: „Debugowanie” i „Wydanie”

Pamiętaj, że 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 skonfigurowany pod kątem nowych celów za pomocą docelowych plików kompilacji. Docelowy plik kompilacji określa, które funkcje obsługuje platforma oraz jakie biblioteki wymagane są dodatkowe ścieżki uwzględniania. Nazwy plików docelowych są zgodne z opisem w języku: targets/NAME/NAME.cmake format, a miejsce docelowe jest wybierane za pomocą parametru kompilacji DEQP_TARGET.

Ścieżki plików w plikach docelowych są względne wobec katalogu podstawowego deqp, a nie katalogu targets/NAME. Poniższe zmienne standardowe można ustawić za pomocą docelowego pliku kompilacji.

Zmienna Opis
DEQP_TARGET_NAME

Nazwa miejsca docelowego (zostanie uwzględniona w logach testowych)
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 ładowanie dynamiczne)
DEQP_SUPPORT_GLES3

Określa, czy GLES3.x jest obsługiwany (domyślnie: WYŁĄCZONE)
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 protokół OpenVG jest obsługiwany (domyślnie: WYŁĄCZONE)
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 obsługiwany jest tryb EGL (domyślnie: WYŁ.)
DEQP_EGL_LIBRARIES

Biblioteki EGL (pozostaw puste, jeśli nie są obsługiwane lub używane jest ładowanie dynamiczne)
DEQP_PLATFORM_LIBRARIES

Do połączenia wymagane są dodatkowe biblioteki właściwe dla danej platformy
DEQP_PLATFORM_COPY_LIBRARIES

Lista bibliotek kopiowanych do każdego testowego katalogu kompilacji binarnej. Może być używane do kopiowania bibliotek potrzebnych do prowadzenia testów, ale nie domyślnie używanych ścieżki 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ą podane względem: framework/platform

Docelowy plik kompilacji może dodać dodatkowe ścieżki „uwzględniania” lub „linki” za pomocą atrybutu Funkcje include_directories() i link_directories() CMake.

Kompilacja Win32

Najprostszym sposobem utworzenia modułów deqp dla systemu Windows jest użycie kompilacji CMake systemu. Potrzebujesz CMake w wersji 2.6.12 lub nowszej oraz pakietu Microsoft Visual C/C++ kompilatora. Zasób został przetestowany w Visual Studio 2013.

Pliki projektów 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”. a wraz z nim generator:

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

Możesz też wygenerować plik NMake za pomocą opcji -G "NMake Makefiles" jako typ kompilacji (-DCMAKE_BUILD_TYPE="Debug" lub "Release").

Tworzenie kontekstu renderowania

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

obsługa WGL

Wszystkie pliki binarne Win32 obsługują tworzenie kontekstu GL przy użyciu WGL, ponieważ wymaga to tylko bibliotek standardowych. Kontekst WGL można wybrać za pomocą funkcji --deqp-gl-context-type=wgl wiersza poleceń. W trybie WGL deqp używa interfejsu WGL_EXT_create_context_es_profile do tworzenia kontekstów OpenGL ES. To rozwiązanie zostało przetestowane pod kątem współpracy najnowsze sterowniki NVIDIA i Intel. Sterowniki AMD nie obsługują wymaganych .

Obsługa EGL

Deqp jest kompilowane z dynamicznym wczytywaniem dla EGL w systemie Windows, jeśli DEQP_SUPPORT_EGL jest WŁĄCZONE. Jest to domyślne ustawienie w większości celów. Następnie, jeśli host ma biblioteki EGL można na nich uruchamiać testy za pomocą wiersza poleceń parametr: --deqp-gl-context-type=egl

Kompilacja Androida

Kompilacja na Androida używa skryptów kompilacji CMake do tworzenia kodu natywnego do testów. Części Javy, np. serwer wykonania testów i sposób testowania aplikacji, są zostały skompilowane za pomocą standardowych narzędzi do kompilacji na Androida.

Aby kompilować programy testowe Deqp na Androida z udostępnioną kompilacją skryptów, musisz mieć:

  • Najnowsza wersja programu Android NDK; w pliku android/scripts/common.py znajduje się wymagana wersja
  • Oddzielny pakiet SDK na Androida z interfejsem API 13, SDK Tools, SDK Platform i pakietem SDK Zainstalowano pakiety Build-tools
  • Apache Ant 1.9.4 (wymagane przez kompilację kodu Java)
  • CMake w wersji 2.8.12 lub nowszej
  • Python 2.6 lub nowszy z serii 2.x; Python 3.x nie jest obsługiwany
  • Windows: NMake lub JOM w programie PATH
    • JOM umożliwia szybsze kompilacje.
  • Opcjonalnie: marka Ninja jest również obsługiwana w systemie Linux

Pliki binarne Ant i SDK są oparte na zmiennej środowiskowej PATH z parametrem pewnych zastąpień domyślnych. Logiką steruje zasada android/scripts/common.py.

Katalogiem NDK musi być ~/android-ndk-VERSION lub C:/android/android-ndk-VERSION lub zdefiniowane w usłudze ANDROID_NDK_PATH zmiennej środowiskowej.

Komponenty działające na urządzeniu, usługa wykonywania testów i programy testowe są utworzonych przez wykonanie skryptu android/scripts/build.py. Ostateczna wersja pliku APK jest tworzona w android/package/bin i można go zainstalować przy użyciu skryptu install.py. Jeśli wykonawcę wiersza poleceń, zostaje uruchomiona usługa ExecService, ze skryptem launch.py na urządzeniu przez ADB. Skrypty mogą być wykonywane z dowolnego katalogu.

Kompilacja Linuksa

Testowe pliki binarne i narzędzia wiersza poleceń można skompilować pod kątem Linuksa, generując pliki typu „makefile” za pomocą CMake. Istnieje wiele wstępnie zdefiniowanych celów kompilacji, które przydają się podczas tworzenia aplikacji na Linuksa.

Cel kompilacji Opis
default

Domyślny cel korzystający z introspekcji platformy CMake w celu określenia 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 zarówno GLX, jak i EGL z X11.

Zawsze używaj właściwości -DCMAKE_BUILD_TYPE=<Debug|Release> do określania typu kompilacji. Release to dobre ustawienie domyślne. W przeciwnym razie powstaje domyślna, niezoptymalizowana kompilacja wersji.

Argumenty wiersza poleceń -DCMAKE_C_FLAGS i -DCMAKE_CXX_FLAGS mogą być służy do przekazywania dodatkowych argumentów do kompilatora. Na przykład kompilację 32- lub 64-bitową można wykonać przez ustawiając odpowiednio -DCMAKE_C(XX)_FLAGS="-m32" lub "-m64". Jeśli nie, używana jest natywna architektura łańcucha narzędzi, zwykle 64-bitowa w 64-bitowym łańcuchu narzędzi.

Można używać argumentów -DCMAKE_LIBRARY_PATH i -DCMAKE_INCLUDE_PATH , aby umożliwić CMake dodatkową bibliotekę lub uwzględnienie ścieżek wyszukiwania.

Przykład pełnego wiersza poleceń używanego do 32-bitowej kompilacji debugowania Nagłówki i biblioteki sterowników w lokalizacji niestandardowej to:

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 krzyżowa

Kompilację krzyżową można uzyskać za pomocą pliku łańcucha narzędzi CMake. Łańcuch narzędzi określa kompilator do użycia oraz niestandardowe ścieżki wyszukiwania dla biblioteki i nagłówki. W przypadku typowych scenariuszy kilka plików łańcucha narzędzi to: do pakietu do publikacji w katalogu framework/delibs/cmake.

Oprócz standardowych zmiennych CMake możesz stosować następujące zmienne specyficzne dla Deqp można ustawić w pliku łańcucha narzędzi. CMake zwykle wykrywa przypadki DE_OS, DE_COMPILER i DE_PTR_SIZE, ale wartość DE_CPU musi być ustawiona w pliku łańcucha narzędzi.

Zmienna Opis
DE_OS

System operacyjny. Obsługiwane wartości to: 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 to: 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 ten kod spowoduje utworzenie plików createfiles dla kompilacji przy użyciu kompilatora krzyżowego CodeSourcery dla procesorów 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 środowiska wykonawczego bibliotek GLES i EGL

Deqp nie wymaga punktów wejścia testowanego interfejsu API podczas łączenia. kod testowy zawsze uzyskuje dostęp do interfejsów API za pomocą wskaźników funkcji. Punkty wejścia mogą są ładowane dynamicznie w czasie działania lub port platformy może je dostarczyć czas połączenia.

Jeśli obsługa interfejsu API jest włączona w ustawieniach kompilacji, a biblioteki linków są nie został podany, deqp wczyta potrzebne punkty wejścia w czasie działania. Jeśli wymagane jest połączenie statyczne, podaj wymagane biblioteki linków w interfejsie DEQP_<API>_LIBRARIES konfiguracji kompilacji.

Przenoszenie platformy testowej

Przeniesienie biblioteki Deqp obejmuje 3 kroki: adaptację podstawowych bibliotek przenośności, wdrożenia interfejsów do integracji platformy testowej i przenoszenia i usługach wykonywania zadań.

W tabeli poniżej znajdziesz lokalizacje, w których mogą zostać wprowadzone zmiany w przenoszeniu. Wszystko poza prawdopodobnie będą egzotyczne.

Lokalizacja Opis
framework/delibs/debase
framework/delibs/dethread
framework/delibs/deutil

wszelkie niezbędne implementacje kodu systemu operacyjnego.
framework/qphelper/qpCrashHandler.c

Opcjonalnie: implementacja w Twoim systemie operacyjnym.
framework/qphelper/qpWatchDog.c

Implementacja w Twoim systemie operacyjnym. Obecna baza jest na platformie dethread i standardowej bibliotece C.
framework/platform

Nowy port platformy i kod pośredni aplikacji można zaimplementować w sposób opisany w Port platformy testowej.

Podstawowe biblioteki przenośności

Podstawowe biblioteki przenośne obsługują już systemy Windows, większość wersji Linuxa, iOS i Androidzie. Jeśli środowisko testowe działa w jednym z tych systemów operacyjnych, najprawdopodobniej nie trzeba w ogóle klikać podstawowej biblioteki przenośności.

Port platformy testowej

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

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

Interfejs API platformy deqp został szczegółowo opisany w poniższych plikach.

Plik Opis
framework/common/tcuPlatform.hpp

Klasa podstawowa dla wszystkich portów platformy
framework/opengl/gluPlatform.hpp

Interfejs platformy OpenGL
framework/egl/egluPlatform.hpp

Interfejs platformy EGL
framework/platform/tcuMain.cpp

Punkt wejścia aplikacji standardowej

Klasa bazowa wszystkich portów platformy to tcu::Platform. Port platformy może opcjonalnie obsługa interfejsów GL i EGL. Zobacz W tabeli poniżej znajdziesz omówienie tego, co trzeba wdrożyć, aby przeprowadzić testy.

Moduł Interfejs

Moduły testowe OpenGL (ES)

Interfejs platformy GL

Moduł testowania EGL

Interfejs platformy EGL

Szczegółowe instrukcje dotyczące wdrażania portów platformy znajdziesz w portowania nagłówków warstwy.

Usługa wykonywania testów

Aby użyć infrastruktury wykonywania testów deqp lub wykonawcy wiersza poleceń, funkcja usługa wykonywania testu musi być dostępna w środowisku docelowym. Przenośny język C++ implementacja usługi jest dostępna w katalogu execserver. Samodzielny jest częścią modułu testu Deqp. na komputery. Możesz zmodyfikować execserver/CMakeLists.txt, aby włączyć kompilację inne cele.

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

  • --port=<port> ustawi port TCP, na którym nasłuchuje serwer. Wartość domyślna to 50016.
  • --single zakończy proces serwera po rozłączeniu klienta. Domyślnie atrybut proces serwera pozostanie niezmieniony, aby umożliwić obsługę kolejnych żądań wykonania testów.

Przeprowadzanie testów

Ta strona zawiera instrukcje uruchamiania testów deqp w systemach Linux i Windows za pomocą argumentów wiersza poleceń i pracy z Androidem. pakietu aplikacji.

Środowiska Linux i Windows

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

Moduł Katalog Cel
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 przetestować pliki binarne możesz wdrożyć w dowolnym miejscu system plików; ale testowe pliki binarne oczekują odnalezienia katalogów danych w w bieżącym katalogu roboczym. Gdy wszystko będzie gotowe, uruchom usługę wykonywania testów na na urządzeniu docelowym. Szczegółowe informacje o uruchamianiu usługi znajdziesz w sekcji Testuj .

Argumenty wiersza poleceń

Tabela poniżej zawiera listę argumentów wiersza poleceń, które wpływają na wykonanie wszystkich i testowych.

Argument Opis
--deqp-case=<casename> Przypadki uruchomienia pasujące do danego wzorca. Symbol wieloznaczny (*) jest obsługiwany.
--deqp-log-filename=<filename> Zapisz wyniki testu w pliku o podanej przez Ciebie nazwie. Wykonanie testu usługa ustawi nazwę pliku podczas uruchamiania testu.
--deqp-stdin-caselist
--deqp-caselist=<caselist>
--deqp-caselist-file=<filename>		 Przeczytaj listę przypadków ze standardu stdin lub z danego argumentu. Wykonanie testu usługa ustawi argument zgodnie z otrzymanym żądaniem wykonania. Zobacz w następnej sekcji z opisem formatu listy zgłoszeń.
--deqp-test-iteration-count=<count> Zastąp liczbę iteracji w przypadku testów, które obsługują zmienną liczbę powtórzenia.
--deqp-base-seed=<seed> Podstawowy element wyjściowy dla przypadków testowych, które korzystają z randomizacji.

Argumenty typowe dla GLES2 i GLES3

W tabeli poniżej znajdziesz argumenty typowe dla GLES2 i GLES3.
Argument Opis
--deqp-gl-context-type=<type> Typ kontekstu OpenGL. Dostępne typy kontekstu zależą od platformy. Wł. platform obsługujących EGL, do wyboru można użyć wartości egl w kontekście EGL.
--deqp-gl-config-id=<id> Przeprowadź testy dla podanego identyfikatora konfiguracji GL. Interpretacja to zależnych od platformy. Na platformie EGL jest to identyfikator konfiguracji EGL.
--deqp-gl-config-name=<name> Uruchamianie testów nazwanej konfiguracji GL. Interpretacja to zależnych od platformy. W przypadku EGL format to rgb(a)<bits>d<bits>s<bits> Na przykład plik wartość rgb888s8 powoduje wybranie pierwszej konfiguracji, w której bufor kolorów to 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 tej funkcji jest opcjonalna.
--deqp-surface-type=<type> Użyj danego typu nawierzchni jako głównego testowego środowiska docelowego renderowania. Możliwe typy to window, pixmap, pbuffer, i fbo.
--deqp-screen-rotation=<rotation> Orientacja ekranu co 90 stopni dla platform, są obsługiwane.

Format listy przypadków testowych

Lista przypadków testowych może być podana w 2 formatach. Pierwszą opcją jest pełną nazwę każdego testu w osobnym wierszu w standardowym pliku ASCII. Jako ciągle rośnie, więc powtarzające się prefiksy bywają uciążliwe. Aby uniknąć powtarzania tych samych czynności przedrostków, użyj składni trie (zwanej też drzewem prefiksu) widocznej 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 w usłudze wykonywania testów, testowych plikach binarnych i plikach danych. Działanie testowe to NativeActivity z EGL (wymaga Androida 3.2 lub nowszego).

Pakiet aplikacji można zainstalować przy użyciu następującego polecenia (o nazwie widoczna jest nazwa pliku APK w pakiecie Android CTS; Która nazwa zależy od kompilację):

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

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

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

Debugowanie odbitek można włączyć, wykonując te czynności przed rozpoczęciem testy:

adb –d shell setprop log.tag.dEQP DEBUG

Wykonywanie testów na Androidzie bez Android CTS

Aby ręcznie rozpocząć wykonywanie testu, utwórz intencję na Androida kierowanie na android.app.NativeActivity. Działania te mogą być znalezione w pakiecie com.drawelements.deqp. Wiersz poleceń musi: zostanie podany jako dodatkowy ciąg znaków z kluczem "cmdLine" w intencji.

Dziennik testowy jest zapisywany na koncie /sdcard/dEQP-log.qpa. Jeśli uruchomiono test Nie uruchamia się prawidłowo, ale w urządzeniu są dostępne dodatkowe informacje na potrzeby debugowania log.

Działanie możesz uruchomić z poziomu wiersza poleceń za pomocą narzędzia am za media. Aby na przykład przeprowadzić na platformie testy dEQP-GLES2.info obsługujące 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"'

Debuguj na Androidzie

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

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

Po zainstalowaniu kompilacji do debugowania na urządzeniu w celu uruchomienia testów GDB uruchomiony na hoście uruchom 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 przypadków testowych do wykonania i innych . Skrypt dodaje domyślny punkt przerwania na początku wykonanie polecenia deqp (tcu::App::App).

Skrypt debug.py akceptuje wiele argumentów wiersza poleceń dla działania, takie jak ustawianie punktów przerwania na potrzeby debugowania, połączenie z serwerem gdbserver i ścieżki do dodatkowych plików binarnych do debugowania (debug.py --help dla wszystkich argumentów i wyjaśnień). Skrypt kopiuje też niektóre biblioteki domyślne na urządzeniu docelowym, aby pobrać listę symboli.

Aby przejść przez kod sterownika (np. gdy GDB musi znać lokalizacje plików binarnych z pełnymi informacjami na temat debugowania) można dodać więcej bibliotek za pomocą Parametry wiersza poleceń debug.py. Skrypt ten tworzy pliku konfiguracji GDB, począwszy od wiersza 132 pliku skryptu. Ty może udostępnić dodatkowe ścieżki do plików binarnych itp., ale dostarczając poprawne polecenie .

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

Uwaga: debugowanie kodu natywnego nie działa Android 4.3; sposoby obejścia tego problemu znajdziesz w sekcji tego publicznego błędu. Android 4.4 i nowsze wersje nie zawierają tego błędu.

Zautomatyzuj testy

Moduły testowe Deqp można integrować z automatycznymi systemami testowymi na kilka sposobów. Wybór najlepszej metody zależy od istniejącej infrastruktury testowej i docelowego dla środowiska.

Podstawowym wynikiem uruchomienia testu jest zawsze plik dziennika testowego, czyli plik z postfiksem .qpa. Pełne wyniki testu można przeanalizować z dziennika testowego. Dane wyjściowe konsoli to informacje o debugowaniu i mogą być niedostępne na niektórych platformach.

Testowe pliki binarne można wywoływać bezpośrednio z testowego systemu automatyzacji. Test dla konkretnego przypadku, zbioru testowego lub wszystkich dostępnych testów. Jeśli podczas wykonywania wystąpi błąd krytyczny (np. w przypadku określonego interfejsu API) lub awarii), wykonanie testu zostanie przerwane. W przypadku testów regresji parametr Najlepszym sposobem jest wywoływanie testowych plików binarnych w poszczególnych przypadkach lub w ramach małych testów. ustawia się oddzielnie, aby częściowe wyniki były dostępne nawet dla zdarzenia ciężkiej awarii.

Deqp zawiera narzędzia do testowania wiersza poleceń, których można używać w w połączeniu z usługą wykonywania, aby uzyskać silniejszą integrację. Wykonawca wykryje zakończenie procesu testu i wznowi wykonanie testu kolejne dostępne zgłoszenie. Z pełnego testu zostanie utworzony jeden plik dziennika. . Ta konfiguracja jest idealna w przypadku prostych systemów testowych, które nie oferują o systemach odzyskiwania danych po awarii.

Narzędzia do wykonywania testów z wiersza poleceń

Bieżący zestaw narzędzi wiersza poleceń zawiera narzędzie do zdalnego wykonywania testów, generatora logów do analizy regresji, konwerterem dziennika testowego na CSV z konwertera dziennika testowego na XML i konwertera „testlog-to-JUnit”.

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

Wykonawca testu wiersza poleceń

Wykonawca testu wiersza poleceń to przenośne narzędzie w języku C++ służące do uruchamiania testu na urządzeniu i zbierając wygenerowane z niego logi przez TCP/IP. Wykonawca komunikuje się z usługą wykonywania (execserver) na urządzeniu docelowym. Razem zapewniają funkcje, takie jak odzyskiwanie po awarii procesów testowych. Poniższe przykłady pokazują, jak korzystać z wykonawcy testowego w wierszu poleceń (Aby uzyskać więcej informacji, wpisz --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. Kontynuuj częściowy test 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 dzienników testowych w formacie CSV

Deqp zawiera narzędzie do konwertowania dzienników testowych (plików .qpa) na pliki CSV. Plik CSV zawiera listę przypadków testowych i ich wyników. Narzędzie może również porównać co najmniej dwa wyniki wsadowe i wyświetlić tylko przypadki testowe, które mają różne kody stanu w wejściowych wynikach wsadowych. spowoduje również wyświetlenie liczby pasujących przypadków.

Dane wyjściowe w formacie CSV są bardzo praktyczne do dalszego przetwarzania z użyciem standardowego za pomocą narzędzi wiersza poleceń lub edytora arkuszy kalkulacyjnych. Dodatkowy, czytelny dla człowieka Format zwykłego tekstu można wybrać za pomocą następującego argumentu wiersza poleceń: --format=text

Przykład 1. Eksportowanie dziennika testowego 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. Wyświetlanie różnic w wynikach testów między 2 dziennikami testowymi
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Uwaga: argument --value=code zwraca wynik testu kod wyniku, np. "Pass" czy „Niepowodzenie”. Argument --value=details powoduje wybranie dalszej wartości wyjaśnienie wyniku lub wartości liczbowej uzyskanej w wyniku testu wydajności, możliwości lub dokładności.

Eksport logu testowego w formacie XML

Pliki dziennika testowego można konwertować na prawidłowe dokumenty XML za pomocą interfejsu testlog-to-xml za media. Obsługiwane są 2 tryby wyjściowe:

  • Tryb osobnych dokumentów, w którym każdy przypadek testowy i podsumowanie caselist.xml dokumenty 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 testowego można wyświetlić w przeglądarce za pomocą arkusza stylów XML. Dostarczono przykładowe dokumenty z arkusza stylów (testlog.xsl i testlog.css) w katalogu doc/testlog-stylesheet. Aby wyrenderować pliki dziennika w przeglądarce, skopiuj dwa pliki arkuszy stylów do tego samego katalogu, w którym znajdują się wyeksportowane dokumenty XML.

Jeśli korzystasz z Google Chrome, musisz uzyskać dostęp do plików przez HTTP. 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 za pomocą polecenia python –m SimpleHTTPServer 8000. Po uruchomieniu serwera ustaw w przeglądarce Chrome adres http://localhost:8000, aby wyświetlić dziennik testowy.

Konwersja na dziennik testowy JUnit

Wiele systemów automatyzacji testów może generować raporty o wynikach testów na platformie JUnit dane wyjściowe. Pliki dziennika testowego deqp można przekonwertować na format wyjściowy JUnit za pomocą narzędzia testlog-to-junit.

Obecnie narzędzie obsługuje tylko tłumaczenie oceny przypadku testowego. Jako JUnit obsługuje tylko "pass" i „porażka” wyników, zostaje zmapowany pozytywny wynik funkcji deqp do pliku „JUnit Pass” a inne – jako błędy. Oryginalny format kod wyniku jest dostępny w danych wyjściowych JUnit. Inne dane, takie jak komunikaty z dziennika i obrazy wynikowe nie są zachowywane w ramach konwersji.

Użyj specjalnych grup testowych

Niektóre grupy testowe mogą wymagać, obsługiwać specjalne opcje wiersza poleceń lub wymagać w niektórych systemach.

Testy obciążenia alokacji pamięci

Testy obciążenia w ramach alokacji pamięci wielokrotnie ćwiczą warunki braku pamięci przydzielanie pewnych zasobów, dopóki sterownik nie zgłosi błędu braku pamięci.

Na niektórych platformach, np. na Androidzie i większości wersji Linuksa, podane niżej może spowodować przerwanie procesu testowego, zamiast zezwalać na sterownika do obsługi lub w inny sposób wyświetla błąd braku pamięci. W dniu na platformach, testy, które powodują błędy braku pamięci, są wyłączone domyślnie i musi być włączony za pomocą argumentu wiersza poleceń --deqp-test-oom=enable. Zalecamy przeprowadzanie takich testów ręcznie, aby i sprawdzanie, czy system działa prawidłowo w przypadku nadmiaru zasobów. Jednak w takim przypadku w sytuacji, awarię w procesie testowym należy zinterpretować jako pozytywny.

Grupy testowe

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

Długotrwałe testy wytrzymałościowe renderowania

Renderowanie testów wytrzymałościowych ma na celu wykrywanie problemów z odpornością przy długotrwałym podczas renderowania. Domyślnie testy wykonują tylko kilka iteracji, można je skonfigurować tak, aby działały bezterminowo, podając --deqp-test-iteration-count=-1 wiersza poleceń. Testowy watchdog powinien być wyłączony (--deqp-watchdog=disable) podczas testów przez dłuższy czas.

Grupy testowe

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