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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

تنسيق المصدر

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

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

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

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

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

نظام إنشاء CMake

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

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

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

يمكنك أيضًا إنشاء ملفات make الخاصة بـ NMake باستخدام الخيار -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 مفعّلاً. وهذا هو الإعداد التلقائي في معظم الاستهدافات. بعد ذلك، إذا كان المضيف يتضمّن مكتبات EGL متاحة، من الممكن إجراء الاختبارات باستخدامها مع مَعلمة سطر الأوامر: --deqp-gl-context-type=egl

إصدار Android

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

لتجميع برامج اختبار deqp لنظام التشغيل Android باستخدام النصوص البرمجية لإنشاء الإصدارات المقدَّمة، ستحتاج إلى ما يلي:

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

إصدار Linux

يمكن إنشاء الثنائيات الاختبارية وأدوات سطر الأوامر لنظام التشغيل Linux من خلال إنشاء ملفات make باستخدام 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 مكتبة إضافية أو تضمين مسارات البحث.

في ما يلي مثال على سطر أوامر كامل يُستخدَم لإجراء عملية تصحيح أخطاء لإصدار 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. يحدد ملف Toolchain المحول البرمجي المراد استخدامه، إلى جانب مسارات البحث المخصصة للمكتبات والعناوين. يتم تضمين العديد من ملفات سلسلة الأدوات للسيناريوهات الشائعة في حزمة الإصدار في الدليل 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. اطّلِع على الجدول التالي للحصول على نظرة عامة على الإجراءات التي يجب تنفيذها لبدء الاختبارات.

تتوفّر تعليمات مفصّلة لتنفيذ منافذ المنصة في عناوين ملف ‎.java لطبقة النقل.

خدمة تنفيذ الاختبار

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

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

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

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

تقدّم هذه الصفحة تعليمات لتشغيل اختبارات deqp في بيئةَي Linux وWindows ، باستخدام مَعلمات سطر الأوامر والعمل مع حزمة تطبيق 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 أو إصدارًا أحدث).

يمكن تثبيت حزمة التطبيق باستخدام الأمر التالي (اسم المعروض هو اسم حزمة 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. إذا لم يبدأ تنفيذ الاختبار بشكلٍ طبيعي، تتوفّر معلومات إضافية لتصحيح الأخطاء في log الجهاز.

يمكنك بدء نشاط من سطر الأوامر باستخدام أداة 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

لتنفيذ الاختبارات ضمن مصحِّح أخطاء 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.

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

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

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

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

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

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

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

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

يمكن العثور على الرمز المصدر لهذه الأدوات في الدليل executor، ويتم دمج الملفات الثنائية في الدليل <builddir>/executor.

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

أداة تنفيذ اختبارات سطر الأوامر هي أداة محمولة لبرنامج C++ لبدء عملية تنفيذ اختبار على جهاز وجمع السجلات الناتجة منه عبر بروتوكول TCP/IP. يتصل "المنفِّذ" بخدمة التنفيذ (execserver) على الجهاز المستهدَف. وتوفر هذه الأدوات معًا وظائف مثل الاسترداد من الأعطال في عملية الاختبار. توضِّح الأمثلة التالية كيفية استخدام أداة تنفيذ الاختبارات من سطر الأوامر (استخدِم --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 summary في دليل وجهة
• وضع الملف الفردي، حيث يتمّ كتابة جميع النتائج في ملف .qpa إلى مستند XML واحد.

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

إذا كنت تستخدم Google Chrome، يجب الوصول إلى الملفات عبر بروتوكول HTTP لأنّ Chrome يقلل من إمكانية الوصول إلى الملفات المحلية لأسباب تتعلق بالأمان. يتضمّن تثبيت Python العادي خادم HTTP أساسيًا يمكن تشغيله لعرض الdirectory الحالي باستخدام الأمر 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.*