این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

DrawElements Quality Test برنامه

AOSP شامل مجموعه تست گرافیکی DrawElements Quality Program (deqp) در https://android.googlesource.com/platform/external/deqp است. در این صفحه نحوه استقرار مجموعه تست deqp در یک محیط جدید توضیح داده شده است.

برای کار با آخرین کد ارسالی از شاخه deqp-dev استفاده کنید. برای کدی که با نسخه خاص Android CTS مطابقت دارد، از شاخه release-code-name -release استفاده کنید (مثلاً برای Android 6.0، از شاخه marshmallow-release استفاده کنید).

چیدمان منبع

طرح کد منبع برای ماژول های تست deqp و کتابخانه های پشتیبانی کننده در جدول زیر نشان داده شده است (فهرست جامع نیست اما مهمترین دایرکتوری ها را برجسته می کند).

دایرکتوری	توضیحات
`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 from platform/external/[libpng,zlib] واکشی شوند.

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

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

سیستم ساخت CMake

منابع deqp دارای اسکریپت های بیلد برای CMake هستند که ابزار ترجیحی برای کامپایل برنامه های آزمایشی است.

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

CMake از ساخت‌های درختی خارج از منبع پشتیبانی و توصیه می‌کند، به عنوان مثال، همیشه باید فایل‌های makefiles یا فایل‌های پروژه را در یک فهرست ساخت جداگانه خارج از درخت منبع ایجاد کنید. CMake هیچ نوع هدف "distclean" ندارد، بنابراین حذف فایل های تولید شده توسط CMake باید به صورت دستی انجام شود.

گزینه های پیکربندی با استفاده از -D OPTION_NAME = VALUE نحو به CMake داده می شود. برخی از گزینه‌های رایج برای deqp در زیر فهرست شده‌اند.

گزینه پیکربندی توضیحات

گزینه پیکربندی	توضیحات
`DEQP_TARGET`	نام هدف، به عنوان مثال: "اندروید" اسکریپت‌های deqp CMake شامل `targets/ DEQP_TARGET / DEQP_TARGET .cmake` می‌شود و انتظار می‌رود که گزینه‌های ساخت خاص هدف را از آنجا پیدا کنید.
`CMAKE_TOOLCHAIN_FILE`	مسیر فایل Toolchain برای CMake. برای کامپایل متقابل استفاده می شود.
`CMAKE_BUILD_TYPE`	نوع ساخت برای اهداف ساخت فایل. مقادیر معتبر عبارتند از: "Debug" و "Release" توجه داشته باشید که نوع تفسیر و پیش‌فرض به سیستم ساخت هدف بستگی دارد. برای جزئیات به مستندات CMake مراجعه کنید.

DEQP_TARGET

نام هدف، به عنوان مثال: "اندروید"

اسکریپت‌های deqp CMake شامل targets/ DEQP_TARGET / DEQP_TARGET .cmake می‌شود و انتظار می‌رود که گزینه‌های ساخت خاص هدف را از آنجا پیدا کنید.

CMAKE_TOOLCHAIN_FILE

مسیر فایل Toolchain برای CMake. برای کامپایل متقابل استفاده می شود.

CMAKE_BUILD_TYPE

نوع ساخت برای اهداف ساخت فایل. مقادیر معتبر عبارتند از: "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` هستند

فایل ساخت هدف می تواند مسیرهای شامل یا پیوند اضافی را با استفاده از توابع include_directories() و link_directories() CMake اضافه کند.

ساخت Win32

ساده ترین راه برای ساخت ماژول های deqp برای ویندوز استفاده از سیستم ساخت CMake است. شما به CMake 2.6.12 یا جدیدتر و کامپایلر Microsoft Visual C/C++ نیاز دارید. deqp با Visual Studio 2013 تست شده است.

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

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

با انتخاب «Visual Studio VERSION Win64» به‌عنوان مولد ساخت، می‌توان یک ساخت 64 بیتی ایجاد کرد:

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

همچنین می‌توانید با گزینه -G "NMake Makefiles" و همچنین نوع ساخت ( -DCMAKE_BUILD_TYPE="Debug" یا "Release" ) فایل‌های NMake را ایجاد کنید.

ایجاد زمینه را رندر کنید

متن رندر می تواند با WGL یا با EGL در ویندوز ایجاد شود.

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

ساخت اندروید

ساخت اندروید از اسکریپت های ساخت CMake برای ساخت کد تست بومی استفاده می کند. قطعات جاوا، به عنوان مثال، Test Execution Server و Test Application Stub، با استفاده از ابزارهای استاندارد ساخت اندروید کامپایل شده اند.

برای کامپایل برنامه های تست deqp برای اندروید با اسکریپت های ساخت ارائه شده، به موارد زیر نیاز دارید:

آخرین نسخه اندروید NDK ؛ فایل android/scripts/common.py نسخه مورد نیاز را فهرست می کند
Android SDK مستقل با نصب API 13، SDK Tools، SDK Platform-Tools و SDK Build-tools بسته های نصب شده
Apache Ant 1.9.4 (مورد نیاز ساخت کد جاوا)
CMake 2.8.12 یا جدیدتر
پایتون 2.6 یا جدیدتر در سری 2.x. پایتون 3.x پشتیبانی نمی شود
برای ویندوز: NMake یا JOM در PATH
- JOM ساخت سریعتر را امکان پذیر می کند
اختیاری: Ninja make در لینوکس نیز پشتیبانی می شود

باینری‌های 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 بر روی دستگاه راه اندازی می شود. اسکریپت ها را می توان از هر دایرکتوری اجرا کرد.

ساخت لینوکس

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

هدف را بسازید	توضیحات
`default`	هدف پیش فرضی که از درون نگری پلتفرم CMake برای تعیین پشتیبانی از API های مختلف استفاده می کند.
`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 به دست آورد. فایل Toolchain کامپایلر مورد استفاده را به همراه مسیرهای جستجوی سفارشی برای کتابخانه ها و هدرها مشخص می کند. چندین فایل زنجیره ابزار برای سناریوهای رایج در بسته انتشار در دایرکتوری 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*) روی پلت فرم. مقادیر پشتیبانی شده عبارتند از: 4 و 8

فایل Toolchain را می توان با استفاده از پارامتر ساخت CMAKE_TOOLCHAIN_FILE انتخاب کرد. به عنوان مثال، موارد زیر با استفاده از کامپایلر متقابل CodeSourcery برای ARM/Linux، فایل‌های make-files را برای یک ساخت ایجاد می‌کند:

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 تحت آزمایش نیاز ندارد. کد تست همیشه از طریق نشانگرهای تابع به APIها دسترسی دارد. سپس نقاط ورودی می توانند به صورت پویا در زمان اجرا بارگذاری شوند یا پورت پلت فرم می تواند آنها را در زمان پیوند ارائه دهد.

اگر پشتیبانی از یک 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`	پورت پلتفرم جدید و خرد برنامه را می توان همانطور که در درگاه پلت فرم چارچوب تست توضیح داده شده است پیاده سازی کرد.

کتابخانه های قابل حمل پایه

کتابخانه های قابل حمل پایه در حال حاضر از ویندوز، اکثر انواع لینوکس، سیستم عامل مک، iOS و اندروید پشتیبانی می کنند. اگر هدف آزمایشی روی یکی از آن سیستم عامل ها اجرا شود، به احتمال زیاد نیازی به لمس کتابخانه های قابل حمل پایه نیست.

پورت پلت فرم چارچوب را تست کنید

پورت پلت فرم چارچوب تست deqp به دو جزء نیاز دارد: یک نقطه ورود برنامه و یک پیاده سازی رابط پلت فرم.

نقطه ورود برنامه مسئول ایجاد شی پلتفرم، ایجاد یک شیء خط فرمان ( tcu::CommandLine )، باز کردن گزارش آزمایشی ( tcu::TestLog ) و تکرار برنامه آزمایشی ( tcu::App ) است. اگر سیستم عامل هدف از یک نقطه ورودی main() استاندارد پشتیبانی می کند، tcuMain.cpp می تواند به عنوان پیاده سازی نقطه ورودی استفاده شود.

API پلتفرم 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 در محیط های لینوکس و ویندوز، استفاده از آرگومان های خط فرمان و کار با بسته برنامه اندروید ارائه شده است.

محیط های لینوکس و ویندوز

با کپی کردن فایل ها و دایرکتوری های زیر در هدف شروع کنید.

ماژول	دایرکتوری	هدف
سرور اجرا	`build/execserver/execserver`	`<dst>/execserver`
ماژول EGL	`build/modules/egl/deqp-egl`	`<dst>/deqp-egl`
ماژول GLES2	`build/modules/gles2/deqp-gles2`	`<dst>/deqp-gles2`
ماژول GLES2	`data/gles2`	`<dst>/gles2`
ماژول GLES3	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
ماژول GLES3	`data/gles3`	`<dst>/gles3`
ماژول GLES3.1	`build/modules/gles31/deqp-gles31`	`<dst>/deqp-gles31`
ماژول GLES3.1	`data/gles31`	`<dst>/gles31`
ماژول GLES3.2	`build/modules/gles32/deqp-gles32`	`<dst>/deqp-gles32`
ماژول GLES3.2	`data/gles32`	`<dst>/gles32`

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

آرگومان های خط فرمان

جدول زیر آرگومان های خط فرمان را فهرست می کند که بر اجرای همه برنامه های آزمایشی تأثیر می گذارد.

استدلال	توضیحات
`--deqp-case=<casename>`	مواردی را اجرا کنید که با یک الگوی داده شده مطابقت دارند. حروف عام (*) پشتیبانی می شود.
`--deqp-log-filename=<filename>`	نتایج آزمایش را در فایلی که نام آن را ارائه می کنید بنویسید. سرویس اجرای آزمایش، نام فایل را هنگام شروع آزمایش تنظیم می کند.
`--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>`	لیست موارد را از stdin یا از یک آرگومان داده شده بخوانید. سرویس اجرای آزمایش آرگومان را با توجه به درخواست اجرایی دریافتی تنظیم می کند. برای توضیح قالب فهرست موارد، بخش بعدی را ببینید.
`--deqp-test-iteration-count=<count>`	برای تست هایی که از تعداد متغیری از تکرارها پشتیبانی می کنند، تعداد تکرار را لغو کنید.
`--deqp-base-seed=<seed>`	بذر پایه برای موارد آزمایشی که از تصادفی سازی استفاده می کنند.

آرگومان های خاص GLES2 و GLES3

جدول زیر آرگومان های خاص GLES2- و GLES3 را فهرست می کند.

استدلال	توضیحات
`--deqp-gl-context-type=<type>`	نوع زمینه OpenGL. انواع زمینه موجود به پلتفرم بستگی دارد. در پلتفرم هایی که از EGL پشتیبانی می کنند، می توان از مقدار `egl` برای انتخاب زمینه EGL استفاده کرد.
`--deqp-gl-config-id=<id>`	آزمایش‌هایی را برای شناسه پیکربندی GL ارائه شده اجرا کنید. تفسیر وابسته به پلتفرم است. در پلتفرم EGL، این شناسه پیکربندی EGL است.
`--deqp-gl-config-name=<name>`	آزمایش‌هایی را برای پیکربندی GL با نام اجرا کنید. تفسیر وابسته به پلتفرم است. برای EGL، قالب `rgb(a)<bits>d<bits>s<bits>` است. به عنوان مثال، مقدار `rgb888s8` اولین پیکربندی را انتخاب می کند که در آن بافر رنگ RGB888 است و بافر استنسیل دارای 8 بیت است.
`--deqp-gl-context-flags=<flags>`	زمینه ایجاد می کند. `robust` یا `debug` را مشخص کنید.
`--deqp-surface-width=<width> --deqp-surface-height=<height>`	سعی کنید سطحی با اندازه مشخص ایجاد کنید. پشتیبانی از این امر اختیاری است.
`--deqp-surface-type=<type>`	از یک نوع سطح معین به عنوان هدف اصلی رندر آزمایشی استفاده کنید. انواع ممکن عبارتند از `window` , `pixmap` , `pbuffer` و `fbo` .
`--deqp-screen-rotation=<rotation>`	جهت گیری صفحه با افزایش 90 درجه برای پلتفرم هایی که از آن پشتیبانی می کنند.

قالب لیست موارد آزمایشی

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

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

به عنوان مثال:

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

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

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

اندروید

بسته نرم افزار اندروید شامل تمام اجزای مورد نیاز از جمله سرویس اجرای تست، باینری های تست و فایل های داده است. فعالیت آزمایشی یک NativeActivity است که از EGL استفاده می کند (نیاز به اندروید 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 CTS اجرا کنید

برای شروع دستی فعالیت اجرای آزمایش، یک intent 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"'

اشکال زدایی در اندروید

برای اجرای آزمایشات تحت دیباگر GDB در اندروید، ابتدا با اجرای دو اسکریپت زیر، بیلد اشکال زدایی را کامپایل و نصب کنید:

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 فایل اسکریپت شروع می شود. شما می توانید مسیرهای اضافی را به باینری ها و غیره ارائه دهید، اما ارائه پارامترهای خط فرمان صحیح باید کافی باشد.

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

توجه: اشکال زدایی کد بومی در اندروید استوک 4.3 کار نمی کند. برای راه‌حل‌ها، به این باگ عمومی مراجعه کنید. اندروید 4.4 و بالاتر حاوی این باگ نیست.

تست ها را خودکار کنید

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

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

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

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

ابزارهای اجرای تست خط فرمان

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

کد منبع این ابزارها در دایرکتوری executor است و باینری ها در دایرکتوری <builddir>/executor ساخته می شوند.

مجری تست خط فرمان

مجری تست خط فرمان یک ابزار سی پلاس پلاس قابل حمل برای راه اندازی یک آزمایش آزمایشی بر روی یک دستگاه و جمع آوری گزارش های حاصل از آن از طریق TCP/IP است. Executor با سرویس اجرا (execserver) در دستگاه مورد نظر ارتباط برقرار می کند. آنها با هم عملکردهایی مانند بازیابی از خرابی فرآیند آزمایش را ارائه می دهند. مثال های زیر نحوه استفاده از خط فرمان Test Executor را نشان می دهد (برای جزئیات بیشتر از --help استفاده کنید):

مثال 1: تست های عملکردی GLES2 را روی دستگاه اندرویدی اجرا کنید

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

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

حالت اسناد جداگانه، که در آن هر آزمون و سند خلاصه caselist.xml در فهرست مقصد نوشته می‌شوند
حالت یک فایل، که در آن تمام نتایج در فایل .qpa در یک سند XML نوشته می شود.

فایل های گزارش آزمایشی صادر شده را می توان با استفاده از یک شیوه نامه XML در مرورگر مشاهده کرد. نمونه اسناد شیوه نامه ( testlog.xsl و testlog.css ) در فهرست راهنمای doc/testlog-stylesheet ارائه شده است. برای ارائه فایل‌های گزارش در مرورگر، دو فایل شیوه نامه را در همان فهرستی که اسناد XML صادر شده در آن قرار دارند، کپی کنید.

اگر از Google Chrome استفاده می کنید، فایل ها باید از طریق HTTP قابل دسترسی باشند زیرا Chrome دسترسی به فایل های محلی را به دلایل امنیتی محدود می کند. نصب استاندارد پایتون شامل یک سرور اصلی HTTP است که می تواند برای سرویس دهی به دایرکتوری فعلی با دستور python –m SimpleHTTPServer 8000 راه اندازی شود. پس از راه اندازی سرور، کافی است مرورگر کروم را روی http://localhost:8000 قرار دهید تا گزارش تست را مشاهده کنید.

تبدیل به لاگ تست JUnit

بسیاری از سیستم های اتوماسیون تست می توانند گزارش های نتیجه آزمایش را از خروجی JUnit تولید کنند. فایل های لاگ تست deqp را می توان با استفاده از ابزار testlog-to-junit به فرمت خروجی JUnit تبدیل کرد.

این ابزار در حال حاضر فقط از ترجمه حکم مورد آزمایشی پشتیبانی می کند. از آنجایی که JUnit فقط از نتایج «pass» و «fail» پشتیبانی می‌کند، یک نتیجه عبوری از deqp به «JUnit pass» نگاشت می‌شود و سایر نتایج به عنوان شکست در نظر گرفته می‌شوند. کد اصلی نتیجه deqp در خروجی JUnit موجود است. سایر داده‌ها، مانند پیام‌های گزارش و تصاویر نتیجه، در تبدیل حفظ نمی‌شوند.

از گروه های آزمایشی ویژه استفاده کنید

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

تست استرس تخصیص حافظه

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

در پلتفرم‌های خاصی، مانند اندروید و اکثر انواع لینوکس، موارد زیر ممکن است رخ دهد: سیستم عامل ممکن است فرآیند تست را به جای اینکه به راننده اجازه دهد خطای خارج از حافظه را مدیریت کند یا در غیر این صورت ارائه دهد، روند آزمایش را از بین ببرد. در چنین پلتفرم هایی، تست هایی که برای ایجاد خطاهای خارج از حافظه طراحی شده اند به طور پیش فرض غیرفعال هستند و باید با استفاده از آرگومان خط فرمان --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.*