آزمایش برنامه کیفیت drawElements

هشدار: این صفحه نگهداری نمی‌شود و منسوخ خواهد شد. برای اطلاعات فعلی، به این موارد مراجعه کنید:

• ویکی VK-GL-CTS برای اعضای Khronos
• ویکی VK-GL-CTS برای اعضای غیر Khronos

‫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	برنامه‌های کمکی ویژه میانای برنامه‌سازی کاربردی
execserver	منبع ExecServer سمت دستگاه
executor	ابزار و کاربری‌های پوسته اجراکننده آزمایش سمت میزبان
external	ساختن فهرست راهنمای تهی برای کتابخانه‌های خارجی libpng و zlib

اجزای متن‌باز

‫deqp از libpng و zlib استفاده می‌کند که می‌توان آن‌ها را بااستفاده از اسکریپت platform/external/deqp/external/fetch_sources.py یا ازطریق git از platform/external/[libpng,zlib] واکشی کرد.

ساختن برنامه‌های آزمایشی

چارچوب آزمایش با درنظر گرفتن قابلیت انتقال طراحی شده است. تنها الزامات اجباری، پشتیبانی کامل از ++C و کتابخانه‌های سیستم استاندارد برای I/O، رشته‌ها، و سوکت‌ها است.

سیستم ساخت CMake

منابع deqp دارای دستورگان‌های ساخت برای CMake است که ابزار ترجیحی برای گردآوری برنامه‌های آزمایشی است.

‫CMake یک سیستم ساخت متن‌باز است که از چندین پلاتفرم و زنجیره ابزار پشتیبانی می‌کند. CMake فایل‌های makefile بومی یا فایل‌های پروژه IDE را از فایل‌های پیکربندی مستقل از هدف تولید می‌کند. برای کسب اطلاعات بیشتر درباره CMake، لطفاً به مستندات CMake مراجعه کنید.

‫CMake از ساخت‌های خارج از درخت منبع پشتیبانی می‌کند و آن‌ها را توصیه می‌کند، یعنی باید همیشه فایل‌های ساخت یا فایل‌های پروژه را در یک دایرکتوری ساخت جداگانه خارج از درخت منبع ایجاد کنید. ‫CMake هیچ نوع هدف «distclean» ندارد، بنابراین حذف هر فایلی که CMake تولید کرده است باید به‌صورت دستی انجام شود.

گزینه‌های پیکربندی بااستفاده از -DOPTION_NAME=VALUE نحو به CMake داده می‌شود. برخی‌از گزینه‌های معمولاً استفاده‌شده برای deqp در زیر فهرست شده است.

گزینه پیکربندی	شرح
DEQP_TARGET	نام هدف، برای مثال: «android» اسکریپت‌های deqp CMake شامل فایل targets/DEQP_TARGET/DEQP_TARGET.cmake خواهند بود و انتظار می‌رود گزینه‌های ساخت مختص هدف را از آنجا پیدا کنند.
CMAKE_TOOLCHAIN_FILE	مسیر فایل زنجیره ابزار برای CMake. برای ترجمه متقابل استفاده می‌شود.
CMAKE_BUILD_TYPE	نوع ساخت برای هدف‌های فایل ساخت. مقادیر معتبر عبارت‌اند از: «اشکال‌زدایی» و «انتشار» توجه داشته باشید که تفسیر و نوع پیش‌فرض به سیستم ساخت هدف بستگی دارد. برای جزئیات بیشتر، مستندات 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 نسخه ۲.۶.۱۲ یا جدیدتر و کامپایلر Microsoft Visual C/C++‎ نیاز دارید. ‫deqp با Visual Studio 2013 آزمایش شده است.

فایل‌های پروژه Visual Studio را می‌توان با فرمان زیر تولید کرد:

cmake path\to\src\deqp -G "Visual Studio 12"

با انتخاب «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_SUPPORT_EGL روشن باشد، deqp با بارگیری پویا برای EGL در Windows ساخته می‌شود. این گزینه در اکثر هدف‌ها پیش‌فرض است. سپس، اگر میزبان کتابخانه‌های EGL دردسترس داشته باشد، می‌توان با پارامتر خط فرمان با آن‌ها آزمایش اجرا کرد: --deqp-gl-context-type=egl

ساخت Android

ساخت Android از دستورگان ساخت CMake برای ساختن کد آزمایشی بومی استفاده می‌کند. بخش‌های Java، یعنی «سرور اجرای آزمایش» و «ته‌مان برنامه آزمایش»، بااستفاده از ابزارهای ساخت استاندارد Android کامپایل می‌شوند.

برای گردآوری برنامه‌های آزمایشی deqp برای Android بااستفاده از نوشته‌های ساختار ارائه‌شده، به موارد زیر نیاز دارید:

• جدیدترین نسخه Android NDK؛ فایل android/scripts/common.py نسخه موردنیاز را فهرست می‌کند
• کیت توسعه نرم‌افزار مستقل Android با API 13، «ابزارهای کیت توسعه نرم‌افزار»، «ابزارهای پلاتفرم کیت توسعه نرم‌افزار»، و «ابزارهای ساخت کیت توسعه نرم‌افزار» بسته‌ها نصب شد
• Apache Ant 1.9.4 (موردنیاز برای ساخت کد جاوا)
• ‫CMake 2.8.12 یا جدیدتر
• Python 2.6 یا جدیدتر در سری 2.x؛ از Python 3.x پشتیبانی نمی‌شود
• برای Windows: ‏NMake یا JOM در PATH
  • ‫JOM ساخت سریع‌تر را ممکن می‌کند
• اختیاری: Ninja make نیز در Linux پشتیبانی می‌شود

فایل‌های اجرایی Ant و کیت توسعه نرم‌افزار براساس متغیر محیطی PATH با پیش‌فرض‌های معین لغوکننده مکان‌یابی می‌شوند. منطق توسط android/scripts/common.py کنترل می‌شود.

دایرکتوری NDK باید ~/android-ndk-VERSION یا C:/android/android-ndk-VERSION باشد یا ازطریق متغیر محیطی ANDROID_NDK_PATH تعریف شود.

عناصر درون‌دستگاهی deqp، سرویس اجرای آزمایش، و برنامه‌های آزمایش با اجرای نوشتار android/scripts/build.py ساخته می‌شوند. «کیت بسته Android»‏ (APK) نهایی در android/package/bin ایجاد می‌شود و با دستورگان install.py قابل‌نصب است. اگر از مجری خط فرمان استفاده شود، ExecService با اسکریپت launch.py ازطریق ADB در دستگاه راه‌اندازی می‌شود. اسکریپت‌ها را می‌توان از هر دایرکتوری اجرا کرد.

ساخت Linux

با تولید فایل‌های ساخت بااستفاده از CMake، می‌توان فایل‌های اجرایی آزمایشی و ابزارهای خط فرمان را برای Linux ساخت. چندین هدف ساخت ازپیش‌تعریف‌شده وجود دارد که هنگام ساخت برای 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 می‌توان برای ارسال متغیرهای مستقل اضافی به کامپایلر استفاده کرد. برای مثال، ساخت ۳۲ بیتی یا ۶۴ بیتی را می‌توان با تنظیم به‌ترتیب -DCMAKE_C(XX)_FLAGS="-m32" یا "-m64" انجام داد. اگر مشخص نشده باشد، از معماری بومی زنجیره ابزار، که معمولاً ۶۴ بیتی در زنجیره ابزار ۶۴ بیتی است، استفاده می‌شود.

از آرگومان‌های -DCMAKE_LIBRARY_PATH و -DCMAKE_INCLUDE_PATH می‌توان برای CMake استفاده کرد تا مسیرهای جستجوی کتابخانه یا گنجاندن اضافی را به CMake بدهد.

نمونه‌ای از خط فرمان کامل که برای ساختن اشکال‌زدایی ۳۲ بیتی دربرابر سرایندها و کتابخانه‌های درایور در مکان سفارشی استفاده می‌شود به این صورت است:

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	نوع CPU. مقادیر پشتیبانی‌شده عبارت‌اند از: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE	‫sizeof(void*)‎ در پلاتفرم. مقادیر پشتیبانی‌شده: ۴ و ۸

فایل زنجیره ابزار را می‌توان بااستفاده از پارامتر ساخت CMAKE_TOOLCHAIN_FILE انتخاب کرد. برای مثال، دستور زیر فایل‌های make را برای ساختن بااستفاده از کامپایلر متقابل 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 پشتیبانی می‌کنند. اگر هدف آزمایش روی یکی از آن سیستم‌های عامل اجرا شود، به‌احتمال زیاد نیازی به دست زدن به کتابخانه‌های قابلیت حمل پایه نیست.

درگاه پلاتفرم چارچوب آزمایش

درگاه پلاتفرم چارچوب آزمون 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 را که سرور در آن گوش می‌دهد تنظیم می‌کند. پیش‌فرض ۵۰۰۱۶ است.
• وقتی اتصال کارخواه قطع شود، --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
	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 است و میان‌گیر شابلون ۸ بیت دارد.
--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>	جهت صفحه در گام‌های ۹۰ درجه برای پلاتفرم‌هایی که از آن پشتیبانی می‌کنند.

قالب فهرست چارچوب تست

فهرست چارچوب تست را می‌توان در دو قالب ارائه کرد. اولین گزینه این است که نام کامل هر آزمایش را در یک خط جداگانه در یک فایل استاندارد ASCII فهرست کنید. با بزرگ‌تر شدن مجموعه‌های آزمایش، پیشوندهای تکراری می‌توانند دست‌وپاگیر باشند. برای جلوگیری از تکرار پیشوندها، از نحو درخت پیشوندی (که به آن درخت پیشوندی نیز می‌گویند) که در زیر نشان داده شده است استفاده کنید.

{nodeName{firstChild{…},…lastChild{…}}}

برای مثال:

{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}

به دو مورد آزمایشی زیر ترجمه می‌شود:

dEQP-EGL.config_list
dEQP-EGL.create_context.rgb565_depth_stencil

Android

بسته برنامه Android شامل همه مؤلفه‌های لازم، ازجمله سرویس اجرای آزمایشی، فایل‌های دودویی آزمایشی، و فایل‌های داده است. فعالیت آزمایشی یک NativeActivity است که از EGL استفاده می‌کند (به Android 3.2 یا بالاتر نیاز دارد).

بسته برنامه را می‌توان با دستور زیر نصب کرد (نام نشان‌داده‌شده نام APK در بسته Android CTS است؛ این نام به ساخت بستگی دارد):

adb –d install –r com.drawelements.deqp.apk

برای راه‌اندازی سرویس اجرای آزمایشی و راه‌اندازی بازارسال درگاه، از موارد زیر استفاده کنید:

adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter

با اجرای دستور زیر قبل‌از شروع آزمایش‌ها، می‌توان چاپ اشکال‌زدایی را فعال کرد:

adb –d shell setprop log.tag.dEQP DEBUG

اجرای آزمایش‌ها در Android بدون Android CTS

برای شروع کردن دستی فعالیت اجرای آزمایش، هدف Android را بسازید که android.app.NativeActivity را هدف‌یابی می‌کند. فعالیت‌ها را می‌توانید در بسته com.drawelements.deqp پیدا کنید. خط فرمان باید به‌صورت رشته اضافی با کلید "cmdLine" در «هدف» ارائه شود.

گزارش آزمایشی در /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

برای اجرای آزمایش‌ها تحت «اشکال‌زدای GNU» (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 می‌نویسد که از خط ۱۳۲ فایل اسکریپت شروع می‌شود. می‌توانید مسیرهای اضافی برای فایل‌های اجرایی ارائه دهید، اما ارائه پارامترهای خط فرمان صحیح باید کافی باشد.

توجه: در Windows، فایل اجرایی GDB به libpython2.7.dll نیاز دارد. قبل‌از راه‌اندازی debug.py، <path-to-ndk>/prebuilt/windows/bin را به متغیر PATH اضافه کنید.

توجه: اشکال‌زدایی کد بومی در Android 4.3 اصلی کار نمی‌کند؛ برای راه‌حل‌های موقت، به این اشکال عمومی مراجعه کنید. ‫Android نسخه ۴.۴ و بالاتر این اشکال را ندارند.

خودکارسازی کردن آزمایش‌ها

واحدهای آزمایشی Deqp را می‌توان به روش‌های مختلفی در سیستم‌های آزمایشی خودکارشده ادغام کرد. بهترین رویکرد به زیرساخت آزمایش موجود و محیط هدف بستگی دارد.

برونداد اصلی از اجرای آزمایشی همیشه فایل گزارش آزمایشی است، یعنی فایلی با پسوند .qpa. نتایج کامل آزمایش را می‌توان از گزارش آزمایش تجزیه کرد. برونداد کنسول فقط اطلاعات اشکال‌زدایی است و ممکن است در همه پلاتفرم‌ها دردسترس نباشد.

دودویی‌های آزمایشی را می‌توان مستقیماً از سیستم خودکارسازی آزمایشی فراخوانی کرد. باینری آزمایش را می‌توان برای موردی خاص، برای مجموعه‌ای آزمایشی، یا برای همه آزمایش‌های دردسترس راه‌اندازی کرد. اگر درطول اجرا خطای مهلکی رخ دهد (مثل برخی‌از خطاهای API یا خرابی)، اجرای آزمایش متوقف خواهد شد. برای آزمایش پسرفت، بهترین رویکرد این است که فایل‌های اجرایی آزمایش را برای موارد جداگانه یا مجموعه‌های آزمایش کوچک به‌صورت جداگانه فراخوانی کنید تا حتی درصورت بروز خطای سخت، نتایج جزئی دردسترس باشد.

‫deqp همراه با ابزارهای اجرای آزمایشی خط فرمان ارائه می‌شود که می‌توان از آن‌ها در ترکیب با سرویس اجرا برای دستیابی به یکپارچگی قوی‌تر استفاده کرد. مجری پایان فرایند آزمایش را تشخیص می‌دهد و اجرای آزمایش را در مورد بعدی دردسترس ازسر می‌گیرد. یک فایل گزارش از کل جلسه آزمایشی تولید می‌شود. این راه‌اندازی برای سیستم‌های آزمایشی سبک که امکانات بازیابی خرابی ارائه نمی‌دهند ایده‌آل است.

ابزارهای اجرای آزمایش خط فرمان

مجموعه ابزار خط فرمان فعلی شامل یک ابزار اجرای آزمایشی از راه دور، یک تولیدکننده مقایسه گزارش آزمایشی برای تحلیل رگرسیون، یک تبدیل‌کننده گزارش آزمایشی به CSV، یک تبدیل‌کننده گزارش آزمایشی به XML، و یک تبدیل‌کننده گزارش آزمایشی به JUnit است.

کد منبع این ابزارها در پوشه executor قرار دارد و فایل‌های اجرایی در پوشه <builddir>/executor ساخته شده‌اند.

مجری آزمایش خط فرمان

اجراکننده آزمایش خط فرمان ابزار C++ قابل حملی برای راه‌اندازی اجرای آزمایش در دستگاه و جمع‌آوری گزارش‌های نتیجه از آن ازطریق TCP/IP است. «اجراکننده» با سرویس اجرا (execserver) در دستگاه هدف ارتباط برقرار می‌کند. این دو با هم عملکردهایی مثل بازیابی از خرابی‌های فرایند آزمایش را ارائه می‌دهند. مثال‌های زیر نحوه استفاده از «مجری آزمایش» خط فرمان را نشان می‌دهد (برای جزئیات بیشتر، از --help استفاده کنید):

مثال ۱: اجرای آزمایش‌های عملکردی 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"

مثال ۲: ادامه اجرای آزمایشی جزئی 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

مثال ۱: صادر کردن گزارش آزمایش در قالب CSV

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

مثال ۲: فهرست کردن تفاوت‌های نتایج آزمایش بین دو گزارش آزمایش

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

توجه: آرگومان --value=code کد نتیجه آزمایش را، مانند «قبول» یا «رد»، برون‌برد می‌کند. آرگومان --value=details توضیح بیشتر درباره نتیجه یا مقدار عددی تولیدشده توسط آزمون عملکرد، قابلیت، یا دقت را انتخاب می‌کند.

صادر کردن XML گزارش آزمایشی

فایل‌های گزارش آزمایش را می‌توان بااستفاده از ابزار testlog-to-xml به اسناد XML معتبر تبدیل کرد. از دو حالت برونداد پشتیبانی می‌شود:

• حالت اسناد جداگانه، که در آن هر مورد آزمون و سند خلاصه caselist.xml در فهرست راهنمای مقصد نوشته می‌شود
• حالت تک‌فایلی، که در آن همه نتایج موجود در فایل .qpa در یک سند 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 را می‌توان بااستفاده از ابزار testlog-to-junit به قالب برونداد 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.*