ड्रॉएलिमेंट क्वालिटी प्रोग्राम की टेस्टिंग

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

AOSP में https://android.googlesource.com/platform/external/deqp में साइन इन करें. इस पेज पर, deqp टेस्ट सुइट को नए एनवायरमेंट में डिप्लॉय करने का तरीका बताया गया है.

सबमिट किए गए नए कोड का इस्तेमाल करने के लिए, deqp-dev की ब्रांच का इस्तेमाल करें. किसी खास Android CTS रिलीज़ से मेल खाने वाले कोड के लिए, release-code-name-release ब्रांच (जैसे, Android 6.0 के लिए, marshmallow-release ब्रांच का इस्तेमाल करें).

सोर्स का लेआउट

Deqp टेस्ट मॉड्यूल और इसके साथ काम करने वाली लाइब्रेरी के लिए सोर्स कोड लेआउट यह है नीचे दी गई टेबल में दी गई हैं (लिस्टिंग में पूरी जानकारी नहीं दी गई है, लेकिन डालें).

डायरेक्ट्री	ब्यौरा
android	Android टेस्टर के सोर्स और बिल्ड स्क्रिप्��
data	डेटा फ़ाइलों की जांच करें
modules	मॉड्यूल के सोर्स की जांच करें
modules/egl	ईजीएल मॉड्यूल
modules/gles2	GLES2 मॉड्यूल
modules/gles3	GLES3 मॉड्यूल
modules/gles31	GLES3.1 मॉड्यूल
modules/gles32	GLES3.2 मॉड्यूल
targets	टारगेट के हिसाब से बिल्ड कॉन्फ़िगरेशन फ़ाइलें
framework	Deqp टेस्ट मॉड्यूल फ़्रेमवर्क और सुविधाएं
framework/delibs	बेस पोर्टेबिलिटी और बिल्ड लाइब्रेरी
framework/platform	प्लैटफ़ॉर्म पोर्ट
framework/qphelper	टेस्ट प्रोग्राम इंटिग्रेशन लाइब्रेरी (C)
framework/common	Deqp फ़्रेमवर्क (C++)
framework/opengl, framework/egl	एपीआई की खास सुविधाएं
execserver	डिवाइस-साइड एक्ज़ीक्यूटिव सर्वर सोर्स
executor	होस्ट-साइड टेस्ट एक्ज़ेक्यूटर शेल टूल और सुविधाएं
external	एक्सटर्नल libpng और zlib के लिए स्टब डायरेक्ट्री बनाएं

ओपन सोर्स कॉम्पोनेंट

इस डेस्क में libpng और zlib का इस्तेमाल होता है, जिन्हें फ़ेच किया जा सकता है स्क्रिप्ट का उपयोग करके platform/external/deqp/external/fetch_sources.py या git की मदद से platform/external/[libpng,zlib] से.

टेस्ट प्रोग्राम बनाएं

टेस्ट फ़्रेमवर्क को पोर्टेबिलिटी को ध्यान में रखकर बनाया गया है. सिर्फ़ C++ सपोर्ट और स्टैंडर्ड सिस्टम लाइब्रेरी की ज़रूरी शर्तें नीचे दी गई हैं I/O, थ्रेड और सॉकेट.

CMake बिल्ड सिस्टम

deqp स्रोतों में CMake के लिए स्क्रिप्ट बनाई गई हैं, जो इकट्ठा करने की सुविधा देने वाला कॉन्टेंट बनाने में मदद मिलती है.

CMake एक ओपन सोर्स बिल्ड सिस्टम है, जो कई प्लैटफ़ॉर्म और टूलचेन. CMake की मदद से नेटिव मेकफ़ाइल या IDE प्रोजेक्ट फ़ाइलें जनरेट की जाती हैं टारगेट-इंडिपेंडेंट कॉन्फ़िगरेशन फ़ाइलें. CMake के बारे में ज़्यादा जानकारी के लिए, कृपया CMake दस्तावेज़.

CMake की सुविधाएं, एक ऐसी ज��ह बनाने में मदद करती हैं जो काम नहीं करता है. इसका मतलब है कि आपको हमेशा एक अलग बिल्ड डायरेक्ट्री में मेकफ़ाइल या प्रोजेक्ट फ़ाइलें बनाएं सोर्स ट्री के बाहर. CMake की सुविधा में किसी भी तरह की "डिस्टेंस-क्लीन" सुविधा नहीं है टारगेट है, इसलिए CMake के ज़रिए जनरेट की गई किसी भी फ़ाइल को निकालने का काम मैन्युअल रूप से किया जाना चाहिए.

-DOPTION_NAME=VALUE का इस्तेमाल करके CMake को कॉन्फ़िगरेशन के विकल्प दिए जाते हैं सिंटैक्स. डिकोड करने के लिए, आम तौर पर इस्तेमाल होने वाले कुछ विकल्प नीचे दिए गए हैं.

कॉन्फ़िगरेशन का विकल्प	ब्यौरा
DEQP_TARGET	टारगेट का नाम. उदाहरण के लिए: "android" deqp CMake स्क्रिप्ट में फ़ाइल शामिल होगी targets/DEQP_TARGET/DEQP_TARGET.cmake और मुझे उम्मीद है कि बिल्ड विकल्प मौजूद होते हैं.
CMAKE_TOOLCHAIN_FILE	CMake के लिए टूलचेन फ़ाइल का पाथ. क्रॉस कंपाइलेशन के लिए इस्तेमाल किया जाता है.
CMAKE_BUILD_TYPE	मेकफ़ाइल टारगेट के लिए बिल्ड टाइप. मान्य वैल्यू ये हैं: "Debug" और "रिलीज़" करें. ध्यान दें कि परिभाषा और डिफ़ॉल्ट टाइप, टारगेट किए गए बिल्ड सिस्टम के हिसाब से तय होते हैं. ज़्यादा जानकारी के लिए CMake दस्तावेज़ देखें.

टारगेट बिल्ड फ़ाइल बनाना

deqp बिल्ड सिस्टम को टारगेट बिल्ड फ़ाइलों का इस्तेमाल करके, नए टारगेट के लिए कॉन्फ़िगर किया गया है. टारगेट बिल्ड फ़ाइल तय करती है कि प्लैटफ़ॉर्म पर कौनसी सुविधाएं काम करती हैं और कौनसी लाइब्रेरी या अतिरिक्त पाथ शामिल करना ज़रूरी है. टारगेट फ़ाइल के नाम, targets/NAME/NAME.cmake के मुताबिक हैं फ़ॉर्मैट और टारगेट को DEQP_TARGET बिल्ड पैरामीटर का इस्तेमाल करके चुना जाता है.

टारगेट फ़ाइलों में मौजूद फ़ाइल के पाथ, बेस deqp डायरेक्ट्री से जुड़े होते हैं, न कि targets/NAME डायरेक्ट्री. नीचे दिए गए स्टैंडर्ड वैरिएबल, टारगेट बिल्ड फ़ाइल से सेट किए जा सकते हैं.

वैरिएबल	ब्यौरा
DEQP_TARGET_NAME	टारगेट का नाम (टेस्ट लॉग में शामिल किया जाएगा)
DEQP_SUPPORT_GLES2	GLES2 काम करता है या नहीं (डिफ़ॉल्ट: बंद)
DEQP_GLES2_LIBRARIES	GLES2 लाइब्रेरी (अगर काम नहीं करती है या डाइनैमिक लोडिंग का इस्तेमाल किया जाता है, तो इसे खाली छोड़ दें)
DEQP_SUPPORT_GLES3	GLES3.x काम करता है या नहीं (डिफ़ॉल्ट: बंद)
DEQP_GLES3_LIBRARIES	GLES3.x लाइब्रेरी (अगर यह सुविधा काम नहीं करती या डाइनैमिक लोडिंग का इस्तेमाल किया जाता है, तो इसे खाली छोड़ दें)
DEQP_SUPPORT_VG	OpenVG काम करता है या नहीं (डिफ़ॉल्ट: बंद)
DEQP_OPENVG_LIBRARIES	OpenVG लाइब्रेरी (अगर यह सुविधा काम नहीं करती है या डाइनैमिक लोडिंग का इस्तेमाल किया जा रहा है, तो इसे खाली छोड़ दें)
DEQP_SUPPORT_EGL	क्या EGL काम करता है (डिफ़ॉल्ट: बंद)
DEQP_EGL_LIBRARIES	ईजीएल लाइब्रेरी (अगर यह सुविधा काम नहीं करती है या डाइनैमिक लोडिंग का इस्तेमाल किया जाता है, तो इसे खाली छोड़ दें)
DEQP_PLATFORM_LIBRARIES	लिंक करने के लिए, प्लैटफ़ॉर्म के हिसाब से अन्य लाइब्रेरी ज़रूरी हैं
DEQP_PLATFORM_COPY_LIBRARIES	हर टेस्ट बाइनरी बिल्ड डायरेक्ट्री में कॉपी की जाने वाली लाइब्रेरी की सूची. इनमें से कोई भी हो सकता है का इस्तेमाल उन लाइब्रेरी को कॉपी करने में किया जाता है जो टेस्ट चलाने के लिए ज़रूरी हैं, लेकिन डिफ़ॉल्ट रूप से मौजूद नहीं होती हैं खोज पाथ.
TCUTIL_PLATFORM_SRCS	प्लैटफ़ॉर्म पोर्ट के सोर्स की सूची. डिफ़ॉल्ट सोर्स, इनके आधार पर तय किए जाते हैं और ओएस. ध्यान दें: पाथ इनके आधार पर तय होते हैं: framework/platform

टारगेट बिल्ड फ़ाइल include_directories() और link_directories() CMake फ़ंक्शन.

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फ़ाइल जनरेट की जा सकती है बिल्ड टाइप (-DCMAKE_BUILD_TYPE="Debug" या "Release") के ��ौर पर ��ा��ें.

रेंडर करने के लिए कॉन्टेक्स्ट बनाएं

रेंडरिंग कॉन्टेक्स्ट को या तो WGL के साथ या Windows पर EGL के साथ बनाया जा सकता है.

WGL सहायता

Win32 बाइनरी, WGL के साथ जीएल कॉन्टेक्स्ट बनाने की सुविधा देते हैं, क्योंकि इसके लिए सिर्फ़ इसकी ज़रूरत होती है स्टैंडर्ड लाइब्रेरी का इस्तेमाल करके देख सकते हैं. --deqp-gl-context-type=wgl का इस्तेमाल करके, डब्ल्यूजीएल कॉन्टेक्स्ट चुना जा सकता है कमांड लाइन आर्ग्युमेंट. WGL मोड में, deqp, WGL_EXT_create_context_es_profile का इस्तेमाल करता है OpenGL ES कॉन्टेक्स्ट बनाने के लिए एक्सटेंशन. इसे इस तरह की जांच की गई है जिससे यह पुष्टि की जा सके कि यह NVIDIA और Intel के नए ड्राइवर हैं. AMD ड्राइवर ज़रूरी शर्तों के साथ काम नहीं करते एक्सटेंशन चुनें.

EGL सहायता

Deqp को Windows पर EGL के लिए डाइनैमिक लोडिंग के साथ बनाया गया है, अगर DEQP_SUPPORT_EGL चालू है. ज़्यादातर टारगेट में यह सेटिंग डिफ़ॉल्ट रूप से सेट होती है. इसके बाद, अगर होस्ट के पास EGL लाइब्रेरी हैं उपलब्ध है, तो कमांड लाइन का इस्तेमाल करके उनकी मदद से टेस्ट किए जा सकते हैं पैरामीटर: --deqp-gl-context-type=egl

Android बिल्ड

Android बिल्ड, नेटिव टेस्ट कोड बनाने के लिए CMake बिल्ड स्क्रिप्ट का इस्तेमाल करता है. Java के पार्ट यानी टेस्ट एक्ज़िक्यूशन सर्वर और टेस्ट ऐप्लिकेशन स्टूब जिसे स्टैंडर्ड Android बिल्ड टूल का इस्तेमाल करके कंपाइल किया गया है.

दिए गए बिल्ड के साथ Android के लिए डेक्यूपी टेस्ट प्रोग्राम को कंपाइल करने के लिए तो आपको इन चीज़ों की ज़रूरत होगी:

• का नवीनतम संस्करण Android एनडीके; android/scripts/common.py फ़ाइल में ज़रूरी वर्शन की सूची है
• एपीआई 13, SDK टूल, SDK प्लैटफ़ॉर्म-टूल, और SDK टूल वाला Android का स्टैंडअलोन SDK टूल बिल्ड-टूल पैकेज इंस्टॉल किए गए
• Apache Ant 1.9.4 (Java कोड बिल्ड के लिए ज़रूरी)
• CMake 2.8.12 या इसके बाद का वर्शन
• Python 2.6 या 2.x सीरीज़ में नया वर्शन; Python 3.x का इस्तेमाल नहीं किया जा सकता
• Windows के लिए: PATH में NMake या JOM
  • JOM तेज़ बिल्ड की सुविधा देता है
• ज़रूरी नहीं: निंजा बनाने की सुविधा, Linux पर भी काम करती है

Ant और SDK की बाइनरी, PATH के एनवायरमेंट के आधार पर बनाई जाती हैं कुछ ओवरराइडिंग डिफ़ॉल्ट. यह लॉजिक, android/scripts/common.py के ज़रिए कंट्रोल किया जाता है.

एनडीके (NDK) डायरेक्ट्री, ~/android-ndk-VERSION या C:/android/android-ndk-VERSION या ANDROID_NDK_PATH के ज़रिए तय किया गया एनवायरमेंट वैरिएबल.

उपयोगकर्ता के डिवाइस पर मौजूद कॉम्पोनेंट, टेस्ट लागू करने की सेवा, और टेस्ट प्रोग्राम की जानकारी को android/scripts/build.py स्क्रिप्ट को एक्ज़ीक्यूट करके बनाया गया. अंतिम .apk में बनाया गया है android/package/bin को इंस्टॉल किया जा सकता है और इसे install.py स्क्रिप्ट की मदद से इंस्टॉल किया जा सकता है. अगर कमांड लाइन एक्ज़िक्यूटर का इस्तेमाल किया गया हो, तो एक्ज़ीक्यूटिव सेवा लॉन्च की गई हो ADB के ज़रिए डिवाइस पर launch.py स्क्रिप्ट के साथ. स्क्रिप्ट किसी भी डायरेक्ट्री से एक्ज़ीक्यूट की जा सकती हैं.

Linux बिल्ड

Linux के लिए टेस्ट बाइनरी और कमांड लाइन यूटिलिटी बनाई जा सकती हैं. इसके लिए, मेकफ़ाइल को सीमेक करें. पहले से तय किए गए कई बिल्ड टारगेट उपलब्ध हैं, जो Linux के लिए ऐप्लिकेशन बनाते समय काम आ सकते हैं.

टारगेट बनाएं	ब्यौरा
default	यह डिफ़ॉल्ट टारगेट है, जो अलग-अलग एपीआई के साथ काम करने की स्थिति तय करने के लिए, CMake प्लैटफ़ॉर्म की जांच का इस्तेमाल करता है.
x11_glx	OpenGL (ES) कॉन्टेक्स्ट बनाने के लिए GLX का इस्तेमाल करता है.
x11_egl	OpenGL (ES) कॉन्टेक्स्ट बनाने के लिए EGL का इस्तेमाल करता है.
x11_egl_glx	X11 के साथ GLX और EGL, दोनों काम करते हैं.

बिल्ड टाइप बताने के लिए हमेशा -DCMAKE_BUILD_TYPE=<Debug|Release> का इस्तेमाल करें. Release एक अच्छा डिफ़ॉल्ट तरीका है. इसके बिना, एक डिफ़ॉल्ट रिलीज़ बिल्ड बनाया जाता है, जो ऑप्टिमाइज़ नहीं किया गया है.

-DCMAKE_C_FLAGS और -DCMAKE_CXX_FLAGS कमांड लाइन आर्ग्युमेंट इसका इस्तेमाल कंपाइलर को अतिरिक्त आर्ग्युमेंट पास करने के लिए किया जाता है. उदाहरण के लिए 32-बिट या 64-बिट बिल्ड को -DCMAKE_C(XX)_FLAGS="-m32" या "-m64" को सेट करती है. अगर नहीं बताया गया है, तो टूलचेन नेटिव आर्किटेक्चर का इस्तेमाल किया जाता है. आम तौर पर, 64-बिट टूलचेन पर 64-बिट का इस्तेमाल किया जाता है.

-DCMAKE_LIBRARY_PATH और -DCMAKE_INCLUDE_PATH आर्ग्युमेंट इस्तेमाल किए जा सकते हैं CMake के लिए अतिरिक्त लाइब्रेरी देने या खोज पथ शामिल करने के लिए.

पूरे कमांड लाइन का एक उदाहरण जिसका इस्तेमाल करके, कस्टम जगह में ड्राइवर के हेडर और लाइब्रेरी नीचे दी गई हैं:

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 क��� टूलचेन फ़ाइल ��े सेट किया जाना चाहिए.

वैरिएबल	ब्यौरा
DE_OS	ऑपरेटिंग सिस्टम. इन वैल्यू का इस्तेमाल किया जा सकता है: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS
DE_COMPILER	कंपाइलर टाइप. इन वैल्यू का इस्तेमाल किया जा सकता है: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG
DE_CPU	सीपीयू का टाइप. इस्तेमाल की जा सकने वाली वैल्यू हैं: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE	साइज़(void*) का इस्तेमाल कर सकते हैं. इन वैल्यू का इस्तेमाल किया जा सकता है: 4 और 8

टूलचेन फ़ाइल को, CMAKE_TOOLCHAIN_FILE बिल्ड पैरामीटर का इस्तेमाल करके चुना जा सकता है. उदाहरण के लिए, नीचे दिए गए फ़ॉर्मैट, ARM/Linux के लिए CodeSourcery क्रॉस-कंपाइलर का इस्तेमाल करके बिल्ड के लिए मेकफ़ाइल बनाएंगे:

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

जीएलईएस और ईजीएल लाइब्रेरी को रनटाइम के दौरान लिंक करने की सुविधा

लिंक करते समय, deqp को टेस्ट में, एपीआई के एंट्री पॉइंट की ज़रूरत नहीं है. कॉन्टेंट बनाने टेस्ट कोड, फ़ंक्शन पॉइंटर के ज़रिए हमेशा एपीआई को ऐक्सेस करता है. एंट्री पॉइंट ये काम कर सकते हैं फिर उन्हें रन टाइम पर डायनैमिक तौर पर लोड किया जा सकता है या प्लैटफ़ॉर्म पोर्ट उन्हें लिंक समय.

अगर बिल्ड सेटिंग और लिंक लाइब्रेरी में किसी एपीआई के लिए सपोर्ट चालू है अगर वैल्यू नहीं दी गई है, तो रन टाइम के दौरान Deqp से ज़रूरी एंट्री पॉइंट लोड हो जाएंगे. अगर स्टैटिक लिंकिंग की ज़रूरत है, तो DEQP_<API>_LIBRARIES में ज़रूरी लिंक लाइब्रेरी उपलब्ध कराएं बिल्ड कॉन्फ़िगरेशन वैरिएबल.

टेस्ट फ़्रेमवर्क को पोर्ट करना

डीक्यूपी को पोर्ट करने के लिए तीन चरण पूरे कर��े हैं: बेस पोर्टेबिलिटी लाइब्रेरी में बदलाव करना, टेस्ट-फ़्रेमवर्क प्लैटफ़ॉर्म-इंटिग्रेशन इंटरफ़ेस को लागू करना और एक्ज़ीक्यूशन सेवा.

इस टेबल में, उन जगहों की जानकारी दी गई है जहां पोर्ट करने से जुड़े संभावित बदलाव किए जा सकते हैं. इसके अलावा कुछ और काफ़ी अलग हो सकते हैं.

जगह की जानकारी	ब्यौरा
framework/delibs/debase framework/delibs/dethread framework/delibs/deutil	ओएस के हिसाब से कोड को लागू करना.
framework/qphelper/qpCrashHandler.c	ज़रूरी नहीं: आपके ओएस को लागू करने की प्रोसेस.
framework/qphelper/qpWatchDog.c	आपके ओएस को लागू करने की प्रोसेस. मौजूदा लाइब्रेरी dethread और स्टैंडर्ड C लाइब्रेरी पर आधारित है.
framework/platform	नए प्लैटफ़ॉर्म पोर्ट और ऐप्लिकेशन स्टब को यहां बताए गए तरीके से लागू किया जा सकता है फ़्रेमवर्क प्लैटफ़ॉर्म पोर्ट की जांच करना.

बेस पोर्टेबिलिटी लाइब्रेरी

बेस पोर्टेबिलिटी लाइब्रेरी, पहले से ही Windows, Linux के ज़्यादातर वर्शन, Mac OS, iOS, और Android. अगर टेस्ट टारगेट इनमें से किसी एक ऑपरेटिंग सिस्टम पर चलता है, बेस पोर्टेबिलिटी लाइब्रेरी को छूने की कोई ज़रूरत नहीं होगी.

टेस्ट फ़्रेमवर्क प्लैटफ़ॉर्म पोर्ट

deqp टेस्ट फ़्रेमवर्क प्लैटफ़ॉर्म पोर्ट के लिए, दो कॉम्पोनेंट की ज़रूरत होती है: ऐप्लिकेशन और प्लैटफ़ॉर्म इंटरफ़ेस को लागू किया जा सकता है.

ऐप्लिकेशन का एंट्री पॉइंट, प्लैटफ़ॉर्म ऑब्जेक्ट बनाने के लिए ज़िम्मेदार होता है, कमांड लाइन (tcu::CommandLine) ऑब्जेक्ट बनाकर, टेस्ट लॉग खोला जा रहा है (tcu::TestLog) पर क्लिक करके, और टेस्ट ऐप्लिकेशन (tcu::App) को दोहराना होगा. अगर टारगेट ओएस में, स्टैंडर्ड main() एंट्री पॉइंट काम करता है. tcuMain.cpp का इस्तेमाल किया जा सकता है का इस्तेमाल किया जा सकता है.

नीचे दी गई फ़ाइलों में, deqp प्लैटफ़ॉर्म एपीआई के बारे में पूरी जानकारी दी गई है.

फ़ाइल	ब्यौरा
framework/common/tcuPlatform.hpp	सभी प्लैटफ़ॉर्म पोर्ट के लिए बेस क्लास
framework/opengl/gluPlatform.hpp	OpenGL प्लैटफ़ॉर्म इंटरफ़ेस
framework/egl/egluPlatform.hpp	EGL प्लैटफ़ॉर्म का इंटरफ़ेस
framework/platform/tcuMain.cpp	ऐप्लिकेशन का स्टैंडर्ड एंट्री पॉइंट

सभी प्लैटफ़ॉर्म पोर्ट का बेस क्लास tcu::Platform है. प्लैटफ़ॉर्म पोर्ट, इसके अलावा, GL- और EGL के खास इंटरफ़ेस पर भी काम किया जा सकता है. यहां जाएं: नीचे दी गई टेबल में बताया गया है कि टेस्ट करना चाहिए.

मॉड्यूल	इंटरफ़ेस
OpenGL (ES) टेस्ट मॉड्यूल	जीएल प्लैटफ़ॉर्म इंटरफ़ेस
ईजीएल टेस्ट मॉड्यूल	EGL प्लैटफ़ॉर्म का इंटरफ़ेस

प्लैटफ़ॉर्म पोर्ट लागू करने के बारे में ज़्यादा जानकारी पोर्टिंग लेयर हेडर.

जांच करने की सेवा

deqp टेस्ट एक्ज़ीक्यूशन इन्फ़्रास्ट्रक्चर या कमांड लाइन एक्ज���ेक्यूटर का इस्तेमाल करने के लिए, परीक्षण निष्पादन सेवा लक्ष्य पर उपलब्ध होनी चाहिए. पोर्टेबल C++ सेवा लागू करने की जानकारी execserver डायरेक्ट्री में दी गई है. अपने-आप में उपलब्ध बाइनरी को deqp टेस्ट मॉड्यूल के हिस्से के तौर पर बनाया गया है पीसी टारगेट के लिए बिल्ड. बिल्ड ऑन चालू करने के लिए, execserver/CMakeLists.txt में बदलाव किया जा सकता है टारगेट के लिए.

जांच एक्ज़ीक्यूशन सेवा के C++ वर्शन में दो कमांड लाइन इस्तेमाल की जा सकती हैं पैरामीटर:

• --port=<port> वह टीसीपी पोर्ट सेट करेगा जिसे सर्वर सुनता है. डिफ़ॉल्ट संख्या 50016 है.
• क्लाइंट के डिसकनेक्ट होने पर, --single सर्वर प्रोसेस को बंद कर देगा. डिफ़ॉल्ट रूप से, प्रोसेस को आगे की जांच करने के अनुरोध भेजे जा सकेंगे.

टेस्ट करना

इस पेज में, Linux और Windows में deqp टेस्ट चलाने के बारे में निर्देश दिए गए हैं ऐसे कई तरीके हैं जिनकी मदद से, कमांड लाइन आर्ग्युमेंट का इस्तेमाल किया जा सकता है. साथ ही, Android वाला है.

Linux और Windows एनवायरमेंट

टारगेट पर इन फ़ाइलों और डायरेक्ट्री को कॉपी करके शुरू करें.

मॉड्यूल	डायरेक्ट्री	Target
एक्ज़ीक्यूशन सर्वर	build/execserver/execserver	<dst>/execserver
EGL मॉड्यूल	build/modules/egl/deqp-egl	<dst>/deqp-egl
GLES2 मॉड्यूल	build/modules/gles2/deqp-gles2	<dst>/deqp-gles2
	data/gles2	<dst>/gles2
GLES3 मॉड्यूल	build/modules/gles3/deqp-gles3	<dst>/deqp-gles3
	data/gles3	<dst>/gles3
GLES3.1 मॉड्यूल	build/modules/gles31/deqp-gles31	<dst>/deqp-gles31
	data/gles31	<dst>/gles31
GLES3.2 मॉड्यूल	build/modules/gles32/deqp-gles32	<dst>/deqp-gles32
	data/gles32	<dst>/gles32

एक्ज़ीक्यूशन सेवा को डिप्लॉय किया जा सकता है और टारगेट में कहीं भी बाइनरी की जांच की जा सकती है फ़ाइल सिस्टम; हालांकि, टेस्ट बाइनरी की मौजूदा डायरेक्ट्री. तैयार होने पर, टारगेट डिवाइस. सेवा शुरू करने के बारे में जानकारी के लिए, देखें जांच करें एक्ज़ीक्यूशन सेवा.

कमांड लाइन आर्ग्युमेंट

नीचे दी गई टेबल में ऐसे कमांड लाइन आर्ग्युमेंट दिए गए हैं जो सभी क्वेरी को एक्ज़ीक्यूट करने पर असर डालते हैं टेस्ट प्रोग्राम.

आर्ग्यूमेंट	ब्यौरा
--deqp-case=<casename>	दिए गए पैटर्न से मेल खाने वाले केस चलाएं. वाइल्डकार्ड (*) का इस्तेमाल किया जा सकता है.
--deqp-log-filename=<filename>	आपने जिस फ़ाइल का नाम दिया है उस पर जांच के नतीजे लिखें. जांच की प्रक्रिया सेवा, टेस्ट शुरू करते समय फ़ाइल नाम सेट करेगी.
--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>	Stin या दिए गए तर्क से केस सूची पढ़ें. जांच की प्रक्रिया सेवा, किए गए एक्ज़ीक्यूशन के अनुरोध के मुताबिक आर्ग्युमेंट सेट करेगी. यहां जाएं: अगले सेक्शन में केस सूची के फ़ॉर्मैट की जानकारी पाएं.
--deqp-test-iteration-count=<count>	उन परीक्षणों के लिए इटरेशन की संख्या ओवरराइड करें जो एक वैरिएबल संख्या बार-बार किया जा सकता है.
--deqp-base-seed=<seed>	उन टेस्ट केस के लिए बेस सीड जो रैंडमाइज़ेशन का इस्तेमाल करते हैं.

GLES2 और GLES3 के खास तर्क

नीचे दी गई टेबल में, GLES2- और GLES3 के खास आर्ग्युमेंट दिए गए हैं.

आर्ग्यूमेंट	ब्यौरा
--deqp-gl-context-type=<type>	OpenGL कॉन्टेक्स्ट टाइप. कॉन्टेक्स्ट के लिए उपलब्ध विकल्प, प्लैटफ़ॉर्म के हिसाब से तय होते हैं. चालू है EGL के साथ काम करने वाले प्लैटफ़ॉर्म, egl मान का इस्तेमाल चुनने के लिए किया जा सकता है और ईजीएल संदर्भ को समझ लिया.
--deqp-gl-config-id=<id>	दिए गए जीएल कॉन्फ़िगरेशन आईडी के लिए जांच करें. इसका मतलब यह है प्लैटफ़ॉर्म पर निर्भर. ईजीएल प्लैटफ़ॉर्म पर, यह ईजीएल कॉन्फ़िगरेशन आईडी होता है.
--deqp-gl-config-name=<name>	नाम वाले जीएल कॉन्फ़िगरेशन के लिए टेस्ट करें. इसका मतलब यह है प्लैटफ़ॉर्म पर निर्भर. EGL के लिए प्रारूप rgb(a)<bits>d<bits>s<bits>. उदाहरण के लिए, rgb888s8 की वैल्यू से पहले कॉन्फ़िगरेशन को चुना जाएगा, जहां कलर बफ़र RGB888 है और स्टेंसिल बफ़र में 8 बिट हैं.
--deqp-gl-context-flags=<flags>	कॉन्टेक्स्ट बनाता है. robust या debug तय करें.
--deqp-surface-width=<width> --deqp-surface-height=<height>	किसी दिए गए साइज़ में सरफ़ेस बनाने की कोशिश करें. इसके लिए सहायता देना ज़रूरी नहीं है.
--deqp-surface-type=<type>	किसी दिए गए सरफ़ेस टाइप का इस्तेमाल, टेस्ट रेंडरिंग के मुख्य टारगेट के तौर पर करें. संभव है टाइप window, pixmap, pbuffer, और fbo.
--deqp-screen-rotation=<rotation>	उन प्लेटफ़ॉर्म के लिए 90 डिग्री के बढ़ने पर स्क्रीन ओरिएंटेशन इसका समर्थन करता है.

टेस्ट केस की सूची का फ़ॉर्मैट

टेस्ट केस की सूची दो फ़ॉर्मैट में दी जा सकती है. पहला विकल्प यह है कि स्टैंडर्ड 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 ऐप्लिकेशन पैकेज में सभी आवश्यक घटक शाम��ल होते हैं, जिनमें ये शामिल हैं टेस्ट करने की सेवा, टेस्ट बाइनरी, और डेटा फ़ाइलें. जांच के लिए की गई गतिविधि EGL का इस्तेमाल करने वाला 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 इंटेंट बनाएं जो android.app.NativeActivity को टारगेट करती है. ये गतिविधियां हो सकती हैं: com.drawelements.deqp पैकेज में मिला. कमांड लाइन को को इंटेंट में "cmdLine" कुंजी के साथ अतिरिक्त स्ट्रिंग के तौर पर दिया जाना चाहिए.

/sdcard/dEQP-log.qpa पर जांच लॉग लिखा जाता है. अगर परीक्षण किया जाता है, तो सामान्य रूप से शुरू नहीं होता, इसलिए डिवाइस में अतिरिक्त डीबग जानकारी उपलब्ध है लॉग इन करें.

am का इस्तेमाल करके, कमांड लाइन से कोई गतिविधि लॉन्च की जा सकती है उपयोगिता. उदाहरण के लिए, किसी प्लैटफ़ॉर्म पर dEQP-GLES2.info टेस्ट करने के लिए NativeActivity, का इस्तेमाल करने के लिए, इन निर्देशों का इस्तेमाल करें.

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 कमांड लाइन, एक्ज़ीक्यूट किए जाने वाले टेस्ट केस और दूसरे ज़रूरी पैरामीटर. स्क्रिप्ट शुरुआत में एक डिफ़ॉल्ट ब्रेकपॉइंट जोड़ देती है डेक्यूपी एक्ज़ीक्यूशन (tcu::App::App).

debug.py स्क्रिप्ट डीबग करने के लिए ब्रेकपॉइंट सेट करने जैसी कार्रवाइयां, gdbserver कनेक्शन पैरामीटर और डीबग करने के लिए अतिरिक्त बाइनरी के पाथ (सभी आर्ग्युमेंट और एक्सप्लेनेशंस के लिए debug.py --help इस्तेमाल करें). स्क्रिप्ट कुछ सिंबल लिस्टिंग पाने के लिए, टारगेट डिवाइस की डिफ़ॉल्ट लाइब्रेरी.

ड्राइवर कोड की जानकारी पाने के लिए (जैसे, जब GDB को जगहों की जानकारी की ज़रूरत हो) पूरी डीबग जानकारी वाली बाइनरी), तो इसके माध्यम से और लाइब्रेरी जोड़ें debug.py कमांड लाइन पैरामीटर. यह स्क्रिप्ट GDB के लिए कॉन्फ़िगरेशन फ़ाइल, स्क्रिप्ट फ़ाइल की लाइन 132 से शुरू होती है. आपने लोगों तक पहुंचाया मुफ़्त में बाइनरी वगैरह के लिए अतिरिक्त पाथ दे सकता है, लेकिन सही निर्देश दे रहा है पंक्ति पैरामीटर काफ़ी होने चाहिए.

ध्यान दें: Windows पर, GDB बाइनरी के लिए ज़रूरी है libpython2.7.dll. debug.py लॉन्च करने से पहले, यह जोड़ें PATH वैरिएबल के लिए <path-to-ndk>/prebuilt/windows/bin.

ध्यान दें: नेटिव कोड को डीबग करने की सुविधा इन पर काम नहीं करती स्टॉक Android 4.3; अगर आपको सहायता चाहिए, तो इस सार्वजनिक गड़बड़ी को ठीक करने में मदद मिलती है. Android 4.4 और उसके बाद वाले वर्शन में यह बग नहीं है.

जांच को ऑटोमेट करना

Deqp टेस्ट ��ॉड्यूल को, ऑटोमेटेड टेस्ट सिस्टम के साथ कई तरीकों से इंटिग्रेट किया जा सकता है. सबसे अच्छा तरीका मौजूदा टेस्ट इन्फ़्रास्ट्रक्चर और टारगेट पर निर्भर करता है पर्यावरण को ध्यान में रखते हुए काम करना.

टेस्ट रन से मिलने वाला मुख्य आउटपुट हमेशा टेस्ट लॉग फ़ाइल होता है, यानी फ़ाइल .qpa पोस्टफ़िक्स के साथ. जांच के पूरे नतीजों को, जांच लॉग से पार्स किया जा सकता है. कंसोल का आउटपुट यह है सिर्फ़ डीबग करने की जानकारी दी जाती है. ऐसा हो सकता है कि यह सभी प्लैटफ़ॉर्म पर उपलब्ध न हो.

किसी टेस्ट ऑटोमेशन सिस्टम से, टेस्ट बाइनरी को सीधे शुरू किया जा सकता है. जांच बाइनरी को किसी खास मामले, टेस्ट सेट या सभी के लिए लॉन्च किया जा सकता है उपलब्ध टेस्ट. अगर कोड चलाने के दौरान कोई गंभीर गड़बड़ी होती है (जैसे कि कुछ एपीआई कोई गड़बड़ी या क्रैश हो जाता है), तो टेस्ट बंद हो जाएगा. रिग्रेशन टेस्टिंग के लिए, सबसे सही तरीका यह है कि अलग-अलग मामलों या छोटे टेस्ट के लिए टेस्ट बाइनरी का इस्तेमाल किया जाए अलग से सेट करता है, ताकि इवेंट में भी आंशिक नतीजे उपलब्ध रहें गड़बड़ी हुई है.

deqp में, कमांड लाइन की जांच करने वाले टूल मिलते हैं. इनका इस्तेमाल इन कामों के लिए किया जा सकता है और एक और बेहतर इंटिग्रेशन पाने के लिए, एक्ज़ीक्यूशन सेवा के साथ अलग-अलग तरह के कॉम्बिनेशन बनाए जा सकते हैं. निष्पादनकर्ता को परीक्षण प्रक्रिया बंद किए जाने का पता चलेगा और वह इस तारीख को परीक्षण निष्पादन फिर से शुरू करेगा अगला उपलब्ध मामला. पूरे टेस्ट से एक लॉग फ़ाइल बनाई जाती है सत्र. यह सेटअप ऐसे लाइटवेट टेस्ट सिस्टम के लिए बिलकुल सही है जो क्रैश रिकवरी सुविधाएं.

कमांड लाइन की जांच करने के टूल

मौजूदा कमांड-लाइन टूल सेट में, रिमोट की जांच करने वाला टूल, एक टेस्ट, रिग्रेशन विश्लेषण के लिए लॉग तुलना जनरेट करने वाला, टेस्ट-लॉग-टू-CSV कन्वर्टर, एक test-log-to-XML कन्वर्टर, और एक testlog-to-JUnit कन्वर्टर.

इन टूल का सोर्स कोड executor डायरेक्ट्री में है और बाइनरी <builddir>/executor डायरेक्ट्री में पहले से मौजूद है.

कमांड लाइन टेस्ट एक्ज़िक्यूटर

कमांड लाइन जांच करने वाला, जांच के लिए इस्तेमाल किया जाने वाला पोर्टेबल C++ टूल है डिवाइस पर इंस्टॉल कर सकते हैं और इससे टीसीपी/आईपी पर लॉग इकट्ठा कर सकते हैं. द एक्ज़िक्यूटर यह टारगेट किए गए डिवाइस पर, एक्ज़ीक्यूशन सेवा (एक्ज़िक सर्वर) से संपर्क करता है. ये एक साथ मिलकर, टेस्ट प्रोसेस क्रैश होने के बाद ऐप्लिकेशन को रिकवर करने जैसी सुविधाएं उपलब्ध कराते हैं. नीचे दिए गए उदाहरणों में, कमांड लाइन टेस्ट एक्ज़ेक्यूटर का इस्तेमाल करने का तरीका बताया गया है (ज़्यादा जानकारी के लिए, --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 आउटपुट में टेस्ट केस और उनके नतीजे. यह टूल दो या उससे ज़्यादा बैच नतीजों की तुलना कर सकता है और सिर्फ़ इनपुट बैच के नतीजों में अलग-अलग स्टेटस कोड वाले टेस्ट केस. कॉन्टेंट बनाने तुलना करने से मिलान करने वाले केस की संख्या भी प्रिंट हो जाएगी.

जो आउटपुट 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 का आउटपुट है नतीजे का कोड, जैसे कि "पास" या "फ़ेल". आर्ग्युमेंट --value=details अगले चरण को चुनता है परफ़ॉर्मेंस, क्षमता या सटीक होने की जांच से मिलने वाले नतीजे या न्यूमेरिक वैल्यू के बारे में जानकारी.

लॉग एक्सएमएल एक्सपोर्ट की जांच करें

testlog-to-xml का इस्तेमाल करके, जांच लॉग फ़ाइलों को सही एक्सएमएल दस्तावेज़ों में बदला जा सकता है उपयोगिता. इन दो आउटपुट मोड का इस्तेमाल किया जा सकता है:

• दस्तावेज़ मोड को अलग करें, जहां हर टेस्ट केस और caselist.xml की खास जानकारी दिखती है दस्तावेज़ों को डेस्टिनेशन डायरेक्ट्री में लिखा गया है
• सिंगल फ़ाइल मोड, जहां .qpa फ़ाइल के सभी नतीजे, एक ही एक्सएमएल दस्तावेज़ में लिखे जाते हैं.

एक्सपोर्ट की गई टेस्ट लॉग फ़ाइलों को एक्सएमएल स्टाइल शीट का इस्तेमाल करके, ब्राउज़र में देखा जा सकता है. स्टाइल शीट के दस्तावेज़ (testlog.xsl और testlog.css) के सैंपल दिए गए हैं doc/testlog-stylesheet डायरेक्ट्री में. लॉग फ़ाइलों को ब्राउज़र में रेंडर करने के लिए, दो स्टाइल शीट फ़ाइलों को उसी डायरेक्ट्री में ले जाते हैं जिसमें एक्सपोर्ट किए गए एक्सएमएल दस्तावेज़ मौजूद होते हैं.

अगर Google Chrome का इस्तेमाल किया जा रहा है, तो फ़ाइलों को एचटीटीपी से Chrome के तौर पर ऐक्सेस किया जाना चाहिए सुरक्षा कारणों से लोकल फ़ाइल ऐक्सेस को सीमित करती है. स्टैंडर्ड Python इंस्टॉलेशन में एक बेसिक एचटीटीपी सर्वर ��ामिल है, जिसे मौजूदा डायरेक्ट्री का इस्तेमाल करके, python –m SimpleHTTPServer 8000 कमांड का इस्तेमाल किया जा सकता है. सर्वर लॉन्च करने के बाद, परीक्षण लॉग देखने के लिए बस Chrome ब्राउज़र को http://localhost:8000 की ओर इशारा करें.

JUnit टेस्ट लॉग में कन्वर्ज़न

कई टेस्ट ऑटोमेशन सिस्टम, JUnit से टेस्ट रन के नतीजे की रिपोर्ट जनरेट कर सकते हैं आउटपुट. deqp टेस्ट लॉग फ़ाइलों को JUnit आउटपुट फ़ॉर्मैट में बदला जा सकता है इस्तेमाल करके भी बनाया जा सकता है.

फ़िलहाल, यह टूल सिर्फ़ जांच केस के नतीजे का अनुवाद करने की सुविधा देता है. जुनीट के तौर पर केवल "पास" का समर्थन करता है और "फ़ेल" नतीजे मिलते हैं, तो deqp के पास होने के नतीजे को मैप किया जाता है "JUnit Pass" के लिए और दूसरे नतीजों को फ़ेल माना जाता है. ओरिजनल डेस्क नतीजा का कोड, JUnit आउटपुट में उपलब्ध है. अन्य डेटा, जैसे कि लॉग मैसेज और नतीजे की इमेज, कन्वर्ज़न में सुरक्षित नहीं की जातीं.

खास टेस्ट ग्रुप इस्तेमाल करना

कुछ टेस्ट ग्रुप को खास कमांड लाइन विकल्पों की ज़रूरत पड़ सकती है या उन पर काम करना पड़ सकता है या खास देखभाल का ध्यान रखना चाहिए.

मेमोरी ऐलोकेशन स्ट्रेस टेस्ट

मेमोरी ऐलोकेशन स्ट्रेस टेस्ट, बार-बार याददाश्त से बाहर होने वाली समस्याओं को हल करता है कुछ रिसॉर्स को तब तक अलग रखना, जब तक ड्राइवर की ओर से मेमोरी के बाहर होने की गड़बड़ी की शिकायत नहीं कर दी जाती.

Android और ज़्यादातर Linux वर्शन जैसे कुछ प्लैटफ़ॉर्म पर, हो सकता है: ऑपरेटिंग सिस्टम किसी ड्राइवर का इस्तेमाल करके, मेमोरी में जगह खाली होने की गड़बड़ी को हैंडल किया जा सकता है या दिया जा सकता है. इस तरह इस प्लैटफ़ॉर्म का इस्तेमाल करते समय, मेमोरी से जुड़ी गड़बड़ियां पैदा करने के लिए डिज़ाइन किए गए टेस्ट बंद कर दिए जाते हैं. यह सुविधा डिफ़ॉल्ट रूप से चालू होती है. इसे --deqp-test-oom=enable कमांड लाइन आर्ग्युमेंट का इस्तेमाल करके चालू किया जाना चाहिए. हमारा सुझाव है कि आप ऐसे टेस्ट मैन्युअल तौर पर करें, यह जांचें कि सिस्टम, रिसॉर्स के दबाव में सही तरीके से काम करता है या नहीं. हालांकि, ऐसे मामले में स्थिति में, टेस्ट प्रोसेस क्रैश को पास माना जाना चाहिए.

टेस्ट ग्रुप

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

लंबे समय तक चलने वाले रेंडरिंग स्ट्रेस टेस्ट

स्ट्रेस टेस्ट को रेंडर करने से, लंबे समय से चल रही ताकत में होने वाली समस्याओं का पता चलता है रेंडरिंग लोड. डिफ़ॉल्ट रूप से, जांच में सिर्फ़ कुछ बार दोहराया जाएगा, लेकिन --deqp-test-iteration-count=-1 की वैल्यू देकर, उन्हें अनिश्चित समय तक चलाने के लिए कॉन्फ़िगर किया जा सकता है कमांड लाइन आर्ग्युमेंट. टेस्ट वॉचडॉग बंद होना चाहिए (--deqp-watchdog=disable) लंबे समय तक इन परीक्षणों को चलाने पर ध्यान दें.

टेस्ट ग्रुप

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