اختبار برنامج drawElements Quality

يتضمن AOSP مجموعة اختبار وحدة معالجة الرسومات (deqp) الخاصة ببرنامج جودة العناصر الرسومية drawElements كما يلي: 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	أداة واجهة مستخدم الاختبار من جهة المضيف والأدوات المساعدة
external	إنشاء دليل stub لملف libpng وzlib خارجي

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

يستخدم 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 التركيبات التي تأتي خارج شجرة البيانات وتقترحها، أي ينبغي أن تنشئ دائمًا ملفات Makefiles أو ملفات مشروع في دليل إصدار منفصل خارج شجرة المصدر لا يحتوي CMake على أي نوع من "المنفصل" وبالتالي أن إزالة أي ملفات تم إنشاؤها بواسطة CMake يجب أن تتم يدويًا.

يتم منح خيارات الضبط لـ CMake باستخدام -DOPTION_NAME=VALUE. وبناء الجملة. في ما يلي بعض الخيارات الشائعة الاستخدام لـ Deqp.

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

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

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

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

متغير	الوصف
DEQP_TARGET_NAME	اسم الهدف (سيتم تضمينه في سجلات الاختبار)
DEQP_SUPPORT_GLES2	ما إذا كان GLES2 متوافقًا (الإعداد التلقائي: إيقاف)
DEQP_GLES2_LIBRARIES	مكتبات GLES2 (تُترك فارغة إذا لم تكن متوافقة أو إذا تم استخدام التحميل الديناميكي)
DEQP_SUPPORT_GLES3	ما إذا كان GLES3.x متوافقًا (الإعداد التلقائي: إيقاف)
DEQP_GLES3_LIBRARIES	مكتبات GLES3.x (تُترك فارغة إذا لم تكن متوافقة أو إذا تم استخدام التحميل الديناميكي)
DEQP_SUPPORT_VG	ما إذا كان OpenVG متوافقًا (الإعداد التلقائي: إيقاف)
DEQP_OPENVG_LIBRARIES	مكتبات OpenVG (تُترك فارغة إذا لم تكن متوافقة أو إذا تم استخدام التحميل الديناميكي)
DEQP_SUPPORT_EGL	ما إذا كان EGL متوافقًا (الإعداد التلقائي: "إيقاف")
DEQP_EGL_LIBRARIES	مكتبات EGL (تُترك فارغة إذا لم تكن متوافقة أو إذا تم استخدام التحميل الديناميكي)
DEQP_PLATFORM_LIBRARIES	مكتبات إضافية خاصة بالأنظمة الأساسية مطلوبة للربط
DEQP_PLATFORM_COPY_LIBRARIES	قائمة بالمكتبات التي يتم نسخها إلى كل دليل إصدار ثنائي تجريبي يمكن أن يكون تُستخدم لنسخ المكتبات اللازمة لإجراء الاختبارات ولكن لا يتم استخدامها بشكل تلقائي .
TCUTIL_PLATFORM_SRCS	قائمة مصادر منافذ النظام الأساسي يتم تحديد المصادر التلقائية استنادًا إلى والإمكانيات وأنظمة التشغيل. ملاحظة: ترتبط المسارات بما يلي: framework/platform

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

إصدار Win32

إن أسهل طريقة لإنشاء وحدات 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 باستخدام الخيار "-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 باستخدام الإصدار المتوفّر النصوص البرمجية، فستحتاج إلى:

• أحدث إصدار من 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 من Python غير متوافق
• على Windows: إما NMake أو JOM في PATH
  • توفّر JOM إصدارات أسرع
• اختياري: يتوفر إصدار Ninja أيضًا على نظام التشغيل Linux

تستند القيم الثنائية للنمل وحزمة تطوير البرامج (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 من خلال إنشاء ملفات Makefiles باستخدام 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 القياسية، فإن المتغيرات التالية الخاصة بالدقة يمكن تعيينها من قبل ملف سلسلة الأدوات. يمكن أن يرصد 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	نوع وحدة المعالجة المركزية (CPU). القيمتان المسموح بإدراجهما هما: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE	sizeof(null*) على النظام الأساسي. القيمتان المسموح بهما هما: 4 و8.

يمكن اختيار ملف Toolchain باستخدام مَعلمة الإصدار CMAKE_TOOLCHAIN_FILE. على سبيل المثال، سيؤدي ما يلي إلى إنشاء ملفات Makefiles لأي إصدار باستخدام برنامج التجميع المشترك عبر 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. إنشاء متغير تهيئة الإصدار.

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

تتضمن عملية نقل الموقع ثلاث خطوات: تكييف مكتبات قابلية النقل الأساسية، وتنفيذ واجهات اختبار تكامل النظام الأساسي والإطار الخاص بها، ونقل خدمة التنفيذ.

يدرج الجدول أدناه المواقع الجغرافية للتغييرات المحتملة في النقل. أي ميزات أخرى فمن المحتمل أن تكون غريبة.

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

اختبار منفذ النظام الأساسي لإطار العمل

يتطلب منفذ النظام الأساسي لإطار عمل اختبار 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. والبيئات واستخدام وسيطات سطر الأوامر والعمل مع حزمة التطبيق التالية.

بيئات 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
	data/gles2	<dst>/gles2
وحدة GLES3	build/modules/gles3/deqp-gles3	<dst>/deqp-gles3
	data/gles3	<dst>/gles3
وحدة GLES3.1	build/modules/gles31/deqp-gles31	<dst>/deqp-gles31
	data/gles31	<dst>/gles31
وحدة GLES3.2	build/modules/gles32/deqp-gles32	<dst>/deqp-gles32
	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 قياسي. نظرًا لأن العمود زيادة مجموعات الاختبار، فإن البادئات المتكررة قد تكون مرهقة. لتجنب تكرار البادئات، استخدم بناء جملة trie (المعروفة أيضًا باسم شجرة البادئة) كما هو موضّح أدناه.

{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 أو إصدار أحدث)

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

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 intent. التي تستهدف 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.

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

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

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

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

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

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

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

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

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

منفِّذ اختبار سطر الأوامر

أداة تنفيذ اختبار سطر الأوامر عبارة عن أداة C++ محمولة لبدء تشغيل اختبار على أحد الأجهزة وجمع السجلات الناتجة منه عبر بروتوكول TCP/IP. المُنفِّذ يتصل بخدمة التنفيذ (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 الاختبار. كود النتيجة، مثل "Pass" (اجتياز) أو "إخفاق". تختار الوسيطة --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 الإخراج. يمكن تحويل ملفات سجل اختبار dqp إلى تنسيق إخراج 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.*