drawElements 품질 프로그램(deqp) 테스트

AOSP에는 drawElements 품질 프로그램(deqp) GPU 테스트 도구 모음(https://android.googlesource.com/platform/external/deqp)이 포함됩니다. 이 페이지에서는 deqp 테스트 도구 모음을 새로운 환경에 배포하는 방법을 설명합니다.

최근에 제출된 코드로 작업하려면 deqp-dev 브랜치를 사용하세요. 구체적인 Android CTS 버전과 일치하는 코드의 경우 release-code-name-release 분기를 사용하세요(예: Android 6.0에는 marshmallow-release 분기를 사용).

소스 레이아웃

아래 표에는 deqp 테스트 모듈용 소스 코드와 지원 라이브러리가 나와 있습니다. 종합적인 목록은 아니지만 가장 중요한 디렉터리가 강조 표시되어 있습니다.

오픈소스 구성요소

deqp는 platform/external/[libpng,zlib]의 git를 통하거나 스크립트 platform/external/deqp/external/fetch_sources.py를 사용하여 가져올 수 있는 libpng 및 zlib를 사용합니다.

테스트 프로그램 빌드

테스트 프레임워크는 휴대성을 염두에 두고 설계되었습니다. 유일한 필수요건은 일체의 C++ 지원과 I/O, 스레드 및 소켓을 위한 표준 시스템 라이브러리입니다.

CMake 빌드 시스템

deqp 소스에는 빌드 스크립트가 포함됩니다. 이 스크립트는 테스트 프로그램을 컴파일할 때 선호되는 도구입니다.

CMake는 여러 플랫폼과 도구 모음을 지원하는 오픈소스 빌드 시스템입니다. CMake는 대상과 상관없는 구성 파일에서 네이티브 makefile 또는 IDE 프로젝트를 생성합니다. CMake에 관한 자세한 내용은 CMake 문서를 참고하세요.

CMake는 out-of-source-tree 빌드를 지원 및 권장합니다. 즉, 항상 소스 트리 외부에 위치한 별도의 빌드 디렉터리에 makefile 또는 프로젝트 파일을 생성해야 합니다. CMake에는 어떠한 종류의 'distclean' 대상도 없습니다. 따라서 CMake에 의해 생성된 모든 파일은 수동으로 제거해야 합니다.

구성 옵션은 -DOPTION_NAME=VALUE 구문을 사용하는 CMake에 주어집니다. 아래에는 deqp에 자주 사용되는 몇 가지 옵션이 나열되어 있습니다.

대상 빌드 파일 생성

deqp 빌드 시스템은 타겟 빌드 파일을 사용하는 새 타겟에 대해 구성됩니다. 타겟 빌드 파일은 플랫폼에서 어떤 기능을 지원하는지, 어떤 라이브러리 또는 추가적인 include 경로가 요구되는지를 정의합니다. 대상 파일 이름은 targets/NAME/NAME.cmake 형식을 따르며 대상은 DEQP_TARGET 빌드 매개변수를 사용하여 선택됩니다.

대상 파일의 파일 경로는 targets/NAME 디렉터리가 아닌 기본 deqp 디렉터리에 상대적입니다. 다음 표준 변수는 타겟 빌드 파일에 의해 설정될 수 있습니다.

대상 빌드 파일은 include_directories() 및 link_directories() CMake 함수를 사용하여 추가적인 include 또는 링크 경로를 추가할 수 있습니다.

Win32 빌드

Windows용 deqp 모듈을 빌드할 수 있는 가장 쉬운 방법은 CMake 빌드 시스템을 사용하는 것입니다. CMake 2.6.12 이상과 Microsoft Visual C/C++ 컴파일러가 필요합니다. deqp는 Visual Studio 2013으로 테스트되었습니다.

Visual Studio 프로젝트 파일은 다음 명령어로 생성할 수 있습니다.

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

64비트 빌드는 'Visual Studio VERSION Win64'를 빌드 생성자로 선택하여 만들 수 있습니다.

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

또한 -G "NMake Makefiles" 옵션으로 NMake makefile은 물론 빌드 유형(-DCMAKE_BUILD_TYPE="Debug" 또는 "Release")까지 생성할 수 있습니다.

렌더링 컨텍스트 생성

Windows에서는 WGL 또는 EGL로 렌더링 컨텍스트를 생성할 수 있습니다.

WGL 지원

모든 Win32 바이너리는 표준 라이브러리만 요구하기 때문에 WGL을 통한 GL 컨텍스트 생성을 지원합니다. WGL 컨텍스트는 --deqp-gl-context-type=wgl 명령줄 인수를 사용하여 선택할 수 있습니다. WGL 모드에서는 deqp가 WGL_EXT_create_context_es_profile 확장 프로그램을 사용하여 OpenGL ES 컨텍스트를 생성합니다. 이는 NVIDIA 및 Intel의 최신 드라이버와 함께 작동하도록 테스트되었습니다. AMD 드라이버는 필수 확장 프로그램을 지원하지 않습니다.

EGL 지원

deqp는 DEQP_SUPPORT_EGL이 켜진 경우 Windows의 EGL에 관한 동적 로드로 빌드됩니다. 이는 대부분의 타겟에서 기본값입니다. 호스트에 EGL 라이브러리가 있는 경우에는 명령줄 매개변수 --deqp-gl-context-type=egl을 사용하여 대상으로 테스트를 실행할 수 있습니다.

Android 빌드

Android 빌드는 네이티브 테스트 코드를 빌드하기 위해 CMake 빌드 스크립트를 사용합니다. 자바 구성요소(테스트 실행 서버 및 테스트 애플리케이션 스텁)는 표준 Android 빌드 도구를 사용하여 컴파일됩니다.

제공된 빌드 스크립트로 Android용 deqp 테스트 프로그램을 컴파일하려면 다음이 필요합니다.

• 최신 버전의 Android NDK, android/scripts/common.py 파일에 필수 버전이 나열되어 있음
• Android 독립 실행형 SDK 및 API 13, SDK 도구, SDK 플랫폼 도구 및 SDK 빌드 도구 패키지가 설치되어 있어야 함
• Apache Ant 1.9.4(자바 코드 빌드에 필요)
• CMake 2.8.12 이상
• Python 2.6 이상(2.x 시리즈), Python 3.x 지원 안 됨
• Windows: PATH의 NMake 또는 JOM
  • JOM으로 훨씬 빠른 빌드 가능
• 선택사항: Ninja make도 Linux에서 지원됨

Ant 및 SDK 라이브러리는 특정 재정의 값을 포함하는 PATH 환경 변수에 따라 위치가 결정됩니다. 로직은 android/scripts/common.py에 의해 제어됩니다.

NDK 디렉터리는 ~/android-ndk-VERSION 또는 C:/android/android-ndk-VERSION이어야 하거나 ANDROID_NDK_PATH 환경 변수를 통해 정의되어야 합니다.

Deqp 기기 구성요소, 테스트 실행 서비스 및 테스트 프로그램은 android/scripts/build.py 스크립트를 실행하여 빌드됩니다. 최종 .apk는 android/package/bin에서 생성되며 install.py 스크립트에 의해 설치될 수 있습니다. 명령줄 실행기가 사용된 경우 ADB를 통해 기기의 launch.py 스크립트로 ExecService가 실행됩니다. 스크립트는 원하는 디렉터리에서 실행할 수 있습니다.

Linux 빌드

테스트 바이너리 및 명령줄 유틸리티는 CMake로 makefile을 생성하여 Linux용으로 빌드할 수 있습니다. Linux 관련 빌드에 유용한 사전 정의된 여러 빌드 타겟이 있습니다.

항상 -DCMAKE_BUILD_TYPE=<Debug|Release>를 사용하여 빌드 유형을 지원합니다. Release는 적절한 기본값입니다. 이 기본값이 없으면 최적화되지 않은 출시 빌드가 생성됩니다.

-DCMAKE_C_FLAGS 및 -DCMAKE_CXX_FLAGS 명령줄 인수는 추가 인수를 컴파일러에 전달하는 데 사용할 수 있습니다. 예를 들어 32비트 또는 64비트 빌드는 -DCMAKE_C(XX)_FLAGS="-m32" 또는 "-m64"를 각각 설정하여 완료할 수 있습니다. 지정되지 않은 경우에는 일반적으로 64비트 도구 모음에서 64비트인 도구 모음 네이티브 아키텍처가 사용됩니다.

CMake에 -DCMAKE_LIBRARY_PATH 및 -DCMAKE_INCLUDE_PATH 인수를 사용하여 CMake에 추가 라이브러리를 제공하거나 검색 경로를 포함할 수 있습니다.

맞춤 위치의 드라이버 헤더 및 라이브러리에 관해 32비트 디버그 빌드를 수행하는 데 사용된 전체 명령줄의 예는 다음과 같습니다.

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

크로스 컴파일

크로스 컴파일은 CMake 도구 모음 파일을 통해 가능합니다. 도구 모음 파일은 사용할 컴파일러와 함께 라이브러리 및 헤더의 맞춤검색 경로를 지정합니다. 일반적인 시나리오와 관련된 여러 도구 모음 파일은 framework/delibs/cmake 디렉터리의 출시 패키지에 포함되어 있습니다.

표준 CMake 변수 외에도 다음과 같은 deqp 관련 변수가 도구 모음 파일에 의해 설정될 수 있습니다. CMake는 일반적으로 DE_OS, DE_COMPILER 및 DE_PTR_SIZE를 올바르게 감지할 수 있지만 DE_CPU는 도구 모음 파일에 의해 설정되어야 합니다.

도구 모음 파일은 CMAKE_TOOLCHAIN_FILE 빌드 매개변수를 사용하여 선택할 수 있습니다. 예를 들어 다음은 ARM/Linux에 CodeSourcery 크로스 컴파일러를 사용하여 makefile을 생성하게 됩니다.

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

GLES 및 EGL 라이브러리의 런타임 연결

deqp에는 연결 도중에 테스트 중인 API의 진입점이 필요 없습니다. 테스트 코드는 항상 함수 포인터를 통해 API에 액세스합니다. 그러면 런타임에 진입점을 동적으로 로드하거나 플랫폼에서 이를 연결 시점에 제공할 수 있습니다.

빌드 설정에 API 지원이 켜져 있고 링크 라이브러리가 제공되지 않는 경우에는 deqp가 필요한 진입점을 런타임에 로드합니다. 정적 연결을 원하는 경우 DEQP_<API>_LIBRARIES 빌드 구성 변수에 필요한 라이브러리를 제공하세요.

테스트 프레임워크 포팅

deqp를 포팅하려면 세 단계를 수행해야 하며, 기본 이동성 라이브러리를 조정하고 테스트 프레임워크 플랫폼 통합 인터페이스를 구현하고 실행 서비스를 포팅해야 합니다.

아래 표에는 포팅 변경사항이 적용되었을 가능성이 있는 위치가 나열되어 있습니다. 목록에 없는 위치는 외국일 가능성이 높습니다.

기본 이동성 라이브러리

기본 이동성 라이브러리는 이미 Windows, 대부분의 Linux 변수, Mac OS, iOS 및 Android를 지원합니다. 테스트 대상이 이러한 운영체제 중 하나에서 실행 중인 경우 기본 이동성 라이브러리를 아예 건드리지 않아도 될 가능성이 높습니다.

테스트 프레임워크 플랫폼 포트

deqp 테스트 프레임워크 플랫폼 포트에는 애플리케이션 진입점 및 플랫폼 인터페이스 구현, 이렇게 두 가지 구성요소가 필요합니다.

애플리케이션 진입점은 플랫폼 객체를 생성하고 명령줄(tcu::CommandLine) 객체를 생성하고 테스트 로그(tcu::TestLog)를 열고 테스트 애플리케이션(tcu::App)을 반복하는 역할을 합니다. 대상 OS가 표준 main() 진입점을 지원하는 경우 tcuMain.cpp를 진입점 구현으로 사용할 수 있습니다.

deqp 플랫폼 API는 다음 파일에 상세하게 설명되어 있습니다.

모든 플랫폼 포트의 기본 클래스는 tcu::Platform입니다. 플랫폼 포트는 GL 및 EGL 전용 인터페이스를 선택적으로 지원할 수 있습니다. 테스트 실행을 위해 무엇을 구현해야 하는지에 관한 개요는 아래 표를 참고하세요.

플랫폼 포트를 구현하는 방법은 레이어 헤더 포팅에 설명되어 있습니다.

테스트 실행 서비스

deqp 테스트 실행 인프라 또는 명령줄 실행기를 사용하려면 대상에 테스트 실행 서비스를 사용할 수 있어야 합니다. 서비스의 이동식 C++ 구현은 execserver 디렉터리에서 제공됩니다. 독립 실행형 바이너리는 PC 대상을 위한 deqp 테스트 모듈 빌드의 일부로 빌드됩니다. execserver/CMakeLists.txt를 수정하여 다른 대상에 빌드를 사용 설정할 수 있습니다.

테스트 실행 서비스의 C++ 버전은 2개의 명령줄 매개변수를 허용합니다.

• --port=<port>는 서버가 수신하는 TCP 포트를 설정합니다. 기본값은 50016입니다.
• --single은 클라이언트 연결이 끊기면 서버 프로세스를 종료합니다. 기본적으로 서버 프로세스는 테스트 실행 요청의 추가적인 처리를 위해 가동 상태를 유지합니다.

테스트 실행

이 페이지에서는 Linux 및 Windows 환경에서 명령줄 인수를 사용하여 deqp 테스트를 실행하고 Android 애플리케이션 패키지를 작업하는 방법에 관해 설명합니다.

Linux 및 Windows 환경

먼저 다음 파일과 디렉터리를 대상에 복사합니다.

실행 서비스와 테스트 바이너리는 대상 파일 시스템 어디에나 배포 가능하지만 테스트 바이너리는 현재의 작업 디렉터리에서 데이터 디렉터리를 찾게 됩니다. 준비되면 대상 기기에서 테스트 실행 서비스를 시작합니다. 서비스 시작에 관한 자세한 내용은 테스트 실행 서비스를 참고하세요.

명령줄 인수

아래 표에는 모든 테스트 프로그램의 실행에 영향을 미치는 명령줄 인수가 나열되어 있습니다.

GLES2 및 GLES3 전용 인수

테스트 사례 목록 형식

테스트 사례 목록은 두 가지 형식으로 제공될 수 있습니다. 첫 번째 옵션을 선택하면 각 테스트의 온전한 이름이 표준 ASCII 파일의 개별 행에 나열됩니다. 테스트 세트가 커질수록 반복적으로 접두어를 추가하기가 어려울 수 있습니다. 접두어 반복을 피하려면 아래에 보이는 trie(접두어 트리라고도 함) 구문을 사용하세요.

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

예:

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

다음 두 테스트 사례로 해석됩니다.

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

Android

Android 애플리케이션 패키지에는 테스트 실행 서비스, 테스트 바이너리 및 데이터 파일을 비롯한 모든 필수 구성요소가 포함됩니다. 테스트 활동은 ELG을 사용하는 NativeActivity입니다(Android 3.2 이상 필요).

애플리케이션 패키지는 다음 명령어로 설치할 수 있습니다(표시된 이름은 Android CTS 패키지의 APK 이름이며, 이름이 빌드에 종속됨).

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

테스트 실행 서비스를 실행하고 포트 전달을 설정하려면 다음을 사용하세요.

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

디버그 출력은 테스트 실행 전에 다음을 실행하여 사용 설정할 수 있습니다.

adb –d shell setprop log.tag.dEQP DEBUG

Android CTS 없이 Android에서 테스트 실행

테스트 실행 활동을 수동으로 시작하려면 android.app.NativeActivity를 타겟팅하는 Android 인텐트를 구성합니다. 활동은 com.drawelements.deqp 패키지에서 찾을 수 있습니다. 명령줄은 인텐트에 키 "cmdLine"이 있는 추가 문자열로 제공해야 합니다.

테스트 로그는 /sdcard/dEQP-log.qpa에 작성됩니다. 테스트 실행이 정상적으로 시작되지 않는 경우 기기 로그에서 추가적인 디버깅 정보를 사용할 수 있습니다.

활동은 am 유틸리티를 사용하여 명령줄에서 실행할 수 있습니다. 예를 들어 NativeActivity,를 지원하는 플랫폼에서 dEQP-GLES2.info 테스트를 실행하려면 다음 명령어를 사용하세요.

adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \
'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'

Android 디버깅

Android의 GDB 디버거에서 테스트를 실행하려면 먼저 아래의 두 스크립트를 실행하여 디버그 빌드를 컴파일하고 설치합니다.

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

디버그 빌드가 기기에 설치된 이후에 호스트에서 실행 중인 GDB에서 테스트를 실행하려면 다음 명령어를 실행합니다.

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

deqp 명령줄은 실행하려는 테스트 사례 및 기타 필수 매개변수에 종속됩니다. 스크립트는 deqp 실행 시작 부분에 기본 중단점을 추가합니다(tcu::App::App).

debug.py 스크립트는 디버깅용 중단점, gdbserver 연결 매개변수 및 디버그의 추가 바이너리 경로를 설정하는 등의 작업을 위한 여러 개의 명령줄 인수를 허용합니다(모든 인수 및 설명에 debug.py --help 사용). 또한 스크립트는 대상 기기에서 몇몇 기본 라이브러리를 복사하여 기호 목록을 가져옵니다.

드라이버 코드를 순차적으로 실행하려면(GDB가 전체 디버깅 정보를 포함하는 바이너리의 위치를 인지해야 하는 경우) debug.py 명령줄 매개변수를 통해 라이브러리를 더 추가합니다. 이 스크립트는 스크립트 파일의 132행에서 시작되는 GDB의 구성 파일을 작성합니다. 바이너리 등에 추가 경로를 제공할 수는 있지만 올바른 명령줄 매개변수를 제공하는 것만으로도 충분합니다.

참고: Windows에서는 GDB 바이너리에 libpython2.7.dll이 필요합니다. debug.py를 실행하기 전에 <path-to-ndk>/prebuilt/windows/bin을 PATH 변수에 추가하세요.

참고: 네이티브 코드 디버깅은 스톡 Android 4.3에서 작동하지 않습니다. 해결 방법은 이 공개 버그를 참고하세요. Android 4.4 이상에는 이 버그가 포함되지 않습니다.

테스트 자동화

Deqp 테스트 모듈은 여러 가지 방법을 사용하여 자동화된 테스트 시스템에 통합할 수 있습니다. 최상의 접근 방식은 기존 테스트 인프라 및 대상 환경에 따라 다릅니다.

테스트 실행의 기본 출력은 항상 테스트 로그 파일 즉, .qpa 접미사를 포함하는 파일입니다. 전체 테스트 결과는 테스트 로그에서 파싱할 수 있습니다. 콘솔 출력은 디버깅 정보일 뿐이며 일부 플랫폼에서는 사용할 수 없습니다.

테스트 바이너리는 테스트 자동화 시스템에서 직접 호출할 수 있습니다. 테스트 바이너리는 특정 사례, 테스트 모음 또는 모든 가용한 테스트에 실행할 수 있습니다. 실행 도중에 치명적인 오류(예: 특정 API 오류 또는 장애)가 발생하면 테스트 실행이 취소됩니다. 회귀 테스트 시의 가장 좋은 접근 방식은 개별 사례나 소규모 테스트 세트에 관한 테스트 바이너리를 호출하여 하드 오류의 경우에도 부분적인 결과를 제공하는 것입니다.

deqp는 실행 서비스와 함께 사용하여 더욱 안정적인 통합을 실현할 수 있는 명령줄 테스트 실행 도구와 함께 제공됩니다. 실행기는 테스트 프로세스 종료를 감지하고 다음 가용한 사례에 테스트 실행을 재개합니다. 단일 로그 파일은 전체 테스트 세션에서 생성됩니다. 이 설정은 장애 복구 기능을 제공하지 않는 가벼운 테스트 시스템에 적합합니다.

명령줄 테스트 실행 도구

최신 명령줄 도구 모음에는 원격 테스트 실행 도구, 회귀 분석을 위한 테스트 로그 비교 생성기, test-log-to-CSV 변환기, test-log-to-XML 변환기와 testlog-to-JUnit 변환기가 포함됩니다.

이러한 도구의 소스 코드는 executor 디렉터리에 있으며, 바이너리는 <builddir>/executor 디렉터리에 빌드됩니다.

명령줄 테스트 실행기

명령줄 테스트 실행기는 기기에서 테스트 실행을 시작하고 TCP/IP를 통해 관련 결과 로그를 수집하기 위한 이동식 C++ 도구입니다. 실행기는 대상 기기의 실행 서비스(execserver)와 통신합니다. 함께 사용하면 테스트 프로세스 장애로부터의 복구 같은 기능을 얻을 수 있습니다. 다음 예시는 명령줄 테스트 실행기 사용 방법을 보여줍니다(자세한 내용을 확인하려면 --help 사용).

예시 1: Android 기기에서 GLES2 기능 테스트 실행:

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"

예시 2: 부분 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

테스트 로그 CSV 내보내기 및 비교

deqp에는 테스트 로그(.qpa 파일)를 CSV 파일로 변환하기 위한 도구가 있습니다. CSV 출력에는 테스트 사례 목록 및 결과가 포함됩니다. 또한 도구는 2개 이상의 일괄 결과를 비교한 후 입력 일괄 결과에 다른 상태 코드가 포함된 테스트 사례만 나열할 수 있습니다. 비교 시 일치하는 사례의 수도 출력됩니다.

CSV 형식의 출력은 표준 명령줄 유틸리티 또는 스프레드시트 편집기를 이용한 추가 처리를 진행하는 경우에 매우 실용적입니다. 사람이 읽을 수 있는 추가적인 일반 텍스트 형식은 명령줄 인수 --format=text를 사용하여 선택할 수 있습니다.

예시 1: CSV 형식의 테스트 로그 내보내기

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

예시 2: 두 테스트 로그 간의 테스트 결과 차이 나열

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

참고: 인수 --value=code는 'Pass' 또는 'Fail' 등의 테스트 결과 코드를 출력합니다. 인수 --value=details는 성능, 기능 또는 정확성 테스트에 의해 생성된 결과에 관한 추가 설명이나 숫자 값을 선택합니다.

테스트 로그 XML 내보내기

테스트 로그 파일은 testlog-to-xml 유틸리티를 사용하여 유효한 XML 문서로 변환할 수 있습니다. 다음과 같이 두 가지 출력 모드가 지원됩니다.

• 별개의 문서 모드입니다. 대상 디렉터리에 각 테스트 사례와 caselist.xml 요약 문서가 작성됩니다.
• .qpa 파일의 모든 결과가 단일 XML 문서에 작성되는 단일 파일 모드입니다.

내보낸 테스트 로그 파일은 XML 스타일 시트를 사용하여 브라우저에서 볼 수 있습니다. 샘플 스타일 시트 문서(testlog.xsl 및 testlog.css)가 doc/testlog-stylesheet 디렉터리에서 제공됩니다. 브라우저에서 로그 파일을 렌더링하려면 두 스타일 시트 파일을 내보낸 XML 문서가 위치한 동일한 디렉터리에 복사합니다.

Google Chrome을 사용 중인 경우 Chrome에서 보안을 이유로 로컬 파일 액세스를 제한하므로 HTTP를 통해 파일에 액세스해야 합니다. 표준 Python 설치에는 기본 HTTP 서버가 포함됩니다. 이 서버를 실행하면 현재 디렉터리에 python –m SimpleHTTPServer 8000 명령어를 제공할 수 있습니다. 서버를 실행한 후에는 Chrome 브라우저를 http://localhost:8000으로 가리켜 테스트 로그를 보기만 하면 됩니다.

JUnit 테스트 로그로 변환

다수의 테스트 자동화 시스템은 JUnit 출력에서 테스트 실행 결과 보고서를 생성할 수 있습니다. deqp 테스트 로그 파일은 testlog-to-junit 도구를 사용하여 JUnit 출력 형식으로 변환할 수 있습니다.

도구는 현재 테스트 사례 결과만 변환하는 기능을 지원합니다. JUnit은 'pass' 및 'fail' 결과만 지원하므로 deqp의 합격 결과가 'JUnit pass'로 매핑되고 다른 결과는 불합격으로 간주됩니다. 원래 deqp 결과 코드는 JUnit 출력에서 제공됩니다. 로그 메시지 및 결과 이미지와 같은 다른 데이터는 변환 과정에서 보전되지 않습니다.

특수 테스트 그룹 사용

일부 테스트 그룹은 특수 명령줄 옵션을 요구 또는 지원하거나 특정 시스템에 사용할 경우 특별히 조심하도록 요구할 수 있습니다.

메모리 할당 스트레스 테스트

메모리 할당 스트레스 테스트는 드라이버가 메모리 부족 오류를 보고할 때까지 특정 리소스를 반복적으로 할당하여 메모리 부족 조건을 실행할 수 있습니다.

Android 및 대부분의 Linux 변형과 같은 특정 플랫폼에서는 운영체제에서 드라이버가 메모리 부족 오류를 처리하도록 허용하거나 메모리 부족 오류를 제공하는 대신 테스트 프로세스를 중지할 수 있습니다. 이러한 플랫폼에서는 메모리 부족 오류를 일으키도록 설계된 테스트가 기본으로 중지되며, --deqp-test-oom=enable 명령줄 인수를 사용하여 사용 설정해야 합니다. 이러한 테스트는 수동으로 실행하여 시스템이 리소스 압박 하에서 올바르게 동작하는지 확인하는 것이 좋습니다. 하지만 이러한 상황에서는 테스트 프로세스 장애가 합격으로 해석되어야 합니다.

테스트 그룹

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

장시간 실행되는 렌더링 스트레스 테스트

렌더링 스트레스 테스트는 지속적인 렌더링 로드 하에서의 안정성 문제를 드러내도록 설계되었습니다. 기본적으로는 테스트가 몇 차례의 반복만 실행하지만 --deqp-test-iteration-count=-1 명령줄 인수를 제공하여 무제한으로 실행되도록 구성할 수 있습니다. 장시간에 걸쳐 이러한 테스트를 실행할 때에는 테스트 watchdog을 중지(--deqp-watchdog=disable)해야 합니다.

테스트 그룹

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