اختبار برنامج جودة drawElements

يتضمّن مشروع AOSP مجموعة اختبارات وحدة معالجة الرسومات (GPU) الخاصة ببرنامج drawElements Quality Program (deqp) على الرابط https://android.googlesource.com/platform/external/deqp. توضّح هذه الصفحة كيفية نشر مجموعة اختبارات deqp في بيئة جديدة.

للعمل باستخدام أحدث رمز تم إرساله، استخدِم الفرع deqp-dev. بالنسبة إلى الرمز الذي يتطابق مع إصدار معيّن من مجموعة اختبارات التوافق (CTS) لنظام التشغيل Android، استخدِم فرع release-code-name-release (على سبيل المثال، بالنسبة إلى الإصدار 6.0 من نظام التشغيل Android، استخدِم فرع marshmallow-release).

تخطيط المستند المصدر

يظهر في الجدول أدناه تخطيط الرمز المصدري لوحدات اختبار deqp والمكتبات المتوافقة (القائمة ليست شاملة ولكنها تسلّط الضوء على أهم الدلائل).

المكوّنات المفتوحة المصدر

تستخدم حزمة deqp libpng وzlib، ويمكن استرجاعهما باستخدام النص البرمجي platform/external/deqp/external/fetch_sources.py أو عبر git من platform/external/[libpng,zlib].

إنشاء برامج اختبار

تم تصميم إطار الاختبار مع مراعاة إمكانية النقل. المتطلبات الإلزامية الوحيدة هي توفُّر دعم كامل للغة C++ ومكتبات النظام العادية للإدخال/الإخراج والخيوط والمقابس.

نظام التصميم CMake

تحتوي مصادر deqp على نصوص برمجية للإنشاء خاصة بـ CMake، وهي الأداة المفضّلة لتجميع برامج الاختبار.

‫CMake هو نظام تصميم مفتوح المصدر يتوافق مع العديد من الأنظمة الأساسية وسلاسل الأدوات. تنشئ CMake ملفات makefiles أصلية أو ملفات مشاريع IDE من ملفات إعدادات مستقلة عن الهدف. لمزيد من المعلومات عن CMake، يُرجى الاطّلاع على مستندات CMake.

تتيح CMake وتوصي بعمليات الإنشاء خارج شجرة المصدر، أي أنّه عليك دائمًا إنشاء ملفات makefile أو ملفات المشروع في دليل إنشاء منفصل خارج شجرة المصدر. لا يتضمّن CMake أي نوع من أهداف "distclean"، لذا يجب إزالة أي ملفات تم إنشاؤها بواسطة CMake يدويًا.

يتم توفير خيارات الإعداد لـ CMake باستخدام بنية -DOPTION_NAME=VALUE. في ما يلي بعض الخيارات الشائعة الاستخدام في deqp.

إنشاء ملف إصدار مستهدف

تم ضبط نظام تصميم deqp للأهداف الجديدة باستخدام ملفات إصدار الأهداف. يحدّد ملف الإصدار المستهدف الميزات التي تتوافق مع النظام الأساسي والمكتبات أو مسارات التضمين الإضافية المطلوبة. تتّبع أسماء الملفات المستهدَفة التنسيق targets/NAME/NAME.cmake ويتم اختيار الهدف باستخدام مَعلمة الإنشاء DEQP_TARGET.

تكون مسارات الملفات في الملفات المستهدَفة مرتبطة بالدليل الأساسي deqp، وليس بالدليل targets/NAME. يمكن ضبط المتغيّرات العادية التالية من خلال ملف الإصدار المستهدف.

يمكن أن يضيف ملف الإنشاء المستهدف مسارات تضمين أو ربط إضافية باستخدام دالتَي CMake include_directories() وlink_directories().

إصدار Win32

أسهل طريقة لإنشاء وحدات deqp لنظام التشغيل Windows هي استخدام نظام إنشاء 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"

يمكنك أيضًا إنشاء ملفات NMake makefiles باستخدام الخيار -G "NMake Makefiles" بالإضافة إلى نوع التصميم (-DCMAKE_BUILD_TYPE="Debug" أو "Release").

إنشاء سياق العرض

يمكن إنشاء سياق العرض باستخدام WGL أو EGL على نظام التشغيل Windows.

التوافق مع WGL

تتيح جميع ملفات Win32 الثنائية إنشاء سياق GL باستخدام WGL لأنّها لا تتطلّب سوى المكتبات العادية. يمكن اختيار سياق WGL باستخدام وسيطة سطر الأوامر --deqp-gl-context-type=wgl. في وضع WGL، تستخدم حزمة deqp الإضافة WGL_EXT_create_context_es_profile لإنشاء سياقات OpenGL ES. تم اختبار هذه الميزة وتأكّدنا من توافقها مع أحدث برامج التشغيل من NVIDIA وIntel. لا تتوافق برامج تشغيل AMD مع الإضافة المطلوبة.

توافُق EGL

يتم إنشاء deqp باستخدام التحميل الديناميكي لـ EGL على Windows إذا كانت قيمة DEQP_SUPPORT_EGL هي ON. هذا هو الإعداد التلقائي في معظم الاستهدافات. بعد ذلك، إذا كان المضيف يتضمّن مكتبات EGL متاحة، يمكن إجراء الاختبارات باستخدامها من خلال مَعلمة سطر الأوامر: --deqp-gl-context-type=egl

إنشاء إصدار Android

يستخدم إصدار Android نصوص CMake البرمجية لإنشاء رمز الاختبار الأصلي. يتم تجميع أجزاء Java، أي خادم تنفيذ الاختبار ورمز تطبيق الاختبار، باستخدام أدوات إنشاء Android العادية.

لتجميع برامج اختبار deqp لنظام التشغيل Android باستخدام نصوص البرامج الإنشائية المتوفّرة، يجب توفُّر ما يلي:

• أحدث إصدار من Android NDK، ويحتوي الملف android/scripts/common.py على قائمة بالإصدار المطلوب
• تثبيت حِزم حزمة تطوير البرامج (SDK) المستقلة لنظام التشغيل Android مع واجهة برمجة التطبيقات 13 وأدوات حزمة تطوير البرامج (SDK) وأدوات النظام الأساسي لحزمة تطوير البرامج (SDK) وأدوات إنشاء حزمة تطوير البرامج (SDK)
• Apache Ant 1.9.4 (مطلوب لإنشاء رمز Java البرمجي)
• ‫CMake 2.8.12 أو إصدار أحدث
• الإصدار 2.6 أو الإصدارات الأحدث من Python في السلسلة 2.x، علمًا بأنّ الإصدار 3.x غير متوافق
• في نظام التشغيل Windows: NMake أو JOM في PATH
  • تتيح 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. يتم إنشاء حزمة Android Package Kit (APK)‎ النهائية في android/package/bin ويمكن تثبيتها باستخدام البرنامج النصي install.py. في حال استخدام منفِّذ سطر الأوامر، يتم تشغيل ExecService باستخدام نص launch.py البرمجي على الجهاز من خلال ADB. يمكن تنفيذ البرامج النصية من أي دليل.

إصدار Linux

يمكن إنشاء ملفات ثنائية قابلة للاختبار وأدوات سطر الأوامر لنظام التشغيل Linux من خلال إنشاء ملفات makefile باستخدام CMake. هناك العديد من أهداف الإنشاء المحدّدة مسبقًا والتي تكون مفيدة عند الإنشاء لنظام التشغيل Linux.

استخدِم دائمًا -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 من خلال ملف مجموعة الأدوات.

يمكن اختيار ملف سلسلة الأدوات باستخدام مَعلمة الإنشاء CMAKE_TOOLCHAIN_FILE. على سبيل المثال، سيؤدي ما يلي إلى إنشاء ملفات makefile لإنشاء إصدار باستخدام برنامج CodeSourcery المترجم المتقاطع لنظام التشغيل ARM/Linux:

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

الربط في وقت التشغيل لمكتبتَي 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 أو أداة التنفيذ من سطر الأوامر، يجب أن تكون خدمة تنفيذ الاختبار متاحة على الجهاز المستهدف. يتم توفير تطبيق محمول للخدمة بلغة C++‎ في الدليل execserver. يتم إنشاء البرنامج الثنائي المستقل كجزء من عملية إنشاء وحدة اختبار deqp لأجهزة الكمبيوتر الشخصية. يمكنك تعديل execserver/CMakeLists.txt لتفعيل إصدار على أجهزة أخرى.

يقبل إصدار C++ من خدمة تنفيذ الاختبار مَعلمتَين لسطر الأوامر:

• سيضبط --port=<port> منفذ TCP الذي يستمع إليه الخادم. القيمة التلقائية هي 50016.
• ستنهي --single عملية الخادم عند قطع اتصال العميل. بشكل تلقائي، ستبقى عملية الخادم نشطة لتلبية طلبات تنفيذ الاختبارات الإضافية.

إجراء الاختبارات

تقدّم هذه الصفحة تعليمات حول تشغيل اختبارات deqp في بيئات Linux وWindows، واستخدام وسيطات سطر الأوامر، والعمل مع حزمة تطبيق Android.

بيئتا Linux وWindows

ابدأ بنسخ الملفات والأدلة التالية إلى الهدف.

يمكنك نشر خدمة التنفيذ واختبار الثنائيات في أي مكان في نظام الملفات المستهدف، ولكن تتوقّع الثنائيات الاختبارية العثور على أدلة البيانات في دليل العمل الحالي. عندما تكون مستعدًا، ابدأ خدمة تنفيذ الاختبار على جهاز الاختبار. للحصول على تفاصيل حول بدء الخدمة، اطّلِع على خدمة تنفيذ الاختبار.

وسيطات سطر الأوامر

يسرد الجدول التالي وسيطات سطر الأوامر التي تؤثّر في تنفيذ جميع برامج الاختبار.

وسيطات خاصة بإصدارَي GLES2 وGLES3

يسرد الجدول التالي الوسيطات الخاصة بـ 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 (يتطلّب الإصدار 3.2 من نظام التشغيل Android أو إصدارًا أحدث).

يمكن تثبيت حزمة التطبيق باستخدام الأمر التالي (الاسم المعروض هو اسم حزمة APK في حزمة Android CTS، ويعتمد هذا الاسم على الإصدار):

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" في Intent.

يتم تسجيل سجلّ اختبار في /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

لتشغيل الاختبارات ضمن GNU Debugger (GDB) على Android، عليك أولاً تجميع إصدار مخصص لتصحيح الأخطاء وتثبيته من خلال تنفيذ النصَّين البرمجيَّين التاليَين:

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. يكتب هذا البرنامج النصي ملف إعداد لبرنامج GDB بدءًا من السطر 132 من ملف البرنامج النصي. يمكنك تقديم مسارات إضافية إلى الملفات الثنائية، ولكن يجب أن يكون توفير مَعلمات سطر الأوامر الصحيحة كافيًا.

ملاحظة: على أجهزة Windows، يتطلّب ملف GDB الثنائي libpython2.7.dll. قبل تشغيل debug.py، أضِف <path-to-ndk>/prebuilt/windows/bin إلى متغيّر PATH.

ملاحظة: لا يمكن تصحيح أخطاء الرمز البرمجي الأصلي على الإصدار 4.3 من Android. وللحصول على حلول بديلة، يُرجى الرجوع إلى هذا الخطأ العلني. لا يتضمّن الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث هذه الخطأ.

أتمِتة الاختبارات

يمكن دمج وحدات اختبار Deqp في أنظمة الاختبار المبرمَجة بعدة طرق. يعتمد النهج الأفضل على البنية الأساسية الحالية للاختبار والبيئة المستهدفة.

إنّ الناتج الأساسي من عملية الاختبار هو دائمًا ملف سجلّ الاختبار، أي الملف الذي يتضمّن اللاحقة .qpa. يمكن تحليل نتائج الاختبار الكاملة من سجلّ الاختبار. إنّ ناتج وحدة التحكّم هو معلومات تصحيح الأخطاء فقط، وقد لا يكون متاحًا على جميع المنصات.

يمكن استدعاء ملفات الاختبار الثنائية مباشرةً من نظام التشغيل التلقائي للاختبار. يمكن تشغيل رمز الاختبار الثنائي لحالة معيّنة أو لمجموعة اختبار أو لجميع الاختبارات المتاحة. في حال حدوث خطأ فادح أثناء التنفيذ (مثل بعض أخطاء واجهة برمجة التطبيقات أو حدوث عطل)، سيتم إيقاف تنفيذ الاختبار. بالنسبة إلى اختبارات الانحدار، أفضل طريقة هي استدعاء ملفات الاختبار الثنائية للحالات الفردية أو مجموعات الاختبار الصغيرة بشكل منفصل، وذلك لإتاحة النتائج الجزئية حتى في حال حدوث عطل كبير.

تتضمّن حزمة deqp أدوات لتنفيذ الاختبارات من سطر الأوامر يمكن استخدامها مع خدمة التنفيذ لتحقيق تكامل أكثر فعالية. يرصد المنفِّذ إنهاء عملية الاختبار وسيستأنف تنفيذ الاختبار في حالة الاختبار التالية المتاحة. يتم إنشاء ملف سجلّ واحد من جلسة الاختبار الكاملة. يُعدّ هذا الإعداد مثاليًا لأنظمة الاختبار الخفيفة التي لا توفّر إمكانات استرداد البيانات بعد حدوث أعطال.

أدوات تنفيذ الاختبارات من سطر الأوامر

تتضمّن مجموعة أدوات سطر الأوامر الحالية أداة لتنفيذ الاختبار عن بُعد، وأداة لإنشاء مقارنة بين سجلّات الاختبار بغرض تحليل الانحدار، وأداة لتحويل سجلّ الاختبار إلى ملف CSV، وأداة لتحويل سجلّ الاختبار إلى ملف XML، وأداة لتحويل سجلّ الاختبار إلى JUnit.

يتوفّر رمز المصدر الخاص بهذه الأدوات في الدليل executor، ويتم إنشاء الملفات الثنائية في الدليل <builddir>/executor.

أداة تنفيذ الاختبارات من سطر الأوامر

أداة تنفيذ الاختبار من سطر الأوامر هي أداة C++ محمولة لتشغيل اختبار على جهاز وجمع السجلات الناتجة منه عبر TCP/IP. يتواصل Executor مع خدمة التنفيذ (execserver) على جهاز الاختبار. وتوفّر هذه العمليات معًا وظائف مثل إمكانية الاسترداد من الأعطال التي تحدث أثناء عملية الاختبار. توضّح الأمثلة التالية كيفية استخدام أداة Test Executor من سطر الأوامر (استخدِم --help لمزيد من التفاصيل):

المثال 1: تشغيل اختبارات وظيفية لـ GLES2 على جهاز Android

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 التفسير الإضافي للنتيجة أو القيمة العددية التي تم الحصول عليها من خلال اختبار الأداء أو الإمكانات أو الدقة.

تصدير XML لسجلّ الاختبار

يمكن تحويل ملفات سجلّ الاختبار إلى مستندات XML صالحة باستخدام الأداة المساعدة testlog-to-xml. يتوفّر وضعان للإخراج:

• وضع المستندات المنفصلة، حيث تتم كتابة كل حالة اختبار ومستند الملخّص caselist.xml في دليل الوجهة
• وضع الملف الواحد، حيث تتم كتابة جميع النتائج في الملف .qpa إلى مستند XML واحد.

يمكن عرض ملفات سجلّ الاختبار التي تم تصديرها في متصفّح باستخدام ورقة أنماط XML. تتوفّر مستندات نموذجية لورقة الأنماط (testlog.xsl وtestlog.css) في الدليل doc/testlog-stylesheet. لعرض ملفات السجلّ في متصفّح، انسخ ملفَي أوراق الأنماط إلى الدليل نفسه الذي توجد فيه مستندات XML التي تم تصديرها.

إذا كنت تستخدم Google Chrome، يجب الوصول إلى الملفات عبر HTTP لأنّ Chrome يفرض قيودًا على الوصول إلى الملفات المحلية لأسباب أمنية. يتضمّن التثبيت العادي لـ Python خادم HTTP أساسيًا يمكن تشغيله لعرض الدليل الحالي باستخدام الأمر python –m SimpleHTTPServer 8000. بعد تشغيل الخادم، ما عليك سوى توجيه متصفّح Chrome إلى http://localhost:8000 لعرض سجلّ الاختبار.

التحويل إلى سجلّ اختبار JUnit

يمكن للعديد من أنظمة أتمتة الاختبار إنشاء تقارير بنتائج عمليات الاختبار من ناتج JUnit. يمكن تحويل ملفات سجل اختبار deqp إلى تنسيق إخراج JUnit باستخدام أداة testlog-to-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.*