يتضمن 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 |
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 | قائمة مصادر منفذ النظام الأساسي. يتم تحديد المصادر الافتراضية بناءً على الإمكانيات ونظام التشغيل. ملاحظة: المسارات مرتبطة بـ: |
يمكن أن يضيف ملف البناء الهدف مسارات تضمين أو رابط إضافية باستخدام وظائف 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_COMPILER | نوع المترجم. القيم المدعومة هي: |
DE_CPU | نوع وحدة المعالجة المركزية. القيم المدعومة هي: |
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/qphelper/qpCrashHandler.c | اختياري: التنفيذ لنظام التشغيل الخاص بك. |
framework/qphelper/qpWatchDog.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 | قراءة قائمة الحالات من 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-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.*
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2024-04-29 (حسب التوقيت العالمي المتفَّق عليه)