Testowanie w ramach programu jakości drawElements

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

AOSP zawiera pakiet testów GPU deqp (drawElements Quality Program) 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 zgodnego z konkretną wersją CTS 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 pokazano w tabeli poniżej (lista nie jest wyczerpująca, ale wyróżnia najważniejsze katalogi).

Komponenty open source

Deqp używa libpng i zlib, które można pobrać za pomocą skryptu platform/external/deqp/external/fetch_sources.py lub za pomocą git z platform/external/[libpng,zlib].

Tworzenie programów testowych

Platforma testowa została zaprojektowana z myślą o przenośności. Jedynymi wymaganiami są pełne wsparcie dla C++ oraz standardowe biblioteki systemowe do obsługi wejść/wyjść, wątków i gniazd.

System kompilacji CMake

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

CMake to system kompilacji open source, który obsługuje wiele platform i ekosystemów narzędziowych. CMake generuje natywnych plików make lub plików projektu IDE z plików konfiguracji niezależnych od docelowego systemu. Więcej informacji o CMake znajdziesz w dokumentacji CMake.

CMake obsługuje kompilacje poza drzewem źródłowym i zaleca je, co oznacza, że pliki makefile lub pliki projektu należy zawsze tworzyć w oddzielnym katalogu kompilacji poza drzewem źródłowym. CMake nie ma żadnego typu docelowego „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 listę niektórych często używanych opcji deqp.

Tworzenie pliku kompilacji docelowej

System kompilacji deqp jest skonfigurowany pod kątem nowych celów za pomocą plików kompilacji docelowych. Plik kompilacji docelowej określa, które funkcje obsługuje platforma i które biblioteki lub dodatkowe ścieżki include są wymagane. Nazwy plików docelowych są zgodne z formatem targets/NAME/NAME.cmake, a docelowy obiekt jest wybierany za pomocą parametru kompilacji DEQP_TARGET.

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

Plik docelowy kompilacji może dodawać dodatkowe ścieżki include lub link za pomocą funkcji CMake include_directories() i link_directories().

Wersja Win32

Najprostszym sposobem kompilowania modułów deqp na potrzeby systemu Windows jest użycie systemu kompilacji CMake. Potrzebujesz CMake 2.6.12 lub nowszej wersji oraz kompilatora Microsoft Visual C/C++. Narzędzie deqp zostało przetestowane 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ć wersję 64-bitową, jako generatora wybierz „Visual Studio VERSION Win64”:

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

Pliki make NMake możesz też generować 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 Windows.

Obsługa WGL

Wszystkie pliki binarne Win32 obsługują tworzenie kontekstu GL za pomocą WGL, ponieważ wymagają 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. Ta funkcja została przetestowana pod kątem działania z najnowszymi sterownikami NVIDIA i Intel. Sterowniki AMD nie obsługują wymaganego rozszerzenia.

Obsługa EGL

Deqp jest tworzony z dynamicznym wczytywaniem dla EGL w Windows, jeśli opcja DEQP_SUPPORT_EGL jest włączona. Jest to ustawienie domyślne w przypadku większości kierowań. Jeśli host ma dostępne biblioteki EGL, można uruchomić testy za pomocą parametru wiersza poleceń: --deqp-gl-context-type=egl

Kompilacja Androida

Kompilacja na Androida używa skryptów kompilacji CMake do kompilowania natywnego kodu testowego. Elementy w języku Java, np. serwer wykonywania testów i element testowy aplikacji, są kompilowane za pomocą standardowych narzędzi kompilacji Androida.

Aby skompilować programy testowe deqp na Androida za pomocą dostarczonych skryptów kompilacji, musisz mieć:

• najnowsza wersja Android NDK; wymagana wersja jest podana w pliku android/scripts/common.py.
• samodzielny pakiet SDK na Androida z interfejsem API 13, narzędziami SDK, narzędziami platformy SDK i pakietami Build Tools zainstalowanymi
• Apache Ant 1.9.4 (wymagany do kompilacji kodu Java)
• CMake 2.8.12 lub nowsza wersja
• 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 tworzenie wersji.
• Opcjonalnie: Ninja Make jest obsługiwany również w systemie Linux.

Pliki binarne Ant i pakietu SDK są znajdowane na podstawie zmiennej środowiskowej PATH z pewnymi domyślnymi wartościami zastępczymi. Zarządzanie logiką odbywa się za pomocą android/scripts/common.py.

Katalog NDK musi być ~/android-ndk-VERSION lub C:/android/android-ndk-VERSION lub 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 android/package/bin i może być instalowany przez skrypt install.py. Jeśli używany jest wynik wykonywania poleceń w wierszu, usługa ExecService jest uruchamiana za pomocą skryptu launch.py na urządzeniu za pomocą ADB. Skrypty można uruchamiać z dowolnego katalogu.

Kompilacja na Linuksa

Testowe pliki binarne i programy wiersza poleceń można skompilować na potrzeby Linuksa, generując pliki make za pomocą CMake. Dostępnych jest kilka wstępnie zdefiniowanych celów kompilacji, które są przydatne podczas kompilowania na Linuksa.

Do definiowania typu kompilacji zawsze używaj wartości -DCMAKE_BUILD_TYPE=<Debug|Release>. Wartość domyślna to Release. Bez niego zostanie utworzona domyślna nieoptymalizowana wersja.

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

Argumenty -DCMAKE_LIBRARY_PATH i -DCMAKE_INCLUDE_PATH można użyć w CMake, aby podać dodatkową bibliotekę lub uwzględnić ścieżki wyszukiwania.

Przykład pełnego wiersza polecenia używanego do debugowania 32-bitowej kompilacji na podstawie nagłówków sterownika i bibliotek 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 toolchain określa kompilator, który ma być używany, oraz niestandardowe ścieżki wyszukiwania bibliotek i nagłówków. W pakiecie wersji w katalogu framework/delibs/cmake znajduje się kilka plików narzędzia toolchain dostępnych w przypadku typowych scenariuszy.

Oprócz standardowych zmiennych CMake w pliku toolchain można ustawić te zmienne specyficzne dla deqp: CMake zwykle poprawnie wykrywa zmienne DE_OS, DE_COMPILER i DE_PTR_SIZE, ale zmienna DE_CPU musi być ustawiona w pliku toolchain.

Plik toolchain można wybrać za pomocą parametru kompilacji CMAKE_TOOLCHAIN_FILE. Na przykład następujący wiersz kodu utworzy pliki make dla kompilacji za pomocą kompilatora wieloplatformowego 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.

Podczas łączenia deqp nie potrzebuje punktów wejścia interfejsu API, który jest testowany. Kod testowy zawsze uzyskuje dostęp do interfejsów API za pomocą wskaźników funkcji. Punkty wejścia mogą być ładowane dynamicznie w czasie wykonywania lub mogą być udostępniane przez port platformy w momencie tworzenia linku.

Jeśli w ustawieniach kompilacji włączono obsługę interfejsu API, a biblioteki linków nie są podane, deqp wczyta potrzebne punkty wejścia w czasie wykonywania. Jeśli chcesz użyć łączenia statycznych, podaj niezbędne biblioteki linków w zmiennej konfiguracji kompilacji DEQP_<API>_LIBRARIES.

Przenoszenie ram testowych

Przenoszenie deqp obejmuje 3 etapy: dostosowanie podstawowych bibliotek przenośności, implementację interfejsów integracji platformy z ramkami testowymi i przenoszenie usługi wykonywania.

Tabela poniżej zawiera listę lokalizacji, w których mogą wystąpić zmiany podczas przenoszenia. Wszystko poza nimi jest prawdopodobnie egzotyczne.

Podstawowe biblioteki przenoszenia

Podstawowe biblioteki przenośności obsługują już systemy Windows, większość wersji Linuksa, Mac OS, iOS i Android. Jeśli testowany obiekt działa w jednym z tych systemów operacyjnych, prawdopodobnie nie trzeba wcale modyfikować podstawowych bibliotek przenośności.

Port platformy testowej

Portowanie platformy deqp test framework wymaga 2 komponentów: punktu wejścia aplikacji i implementacji interfejsu platformy.

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

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

Klasa podstawowa dla wszystkich portów platform to tcu::Platform. Port platformy może opcjonalnie obsługiwać interfejsy GL i EGL. W tabeli poniżej znajdziesz przegląd tego, co należy wdrożyć, aby przeprowadzić testy.

Szczegółowe instrukcje dotyczące implementowania portów platformy znajdziesz w nagłówkach warstwy portowania.

Usługa wykonywania testów

Aby korzystać z infrastruktury wykonywania testów deqp lub wykonawcy w wierszu poleceń, usługa wykonywania testów musi być dostępna na urządzeniu docelowym. Przenośna implementacja usługi w C++ jest dostępna w katalogu execserver. Samodzielny binarny plik jest kompilowany w ramach kompilacji modułu testowego deqp na potrzeby platformy PC. Możesz zmodyfikować execserver/CMakeLists.txt, aby włączyć kompilację na innych celach.

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

• --port=<port> skonfiguruje port TCP, na którym serwer nasłuchuje. Wartość domyślna to 50016.
• --single spowoduje zakończenie procesu serwera, gdy klient się rozłączy. Domyślnie proces serwera będzie nadal 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 polecenia oraz pracy z pakietem aplikacji na Androida.

Środowiska Linux i Windows

Najpierw skopiuj te pliki i katalogi do miejsca docelowego.

Usługę wykonywania i testowe pliki binarne możesz wdrożyć w dowolnym miejscu docelowego systemu plików, ale testowe pliki binarne oczekują, że katalogi danych będą znajdować się w bieżącym katalogu roboczym. Gdy to zrobisz, uruchom usługę wykonywania testów na urządzeniu docelowym. Szczegółowe informacje o uruchamianiu usługi znajdziesz w artykule Testowanie usługi wykonania.

Argumenty wiersza poleceń

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

Argumenty specyficzne dla GLES 2 i GLES 3

Format listy przypadków testowych

Lista przypadków testowych może być podana w 2 formatach. Pierwszą opcją jest podanie pełnej nazwy każdego testu w oddzielnym wierszu w standardowym pliku ASCII. W miarę powiększania się zbiorów testów powtarzające się prefiksy mogą być uciążliwe. Aby uniknąć powtarzania prefiksów, użyj składni trójki (czyli drzewa prefiksów) pokazanej poniżej.

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

Przykład:

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

Przekłada się to na 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, testowe pliki binarne 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 wyświetlana 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, wykonaj te czynności:

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

Aby włączyć drukowanie debugowania, przed rozpoczęciem testów wykonaj te czynności:

adb –d shell setprop log.tag.dEQP DEBUG

Wykonywanie testów na Androidzie bez pakietu Android CTS

Aby ręcznie uruchomić aktywność wykonywania testu, utwórz intencję Androida, która kieruje na android.app.NativeActivity. Te zajęcia znajdziesz w pakiecie com.drawelements.deqp. Wiersz poleceń musi być podany jako dodatkowy ciąg znaków z kluczem "cmdLine" w intencji.

Log testowy jest zapisywany w folderze /sdcard/dEQP-log.qpa. Jeśli test nie uruchamia się normalnie, dodatkowe informacje debugowania są dostępne w logu 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 wersję debugową, uruchamiając te 2 skrypty:

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

Gdy kompilacja debugowania zostanie zainstalowana na urządzeniu, uruchom testy w GDB działającym na hoście, wykonując to polecenie:

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

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

Skrypt debug.py obsługuje wiele argumentów wiersza poleceń do wykonywania takich działań jak ustawianie punktów przerwania na potrzeby debugowania, parametry połączenia z gdbserver oraz ścieżki do dodatkowych plików binarnych do debugowania (użyj debug.py --help dla wszystkich argumentów i wyjaśnień). Skrypt kopiuje też niektóre domyślne biblioteki z urządzenia docelowego, aby pobrać listy symboli.

Aby przejrzeć kod sterownika (np. 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. Ten skrypt zapisuje plik konfiguracji GDB, zaczynając od wiersza 132. Możesz podać dodatkowe ścieżki do plików binarnych itp., ale podanie prawidłowych parametrów wiersza poleceń powinno wystarczyć.

Uwaga: w Windowsie 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 standardowego Androida 4.3. Aby dowiedzieć się, jak rozwiązać ten problem, zapoznaj się z  tutaj. Android 4.4 i nowsze nie zawierają tego błędu.

Automatyzowanie testów

Moduły testów Deqp można zintegrować z systemami testów automatycznych na wiele sposobów. Najlepsze podejście zależy od obecnej infrastruktury testowej i docelowego środowiska.

Głównym wynikiem wykonania testu jest zawsze plik dziennika testu, czyli plik z sufiksem .qpa. Pełne wyniki testu można przeanalizować na podstawie dziennika testu. Dane wyjściowe konsoli zawierają tylko informacje debugujące i mogą nie być dostępne na wszystkich platformach.

Binarnych plików testowych można używać bezpośrednio w systemie automatyzacji testów. Testowy binarny plik wykonywalny 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 interfejsu API lub awaria), jego wykonywanie zostanie przerwane. W przypadku testów regresyjnych najlepszym rozwiązaniem jest wywoływanie testowych plików binarnych w przypadku poszczególnych przypadków lub małych zbiorów testów osobno, aby mieć dostępne częściowe wyniki nawet w przypadku poważnej awarii.

Deqp jest dostarczany z narzędziami 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 wykryje zakończenie procesu testu i wznowi jego wykonywanie w następnym dostępnym przypadku. Z całego testu sesji zostanie wygenerowany jeden plik dziennika. Ta konfiguracja jest idealna dla małych 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ównywania dzienników testów na potrzeby analizy regresji, konwerter dzienników testów na pliki CSV, konwerter dzienników testów na pliki XML oraz konwerter dzienników testów na pliki JUnit.

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

Wykonawca testów w wierszu poleceń

Wykonawca testu w wierszu poleceń to przenośne narzędzie w języku C++, które umożliwia uruchamianie testu na urządzeniu i zbieranie z niego generowanych dzienników za pomocą protokołu TCP/IP. Wykonawca komunikuje się z usługą wykonywania (execserver) na urządzeniu docelowym. Razem zapewniają funkcje takie jak przywracanie po awarii procesu testowania. W następujących przykładach pokazano, jak korzystać z Test Executora w wierszu poleceń (więcej informacji znajdziesz w --help):

Przykład 1. Wykonywanie 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 na urządzeniu lokalnym

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 pliku CSV z danymi dziennika testowego

Deqp zawiera narzędzie do konwertowania dzienników testów (plików .qpa) na pliki CSV. Wyjście w formacie CSV zawiera listę przypadków testowych i ich wyniki. Narzędzie może też porównywać co najmniej 2 wyniki zbiorcze i wypisywać tylko te przypadki testowe, które mają różne kody stanu w wynikach zbiorczych danych wejściowych. Porównanie wydrukuje też liczbę pasujących przypadków.

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

Przykład 1. Wyeksportuj dziennik testów 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świetl różnice między wynikami testów w 2 logach testowych

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ść liczbową wygenerowaną przez test wydajności, możliwości lub dokładności.

Testowanie eksportu dzienników w formacie 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ścia:

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

Wyeksportowane pliki dziennika testów można wyświetlić w przeglądarce przy użyciu arkusza stylów XML. Przykładowe dokumenty arkuszy stylów (testlog.xsl i testlog.css) są dostępne w katalogu doc/testlog-stylesheet. Aby wyrenderować pliki dziennika w przeglądarce, skopiuj 2 pliki arkuszy 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ć uzyskiwany przez HTTP, ponieważ Chrome ze względów bezpieczeństwa ogranicza dostęp do plików lokalnych. Standardowa instalacja Pythona zawiera podstawowy serwer HTTP, który można uruchomić, aby wyświetlić bieżący katalog, używając polecenia python –m SimpleHTTPServer 8000. Po uruchomieniu serwera wystarczy wskazać http://localhost:8000 w przeglądarce Chrome, aby wyświetlić testowy dziennik.

Konwersja na log testu JUnit

Wiele systemów automatyzacji testów może generować raporty z wyników testów z wyjścia JUnit. Pliki dziennika testu deqp można przekonwertować do formatu wyjściowego JUnit za pomocą narzędzia testlog-to-junit.

Obecnie narzędzie obsługuje tylko tłumaczenie werdyktu testu. JUnit obsługuje tylko wyniki „pass” (przejdź) i „fail” (nieprzejdź). Wynik „pass” (przejdź) z deqp jest mapowany na „JUnit pass” (przejdź JUnit), a inne wyniki są uznawane za błędy. Oryginalny kod wyniku deqp jest dostępny w wyjściu JUnit. Inne dane, takie jak komunikaty w dzienniku i obrazy wyników, nie są zachowywane w konwersji.

Używanie specjalnych grup testowych

Niektóre grupy testów mogą wymagać specjalnych opcji wiersza poleceń lub wymagać szczególnej ostrożności podczas korzystania z nich w określonych 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, aż sterownik zgłosi błąd braku pamięci.

Na niektórych platformach, takich jak Android i większości wersji Linuksa, może wystąpić jeden z tych problemów: system operacyjny może przerwać proces testowania zamiast pozwolić sterownikowi na przetworzenie lub wyświetlenie komunikatu o braku pamięci. Na takich platformach testy, które mają wywoływać błędy związane z brakiem pamięci, są domyślnie wyłączone i muszą zostać włączone za pomocą argumentu wiersza poleceń --deqp-test-oom=enable. Zalecamy ręczne przeprowadzanie takich testów, aby sprawdzić, czy system działa prawidłowo pod wpływem presji zasobów. W takim przypadku awaria procesu testowego powinna być interpretowana 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 wydajnością podczas długotrwałego renderowania. Domyślnie testy będą przeprowadzać tylko kilka iteracji, ale można je skonfigurować tak, aby działały w nieskończoność. W tym celu należy podać argument wiersza poleceń --deqp-test-iteration-count=-1. W przypadku wykonywania tych testów przez dłuższy czas należy wyłączyć test nadzorczy (--deqp-watchdog=disable).

Grupy testowe

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