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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

सोर्स लेआउट

deqp टेस्ट मॉड्यूल और सहायक लाइब्रेरी के सोर्स कोड का लेआउट, यहां दी गई टेबल में दिखाया गया है. इस सूची में सभी जानकारी नहीं है, लेकिन इसमें सबसे ज़रूरी डायरेक्ट्री हाइलाइट की गई हैं.

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

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

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

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

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

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

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

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

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

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

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

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

टारगेट बिल्ड फ़ाइल, include_directories() और link_directories() CMake फ़ंक्शन का इस्तेमाल करके, शामिल किए जाने वाले या लिंक किए जाने वाले अन्य पाथ जोड़ सकती है.

Win32 बिल्ड

Windows के लिए deqp मॉड्यूल बनाने का सबसे आसान तरीका, CMake बिल्ड सिस्टम का इस्तेमाल करना है. इसके लिए, आपके पास CMake 2.6.12 या उसके बाद का वर्शन और Microsoft Visual C/C++ compiler होना चाहिए. 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 मेकफ़ाइलें जनरेट की जा सकती हैं.

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

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

Android बिल्ड

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

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

• Android NDK का नया वर्शन; android/scripts/common.py फ़ाइल में ज़रूरी वर्शन की सूची दी गई है
• Android स्टैंडअलोन SDK, जिसमें एपीआई 13, SDK टूल, SDK Platform-tools, और SDK Build-tools पैकेज इंस्टॉल किए गए हों
• Apache Ant 1.9.4 (Java कोड बिल्ड करने के लिए ज़रूरी है)
• CMake 2.8.12 या इसके बाद का वर्शन
• 2.x सीरीज़ में Python 2.6 या इसके बाद का वर्शन; 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 स्क्रिप्ट से इंस्टॉल किया जा सकता है. अगर कमांड-लाइन एक्सीक्यूटर का इस्तेमाल किया जाता है, तो ExecService को डिवाइस पर launch.py स्क्रिप्ट के साथ, adb की मदद से लॉन्च किया जाता है. स्क्रिप्ट को किसी भी डायरेक्ट्री से चलाया जा सकता है.

Linux बिल्ड

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

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

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

-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 वैरिएबल के अलावा, toolchain फ़ाइल से deqp के लिए ये वैरिएबल सेट किए जा सकते हैं. आम तौर पर, CMake DE_OS, DE_COMPILER और DE_PTR_SIZE का पता सही तरीके से लगा सकता है. हालांकि, DE_CPU को टूलचेन फ़ाइल से सेट करना ज़रूरी है.

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 को पोर्ट करने के लिए, ये तीन चरण पूरे करने होंगे: बेस पोर्टेबिलिटी लाइब्रेरी को अडैप्ट करना, टेस्ट-फ़्रेमवर्क प्लैटफ़ॉर्म-इंटिग्रेशन इंटरफ़ेस लागू करना, और एक्सीक्यूशन सेवा को पोर्ट करना.

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

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

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

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

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

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

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

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

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

टेस्ट को लागू करने की सेवा

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

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

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

टेस्ट चलाना

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

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

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

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

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

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

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

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

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

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

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

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

टेस्ट को ऑटोमेट करना

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

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

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

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

कमांड-लाइन टेस्ट को लागू करने वाले टूल

मौजूदा कमांड-लाइन टूल सेट में, रिमोट टेस्ट को चलाने वाला टूल, रिग्रेशन विश्लेषण के लिए टेस्ट लॉग की तुलना करने वाला जनरेटर, टेस्ट लॉग को CSV में बदलने वाला कन्वर्टर, टेस्ट लॉग को एक्सएमएल में बदलने वाला कन्वर्टर, और टेस्ट लॉग को 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 फ़ाइल के सभी नतीजे, एक एक्सएमएल दस्तावेज़ में लिखे जाते हैं.

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

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

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

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

फ़िलहाल, यह टूल सिर्फ़ टेस्ट केस के नतीजे का अनुवाद करता है. JUnit सिर्फ़ "पास" और "फ़ेल" नतीजों के साथ काम करता है. इसलिए, deqp के पास होने वाले नतीजे को "JUnit पास" के साथ मैप किया जाता है और अन्य नतीजों को फ़ेल माना जाता है. deqp का मूल नतीजा, 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.*