drawElements গুণমান প্রোগ্রাম পরীক্ষা

AOSP-এর মধ্যে রয়েছে drawElements কোয়ালিটি প্রোগ্রাম (deqp) GPU টেস্টিং স্যুট https://android.googlesource.com/platform/external/deqp । এই পৃষ্ঠাটি একটি নতুন পরিবেশে deqp পরীক্ষা স্যুট স্থাপনের বিবরণ।

সর্বশেষ জমা দেওয়া কোডের সাথে কাজ করতে, deqp-dev শাখা ব্যবহার করুন। একটি নির্দিষ্ট অ্যান্ড্রয়েড সিটিএস রিলিজের সাথে মেলে এমন কোডের জন্য, release-code-name -release শাখা ব্যবহার করুন (যেমন অ্যান্ড্রয়েড 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

বাহ্যিক libs libpng এবং zlib-এর জন্য stub ডিরেক্টরি তৈরি করুন

ওপেন সোর্স উপাদান

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 দ্বারা জেনারেট করা যেকোনো ফাইল মুছে ফেলা অবশ্যই ম্যানুয়ালি করতে হবে।

-D OPTION_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

প্ল্যাটফর্ম পোর্ট উত্স তালিকা. ডিফল্ট উত্সগুলি ক্ষমতা এবং OS এর উপর ভিত্তি করে নির্ধারিত হয়।

দ্রষ্টব্য: পাথগুলি এর সাথে আপেক্ষিক: framework/platform

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

Win32 বিল্ড

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

ভিজ্যুয়াল স্টুডিও প্রকল্প ফাইল নিম্নলিখিত কমান্ড দিয়ে তৈরি করা যেতে পারে:

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

বিল্ড জেনারেটর হিসাবে "ভিজ্যুয়াল স্টুডিও VERSION Win64" নির্বাচন করে একটি 64-বিট বিল্ড তৈরি করা যেতে পারে:

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

আপনি -G "NMake Makefiles" বিকল্পের পাশাপাশি বিল্ড টাইপ ( -DCMAKE_BUILD_TYPE="Debug" বা "Release" ) দিয়ে NMake makefiles তৈরি করতে পারেন।

রেন্ডার প্রসঙ্গ সৃষ্টি

রেন্ডারিং প্রসঙ্গ WGL দিয়ে বা Windows এ EGL দিয়ে তৈরি করা যেতে পারে।

WGL সমর্থন

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

EGL সমর্থন

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

অ্যান্ড্রয়েড বিল্ড

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

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

  • Android NDK এর সর্বশেষ সংস্করণ; android/scripts/common.py ফাইলটি প্রয়োজনীয় সংস্করণের তালিকা করে
  • এপিআই 13, SDK টুলস, SDK প্ল্যাটফর্ম-টুলস, এবং SDK বিল্ড-টুল প্যাকেজ ইনস্টল করা সহ Android স্ট্যান্ড-অ্যালোন SDK
  • Apache Ant 1.9.4 (জাভা কোড বিল্ড দ্বারা প্রয়োজনীয়)
  • CMake 2.8.12 বা নতুন
  • Python 2.6 বা 2.x সিরিজের নতুন; Python 3.x সমর্থিত নয়
  • উইন্ডোজের জন্য: PATH এ হয় NMake বা JOM
    • JOM দ্রুত বিল্ড সক্ষম করে
  • ঐচ্ছিক: নিনজা মেক লিনাক্সেও সমর্থিত

পিঁপড়া এবং 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 ADB এর মাধ্যমে ডিভাইসে launch.py ​​স্ক্রিপ্ট সহ চালু করা হয়। স্ক্রিপ্টগুলি যে কোনও ডিরেক্টরি থেকে কার্যকর করা যেতে পারে।

লিনাক্স বিল্ড

CMake ব্যবহার করে মেকফাইল তৈরি করে লিনাক্সের জন্য টেস্ট বাইনারি এবং কমান্ড লাইন ইউটিলিটি তৈরি করা যেতে পারে। একাধিক, প্রাক-সংজ্ঞায়িত বিল্ড টার্গেট রয়েছে যা লিনাক্সের জন্য তৈরি করার সময় দরকারী।

লক্ষ্য তৈরি করুন বর্ণনা
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 কমান্ড লাইন আর্গুমেন্টগুলি কম্পাইলারকে অতিরিক্ত আর্গুমেন্ট পাস করতে ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ 32-বিট বা 64-বিট বিল্ড যথাক্রমে -DCMAKE_C(XX)_FLAGS="-m32" বা "-m64" সেট করে করা যেতে পারে। নির্দিষ্ট না থাকলে, টুলচেন নেটিভ আর্কিটেকচার, সাধারণত 64-বিট টুলচেইনে 64-বিট ব্যবহার করা হয়।

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

একটি কাস্টম অবস্থানে ড্রাইভার হেডার এবং লাইব্রেরির বিরুদ্ধে 32-বিট ডিবাগ বিল্ড করতে ব্যবহৃত একটি সম্পূর্ণ কমান্ড লাইনের একটি উদাহরণ নিম্নরূপ:

cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32"
-DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_LIBRARY_PATH="PATH_TO_DRIVER/lib"
-DCMAKE_INCLUDE_PATH="PATH_TO_DRIVER/inc"
make -j4

ক্রস-কম্পাইলিং

একটি CMake টুলচেন ফাইল ব্যবহার করে ক্রস-কম্পাইলিং অর্জন করা যেতে পারে। টুলচেইন ফাইলটি লাইব্রেরি এবং হেডারের জন্য কাস্টম অনুসন্ধান পাথ সহ ব্যবহার করার জন্য কম্পাইলারকে নির্দিষ্ট করে। সাধারণ পরিস্থিতির জন্য বেশ কিছু টুলচেন ফাইল framework/delibs/cmake ডিরেক্টরির রিলিজ প্যাকেজে অন্তর্ভুক্ত করা হয়েছে।

স্ট্যান্ডার্ড CMake ভেরিয়েবল ছাড়াও, নিম্নলিখিত deqp-নির্দিষ্ট ভেরিয়েবল টুলচেইন ফাইল দ্বারা সেট করা যেতে পারে। CMake সাধারণত DE_OS , DE_COMPILER এবং DE_PTR_SIZE সঠিকভাবে সনাক্ত করতে পারে তবে DE_CPU অবশ্যই টুলচেন ফাইল দ্বারা সেট করা উচিত।

পরিবর্তনশীল বর্ণনা
DE_OS

অপারেটিং সিস্টেম। সমর্থিত মানগুলি হল: DE_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৷

টুলচেন ফাইলটি 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 লাইব্রেরির রানটাইম লিঙ্কিং

লিঙ্ক করার সময় পরীক্ষার অধীনে API-এর এন্ট্রি পয়েন্টের প্রয়োজন নেই deqp-এর। পরীক্ষার কোড সবসময় ফাংশন পয়েন্টার মাধ্যমে APIs অ্যাক্সেস করে. এন্ট্রি পয়েন্টগুলি রান টাইমে গতিশীলভাবে লোড করা যেতে পারে বা প্ল্যাটফর্ম পোর্ট লিঙ্কের সময় সেগুলি সরবরাহ করতে পারে।

যদি বিল্ড সেটিংসে একটি 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 এবং স্ট্যান্ডার্ড সি লাইব্রেরির উপর ভিত্তি করে।

framework/platform

টেস্ট ফ্রেমওয়ার্ক প্ল্যাটফর্ম পোর্টে বর্ণিত নতুন প্ল্যাটফর্ম পোর্ট এবং অ্যাপ্লিকেশন স্টাব প্রয়োগ করা যেতে পারে।

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

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

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

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

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

  • --port=<port> টিসিপি পোর্ট সেট করবে যা সার্ভার শোনে। ডিফল্ট হল 50016।
  • --single ক্লায়েন্ট সংযোগ বিচ্ছিন্ন হলে সার্ভার প্রক্রিয়াটি বন্ধ করবে। ডিফল্টরূপে, সার্ভার প্রক্রিয়া আরও পরীক্ষা সম্পাদনের অনুরোধগুলি পরিবেশন করতে থাকবে।

পরীক্ষা চালান

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

লিনাক্স এবং উইন্ডোজ পরিবেশ

লক্ষ্যে নিম্নলিখিত ফাইল এবং ডিরেক্টরি অনুলিপি করে শুরু করুন।

মডিউল ডিরেক্টরি টার্গেট
এক্সিকিউশন সার্ভার build/execserver/execserver <dst>/execserver
ইজিএল মডিউল 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 কনফিগারেশন আইডির জন্য পরীক্ষা চালান। ব্যাখ্যা প্ল্যাটফর্ম-নির্ভর। ইজিএল প্ল্যাটফর্মে, এটি ইজিএল কনফিগারেশন আইডি।
--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 ফাইলে একটি পৃথক লাইনে প্রতিটি পরীক্ষার পুরো নাম তালিকাভুক্ত করা। পরীক্ষার সেট বাড়ার সাথে সাথে পুনরাবৃত্তিমূলক উপসর্গগুলি কষ্টকর হতে পারে। উপসর্গগুলির পুনরাবৃত্তি এড়াতে, নীচে দেখানো একটি ট্রি (একটি উপসর্গ গাছ হিসাবেও পরিচিত) সিনট্যাক্স ব্যবহার করুন।

{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 বা উচ্চতর প্রয়োজন)।

অ্যাপ্লিকেশন প্যাকেজটি নিম্নলিখিত কমান্ড দিয়ে ইনস্টল করা যেতে পারে (নামটি 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 উদ্দেশ্য তৈরি করুন যা android.app.NativeActivity কে লক্ষ্য করে। কার্যক্রম com.drawelements.deqp প্যাকেজে পাওয়া যাবে। কমান্ড লাইনটি অবশ্যই ইন্টেন্টে "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"'

অ্যান্ড্রয়েডে ডিবাগ করুন

অ্যান্ড্রয়েডে জিডিবি ডিবাগারের অধীনে পরীক্ষা চালানোর জন্য, প্রথমে নিম্নলিখিত দুটি স্ক্রিপ্ট চালিয়ে ডিবাগ বিল্ড কম্পাইল এবং ইনস্টল করুন:

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 কমান্ড লাইন প্যারামিটারের মাধ্যমে আরও লাইব্রেরি যোগ করুন। এই স্ক্রিপ্টটি স্ক্রিপ্ট ফাইলের 132 লাইন থেকে শুরু করে GDB-এর জন্য একটি কনফিগারেশন ফাইল তৈরি করে। আপনি বাইনারি, ইত্যাদি অতিরিক্ত পাথ প্রদান করতে পারেন, কিন্তু সঠিক কমান্ড লাইন পরামিতি সরবরাহ করা যথেষ্ট হওয়া উচিত।

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

দ্রষ্টব্য: নেটিভ কোড ডিবাগিং স্টক অ্যান্ড্রয়েড 4.3 এ কাজ করে না; সমাধানের জন্য, এই সর্বজনীন বাগ পড়ুন। অ্যান্ড্রয়েড 4.4 এবং উচ্চতর এই বাগ ধারণ করে না.

পরীক্ষা স্বয়ংক্রিয়

Deqp পরীক্ষা মডিউলগুলি একাধিক উপায়ে স্বয়ংক্রিয় পরীক্ষা সিস্টেমে একত্রিত করা যেতে পারে। সর্বোত্তম পদ্ধতি বিদ্যমান পরীক্ষার পরিকাঠামো এবং লক্ষ্য পরিবেশের উপর নির্ভর করে।

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

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

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

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

বর্তমান কমান্ড লাইন টুল সেটটিতে একটি দূরবর্তী পরীক্ষা কার্যকর করার সরঞ্জাম, রিগ্রেশন বিশ্লেষণের জন্য একটি পরীক্ষা লগ তুলনা জেনারেটর, একটি পরীক্ষা-লগ-টু-সিএসভি রূপান্তরকারী, একটি পরীক্ষা-লগ-টু-এক্সএমএল রূপান্তরকারী এবং একটি টেস্টলগ-টু-জুনিট রূপান্তরকারী অন্তর্ভুক্ত রয়েছে। .

এই টুলগুলির সোর্স কোডটি executor ডিরেক্টরিতে থাকে এবং বাইনারিগুলি <builddir>/executor ডিরেক্টরিতে তৈরি করা হয়।

কমান্ড লাইন পরীক্ষা নির্বাহক

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

উদাহরণ 1: একটি 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"
উদাহরণ 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 রপ্তানি এবং তুলনা

পরীক্ষা লগ (. qpa ফাইল) CSV ফাইলে রূপান্তর করার জন্য deqp-এর একটি টুল রয়েছে। 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 পরীক্ষার ফলাফলের কোড আউটপুট করে, যেমন "পাস" বা "ফেল"। যুক্তি --value=details একটি কর্মক্ষমতা, ক্ষমতা, বা নির্ভুলতা পরীক্ষা দ্বারা উত্পাদিত ফলাফল বা সংখ্যাসূচক মানের আরও ব্যাখ্যা নির্বাচন করে।

পরীক্ষা লগ এক্সএমএল রপ্তানি

টেস্ট লগ ফাইলগুলি testlog-to-xml ইউটিলিটি ব্যবহার করে বৈধ XML নথিতে রূপান্তর করা যেতে পারে। দুটি আউটপুট মোড সমর্থিত:

  • পৃথক নথি মোড, যেখানে প্রতিটি পরীক্ষার কেস এবং caselist.xml সারাংশ নথি একটি গন্তব্য ডিরেক্টরিতে লেখা হয়
  • একক ফাইল মোড, যেখানে .qpa ফাইলের সমস্ত ফলাফল একক 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 শুধুমাত্র "পাস" এবং "ফেল" ফলাফল সমর্থন করে, তাই deqp-এর একটি পাসিং ফলাফলকে "JUnit পাস"-এ ম্যাপ করা হয় এবং অন্যান্য ফলাফলগুলি ব্যর্থ বলে বিবেচিত হয়। মূল 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.*