हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

drawElements Quality Program की टेस्टिंग

AOSP में, drawElements Quality Program (deqp) GPU टेस्टिंग सुइट शामिल है. इसे 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`	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`	डिवाइस-साइड ExecServer सोर्स
`executor`	होस्ट-साइड टेस्ट एक्ज़ीक्यूटर शेल टूल और यूटिलिटी
`external`	libpng और zlib जैसी बाहरी लाइब्रेरी के लिए स्टब डायरेक्ट्री बनाएं

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

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

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

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

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

deqp सोर्स में CMake के लिए बिल्ड स्क्रिप्ट होती हैं. CMake, टेस्ट प्रोग्राम को कंपाइल करने के लिए पसंदीदा टूल है.

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

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

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

कॉन्फ़िगरेशन का विकल्प ब्यौरा

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

DEQP_TARGET

टारगेट का नाम, उदाहरण के लिए: "android"

deqp की CMake स्क्रिप्ट में, targets/DEQP_TARGET/DEQP_TARGET.cmake फ़ाइल शामिल होगी. साथ ही, इसमें टारगेट के हिसाब से बिल्ड के विकल्प मौजूद होंगे.

CMAKE_TOOLCHAIN_FILE

CMake के लिए टूलचेन फ़ाइल का पाथ. इसका इस्तेमाल क्रॉस कंपाइलेशन के लिए किया जाता है.

CMAKE_BUILD_TYPE

मेकफ़ाइल टारगेट के लिए बिल्ड टाइप. मान्य वैल्यू ये हैं: "Debug" और "Release"

ध्यान दें कि इंटरप्रिटेशन और डिफ़ॉल्ट टाइप, टारगेट किए गए बिल्ड सिस्टम पर निर्भर करता है. ज़्यादा जानकारी के लिए, 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`	EGL लाइब्रेरी (अगर यह सुविधा काम नहीं करती है या डाइनैमिक लोडिंग का इस्तेमाल किया जाता है, तो इसे खाली छोड़ दें)
`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"

बिल्ड जनरेटर के तौर पर "Visual Studio VERSION Win64" को चुनकर, 64-बिट बिल्ड बनाया जा सकता है:

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

-G "NMake Makefiles" विकल्प के साथ-साथ, बिल्ड टाइप (-DCMAKE_BUILD_TYPE="Debug" या "Release") का इस्तेमाल करके भी NMake makefiles जनरेट किए जा सकते हैं.

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

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

WGL के साथ काम करने की सुविधा

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

EGL के साथ काम करने की सुविधा

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

Android बिल्ड

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

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

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

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

एनडीके डायरेक्ट्री, ~/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 का इस्तेमाल करके मेकफ़ाइलें जनरेट करके, Linux के लिए टेस्ट बाइनरी और कमांड लाइन यूटिलिटी बनाई जा सकती हैं. Linux के लिए ऐप्लिकेशन बनाते समय, पहले से तय किए गए कई बिल्ड टारगेट का इस्तेमाल किया जा सकता है.

टारगेट बनाना	ब्यौरा
`default`	डिफ़ॉल्ट टारगेट, जो अलग-अलग एपीआई के साथ काम करने की सुविधा के बारे में पता लगाने के लिए, CMake प्लैटफ़ॉर्म इंट्रॉस्पेक्शन का इस्तेमाल करता है.
`x11_glx`	यह GLX का इस्तेमाल करके, OpenGL (ES) कॉन्टेक्स्ट बनाता है.
`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 को लाइब्रेरी या शामिल किए जाने वाले खोज पाथ के बारे में अतिरिक्त जानकारी दी जा सके.

कस्टम लोकेशन में मौजूद ड्राइवर हेडर और लाइब्रेरी के ख़िलाफ़ 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 को टूलचेन फ़ाइल से सेट किया जाना चाहिए.

वैरिएबल	ब्यौरा
`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`	प्लैटफ़ॉर्म पर sizeof(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

GLES और EGL लाइब्रेरी को रनटाइम में लिंक करना

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

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

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

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

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

जगह की जानकारी	ब्यौरा
`framework/delibs/debase framework/delibs/dethread framework/delibs/deutil`	ओएस के हिसाब से कोड लागू करने की कोई भी ज़रूरी सुविधा.
`framework/qphelper/qpCrashHandler.c`	ज़रूरी नहीं: अपने ओएस के लिए लागू करें.
`framework/qphelper/qpWatchDog.c`	आपके ओएस के लिए लागू करने का तरीका. मौजूदा वर्शन, `dethread` और स्टैंडर्ड सी लाइब्रेरी पर आधारित है.
`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) टेस्ट मॉड्यूल	GL प्लैटफ़ॉर्म इंटरफ़ेस
EGL टेस्ट मॉड्यूल	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`
GLES2 मॉड्यूल	`data/gles2`	`<dst>/gles2`
GLES3 मॉड्यूल	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
GLES3 मॉड्यूल	`data/gles3`	`<dst>/gles3`
GLES3.1 मॉड्यूल	`build/modules/gles31/deqp-gles31`	`<dst>/deqp-gles31`
GLES3.1 मॉड्यूल	`data/gles31`	`<dst>/gles31`
GLES3.2 मॉड्यूल	`build/modules/gles32/deqp-gles32`	`<dst>/deqp-gles32`
GLES3.2 मॉड्यूल	`data/gles32`	`<dst>/gles32`

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

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

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

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

GLES2 और GLES3 के लिए खास आर्ग्युमेंट

यहां दी गई टेबल में, GLES2 और GLES3 के लिए खास तौर पर इस्तेमाल किए जाने वाले आर्ग्युमेंट दिए गए हैं.

आर्ग्युमेंट	ब्यौरा
`--deqp-gl-context-type=<type>`	OpenGL कॉन्टेक्स्ट टाइप. उपलब्ध कॉन्टेक्स्ट टाइप, प्लैटफ़ॉर्म पर निर्भर करते हैं. EGL की सुविधा देने वाले प्लैटफ़ॉर्म पर, EGL कॉन्टेक्स्ट चुनने के लिए `egl` वैल्यू का इस्तेमाल किया जा सकता है.
`--deqp-gl-config-id=<id>`	दिए गए GL कॉन्फ़िगरेशन आईडी के लिए टेस्ट चलाएं. इंटरप्रिटेशन, प्लैटफ़ॉर्म पर निर्भर करता है. EGL प्लैटफ़ॉर्म पर, यह EGL कॉन्फ़िगरेशन आईडी होता है.
`--deqp-gl-config-name=<name>`	नाम वाले GL कॉन्फ़िगरेशन के लिए जांच चलाएं. इंटरप्रिटेशन, प्लैटफ़ॉर्म पर निर्भर करता है. 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 फ़ाइल में अलग-अलग लाइन पर लिखा जाए. टेस्ट सेट बढ़ने पर, बार-बार इस्तेमाल होने वाले प्रीफ़िक्स को मैनेज करना मुश्किल हो सकता है. प्रीफ़िक्स को दोहराने से बचने के लिए, नीचे दिए गए ट्राइ (इसे प्रीफ़िक्स ट्री भी कहा जाता है) सिंटैक्स का इस्तेमाल करें.

{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 सीटीएस के बिना 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 वैरिएबल में <path-to-ndk>/prebuilt/windows/bin जोड़ें.

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

टेस्ट को अपने-आप चलने की सुविधा के साथ सेट अप करना

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

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

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

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

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

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

इन टूल का सोर्स कोड, executor डायरेक्ट्री में है. साथ ही, बाइनरी को <builddir>/executor डायरेक्ट्री में बनाया गया है.

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

कमांड लाइन टेस्ट एक्ज़ीक्यूटर, C++ का पोर्टेबल टूल है. इसका इस्तेमाल, डिवाइस पर टेस्ट रन लॉन्च करने के लिए किया जाता है. साथ ही, टीसीपी/आईपी पर डिवाइस से लॉग इकट्ठा करने के लिए भी इसका इस्तेमाल किया जाता है. एक्ज़ीक्यूटर, टारगेट डिवाइस पर मौजूद एक्ज़ीक्यूशन सेवा (execserver) से कम्यूनिकेट करता है. ये दोनों मिलकर, टेस्ट प्रोसेस क्रैश होने पर रिकवर करने जैसी सुविधाएं देते हैं. यहां दिए गए उदाहरणों में, कमांड लाइन टेस्ट एक्ज़ीक्यूटर का इस्तेमाल करने का तरीका बताया गया है. ज़्यादा जानकारी के लिए, --help का इस्तेमाल करें:

पहला उदाहरण: 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"

दूसरा उदाहरण: 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

पहला उदाहरण: CSV फ़ॉर्मैट में टेस्ट लॉग एक्सपोर्ट करना

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

दूसरा उदाहरण: दो टेस्ट लॉग के बीच, टेस्ट के नतीजों में अंतर की सूची

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

ध्यान दें: --value=code आर्ग्युमेंट, टेस्ट के नतीजे का कोड दिखाता है. जैसे, "पास" या "फ़ेल". --value=details आर्ग्युमेंट, परफ़ॉर्मेंस, क्षमता या सटीक जवाब देने से जुड़े टेस्ट के नतीजे या संख्यात्मक वैल्यू के बारे में ज़्यादा जानकारी देता है.

लॉग को एक्सएमएल फ़ॉर्मैट में एक्सपोर्ट करने की सुविधा की जांच करना

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

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

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

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

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

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

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

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

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

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

मेमोरी के बंटवारे की स्ट्रेस टेस्ट में, मेमोरी खत्म होने की स्थितियों को बार-बार दोहराया जाता है. ऐसा तब तक किया जाता है, जब तक ड्राइवर मेमोरी खत्म होने की गड़बड़ी की सूचना नहीं देता.

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.*