اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

يتضمّن مشروع AOSP مجموعة اختبارات وحدة معالجة الرسومات (GPU) الخاصة ببرنامج 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 والمكتبات المتوافقة (القائمة ليست شاملة ولكنها تسلّط الضوء على أهم الدلائل).

الدليل	الوصف
`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`	أداة shell ومرافق لتنفيذ الاختبار من جهة المضيف
`external`	إنشاء دليل فارغ للمكتبتَين الخارجيتَين libpng وzlib

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

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

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

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

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

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

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

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

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

خيار الإعداد الوصف

خيار الإعداد	الوصف
`DEQP_TARGET`	اسم الهدف، على سبيل المثال: "android" ستتضمّن نصوص CMake البرمجية الخاصة بـ deqp الملف `targets/DEQP_TARGET/DEQP_TARGET.cmake`، وسيتم توقّع العثور على خيارات إنشاء خاصة بالهدف من هناك.
`CMAKE_TOOLCHAIN_FILE`	مسار ملف مجموعة الأدوات لـ CMake. تُستخدَم في الترجمة البرمجية المتعددة المنصات.
`CMAKE_BUILD_TYPE`	نوع الإصدار الخاص باستهدافات ملف makefile. القيم الصالحة هي: "Debug" و "Release" يُرجى العِلم أنّ التفسير والنوع التلقائي يعتمدان على نظام الإنشاء المستهدَف. لمزيد من التفاصيل، يُرجى الاطّلاع على مستندات CMake.

DEQP_TARGET

اسم الهدف، على سبيل المثال: "android"

ستتضمّن نصوص CMake البرمجية الخاصة بـ deqp الملف targets/DEQP_TARGET/DEQP_TARGET.cmake، وسيتم توقّع العثور على خيارات إنشاء خاصة بالهدف من هناك.

CMAKE_TOOLCHAIN_FILE

مسار ملف مجموعة الأدوات لـ CMake. تُستخدَم في الترجمة البرمجية المتعددة المنصات.

CMAKE_BUILD_TYPE

نوع الإصدار الخاص باستهدافات ملف makefile. القيم الصالحة هي: "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 متاحًا (القيمة التلقائية: OFF)
`DEQP_EGL_LIBRARIES`	مكتبات EGL (اترك الحقل فارغًا إذا لم يكن متاحًا أو إذا تم استخدام التحميل الديناميكي)
`DEQP_PLATFORM_LIBRARIES`	مكتبات إضافية خاصة بالمنصة مطلوبة للربط
`DEQP_PLATFORM_COPY_LIBRARIES`	قائمة بالمكتبات التي يتم نسخها إلى كل دليل إنشاء ثنائي للاختبار. يمكن استخدامها لنسخ المكتبات اللازمة لتشغيل الاختبارات ولكنها غير مضمّنة في مسار البحث التلقائي.
`TCUTIL_PLATFORM_SRCS`	قائمة مصادر منافذ المنصّة يتم تحديد المصادر التلقائية استنادًا إلى الإمكانات ونظام التشغيل. ملاحظة: تكون المسارات مرتبطة بما يلي: `framework/platform`

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

إصدار Win32

أسهل طريقة لإنشاء وحدات deqp لنظام التشغيل Windows هي استخدام نظام CMake. ستحتاج إلى الإصدار 2.6.12 من CMake أو إصدار أحدث وإلى برنامج 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. يتم إنشاء ملف APK النهائي في android/package/bin ويمكن تثبيته باستخدام النص البرمجي install.py. في حال استخدام منفِّذ سطر الأوامر، يتم تشغيل ExecService باستخدام النص البرمجي launch.py على الجهاز من خلال ADB. يمكن تنفيذ البرامج النصية من أي دليل.

إنشاء Linux

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

إنشاء هدف	الوصف
`default`	الهدف التلقائي الذي يستخدم فحص منصة CMake لتحديد إمكانية استخدام واجهات برمجة التطبيقات المختلفة
`x11_glx`	يستخدم GLX لإنشاء سياقات OpenGL (ES).
`x11_egl`	يستخدم EGL لإنشاء سياقات OpenGL (ES).
`x11_egl_glx`	يتوافق مع كلّ من GLX وEGL مع X11.

استخدِم -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. على سبيل المثال، سيؤدي ما يلي إلى إنشاء ملفات 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 ثلاث خطوات: تكييف مكتبات إمكانية النقل الأساسية، وتنفيذ واجهات دمج النظام الأساسي لإطار الاختبار، ونقل خدمة التنفيذ.

يسرد الجدول أدناه المواقع الجغرافية التي من المحتمل أن تحدث فيها تغييرات في نقل الأرقام. وأي شيء يتجاوز هذه الحدود من المرجّح أن يكون غريبًا.

الموقع الجغرافي	الوصف
`framework/delibs/debase framework/delibs/dethread framework/delibs/deutil`	أي عمليات تنفيذ ضرورية للرمز الخاص بنظام التشغيل
`framework/qphelper/qpCrashHandler.c`	اختياري: تنفيذ نظام التشغيل
`framework/qphelper/qpWatchDog.c`	خطوات التنفيذ لنظام التشغيل يستند الإصدار الحالي إلى `dethread` ومكتبة C العادية.
`framework/platform`	يمكن تنفيذ منفذ النظام الأساسي الجديد ورمز التطبيق كما هو موضّح في منفذ النظام الأساسي لإطار الاختبار.

مكتبات إمكانية النقل الأساسية

تتوافق مكتبات إمكانية النقل الأساسية حاليًا مع نظام التشغيل Windows ومعظم إصدارات Linux وMac OS وiOS وAndroid. إذا كان الهدف من الاختبار يعمل على أحد أنظمة التشغيل هذه، لن تحتاج على الأرجح إلى تعديل مكتبات إمكانية النقل الأساسية على الإطلاق.

Test framework platform port

يتطلّب نقل منصة إطار عمل اختبار 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> منفذ TCP الذي يستجيب له الخادم. القيمة التلقائية هي 50016.
ستنهي --single عملية الخادم عند انقطاع اتصال العميل. بشكل تلقائي، ستبقى عملية الخادم نشطة لتلبية طلبات تنفيذ الاختبارات الإضافية.

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

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

بيئتا Linux وWindows

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

الوحدة	الدليل	هدف
خادم التنفيذ	`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 Module	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
GLES3 Module	`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`

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

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

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

الوسيطة	الوصف
`--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 على جميع المكوّنات المطلوبة، بما في ذلك خدمة تنفيذ الاختبارات، وملفات الاختبار الثنائية، وملفات البيانات. نشاط الاختبار هو 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

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

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

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

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

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

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

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

إصدار Win32

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

التوافق مع WGL

توافُق EGL

إنشاء إصدار Android

إنشاء Linux

الترجمة البرمجية المتعددة المنصات

الربط في وقت التشغيل لمكتبتَي GLES وEGL

نقل إطار الاختبار

مكتبات إمكانية النقل الأساسية

Test framework platform port

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

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

بيئتا Linux وWindows

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

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

تنسيق قائمة حالات الاختبار

Android

تنفيذ الاختبارات على Android بدون مجموعة اختبار التوافق (CTS) لنظام التشغيل Android

تصحيح الأخطاء على Android

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

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

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

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

المثال 2: مواصلة تشغيل اختبار OpenGL ES 2 جزئيًا على الجهاز

تصدير سجلّ الاختبار بتنسيق CSV ومقارنته

المثال 1: تصدير سجلّ الاختبار بتنسيق CSV

المثال 2: إدراج الاختلافات في نتائج الاختبار بين سجلَّي اختبار

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

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

استخدام مجموعات اختبار خاصة

اختبارات الضغط لتخصيص الذاكرة

مجموعات الاختبار

اختبارات إجهاد العرض الطويلة

مجموعات الاختبار

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