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

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

للعمل مع أحدث التعليمات البرمجية المقدمة، استخدم فرع deqp-dev . بالنسبة للتعليمات البرمجية التي تتوافق مع إصدار Android CTS محدد، استخدم فرع 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	الأدوات المساعدة الخاصة بواجهة برمجة التطبيقات (API).
execserver	مصدر ExecServer من جانب الجهاز
executor	أداة وأدوات مساعدة لمنفذ الاختبار من جانب المضيف
external	إنشاء دليل كعب الروتين للمكتبات الخارجية libpng وzlib

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

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

بناء برامج الاختبار

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

نظام بناء CMake

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

CMake هو نظام بناء مفتوح المصدر يدعم منصات وسلاسل أدوات متعددة. يقوم CMake بإنشاء ملفات تعريف أصلية أو ملفات مشروع IDE من ملفات تكوين مستقلة عن الهدف. لمزيد من المعلومات حول CMake، الرجاء مراجعة وثائق CMake .

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

يتم توفير خيارات التكوين لـ CMake باستخدام -D OPTION_NAME = VALUE . بعض الخيارات الشائعة الاستخدام لـ deqp مذكورة أدناه.

خيار التكوين	وصف
DEQP_TARGET	اسم الهدف، على سبيل المثال: "android" ستتضمن البرامج النصية deqp CMake 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 مدعومًا (الافتراضي: OFF)
DEQP_GLES2_LIBRARIES	مكتبات GLES2 (اتركها فارغة إذا لم تكن مدعومة أو تم استخدام التحميل الديناميكي)
DEQP_SUPPORT_GLES3	ما إذا كان GLES3.x مدعومًا (الافتراضي: OFF)
DEQP_GLES3_LIBRARIES	مكتبات GLES3.x (اتركها فارغة إذا لم تكن مدعومة أو تم استخدام التحميل الديناميكي)
DEQP_SUPPORT_VG	ما إذا كان OpenVG مدعومًا (الافتراضي: OFF)
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 باستخدام خيار -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 الامتداد المطلوب.

دعم إي جي إل

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

بناء الروبوت

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

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

• أحدث إصدار من Android NDK ؛ يسرد الملف android/scripts/common.py الإصدار المطلوب
• تم تثبيت حزمة SDK المستقلة لنظام التشغيل Android مع API 13 وأدوات SDK وأدوات منصة SDK وحزم أدوات إنشاء SDK
• Apache Ant 1.9.4 (مطلوب لبناء كود Java)
• كميك 2.8.12 أو أحدث
• Python 2.6 أو الأحدث في سلسلة 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 عن طريق إنشاء ملفات تعريفية باستخدام 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 . على سبيل المثال، قد يقوم ما يلي بإنشاء ملفات تكوين للبنية باستخدام مترجم 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 إلى نقاط دخول لواجهة برمجة التطبيقات قيد الاختبار أثناء الارتباط. يصل رمز الاختبار دائمًا إلى واجهات برمجة التطبيقات من خلال مؤشرات الوظائف. يمكن بعد ذلك تحميل نقاط الإدخال ديناميكيًا في وقت التشغيل أو يمكن لمنفذ النظام الأساسي توفيرها في وقت الارتباط.

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

اختبار منفذ منصة الإطار

يتطلب منفذ النظام الأساسي لإطار عمل اختبار 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.

بيئات لينكس وويندوز

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

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

لبدء نشاط تنفيذ الاختبار يدويًا، أنشئ غرض 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.

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

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

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

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

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

يأتي 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 بإخراج رمز نتيجة الاختبار، مثل "Pass" أو "Fail". تحدد الوسيطة --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.*