DrawElements Quality Test برنامه

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

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

طرح منبع

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

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

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 از ساخت‌های خارج از درخت منبع پشتیبانی و توصیه می‌کند، یعنی شما همیشه باید فایل‌های makefile یا پروژه را در یک دایرکتوری ساخت جداگانه خارج از درخت منبع ایجاد کنید. CMake هیچ نوع هدف "distclean" ندارد، بنابراین حذف هر فایلی که توسط CMake ایجاد می‌شود باید به صورت دستی انجام شود.

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

یک فایل ساخت هدف ایجاد کنید

سیستم ساخت deqp برای اهداف جدید با استفاده از فایل‌های ساخت هدف پیکربندی می‌شود. یک فایل ساخت هدف، ویژگی‌هایی را که پلتفرم پشتیبانی می‌کند و کتابخانه‌ها یا مسیرهای اضافی مورد نیاز را تعریف می‌کند. نام فایل‌های هدف از فرمت targets/ NAME / NAME .cmake پیروی می‌کنند و هدف با استفاده از پارامتر ساخت DEQP_TARGET انتخاب می‌شود.

مسیرهای فایل در فایل‌های هدف نسبت به دایرکتوری deqp پایه هستند، نه دایرکتوری targets/ NAME . متغیرهای استاندارد زیر می‌توانند توسط فایل ساخت هدف تنظیم شوند.

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

ساخت 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" به عنوان تولیدکننده‌ی نسخه، می‌توان یک نسخه ۶۴ بیتی ساخت:

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

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

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

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

ساخت اندروید

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

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

• آخرین نسخه Android NDK ؛ فایل android/scripts/common.py نسخه مورد نیاز را فهرست می‌کند.
• کیت توسعه نرم‌افزار مستقل اندروید (SDK) به همراه API 13، ابزارهای SDK، ابزارهای پلتفرم SDK و ابزارهای ساخت SDK نصب شده
• آپاچی انت ۱.۹.۴ (مورد نیاز برای ساخت کد جاوا)
• سی‌میک ۲.۸.۱۲ یا جدیدتر
• پایتون ۲.۶ یا جدیدتر در سری ۲.x؛ پایتون ۳.x پشتیبانی نمی‌شود
• برای ویندوز: یا NMake یا JOM در PATH
  • JOM امکان ساخت سریع‌تر را فراهم می‌کند
• اختیاری: نینجا میک در لینوکس نیز پشتیبانی می‌شود

فایل‌های باینری 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 می‌توان با تولید فایل‌های ساخت (makefiles) با استفاده از دودویی‌های آزمایشی و ابزارهای خط فرمان، آن‌ها را برای لینوکس ساخت. چندین هدف ساخت از پیش تعریف‌شده وجود دارد که هنگام ساخت برای لینوکس مفید هستند.

همیشه از -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 زیر می‌توانند توسط فایل toolchain تنظیم شوند. CMake معمولاً می‌تواند DE_OS ، DE_COMPILER و DE_PTR_SIZE به درستی تشخیص دهد، اما DE_CPU باید توسط فایل toolchain تنظیم شود.

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

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

پیوند زمان اجرا کتابخانه‌های GLES و EGL

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

اگر پشتیبانی از API در تنظیمات ساخت فعال باشد و کتابخانه‌های پیوند ارائه نشده باشند، deqp نقاط ورودی مورد نیاز را در زمان اجرا بارگذاری می‌کند. اگر پیوند استاتیک مورد نظر باشد، کتابخانه‌های پیوند مورد نیاز را در متغیر پیکربندی ساخت DEQP_<API>_LIBRARIES ارائه دهید.

چارچوب آزمون را منتقل کنید

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

جدول زیر مکان‌هایی را که احتمالاً تغییرات در آن‌ها اعمال می‌شود، فهرست کرده است. هر چیزی فراتر از این مکان‌ها احتمالاً عجیب و غریب خواهد بود.

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

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

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

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

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

API پلتفرم deqp در فایل‌های زیر به تفصیل شرح داده شده است.

کلاس پایه برای همه پورت‌های پلتفرم، tcu::Platform است. پورت پلتفرم می‌تواند به صورت اختیاری از رابط‌های مخصوص GL و EGL پشتیبانی کند. برای مرور کلی آنچه که برای اجرای تست‌ها باید پیاده‌سازی شود، به جدول زیر مراجعه کنید.

دستورالعمل‌های دقیق برای پیاده‌سازی پورت‌های پلتفرم در هدرهای لایه پورتینگ قرار دارند.

سرویس اجرای تست

برای استفاده از زیرساخت اجرای تست deqp یا اجراکننده خط فرمان، سرویس اجرای تست باید روی هدف موجود باشد. یک پیاده‌سازی قابل حمل C++ از این سرویس در دایرکتوری execserver ارائه شده است. فایل باینری مستقل به عنوان بخشی از ماژول تست deqp برای اهداف PC ساخته شده است. می‌توانید execserver/CMakeLists.txt را تغییر دهید تا امکان ساخت روی اهداف دیگر فراهم شود.

نسخه C++ سرویس اجرای تست، دو پارامتر خط فرمان را می‌پذیرد:

• --port=<port> ‎ پورت TCP که سرور به آن گوش می‌دهد را تنظیم می‌کند. مقدار پیش‌فرض ۵۰۰۱۶ است.
• --single فرآیند سرور را هنگام قطع ارتباط کلاینت خاتمه می‌دهد. به طور پیش‌فرض، فرآیند سرور برای ارائه درخواست‌های اجرای آزمایشی بیشتر فعال می‌ماند.

تست‌ها را اجرا کنید

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

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

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

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

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

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

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

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

قالب فهرست موارد آزمون

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

اندروید

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

بسته برنامه را می‌توان با دستور زیر نصب کرد (نام نشان داده شده، نام APK در بسته 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

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

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

برای اجرای تست‌ها تحت GNU Debugger (GDB) در اندروید، ابتدا با اجرای دو اسکریپت زیر، نسخه debug را کامپایل و نصب کنید:

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

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

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

خودکارسازی تست‌ها

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

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

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

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

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

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

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

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

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

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

مثال ۲: ادامه اجرای آزمایشی جزئی 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 واحد نوشته می‌شوند.

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

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

تبدیل به یک گزارش تست JUnit

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

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

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

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

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

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

در پلتفرم‌های خاصی مانند اندروید و اکثر انواع لینوکس، موارد زیر ممکن است رخ دهد: سیستم عامل ممکن است به جای اینکه به یک درایور اجازه دهد تا خطای خارج از حافظه را مدیریت کند یا در غیر این صورت خطایی را ارائه دهد، فرآیند تست را از بین ببرد. در چنین پلتفرم‌هایی، تست‌هایی که برای ایجاد خطاهای خارج از حافظه طراحی شده‌اند، به طور پیش‌فرض غیرفعال هستند و باید با استفاده از آرگومان خط فرمان --deqp-test-oom=enable فعال شوند. توصیه می‌شود چنین تست‌هایی را به صورت دستی اجرا کنید تا بررسی شود که آیا سیستم تحت فشار منابع به درستی رفتار می‌کند یا خیر. با این حال، در چنین شرایطی، خرابی فرآیند تست باید به عنوان یک موفقیت تلقی شود.

گروه‌های آزمایشی

dEQP-GLES2.stress.memory.*
dEQP-GLES3.stress.memory.*

تست‌های استرس رندرینگ طولانی مدت

تست‌های استرس رندرینگ به گونه‌ای طراحی شده‌اند که مشکلات مربوط به پایداری را تحت بار رندرینگ پایدار نشان دهند. به طور پیش‌فرض، تست‌ها فقط چند تکرار اجرا می‌شوند، اما می‌توان آن‌ها را طوری پیکربندی کرد که با ارائه آرگومان خط فرمان --deqp-test-iteration-count=-1 به طور نامحدود اجرا شوند. هنگام اجرای طولانی مدت این تست‌ها، باید test watchdog غیرفعال شود ( --deqp-watchdog=disable ).

گروه‌های آزمایشی

dEQP-GLES2.stress.long.*
dEQP-GLES3.stress.long.*