drawElements কোয়ালিটি প্রোগ্রাম টেস্টিং

AOSP-তে drawElements কোয়ালিটি প্রোগ্রাম (deqp) GPU টেস্টিং স্যুট অন্তর্ভুক্ত আছে, যা 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 স্ক্রিপ্ট ব্যবহার করে অথবা platform/external/[libpng,zlib] থেকে git-এর মাধ্যমে পাওয়া যেতে পারে।

টেস্ট প্রোগ্রাম তৈরি করা

টেস্ট ফ্রেমওয়ার্কটি পোর্টেবিলিটির কথা মাথায় রেখে ডিজাইন করা হয়েছে। একমাত্র আবশ্যকীয় বিষয় হল সম্পূর্ণ C++ সাপোর্ট এবং I/O, থ্রেড ও সকেটের জন্য স্ট্যান্ডার্ড সিস্টেম লাইব্রেরি।

CMake বিল্ড সিস্টেম

deqp সোর্সে CMake-এর জন্য বিল্ড স্ক্রিপ্ট আছে, যা টেস্ট প্রোগ্রাম কম্পাইল করার জন্য পছন্দের টুল।

CMake হল একটি ওপেন সোর্স বিল্ড সিস্টেম যা একাধিক প্ল্যাটফর্ম ও টুলচেন সাপোর্ট করে। CMake, টার্গেট-ইনডিপেন্ডেন্ট কনফিগারেশন ফাইল থেকে নেটিভ মেকফাইল বা IDE প্রোজেক্ট ফাইল জেনারেট করে। CMake সম্পর্কে আরও তথ্যের জন্য, CMake ডকুমেন্টেশন দেখুন।

CMake, সোর্স-ট্রি-এর বাইরে বিল্ড করার সুবিধা দেয় এবং এটি করার জন্য সাজেস্ট করে, অর্থাৎ আপনাকে সবসময় সোর্স-ট্রি-এর বাইরে একটি আলাদা বিল্ড ডিরেক্টরিতে মেকফাইল বা প্রোজেক্ট ফাইল তৈরি করতে হবে। CMake-এ কোনও ধরনের "distclean" টার্গেট নেই, তাই CMake-এর তৈরি করা যেকোনও ফাইল ম্যানুয়ালি সরাতে হবে।

-DOPTION_NAME=VALUE সিনট্যাক্স ব্যবহার করে CMake-এ কনফিগারেশন বিকল্প দেওয়া হয়। deqp-এর জন্য সাধারণত ব্যবহৃত কিছু বিকল্প নিচে তালিকাভুক্ত করা হল।

কনফিগারেশন বিকল্প বর্ণনা
DEQP_TARGET

টার্গেটের নাম, যেমন: "android"

deqp CMake স্ক্রিপ্টে file targets/DEQP_TARGET/DEQP_TARGET.cmake অন্তর্ভুক্ত থাকবে এবং সেখান থেকে টার্গেট-নির্দিষ্ট বিল্ড বিকল্প খুঁজে পাওয়ার আশা করা হবে।
CMAKE_TOOLCHAIN_FILE

CMake-এর জন্য টুলচেন ফাইলের পাথ। ক্রস কম্পাইলেশনের জন্য ব্যবহার করা হয়।
CMAKE_BUILD_TYPE

makefile টার্গেটের জন্য বিল্ডের ধরন। সঠিক ভ্যালু হল: "ডিবাগ" এবং "রিলিজ"

মনে রাখবেন যে ইন্টারপ্রিটেশন এবং ডিফল্ট ধরন টার্গেট করা বিল্ড সিস্টেমের উপর নির্ভর করে। বিবরণের জন্য 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

প্ল্যাটফর্ম পোর্ট সোর্সের তালিকা। ডিফল্ট সোর্স নির্ধারণ করা হয় ক্ষমতা ও OS-এর উপর ভিত্তি করে।

মনে রাখবেন: পাথগুলি এর সাথে সম্পর্কিত: framework/platform

টার্গেট বিল্ড ফাইল include_directories() এবং link_directories() CMake ফাংশন ব্যবহার করে অতিরিক্ত ইনক্লুড বা লিঙ্ক পাথ যোগ করতে পারে।

Win32 বিল্ড

Windows-এর জন্য deqp মডিউল তৈরি করার সবচেয়ে সহজ উপায় হল CMake বিল্ড সিস্টেম ব্যবহার করা। আপনার CMake 2.6.12 বা তার পরবর্তী ভার্সন এবং Microsoft Visual C/C++ কম্পাইলার লাগবে। Visual Studio 2013-এর মাধ্যমে deqp পরীক্ষা করা হয়েছে।

নিম্নলিখিত কমান্ডের সাহায্যে 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"

এছাড়াও, আপনি -G "NMake Makefiles" বিকল্পের পাশাপাশি বিল্ডের ধরন (-DCMAKE_BUILD_TYPE="Debug" বা "Release") সহ NMake makefiles তৈরি করতে পারবেন।

প্রসঙ্গ তৈরি করা রেন্ডার করুন

Windows-এ WGL বা EGL-এর মাধ্যমে রেন্ডারিং কনটেক্সট তৈরি করা যেতে পারে।

WGL সংক্রান্ত সহায়তা

সমস্ত Win32 বাইনারি WGL-এর সাথে GL কনটেক্সট তৈরি করা সমর্থন করে কারণ এর জন্য শুধুমাত্র স্ট্যান্ডার্ড লাইব্রেরি প্রয়োজন। --deqp-gl-context-type=wgl কমান্ড লাইন আর্গুমেন্ট ব্যবহার করে WGL প্রসঙ্গ বেছে নেওয়া যেতে পারে। WGL মোডে, OpenGL ES কন্টেক্সট তৈরি করতে deqp WGL_EXT_create_context_es_profile এক্সটেনশন ব্যবহার করে। এটি NVIDIA এবং Intel-এর লেটেস্ট ড্রাইভারের সাথে কাজ করে বলে পরীক্ষা করে দেখা গেছে। প্রয়োজনীয় এক্সটেনশন AMD ড্রাইভারের সাথে কাজ করে না।

EGL সহায়তা

DEQP_SUPPORT_EGL চালু থাকলে, Windows-এ EGL-এর জন্য ডায়নামিক লোডিং সহ deqp তৈরি করা হয়। বেশিরভাগ টার্গেটে এটি ডিফল্ট হিসেবে সেট করা থাকে। তারপর, হোস্টের কাছে EGL লাইব্রেরি উপলভ্য থাকলে, কমান্ড লাইন প্যারামিটার ব্যবহার করে সেগুলির সাথে পরীক্ষা চালানো সম্ভব: --deqp-gl-context-type=egl

Android বিল্ড

নেটিভ টেস্ট কোড তৈরি করার জন্য Android বিল্ড CMake বিল্ড স্ক্রিপ্ট ব্যবহার করে। Java পার্ট, অর্থাৎ, টেস্ট এক্সিকিউশন সার্ভার এবং টেস্ট অ্যাপ্লিকেশন স্টাব, স্ট্যান্ডার্ড Android বিল্ড টুল ব্যবহার করে কম্পাইল করা হয়।

প্রদান করা বিল্ড স্ক্রিপ্টের সাহায্যে Android-এর জন্য deqp টেস্ট প্রোগ্রাম কম্পাইল করতে, আপনার এগুলি প্রয়োজন হবে:

  • Android NDK-এর লেটেস্ট ভার্সন; android/scripts/common.py ফাইলে প্রয়োজনীয় ভার্সনের তালিকা দেওয়া আছে
  • API 13, SDK টুল, SDK প্ল্যাটফর্ম-টুল এবং SDK বিল্ড-টুল প্যাকেজ সহ Android স্ট্যান্ড-অ্যালোন SDK ইনস্টল করা আছে
  • Apache Ant 1.9.4 (Java কোড বিল্ডের জন্য প্রয়োজন)
  • CMake 2.8.12 বা এর পরের যেকোনও ভার্সন
  • 2.x সিরিজে Python 2.6 বা এর পরের যেকোনও ভার্সন; Python 3.x কাজ করে না
  • Windows-এর জন্য: NMake অথবা JOM in 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 স্ক্রিপ্ট এক্সিকিউট করে তৈরি করা হয়। ফাইনাল Android প্যাকেজ কিট (APK) android/package/bin-এ তৈরি করা হয় এবং install.py স্ক্রিপ্টের মাধ্যমে ইনস্টল করা যায়। কমান্ড লাইন এক্সিকিউটর ব্যবহার করা হলে, ADB-এর মাধ্যমে ডিভাইসে launch.py স্ক্রিপ্ট সহ ExecService লঞ্চ করা হয়। স্ক্রিপ্ট যেকোনও ডিরেক্টরি থেকে এক্সিকিউট করা যেতে পারে।

Linux বিল্ড

CMake ব্যবহার করে মেকফাইল তৈরি করার মাধ্যমে Linux-এর জন্য টেস্ট বাইনারি ও কমান্ড লাইন ইউটিলিটি তৈরি করা যেতে পারে। Linux-এর জন্য বিল্ড করার সময় একাধিক আগে থেকে সংজ্ঞায়িত বিল্ড টার্গেট কাজে লাগে।

বিল্ড টার্গেট বর্ণনা
default

ডিফল্ট টার্গেট যা বিভিন্ন API-এর জন্য সহায়তা নির্ধারণ করতে CMake প্ল্যাটফর্ম ইন্ট্রোস্পেকশন ব্যবহার করে।
x11_glx

OpenGL (ES) কন্টেক্সট তৈরি করতে GLX ব্যবহার করে।
x11_egl

OpenGL (ES) কন্টেক্সট তৈরি করতে EGL ব্যবহার করে।
x11_egl_glx

X11-এর সাথে GLX ও EGL, দু'টিই কাজ করে।

বিল্ডের ধরন নির্ধারণ করতে সবসময় -DCMAKE_BUILD_TYPE=<Debug|Release> ব্যবহার করুন। Release হল একটি ভালো ডিফল্ট। এটি না থাকলে, ডিফল্ট, অপ্টিমাইজ না করা রিলিজ বিল্ড তৈরি করা হয়।

-DCMAKE_C_FLAGS এবং -DCMAKE_CXX_FLAGS কমান্ড লাইন আর্গুমেন্টগুলি কম্পাইলারকে অতিরিক্ত আর্গুমেন্ট পাস করার জন্য ব্যবহার করা যেতে পারে। যেমন, -DCMAKE_C(XX)_FLAGS="-m32" বা "-m64" সেট করে যথাক্রমে ৩২-বিট বা ৬৪-বিট বিল্ড করা যেতে পারে। উল্লেখ করা না থাকলে, টুলচেন নেটিভ আর্কিটেকচার, সাধারণত ৬৪-বিট টুলচেনে ৬৪-বিট ব্যবহার করা হয়।

CMake-কে অতিরিক্ত লাইব্রেরি বা অন্তর্ভুক্ত সার্চ পাথ দেওয়ার জন্য -DCMAKE_LIBRARY_PATH ও -DCMAKE_INCLUDE_PATH আর্গুমেন্ট ব্যবহার করা যেতে পারে।

কাস্টম লোকেশনে ড্রাইভার হেডার ও লাইব্রেরির বিরুদ্ধে ৩২-বিট ডিবাগ বিল্ড করার জন্য ব্যবহৃত সম্পূর্ণ কমান্ড লাইনের একটি উদাহরণ হল:

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 বিল্ড প্যারামিটার ব্যবহার করে টুলচেন ফাইল বেছে নেওয়া যেতে পারে। যেমন, নিম্নলিখিত কমান্ডটি ARM/Linux-এর জন্য CodeSourcery ক্রস-কম্পাইলার ব্যবহার করে বিল্ডের জন্য মেকফাইল তৈরি করবে:

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

OS-নির্দিষ্ট কোডের প্রয়োজনীয় প্রয়োগ।
framework/qphelper/qpCrashHandler.c

ঐচ্ছিক: আপনার OS-এর জন্য প্রয়োগ।
framework/qphelper/qpWatchDog.c

আপনার OS-এর জন্য প্রয়োগ। বর্তমানটি dethread এবং স্ট্যান্ডার্ড C লাইব্রেরির উপর ভিত্তি করে তৈরি।
framework/platform

টেস্ট ফ্রেমওয়ার্ক প্ল্যাটফর্ম পোর্ট লিঙ্কে যেভাবে বর্ণনা করা হয়েছে সেইভাবে নতুন প্ল্যাটফর্ম পোর্ট ও অ্যাপ্লিকেশন স্টাব প্রয়োগ করা যেতে পারে।

বেস পোর্টেবিলিটি লাইব্রেরি

বেস পোর্টেবিলিটি লাইব্রেরি আগে থেকেই Windows, বেশিরভাগ Linux ভেরিয়েন্ট, Mac OS, iOS ও Android-এ কাজ করে। যদি টেস্ট টার্গেট সেইসব অপারেটিং সিস্টেমের কোনও একটিতে রান করে, তাহলে সম্ভবত বেস পোর্টেবিলিটি লাইব্রেরি স্পর্শ করার কোনও প্রয়োজন নেই।

টেস্ট ফ্রেমওয়ার্ক প্ল্যাটফর্ম পোর্ট

deqp টেস্ট ফ্রেমওয়ার্ক প্ল্যাটফর্ম পোর্টের জন্য দুটি কম্পোনেন্ট প্রয়োজন: একটি অ্যাপ্লিকেশন এন্ট্রি পয়েন্ট এবং একটি প্ল্যাটফর্ম ইন্টারফেস ইমপ্লিমেন্টেশন।

অ্যাপ্লিকেশন এন্ট্রি পয়েন্ট প্ল্যাটফর্ম অবজেক্ট তৈরি করা, কমান্ড লাইন (tcu::CommandLine) অবজেক্ট তৈরি করা, টেস্ট লগ খোলা (tcu::TestLog) এবং টেস্ট অ্যাপ্লিকেশন (tcu::App) ইটারেট করার জন্য দায়ী। টার্গেট OS স্ট্যান্ডার্ড main() এন্ট্রি পয়েন্ট সাপোর্ট করলে, এন্ট্রি পয়েন্ট ইমপ্লিমেন্টেশন হিসেবে tcuMain.cpp ব্যবহার করা যেতে পারে।

নিম্নলিখিত ফাইলগুলিতে deqp প্ল্যাটফর্ম API-এর বিবরণ বিস্তারিতভাবে দেওয়া আছে।

ফাইল বর্ণনা
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 টেস্ট এক্সিকিউশন ইনফ্রাস্ট্রাকচার বা কমান্ড লাইন এক্সিকিউটর ব্যবহার করতে হলে, টার্গেটে টেস্ট এক্সিকিউশন পরিষেবা উপলভ্য থাকতে হবে। execserver ডিরেক্টরিতে পরিষেবার একটি পোর্টেবল C++ ইমপ্লিমেন্টেশন প্রদান করা হয়েছে। স্ট্যান্ড-অলোন বাইনারি deqp টেস্ট মডিউলের অংশ হিসেবে তৈরি করা হয় যা পিসি (PC) টার্গেটের জন্য তৈরি করা হয়। অন্যান্য টার্গেটে বিল্ড চালু করতে আপনি execserver/CMakeLists.txt পরিবর্তন করতে পারেন।

টেস্ট এক্সিকিউশন পরিষেবার C++ ভার্সন দুটি কমান্ড লাইন প্যারামিটার গ্রহণ করে:

  • --port=<port> সার্ভার যে TCP পোর্টে শুনবে সেটি সেট করবে। ডিফল্ট হল ৫০০০১৬।
  • ক্লায়েন্ট ডিসকানেক্ট হয়ে গেলে --single সার্ভার প্রসেস বন্ধ করে দেবে। ডিফল্ট হিসেবে, আরও টেস্ট এক্সিকিউশন অনুরোধ পরিবেশন করার জন্য সার্ভার প্রসেস চালু থাকবে।

টেস্টগুলি চালান

এই পৃষ্ঠায় কমান্ড লাইন আর্গুমেন্ট ব্যবহার করে এবং Android অ্যাপ্লিকেশন প্যাকেজের সাথে কাজ করে, Linux এবং Windows এনভায়রনমেন্টে deqp টেস্ট চালানোর নির্দেশাবলী দেওয়া আছে।

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 বা তার পরবর্তী যেকোনও ভার্সন প্রয়োজন)।

নিম্নলিখিত কমান্ডের সাহায্যে অ্যাপ্লিকেশন প্যাকেজ ইনস্টল করা যেতে পারে (নাম দেখানো হল Android CTS প্যাকেজে APK-এর নাম; কোন নাম ব্যবহার করা হবে তা বিল্ডের উপর নির্ভর করে):

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-এ টেস্ট চালান

টেস্ট এক্সিকিউশন অ্যাক্টিভিটি ম্যানুয়ালি শুরু করতে, android.app.NativeActivity-কে টার্গেট করে এমন একটি Android ইনটেন্ট তৈরি করুন। com.drawelements.deqp প্যাকেজে অ্যাক্টিভিটি খুঁজে পাওয়া যাবে। কমান্ড লাইনকে অবশ্যই Intent-এ "cmdLine" কী সহ অতিরিক্ত স্ট্রিং হিসেবে সাপ্লাই করতে হবে।

/sdcard/dEQP-log.qpa-এ একটি টেস্ট লগ লেখা হয়। টেস্ট রান স্বাভাবিকভাবে শুরু না হলে, ডিভাইসের লগে অতিরিক্ত ডিবাগ তথ্য উপলভ্য থাকে।

আপনি কমান্ড লাইন থেকে am ইউটিলিটি ব্যবহার করে অ্যাক্টিভিটি লঞ্চ করতে পারবেন। যেমন, NativeActivity, কাজ করে এমন প্ল্যাটফর্মে dEQP-GLES2.info পরীক্ষা চালাতে, নিম্নলিখিত কমান্ড ব্যবহার করুন।

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-এ ডিবাগ করা

Android-এ GNU ডিবাগার (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-এর জন্য একটি কনফিগারেশন ফাইল লেখে। আপনি বাইনারির জন্য অতিরিক্ত পাথ দিতে পারেন, তবে সঠিক কমান্ড লাইন প্যারামিটার দিলে তা যথেষ্ট হবে।

মনে রাখবেন: Windows-এ, GDB বাইনারির জন্য libpython2.7.dll প্রয়োজন। debug.py লঞ্চ করার আগে, PATH ভেরিয়েবলে <path-to-ndk>/prebuilt/windows/bin যোগ করুন।

মনে রাখবেন: নেটিভ কোড ডিবাগিং স্টক Android 4.3-এ কাজ করে না; এর বিকল্প সমাধান পেতে, এই পাবলিক বাগ দেখুন। Android 4.4 ও তার পরবর্তী যেকোনও ভার্সনে এই সমস্যা নেই।

টেস্ট অটোমেট করা

Deqp টেস্ট মডিউলকে একাধিক উপায়ে অটোমেটেড টেস্ট সিস্টেমে ইন্টিগ্রেট করা যায়। সবচেয়ে ভালো পদ্ধতিটি নির্ভর করে আগে থেকে থাকা টেস্ট ইনফ্রাস্ট্রাকচার ও টার্গেট এনভায়রনমেন্টের উপর।

টেস্ট রান থেকে পাওয়া প্রাথমিক আউটপুট হল সবসময় টেস্ট লগ ফাইল, অর্থাৎ, .qpa পোস্টফিক্স সহ ফাইল। টেস্ট লগ থেকে সম্পূর্ণ টেস্ট ফলাফল পার্স করা যেতে পারে। কনসোল আউটপুট হল শুধুমাত্র ডিবাগ সংক্রান্ত তথ্য এবং এটি সব প্ল্যাটফর্মে উপলভ্য নাও থাকতে পারে।

টেস্ট অটোমেশন সিস্টেম থেকে সরাসরি টেস্ট বাইনারি ইনভোক করা যেতে পারে। টেস্ট বাইনারি নির্দিষ্ট কেস, টেস্ট সেট বা উপলভ্য সব টেস্টের জন্য লঞ্চ করা যেতে পারে। এক্সিকিউশন চলাকালীন কোনও মারাত্মক সমস্যা হলে (যেমন, নির্দিষ্ট API সমস্যা বা ক্র্যাশ), টেস্ট এক্সিকিউশন বাতিল হয়ে যাবে। রিগ্রেশন টেস্টিংয়ের জন্য, সবচেয়ে ভালো পদ্ধতি হল, হার্ডওয়্যার সংক্রান্ত সমস্যা হলেও যাতে আংশিক ফলাফল পাওয়া যায়, সেই জন্য আলাদা আলাদাভাবে স্বতন্ত্র কেস বা ছোট টেস্ট সেটের জন্য টেস্ট বাইনারি ইনভোক করা।

deqp-এর সাথে কমান্ড লাইন টেস্ট এক্সিকিউশন টুল থাকে যা আরও শক্তিশালী ইন্টিগ্রেশন অর্জন করতে এক্সিকিউশন পরিষেবার সাথে ব্যবহার করা যেতে পারে। এক্সিকিউটর টেস্ট প্রসেস বন্ধ হয়ে যাওয়া শনাক্ত করে এবং পরবর্তী উপলভ্য কেসে টেস্ট এক্সিকিউশন আবার শুরু করবে। সম্পূর্ণ টেস্ট সেশন থেকে একটি লগ ফাইল তৈরি করা হয়। এই সেট-আপটি হালকা ওজনের টেস্ট সিস্টেমের জন্য আদর্শ যা ক্র্যাশ রিকভারি সুবিধা প্রদান করে না।

কমান্ড লাইন টেস্ট এক্সিকিউশন টুল

বর্তমান কমান্ড লাইন টুল সেটে রিমোট টেস্ট এক্সিকিউশন টুল, রিগ্রেশন অ্যানালিসিসের জন্য টেস্ট লগ তুলনা জেনারেটর, টেস্ট-লগ-টু-CSV কনভার্টার, টেস্ট-লগ-টু-XML কনভার্টার এবং টেস্টলগ-টু-JUnit কনভার্টার অন্তর্ভুক্ত।

এইসব টুলের সোর্স কোড executor ডিরেক্টরিতে আছে এবং বাইনারি <builddir>/executor ডিরেক্টরিতে বিল্ট-ইন আছে।

কমান্ড লাইন টেস্ট এক্সিকিউটর

কমান্ড লাইন টেস্ট এক্সিকিউটর হল একটি পোর্টেবল C++ টুল যা কোনও ডিভাইসে টেস্ট রান লঞ্চ করতে এবং TCP/IP-এর মাধ্যমে সেটির থেকে ফলাফল সংক্রান্ত লগ সংগ্রহ করতে ব্যবহার করা হয়। Executor টার্গেট ডিভাইসে এক্সিকিউশন পরিষেবার (execserver) সাথে যোগাযোগ করে। দুটি মিলে টেস্ট প্রসেস ক্র্যাশ থেকে রিকভার করার মতো কার্যকারিতা প্রদান করে। কমান্ড লাইন টেস্ট এক্সিকিউটর কীভাবে ব্যবহার করতে হয় তা নিম্নলিখিত উদাহরণ থেকে বোঝা যায় (আরও বিবরণের জন্য --help ব্যবহার করুন):

উদাহরণ ১: Android ডিভাইসে 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 স্টাইল শিট ব্যবহার করে ব্রাউজারে এক্সপোর্ট করা টেস্ট লগ ফাইল দেখা যেতে পারে। doc/testlog-stylesheet ডিরেক্টরিতে স্যাম্পেল স্টাইল শিট ডকুমেন্ট (testlog.xsl ও testlog.css) দেওয়া আছে। ব্রাউজারে লগ ফাইল রেন্ডার করতে, এক্সপোর্ট করা XML ডকুমেন্ট যেখানে আছে সেই একই ডিরেক্টরিতে দুটি স্টাইল শিট ফাইল কপি করুন।

আপনি Google Chrome ব্যবহার করলে, ফাইলগুলি অবশ্যই HTTP-এর মাধ্যমে অ্যাক্সেস করতে হবে কারণ Chrome নিরাপত্তার কারণে লোকাল ফাইল অ্যাক্সেস সীমিত করে। স্ট্যান্ডার্ড Python ইনস্টলেশনে একটি বেসিক HTTP সার্ভার থাকে যা python –m SimpleHTTPServer 8000 কমান্ডের সাহায্যে বর্তমান ডিরেক্টরি পরিবেশন করার জন্য চালু করা যেতে পারে। সার্ভার চালু করার পরে, টেস্ট লগ দেখতে Chrome ব্রাউজারকে http://localhost:8000-এ পয়েন্ট করুন।

JUnit টেস্ট লগে কনভার্ট করা

অনেক টেস্ট অটোমেশন সিস্টেম JUnit আউটপুট থেকে টেস্ট রান ফলাফল রিপোর্ট তৈরি করতে পারে। testlog-to-junit টুল ব্যবহার করে deqp টেস্ট লগ ফাইল JUnit আউটপুট ফর্ম্যাটে কনভার্ট করা যেতে পারে।

টুলটি বর্তমানে শুধুমাত্র টেস্ট কেসের রায় অনুবাদ করতে পারে। JUnit শুধুমাত্র "সফল" ও "ব্যর্থ" ফলাফল দেখায় বলে, deqp-এর সফল ফলাফলকে "JUnit সফল" হিসেবে ম্যাপ করা হয় এবং অন্যান্য ফলাফলকে ব্যর্থ হিসেবে বিবেচনা করা হয়। JUnit আউটপুটে আসল deqp result কোড উপলভ্য। লগ মেসেজ ও ফলাফল ছবির মতো অন্যান্য ডেটা কনভার্সনে সেভ করা হয় না।

বিশেষ টেস্ট গ্রুপ ব্যবহার করা

কিছু টেস্ট গ্রুপের বিশেষ কমান্ড লাইন বিকল্পের প্রয়োজন হতে পারে বা সেগুলি কাজ করতে পারে অথবা নির্দিষ্ট সিস্টেমে ব্যবহার করার সময় বিশেষ যত্ন নেওয়ার প্রয়োজন হতে পারে।

মেমরি অ্যালোকেশন স্ট্রেস টেস্ট

মেমরি অ্যালোকেশন স্ট্রেস টেস্ট, আউট-অফ-মেমরি ত্রুটি রিপোর্ট না করা পর্যন্ত নির্দিষ্ট রিসোর্স বারবার অ্যালোকেট করে আউট-অফ-মেমরি পরিস্থিতি তৈরি করে।

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.*