AOSP zawiera pakiet testów GPU DrawElements Quality Program (deqp) pod adresem https://android.googlesource.com/platform/external/deqp . Na tej stronie szczegółowo opisano, jak wdrożyć zestaw testów deqp w nowym środowisku.
Aby pracować z najnowszym przesłanym kodem, użyj gałęzi deqp-dev . W przypadku kodu pasującego do konkretnej wersji Androida CTS 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 pokazano w poniższej tabeli (lista nie jest wyczerpująca, ale podkreśla najważniejsze katalogi).
| Informator | Opis |
|---|---|
android | Źródła testerów Androida i skrypty kompilacji |
data | Testuj pliki danych |
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 konfiguracyjne kompilacji specyficzne dla obiektu docelowego |
framework | framework i narzędzia modułu testowego deqp |
framework/delibs | Bazowa przenośność i budowanie bibliotek |
framework/platform | Porty platformy |
framework/qphelper | Biblioteka integracji programu testowego (C) |
framework/common | Framework Deqp (C++) |
framework/opengl, framework/egl | Narzędzia specyficzne dla API |
execserver | Źródło ExecServer po stronie urządzenia |
executor | Narzędzie i narzędzia powłoki modułu wykonującego testy po stronie hosta |
external | Zbuduj katalog pośredniczący dla zewnętrznych bibliotek libpng i zlib |
Komponenty typu open source
Deqp używa libpng i zlib , które można pobrać za pomocą skryptu platform/external/deqp/external/fetch_sources.py lub poprzez git z platform/external/[libpng,zlib] .
Twórz programy testowe
Framework testowy został zaprojektowany z myślą o przenośności. Jedyne obowiązkowe wymagania to pełna obsługa C++ i standardowe biblioteki systemowe dla wejść/wyjść, wątków i gniazd.
System kompilacji CMake
Źródła deqp posiadają skrypty kompilacji dla CMake, które jest preferowanym narzędziem do kompilowania programów testowych.
CMake to system kompilacji typu open source, który obsługuje wiele platform i łańcuchów narzędzi. CMake generuje natywne pliki makefile lub pliki projektów IDE z plików konfiguracyjnych niezależnych od celu. Więcej informacji na temat CMake można znaleźć w dokumentacji CMake .
CMake obsługuje i zaleca kompilacje z drzewa źródłowego, tj. zawsze powinieneś tworzyć pliki makefile lub pliki projektu w oddzielnym katalogu kompilacji poza drzewem źródłowym. CMake nie ma żadnego celu „distclean”, więc usuwanie wszelkich plików wygenerowanych przez CMake musi zostać wykonane ręcznie.
Opcje konfiguracyjne są podawane do CMake przy użyciu -D OPTION_NAME = VALUE . Poniżej wymieniono niektóre powszechnie używane opcje deqp.
| Opcja konfiguracji | Opis |
|---|---|
DEQP_TARGET | Nazwa docelowa, na przykład: „android” Skrypty deqp CMake będą zawierać plik |
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” Należy pamiętać, że interpretacja i typ domyślny zależą od docelowego systemu kompilacji. Aby uzyskać szczegółowe informacje, zobacz dokumentację CMake. |
Utwórz docelowy plik kompilacji
System kompilacji deqp jest skonfigurowany dla nowych obiektów docelowych przy użyciu docelowych plików kompilacji. Docelowy plik kompilacji definiuje, które funkcje obsługuje platforma i jakie biblioteki lub dodatkowe ścieżki są wymagane. Nazwy plików docelowych mają format targets/ NAME / NAME .cmake , a cel jest wybierany przy użyciu parametru kompilacji DEQP_TARGET .
Ścieżki plików w plikach docelowych odnoszą się do podstawowego katalogu deqp , a nie do katalogu targets/ NAME . Poniższe zmienne standardowe można ustawić za pomocą docelowego pliku kompilacji.
| Zmienny | Opis |
|---|---|
DEQP_TARGET_NAME | Nazwa docelowa (zostanie uwzględniona w dziennikach testów) |
DEQP_SUPPORT_GLES2 | 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 | Czy obsługiwany jest 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 | 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 | Czy obsługiwany jest 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 łączenia wymagane są dodatkowe biblioteki specyficzne dla platformy |
DEQP_PLATFORM_COPY_LIBRARIES | Lista bibliotek skopiowanych do każdego testowego katalogu kompilacji binarnej. Można go używać do kopiowania bibliotek potrzebnych do uruchamiania testów, ale których nie ma 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 odnoszą się do: |
Docelowy plik kompilacji może dodać dodatkowe ścieżki dołączania lub łączenia przy użyciu funkcji CMake include_directories() i link_directories() .
Kompilacja Win32
Najłatwiejszym sposobem budowania modułów deqp dla systemu Windows jest użycie systemu kompilacji CMake. Będziesz potrzebował CMake 2.6.12 lub nowszego i kompilatora Microsoft Visual C/C++. Deqp został przetestowany w Visual Studio 2013.
Pliki projektu Visual Studio można wygenerować za pomocą następującego polecenia:
cmake path\to\src\deqp -G "Visual Studio 12"
Kompilację 64-bitową można wykonać, wybierając „Visual Studio VERSION Win64” jako generator kompilacji:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Można także generować 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.
Wsparcie 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_profile do tworzenia kontekstów OpenGL ES. Zostało to przetestowane pod kątem współpracy z najnowszymi sterownikami firm NVIDIA i Intel. Sterowniki AMD nie obsługują wymaganego rozszerzenia.
Wsparcie EGL
Deqp jest zbudowany z dynamicznym ładowaniem dla EGL w systemie Windows, jeśli DEQP_SUPPORT_EGL jest włączony. Jest to ustawienie domyślne w większości celów. Następnie, jeśli host ma dostępne biblioteki EGL, możliwe jest uruchomienie z nimi testów za pomocą parametru wiersza poleceń: --deqp-gl-context-type=egl
Kompilacja Androida
Kompilacja systemu Android korzysta ze skryptów kompilacji CMake do tworzenia natywnego kodu testowego. Części Java, tj. serwer wykonywania testów i kod źródłowy aplikacji testowej, są kompilowane przy użyciu standardowych narzędzi do kompilacji systemu Android.
Aby skompilować programy testowe deqp dla Androida za pomocą dostarczonych skryptów kompilacji, będziesz potrzebować:
- Najnowsza wersja Androida NDK ; plik
android/scripts/common.pyzawiera listę wymaganych wersji - Samodzielny zestaw SDK dla systemu Android z zainstalowanym interfejsem API 13, narzędziami SDK, narzędziami platformy SDK i pakietami narzędzi do budowania SDK
- Apache Ant 1.9.4 (wymagany przez kompilację kodu Java)
- CMake 2.8.12 lub nowszy
- Python 2.6 lub nowszy w serii 2.x; Python 3.x nie jest obsługiwany
- Dla Windows: NMake lub JOM w
PATH- JOM umożliwia szybsze kompilacje
- Opcjonalnie: Ninja make jest również obsługiwany w systemie Linux
Pliki binarne Ant i SDK są lokalizowane na podstawie zmiennej środowiskowej PATH z pewnymi nadrzędnymi wartościami domyślnymi. Logiką steruje android/scripts/common.py .
Katalog NDK musi mieć postać ~/android-ndk- VERSION lub C:/android/android-ndk- VERSION lub być zdefiniowany za pomocą zmiennej środowiskowej ANDROID_NDK_PATH .
Komponenty Deqp na urządzeniu, usługa wykonywania testów i programy testowe są tworzone poprzez wykonanie skryptu android/scripts/build.py . Ostateczny plik .apk jest tworzony w android/package/bin i można go zainstalować za pomocą skryptu install.py . Jeśli używany jest moduł wykonawczy wiersza poleceń , usługa ExecService jest uruchamiana ze skryptem launch.py na urządzeniu za pośrednictwem ADB. Skrypty można wykonywać z dowolnego katalogu.
Kompilacja Linuksa
Testowe pliki binarne i narzędzia wiersza poleceń można tworzyć dla systemu Linux, generując pliki makefile przy użyciu CMake. Istnieje wiele wstępnie zdefiniowanych celów kompilacji, które są przydatne podczas kompilowania dla systemu Linux.
| Zbuduj cel | 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 języka EGL do tworzenia kontekstów OpenGL (ES). |
x11_egl_glx | Obsługuje zarówno GLX, jak i EGL z X11. |
Zawsze używaj -DCMAKE_BUILD_TYPE=<Debug|Release> aby zdefiniować typ kompilacji. Release jest dobrym ustawieniem domyślnym. Bez tego tworzona jest domyślna, niezoptymalizowana kompilacja wydania.
Argumentów wiersza poleceń -DCMAKE_C_FLAGS i -DCMAKE_CXX_FLAGS można użyć do przekazania dodatkowych argumentów do kompilatora. Na przykład kompilację 32-bitową lub 64-bitową można wykonać, ustawiając odpowiednio -DCMAKE_C(XX)_FLAGS="-m32" lub "-m64" . Jeśli nie określono, używana jest natywna architektura łańcucha narzędzi, zazwyczaj 64-bitowa w 64-bitowym łańcuchu narzędzi.
Argumentów -DCMAKE_LIBRARY_PATH i -DCMAKE_INCLUDE_PATH można użyć dla narzędzia CMake, aby zapewnić CMake dodatkową bibliotekę lub uwzględnić ścieżki wyszukiwania.
Przykład pełnego wiersza poleceń używanego do 32-bitowej kompilacji debugowania względem nagłówków sterowników i bibliotek w niestandardowej lokalizacji jest następujący:
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 osiągnąć za pomocą pliku łańcucha narzędzi CMake. Plik łańcucha narzędzi określa używany kompilator wraz z niestandardowymi ścieżkami wyszukiwania bibliotek i nagłówków. Kilka plików zestawu narzędzi dla typowych scenariuszy znajduje się w pakiecie wydania w katalogu framework/delibs/cmake .
Oprócz standardowych zmiennych CMake, w pliku Toolchain można ustawić następujące zmienne specyficzne dla deqp. CMake zwykle potrafi poprawnie wykryć DE_OS , DE_COMPILER i DE_PTR_SIZE , ale DE_CPU musi być ustawione przez plik łańcucha narzędzi.
| Zmienny | Opis |
|---|---|
DE_OS | System operacyjny. Obsługiwane wartości to: |
DE_COMPILER | Typ kompilatora. Obsługiwane wartości to: |
DE_CPU | Typ procesora. Obsługiwane wartości to: |
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 poniższe utworzą pliki makefile dla kompilacji przy użyciu kompilatora krzyżowego CodeSourcery dla 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 w czasie wykonywania bibliotek GLES i EGL
Deqp nie potrzebuje punktów wejścia testowanego API podczas łączenia. Kod testowy zawsze uzyskuje dostęp do interfejsów API poprzez wskaźniki funkcji. Punkty wejściowe można następnie ładować dynamicznie w czasie wykonywania lub port platformy może je udostępniać w czasie łączenia.
Jeśli w ustawieniach kompilacji włączona jest obsługa API i nie są dostępne biblioteki łączy, deqp załaduje potrzebne punkty wejścia w czasie wykonywania. Jeśli pożądane jest łączenie statyczne, podaj potrzebne biblioteki łączy w zmiennej konfiguracyjnej kompilacji DEQP_<API>_LIBRARIES .
Przeportuj środowisko testowe
Przenoszenie deqp obejmuje trzy kroki: dostosowanie podstawowych bibliotek przenośności, wdrożenie interfejsów integrujących platformę ze środowiskiem testowym oraz przeniesienie usługi wykonawczej.
Poniższa tabela zawiera listę lokalizacji, w których mogą nastąpić prawdopodobne zmiany w przenoszeniu. Wszystko poza nimi będzie prawdopodobnie egzotyczne.
| Lokalizacja | Opis |
|---|---|
framework/delibs/debase | Wszelkie niezbędne implementacje kodu specyficznego dla systemu operacyjnego. |
framework/qphelper/qpCrashHandler.c | Opcjonalnie: wdrożenie dla Twojego systemu operacyjnego. |
framework/qphelper/qpWatchDog.c | Implementacja dla Twojego systemu operacyjnego. Obecny oparty jest na |
framework/platform | Nowy port platformy i kod pośredni aplikacji można zaimplementować zgodnie z opisem w temacie Port platformy platformy testowej . |
Podstawowe biblioteki przenośności
Podstawowe biblioteki przenośności obsługują już system Windows, większość wariantów Linuksa, Mac OS, iOS i Android. Jeśli cel testowy działa na jednym z tych systemów operacyjnych, najprawdopodobniej nie ma w ogóle potrzeby dotykania podstawowych bibliotek przenośności.
Testuj port platformy frameworka
Port platformy testowej deqp wymaga dwóch 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 testów ( tcu::TestLog ) i iterację aplikacji testowej ( tcu::App ). Jeśli docelowy system operacyjny obsługuje standardowy punkt wejścia main() , jako implementację punktu wejścia można zastosować tcuMain.cpp .
API platformy deqp zostało szczegółowo opisane w poniższych 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ą dla wszystkich portów platformy jest tcu::Platform . Port platformy może opcjonalnie obsługiwać interfejsy specyficzne dla GL i EGL. W poniższej tabeli znajduje się przegląd elementów, które należy zaimplementować, aby uruchomić testy.
| Moduł | Interfejs |
|---|---|
Moduły testowe OpenGL (ES). | Interfejs platformy GL |
Moduł testowy EGL | Interfejs platformy EGL |
Szczegółowe instrukcje dotyczące implementowania portów platformy znajdują się w nagłówkach warstwy przenoszenia.
Usługa wykonania testu
Aby móc korzystać z infrastruktury wykonywania testów deqp lub modułu wykonującego wiersz poleceń, usługa wykonywania testów musi być dostępna w systemie docelowym. Przenośna implementacja usługi w C++ jest dostępna w katalogu execserver . Samodzielny plik binarny jest budowany jako część kompilacji modułu testowego deqp dla komputerów docelowych. Możesz zmodyfikować execserver/CMakeLists.txt aby umożliwić kompilację na innych obiektach docelowych.
Wersja C++ usługi wykonania testu akceptuje dwa parametry wiersza poleceń:
-
--port=<port>ustawi port TCP, na którym nasłuchuje serwer. Wartość domyślna to 50016. -
--singlezakończy proces serwera, gdy klient się rozłączy. Domyślnie proces serwera nie będzie działać, aby obsłużyć dalsze żądania wykonania testu.
Uruchom testy
Ta strona zawiera instrukcje dotyczące uruchamiania testów deqp w środowiskach Linux i Windows, używania argumentów wiersza poleceń i pracy z pakietem aplikacji dla systemu Android.
Środowiska Linux i Windows
Zacznij od skopiowania następujących plików i katalogów do miejsca docelowego.
| Moduł | Informator | 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 |
Możesz wdrożyć usługę wykonania i przetestować pliki binarne w dowolnym miejscu docelowego systemu plików; jednakże testowe pliki binarne oczekują znalezienia katalogów danych w bieżącym katalogu roboczym. Gdy wszystko będzie gotowe, uruchom usługę wykonywania testów na urządzeniu docelowym. Aby uzyskać szczegółowe informacje na temat uruchamiania usługi, zobacz Usługa wykonywania testów .
Argumenty wiersza poleceń
W poniższej tabeli wymieniono argumenty wiersza poleceń, które wpływają na wykonanie wszystkich programów testowych.
| Argument | Opis |
|---|---|
--deqp-case=<casename> | Uruchom przypadki pasujące do danego wzorca. Obsługiwany jest symbol wieloznaczny (*). |
--deqp-log-filename=<filename> | Zapisz wyniki testu do pliku o podanej nazwie. Usługa wykonania testu ustawi nazwę pliku podczas uruchamiania testu. |
--deqp-stdin-caselist | Czytaj listę przypadków ze standardowego wejścia lub z podanego argumentu. Usługa wykonania testu ustawi argument zgodnie z otrzymanym żądaniem wykonania. W następnej sekcji znajduje się opis formatu listy spraw. |
--deqp-test-iteration-count=<count> | Zastąp liczbę iteracji w przypadku testów obsługujących zmienną liczbę iteracji. |
--deqp-base-seed=<seed> | Podstawowy materiał siewny dla przypadków testowych korzystających z randomizacji. |
Argumenty specyficzne dla GLES2 i GLES3
W poniższej tabeli wymieniono argumenty specyficzne dla GLES2 i GLES3.| Argument | Opis |
|---|---|
--deqp-gl-context-type=<type> | Typ kontekstu OpenGL. Dostępne typy kontekstów zależą od platformy. Na platformach obsługujących EGL wartość egl może zostać użyta do wybrania kontekstu EGL. |
--deqp-gl-config-id=<id> | Uruchom testy dla podanego identyfikatora konfiguracji GL. Interpretacja zależy od platformy. Na platformie EGL jest to identyfikator konfiguracji EGL. |
--deqp-gl-config-name=<name> | Uruchom testy dla nazwanej konfiguracji GL. Interpretacja zależy od platformy. W przypadku EGL format to rgb(a)<bits>d<bits>s<bits> . Na przykład wartość rgb888s8 spowoduje 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> | Spróbuj stworzyć powierzchnię o zadanym rozmiarze. Wsparcie w tym zakresie jest opcjonalne. |
--deqp-surface-type=<type> | Użyj danego typu powierzchni jako głównego celu renderowania testowego. Możliwe typy to: window , pixmap , pbuffer i fbo . |
--deqp-screen-rotation=<rotation> | Orientacja ekranu w odstępach co 90 stopni dla platform, które ją obsługują. |
Format listy przypadków testowych
Listę przypadków testowych można podać w dwóch formatach. Pierwszą opcją jest wypisanie pełnej nazwy każdego testu w osobnej linii standardowego pliku ASCII. W miarę powiększania się zestawów testowych powtarzające się przedrostki mogą być kłopotliwe. Aby uniknąć powtarzania przedrostków, użyj pokazanej poniżej składni trie (znanej również jako drzewo przedrostków).
{nodeName{firstChild{…},…lastChild{…}}}
Na przykład:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Przekłada się to na następujące dwa 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, testowe pliki binarne i pliki danych. Działanie testowe to NativeActivity korzystające z EGL (wymaga systemu Android 3.2 lub nowszego).
Pakiet aplikacji można zainstalować za pomocą następującego polecenia (wyświetlana nazwa to nazwa pliku APK w pakiecie Android CTS; która nazwa zależy od wersji):
adb –d install –r com.drawelements.deqp.apk
Aby uruchomić usługę wykonania testu i skonfigurować przekierowanie portów, użyj następujących poleceń:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Wydruki debugujące można włączyć, wykonując przed rozpoczęciem testów następujące czynności:
adb –d shell setprop log.tag.dEQP DEBUG
Wykonaj testy na Androidzie bez Androida CTS
Aby ręcznie rozpocząć działanie polegające na wykonaniu testu, utwórz intencję systemu Android skierowaną na android.app.NativeActivity . Aktywności można znaleźć w pakiecie com.drawelements.deqp . Wiersz poleceń musi być dostarczony jako dodatkowy ciąg znaków z kluczem "cmdLine" w intencji.
Dziennik testów jest zapisywany w pliku /sdcard/dEQP-log.qpa . Jeśli uruchomienie testowe nie rozpocznie się normalnie, w dzienniku urządzenia dostępne są dodatkowe informacje debugowania.
Możesz uruchomić działanie z wiersza poleceń za pomocą narzędzia am . Na przykład, aby uruchomić testy dEQP-GLES2.info na platformie obsługującej NativeActivity, użyj poniższych 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ę debugowania, uruchamiając następujące dwa skrypty:
python android/scripts/build.py --native-build-type=Debugpython android/scripts/install.py
Po zainstalowaniu na urządzeniu kompilacji debugowania, aby uruchomić testy w ramach GDB uruchomionego na hoście, uruchom następującą komendę:
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, które mają zostać wykonane, i innych wymaganych parametrów. Skrypt dodaje domyślny punkt przerwania na początku wykonania deqp ( tcu::App::App ).
Skrypt debug.py akceptuje wiele argumentów wiersza poleceń dla działań, takich jak ustawianie punktów przerwania na potrzeby debugowania, parametrów połączenia gdbserver i ścieżek do dodatkowych plików binarnych do debugowania (użyj debug.py --help dla wszystkich argumentów i wyjaśnień). Skrypt kopiuje również niektóre domyślne biblioteki z urządzenia docelowego, aby uzyskać listę symboli.
Aby przejść przez kod sterownika (na przykład gdy GDB musi znać lokalizacje plików binarnych z pełnymi informacjami debugowania), dodaj więcej bibliotek za pomocą parametrów wiersza poleceń debug.py . Skrypt ten zapisuje plik konfiguracyjny dla GDB, zaczynając od linii 132 pliku skryptu. Możesz podać dodatkowe ścieżki do plików binarnych itp., ale podanie poprawnych parametrów wiersza poleceń powinno wystarczyć.
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 systemie Android 4.3; Aby znaleźć obejścia, zapoznaj się z tym publicznym błędem . Android 4.4 i nowsze wersje nie zawierają tego błędu.
Zautomatyzuj testy
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.
Podstawowym wynikiem przebiegu testu jest zawsze plik dziennika testów, tj. plik z przyrostkiem .qpa . Pełne wyniki testu można przeanalizować z dziennika testów. Dane wyjściowe konsoli służą wyłącznie do celów debugowania i mogą nie być dostępne na wszystkich platformach.
Pliki binarne testów można wywołać bezpośrednio z systemu automatyzacji testów. Plik binarny testowy można uruchomić dla konkretnego przypadku, dla zestawu testowego lub dla wszystkich dostępnych testów. Jeśli podczas wykonywania wystąpi błąd krytyczny (taki jak pewne błędy API lub awaria), wykonywanie testu zostanie przerwane. W przypadku testów regresyjnych najlepszym podejściem jest wywoływanie plików binarnych testowych dla poszczególnych przypadków lub małych zestawów testowych oddzielnie, aby mieć dostęp do częściowych wyników nawet w przypadku twardej awarii.
Deqp jest wyposażony w narzędzia do wykonywania testów wiersza poleceń, których można używać w połączeniu z usługą wykonywania, aby osiągnąć solidniejszą integrację. Osoba wykonująca wykrywa zakończenie procesu testowego i wznowi wykonywanie testu od następnego dostępnego przypadku. Z pełnej sesji testowej tworzony jest pojedynczy plik dziennika. Ta konfiguracja jest idealna dla lekkich systemów testowych, które nie zapewniają możliwości odzyskiwania po awarii.
Narzędzia do wykonywania testów z wiersza 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 dziennika testów na CSV, konwerter dziennika testów na XML i konwerter dziennika testów na JUnit .
Kod źródłowy tych narzędzi znajduje się w katalogu executor , a pliki binarne są wbudowane w katalog <builddir>/executor .
Osoba wykonująca test z wiersza poleceń
Program wykonujący testy wiersza poleceń to przenośne narzędzie C++ służące do uruchamiania przebiegu testowego na urządzeniu i zbierania z niego wynikowych dzienników za pośrednictwem protokołu TCP/IP. Executor komunikuje się z usługą wykonania (execserver) na urządzeniu docelowym. Razem zapewniają funkcjonalność, taką jak odzyskiwanie danych po awarii procesu testowego. Poniższe przykłady pokazują, jak używać narzędzia Test Executor z wiersza poleceń (użyj --help , aby uzyskać więcej szczegółów):
Przykład 1: Uruchom testy funkcjonalne GLES2 na urządzeniu z systemem Android
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 lokalnie częściowe uruchomienie testowe OpenGL ES 2
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
Eksport dziennika testowego w formacie CSV i porównanie
Deqp posiada narzędzie do konwersji logów testowych (plików qpa ) do plików CSV. Dane wyjściowe CSV zawierają listę przypadków testowych i ich wyników. Narzędzie może także porównać dwa lub więcej wyników wsadowych i wyświetlić tylko przypadki testowe, które mają różne kody stanu w wejściowych wynikach wsadowych. Porównanie wyświetli również liczbę pasujących przypadków.
Dane wyjściowe w formacie CSV są bardzo praktyczne do dalszego przetwarzania za pomocą standardowych 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: Eksportuj dziennik testów w formacie CSV
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Przykład 2: Wypisz różnice w wynikach testów pomiędzy dwoma dziennikami testów
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Uwaga: Argument --value=code wyświetla kod wyniku testu, taki jak „Pozytywny” lub „Niepowodzenie”. Argument --value=details wybiera dalsze wyjaśnienie wyniku lub wartości liczbowej uzyskanej w wyniku testu wydajności, możliwości lub dokładności.
Eksport dziennika testów w formacie XML
Pliki dziennika testów można konwertować na prawidłowe dokumenty XML za pomocą narzędzia testlog-to-xml . Obsługiwane są dwa tryby wyjściowe:
- Tryb oddzielnych dokumentów, w którym każdy przypadek testowy i dokument podsumowujący
caselist.xmlsą zapisywane w katalogu docelowym - Tryb pojedynczego pliku, w którym wszystkie wyniki w pliku
.qpasą zapisywane w jednym dokumencie XML.
Wyeksportowane pliki dziennika testów można przeglądać w przeglądarce przy użyciu arkusza stylów XML. Przykładowe dokumenty arkuszy stylów ( testlog.xsl i testlog.css ) znajdują się 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 przeglądarki Google Chrome, dostęp do plików musi być uzyskiwany za pośrednictwem protokołu HTTP, ponieważ Chrome ogranicza dostęp do plików lokalnych ze względów bezpieczeństwa. Standardowa instalacja Pythona obejmuje podstawowy serwer HTTP, który można uruchomić w celu obsługi bieżącego katalogu za pomocą polecenia python –m SimpleHTTPServer 8000 . Po uruchomieniu serwera wystarczy skierować przeglądarkę Chrome na adres http://localhost:8000 , aby wyświetlić dziennik testów.
Konwersja do dziennika testowego JUnit
Wiele systemów automatyzacji testów może generować raporty z wynikami przebiegu testów na podstawie danych wyjściowych JUnit. Pliki dziennika testów deqp można przekonwertować do formatu wyjściowego JUnit za pomocą narzędzia testlog-to-junit.
Narzędzie obecnie obsługuje wyłącznie tłumaczenie werdyktu przypadku testowego. Ponieważ JUnit obsługuje tylko wyniki „pozytywne” i „niepowodzenie”, pozytywny wynik deqp jest mapowany na „powodzenie JUnit”, a inne wyniki są uznawane za niepowodzenie. Oryginalny kod wyniku deqp jest dostępny na wyjściu JUnit. Inne dane, takie jak komunikaty dziennika i obrazy wyników, nie są zachowywane podczas konwersji.
Użyj specjalnych grup testowych
Niektóre grupy testowe mogą potrzebować lub obsługiwać specjalne opcje wiersza poleceń lub wymagać szczególnej ostrożności podczas używania w niektórych systemach.
Testy obciążeniowe alokacji pamięci
Testy obciążeniowe alokacji pamięci sprawdzają warunki braku pamięci poprzez wielokrotne przydzielanie określonych zasobów, dopóki sterownik nie zgłosi błędu braku pamięci.
Na niektórych platformach, takich jak Android i większość wariantów Linuksa, mogą wystąpić następujące zdarzenia: System operacyjny może przerwać proces testowy, zamiast pozwolić sterownikowi na obsługę lub w inny sposób zgłosić błąd braku pamięci. Na takich platformach testy, które mają powodować błędy braku pamięci, są domyślnie wyłączone i należy je włączyć za pomocą argumentu wiersza poleceń --deqp-test-oom=enable . Zaleca się ręczne uruchomienie takich testów w celu sprawdzenia, czy system zachowuje się poprawnie pod presją zasobów. Jednak w takiej sytuacji awarię procesu testowego należy interpretować jako pozytywny wynik.
Grupy testowe
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Długotrwałe testy obciążeniowe renderowania
Testy obciążeniowe renderowania mają na celu wykrycie problemów z odpornością przy ciągłym obciążeniu renderowania. Domyślnie testy wykonają tylko kilka iteracji, ale można je skonfigurować tak, aby uruchamiały się w nieskończoność, podając argument wiersza poleceń --deqp-test-iteration-count=-1 . Testowy watchdog powinien być wyłączony ( --deqp-watchdog=disable ) podczas wykonywania tych testów przez dłuższy czas.
Grupy testowe
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2024-03-18 UTC.