การทดสอบโปรแกรมคุณภาพของ drawElements

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

AOSP มีชุดทดสอบ GPU ของโปรแกรมคุณภาพของ drawElements (deqp) ที่ https://android.googlesource.com/platform/external/deqp หน้านี้จะอธิบายรายละเอียดวิธีทำให้ชุดทดสอบ deqp ใช้งานได้ในสภาพแวดล้อมใหม่

หากต้องการทำงานกับโค้ดที่ส่งล่าสุด ให้ใช้สาขา deqp-dev สำหรับโค้ดที่ตรงกับรุ่น Android CTS ที่เฉพาะเจาะจง ให้ใช้สาขา release-code-name-release (เช่น สำหรับ Android 6.0 ให้ใช้สาขา marshmallow-release)

เลย์เอาต์แหล่งที่มา

เลย์เอาต์ซอร์สโค้ดสําหรับโมดูลทดสอบ deqp และไลบรารีสนับสนุนแสดงอยู่ในตารางด้านล่าง (รายการนี้ไม่ครอบคลุมทั้งหมด แต่ไฮไลต์ไดเรกทอรีที่สําคัญที่สุด)

คอมโพเนนต์โอเพนซอร์ส

deqp ใช้ libpng และ zlib ซึ่งดึงข้อมูลได้โดยใช้สคริปต์ platform/external/deqp/external/fetch_sources.py หรือผ่าน git จาก platform/external/[libpng,zlib]

สร้างโปรแกรมทดสอบ

เฟรมเวิร์กการทดสอบได้รับการออกแบบโดยคำนึงถึงความสามารถในการเคลื่อนย้ายได้ง่าย ข้อกำหนดที่จําเป็นเพียงอย่างเดียวคือต้องรองรับ C++ อย่างเต็มรูปแบบและไลบรารีระบบมาตรฐานสําหรับ I/O, เทรด และซ็อกเก็ต

ระบบบิลด์ CMake

แหล่งที่มาของ deqp มีสคริปต์การสร้างสำหรับ CMake ซึ่งเป็นเครื่องมือที่แนะนำสำหรับการคอมไพล์โปรแกรมทดสอบ

CMake เป็นระบบการต่อยอดแบบโอเพนซอร์สที่รองรับแพลตฟอร์มและเครื่องมือต่างๆ หลายรายการ CMake จะสร้างไฟล์ make ดั้งเดิมหรือไฟล์โปรเจ็กต์ IDE จากไฟล์การกำหนดค่าที่ไม่ขึ้นอยู่กับเป้าหมาย ดูข้อมูลเพิ่มเติมเกี่ยวกับ CMake ได้ที่เอกสารประกอบของ CMake

CMake รองรับและแนะนำให้ใช้บิลด์นอกสคีมาซอร์สโค้ด กล่าวคือ คุณควรสร้างไฟล์ make หรือไฟล์โปรเจ็กต์ในไดเรกทอรีบิลด์แยกต่างหากเสมอ ซึ่งอยู่นอกสคีมาซอร์สโค้ด CMake ไม่มีเป้าหมาย "distclean" ใดๆ คุณจึงต้องนําไฟล์ที่ CMake สร้างขึ้นออกด้วยตนเอง

ตัวเลือกการกำหนดค่าจะส่งไปยัง CMake โดยใช้ไวยากรณ์ -DOPTION_NAME=VALUE ตัวเลือกที่ใช้กันโดยทั่วไปสำหรับ deqp มีดังนี้

สร้างไฟล์บิลด์เป้าหมาย

ระบบบิลด์ deqp ได้รับการกําหนดค่าสําหรับเป้าหมายใหม่โดยใช้ไฟล์บิลด์เป้าหมาย ไฟล์บิลด์เป้าหมายจะกำหนดฟีเจอร์ที่แพลตฟอร์มรองรับ รวมถึงไลบรารีหรือเส้นทางรวมเพิ่มเติมที่จำเป็น ชื่อไฟล์เป้าหมายต้องเป็นไปตามtargets/NAME/NAME.cmakeรูปแบบ และระบบจะเลือกเป้าหมายโดยใช้พารามิเตอร์บิลด์ DEQP_TARGET

เส้นทางไฟล์ในไฟล์เป้าหมายจะสัมพันธ์กับไดเรกทอรี deqp หลัก ไม่ใช่ไดเรกทอรี targets/NAME ตัวแปรมาตรฐานต่อไปนี้สามารถตั้งค่าได้โดยไฟล์บิลด์เป้าหมาย

ไฟล์บิลด์เป้าหมายสามารถเพิ่มเส้นทางรวมหรือลิงก์เพิ่มเติมได้โดยใช้ฟังก์ชัน CMake include_directories() และ link_directories()

บิลด์ Win32

วิธีที่ง่ายที่สุดในการสร้างโมดูล deqp สำหรับ Windows คือการใช้ระบบการคอมไพล์ CMake คุณจะต้องมี CMake 2.6.12 ขึ้นไปและคอมไพเลอร์ Microsoft Visual C/C++ deqp ได้รับการทดสอบกับ Visual Studio 2013 แล้ว

คุณสร้างไฟล์โปรเจ็กต์ Visual Studio ได้ด้วยคำสั่งต่อไปนี้

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

คุณสร้างบิลด์ 64 บิตได้โดยเลือก "Visual Studio VERSION Win64" เป็นเครื่องมือสร้าง

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

คุณยังสร้างไฟล์ Make ของ NMake ด้วยตัวเลือก -G "NMake Makefiles" และประเภทบิลด์ (-DCMAKE_BUILD_TYPE="Debug" หรือ "Release") ได้ด้วย

การสร้างบริบทการแสดงผล

คุณสร้างบริบทการแสดงภาพได้โดยใช้ WGL หรือ EGL ใน Windows

การรองรับ WGL

ไฟล์ไบนารี Win32 ทั้งหมดรองรับการสร้างบริบท GL ด้วย WGL เนื่องจากต้องใช้เฉพาะไลบรารีมาตรฐาน คุณเลือกบริบท WGL ได้โดยใช้อาร์กิวเมนต์บรรทัดคำสั่ง --deqp-gl-context-type=wgl ในโหมด WGL นั้น deqp จะใช้ส่วนขยาย WGL_EXT_create_context_es_profile เพื่อสร้างบริบท OpenGL ES โปรแกรมนี้ได้รับการทดสอบให้ทำงานร่วมกับไดรเวอร์ล่าสุดจาก NVIDIA และ Intel ไดรเวอร์ AMD ไม่รองรับส่วนขยายที่จําเป็น

การรองรับ EGL

deqp สร้างขึ้นด้วยการโหลดแบบไดนามิกสําหรับ EGL ใน Windows หาก DEQP_SUPPORT_EGL อยู่ในสถานะเปิด ซึ่งเป็นค่าเริ่มต้นในเป้าหมายส่วนใหญ่ จากนั้น หากโฮสต์มีไลบรารี EGL ให้ใช้งาน คุณจะทำการทดสอบกับไลบรารีเหล่านั้นได้โดยใช้พารามิเตอร์บรรทัดคำสั่ง --deqp-gl-context-type=egl

บิลด์ Android

บิลด์ Android ใช้สคริปต์บิลด์ CMake เพื่อสร้างโค้ดทดสอบเนทีฟ ส่วน Java เช่น เซิร์ฟเวอร์การเรียกใช้การทดสอบและ Test Application Stub จะคอมไพล์โดยใช้เครื่องมือสร้าง Android มาตรฐาน

หากต้องการคอมไพล์โปรแกรมทดสอบ deqp สําหรับ Android ด้วยสคริปต์การสร้างที่ให้มา คุณจะต้องมีสิ่งต่อไปนี้

• Android NDK เวอร์ชันล่าสุด ไฟล์ android/scripts/common.py จะแสดงเวอร์ชันที่จําเป็น
• SDK แบบสแตนด์อโลนของ Android ที่มี API 13, SDK Tools, SDK Platform-tools และ SDK packages เครื่องมือสร้าง
• Apache Ant 1.9.4 (จําเป็นสําหรับการสร้างโค้ด Java)
• CMake 2.8.12 ขึ้นไป
• Python 2.6 ขึ้นไปในซีรีส์ 2.x ไม่รองรับ Python 3.x
• สําหรับ Windows: NMake หรือ JOM ใน PATH
  • JOM ช่วยให้คุณสร้างได้เร็วขึ้น
• ไม่บังคับ: Linux รองรับ 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 สคริปต์จะเรียกใช้ได้จากไดเรกทอรีใดก็ได้

บิลด์ Linux

คุณสร้างไฟล์ไบนารีทดสอบและยูทิลิตีบรรทัดคำสั่งสำหรับ Linux ได้โดยการสร้างไฟล์ Make โดยใช้ CMake มีเป้าหมายการสร้างที่กําหนดไว้ล่วงหน้าหลายรายการที่มีประโยชน์เมื่อสร้างสําหรับ Linux

ใช้ -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 เพิ่มไลบรารีหรือรวมเส้นทางการค้นหา

ตัวอย่างบรรทัดคำสั่งแบบเต็มที่ใช้สร้างการแก้ไขข้อบกพร่องแบบ 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 โดยไฟล์ toolchain

คุณเลือกไฟล์เครื่องมือได้โดยใช้พารามิเตอร์บิลด์ CMAKE_TOOLCHAIN_FILE ตัวอย่างเช่น คำสั่งต่อไปนี้จะสร้างไฟล์ make สำหรับบิลด์โดยใช้คอมไพเลอร์ข้ามแพลตฟอร์ม CodeSourcery สำหรับ ARM/Linux

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

การลิงก์รันไทม์ของไลบรารี GLES และ EGL

deqp ไม่จำเป็นต้องมีจุดแรกเข้าของ API ที่กำลังทดสอบระหว่างการลิงก์ โค้ดทดสอบจะเข้าถึง API ผ่านตัวชี้ฟังก์ชันเสมอ จากนั้นระบบจะโหลดจุดแรกเข้าแบบไดนามิกเมื่อรันไทม์ หรือพอร์ตแพลตฟอร์มจะระบุจุดแรกเข้าได้เมื่อลิงก์

หากเปิดการรองรับ API ในการตั้งค่าบิลด์และไม่ได้ระบุไลบรารีลิงก์ไว้ deqp จะโหลดจุดแรกเข้าที่จำเป็นเมื่อรันไทม์ หากต้องการใช้การลิงก์แบบคงที่ ให้ระบุไลบรารีลิงก์ที่จำเป็นในตัวแปรการกำหนดค่าบิลด์ DEQP_<API>_LIBRARIES

พอร์ตเฟรมเวิร์กทดสอบ

การพอร์ต deqp ประกอบด้วย 3 ขั้นตอน ได้แก่ การปรับเปลี่ยนไลบรารีการย้ายข้อมูลพื้นฐาน การใช้อินเทอร์เฟซการผสานรวมแพลตฟอร์มเฟรมเวิร์กทดสอบ และการพอร์ตบริการการดําเนินการ

ตารางด้านล่างแสดงตำแหน่งที่อาจมีการเปลี่ยนแปลงการพอร์ต นอกเหนือจากนั้น อาจเป็นคำที่แปลกใหม่

ไลบรารีการย้ายข้อมูลพื้นฐาน

ไลบรารีการย้ายข้อมูลพื้นฐานรองรับ Windows, Linux ส่วนใหญ่, Mac OS, iOS และ Android อยู่แล้ว หากเป้าหมายการทดสอบทำงานบนระบบปฏิบัติการใดระบบปฏิบัติการหนึ่งดังกล่าว ก็อาจไม่จำเป็นต้องแตะต้องไลบรารีการย้ายข้อมูลพื้นฐานเลย

พอร์ตแพลตฟอร์มเฟรมเวิร์กทดสอบ

พอร์ตแพลตฟอร์มเฟรมเวิร์กทดสอบ deqp ต้องใช้คอมโพเนนต์ 2 อย่าง ได้แก่ จุดแรกเข้าของแอปพลิเคชันและการใช้งานอินเทอร์เฟซแพลตฟอร์ม

จุดแรกเข้าของแอปพลิเคชันมีหน้าที่สร้างออบเจ็กต์แพลตฟอร์ม สร้างออบเจ็กต์บรรทัดคำสั่ง (tcu::CommandLine) เปิดบันทึกการทดสอบ (tcu::TestLog) และเรียกใช้แอปพลิเคชันทดสอบซ้ำ (tcu::App) หากระบบปฏิบัติการเป้าหมายรองรับจุดแรกเข้า main() มาตรฐาน คุณจะใช้ tcuMain.cpp เป็นการใช้งานจุดแรกเข้าได้

โปรดดูรายละเอียด API ของแพลตฟอร์ม deqp ในไฟล์ต่อไปนี้

คลาสพื้นฐานสำหรับพอร์ตแพลตฟอร์มทั้งหมดคือ tcu::Platform พอร์ตแพลตฟอร์มอาจรองรับอินเทอร์เฟซเฉพาะ GL และ EGL ดูภาพรวมของสิ่งที่ต้องติดตั้งใช้งานเพื่อทำการทดสอบได้ในตารางต่อไปนี้

วิธีการโดยละเอียดในการใช้พอร์ตแพลตฟอร์มอยู่ในส่วนหัวของเลเยอร์การพอร์ต

บริการการดำเนินการทดสอบ

หากต้องการใช้โครงสร้างพื้นฐานการเรียกใช้การทดสอบ deqp หรือโปรแกรมที่ใช้เรียกใช้บรรทัดคำสั่ง บริการการเรียกใช้การทดสอบต้องพร้อมใช้งานบนเป้าหมาย การใช้งานบริการ C++ แบบพกพามีอยู่ในไดเรกทอรี execserver ไฟล์ไบนารีแบบสแตนด์อโลนสร้างขึ้นเป็นส่วนหนึ่งของโมดูลทดสอบ deqp ที่สร้างขึ้นสำหรับเป้าหมาย PC คุณสามารถแก้ไข execserver/CMakeLists.txt เพื่อเปิดใช้การสร้างในเป้าหมายอื่นๆ ได้

บริการการเรียกใช้การทดสอบเวอร์ชัน C++ ยอมรับพารามิเตอร์บรรทัดคำสั่ง 2 รายการ ได้แก่

• --port=<port> จะตั้งค่าพอร์ต TCP ที่เซิร์ฟเวอร์รอรับการเชื่อมต่อ ค่าเริ่มต้นคือ 50016
• --single จะสิ้นสุดกระบวนการของเซิร์ฟเวอร์เมื่อไคลเอ็นต์ตัดการเชื่อมต่อ โดยค่าเริ่มต้น กระบวนการของเซิร์ฟเวอร์จะยังคงทำงานเพื่อให้บริการคำขอการเรียกใช้การทดสอบเพิ่มเติม

ทำการทดสอบ

หน้านี้มีวิธีการเรียกใช้การทดสอบ deqp ในสภาพแวดล้อม Linux และ Windows, การใช้อาร์กิวเมนต์บรรทัดคำสั่ง และการทํางานกับแพ็กเกจแอปพลิเคชัน Android

สภาพแวดล้อม Linux และ Windows

เริ่มต้นด้วยการคัดลอกไฟล์และไดเรกทอรีต่อไปนี้ไปยังปลายทาง

คุณสามารถติดตั้งใช้งานบริการการดําเนินการและทดสอบไบนารีได้ทุกที่ในระบบไฟล์เป้าหมาย แต่ไบนารีทดสอบจะคาดหวังว่าจะพบไดเรกทอรีข้อมูลในไดเรกทอรีทํางานปัจจุบัน เมื่อพร้อมแล้ว ให้เริ่มบริการการเรียกใช้การทดสอบในอุปกรณ์เป้าหมาย โปรดดูรายละเอียดเกี่ยวกับการเริ่มบริการที่หัวข้อทดสอบบริการการดำเนินการ

อาร์กิวเมนต์บรรทัดคำสั่ง

ตารางต่อไปนี้แสดงอาร์กิวเมนต์บรรทัดคำสั่งที่ส่งผลต่อการดำเนินการของโปรแกรมทดสอบทั้งหมด

อาร์กิวเมนต์เฉพาะ GLES2 และ GLES3

รูปแบบรายการ Test Case

รายการชุดทดสอบมี 2 รูปแบบ ตัวเลือกแรกคือการระบุชื่อเต็มของการทดสอบแต่ละรายการในบรรทัดแยกต่างหากในไฟล์ ASCII มาตรฐาน เมื่อชุดทดสอบมีจำนวนมากขึ้น การใช้คำนำหน้าซ้ำๆ อาจทำให้ยุ่งยาก หากต้องการหลีกเลี่ยงการใช้คำนำหน้าซ้ำ ให้ใช้ไวยากรณ์ไตร (หรือที่เรียกว่าต้นไม้คำนำหน้า) ที่แสดงด้านล่าง

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

เช่น

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

ซึ่งแปลเป็น 2 กรณีทดสอบต่อไปนี้

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

Android

แพ็กเกจแอปพลิเคชัน Android มีคอมโพเนนต์ที่จำเป็นทั้งหมด รวมถึงบริการเรียกใช้การทดสอบ ไฟล์ไบนารีทดสอบ และไฟล์ข้อมูล กิจกรรมทดสอบคือ NativeActivity ที่ใช้ EGL (ต้องใช้ Android 3.2 ขึ้นไป)

ติดตั้งแพ็กเกจแอปพลิเคชันได้ด้วยคำสั่งต่อไปนี้ (ชื่อที่แสดงคือชื่อ APK ในแพ็กเกจ Android CTS ซึ่งชื่อจะขึ้นอยู่กับบิลด์)

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

หากต้องการเปิดบริการการเรียกใช้การทดสอบและตั้งค่าการส่งต่อพอร์ต ให้ใช้สิ่งต่อไปนี้

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

คุณเปิดใช้การพิมพ์การแก้ไขข้อบกพร่องได้โดยทำตามขั้นตอนต่อไปนี้ก่อนเริ่มการทดสอบ

adb –d shell setprop log.tag.dEQP DEBUG

ทำการทดสอบใน Android ที่ไม่มี Android CTS

หากต้องการเริ่มกิจกรรมการเรียกใช้การทดสอบด้วยตนเอง ให้สร้าง 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"'

แก้ไขข้อบกพร่องใน Android

หากต้องการเรียกใช้การทดสอบภายใต้โปรแกรมแก้ไขข้อบกพร่อง GDB ใน Android ก่อนอื่นให้คอมไพล์และติดตั้งบิลด์แก้ไขข้อบกพร่องโดยเรียกใช้สคริปต์ 2 รายการต่อไปนี้

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 ของไฟล์สคริปต์ คุณสามารถระบุเส้นทางเพิ่มเติมไปยังไบนารี ฯลฯ ได้ แต่การให้พารามิเตอร์บรรทัดคำสั่งที่ถูกต้องก็เพียงพอแล้ว

หมายเหตุ: ใน Windows ไบนารี GDB ต้องใช้ libpython2.7.dll ก่อนเปิด debug.py ให้เพิ่ม <path-to-ndk>/prebuilt/windows/bin ลงในตัวแปร PATH

หมายเหตุ: การแก้ไขข้อบกพร่องโค้ดที่มาพร้อมเครื่องใช้ไม่ได้กับ Android 4.3 เวอร์ชันสต็อก โปรดดูวิธีแก้ปัญหาชั่วคราวใน ข้อบกพร่องสาธารณะนี้ Android 4.4 ขึ้นไปจะไม่มีข้อบกพร่องนี้

ทำการทดสอบอัตโนมัติ

โมดูลทดสอบ Deqp สามารถผสานรวมเข้ากับระบบทดสอบอัตโนมัติได้หลายวิธี แนวทางที่ดีที่สุดขึ้นอยู่กับโครงสร้างพื้นฐานการทดสอบและสภาพแวดล้อมเป้าหมายที่มีอยู่

เอาต์พุตหลักจากการเรียกใช้การทดสอบคือไฟล์บันทึกการทดสอบเสมอ กล่าวคือไฟล์ที่มีส่วนต่อท้าย .qpa คุณสามารถแยกวิเคราะห์ผลการทดสอบทั้งหมดได้จากบันทึกการทดสอบ เอาต์พุตคอนโซลเป็นข้อมูลการแก้ไขข้อบกพร่องเท่านั้น และอาจไม่พร้อมใช้งานในบางแพลตฟอร์ม

เรียกใช้ไบนารีทดสอบได้โดยตรงจากระบบการทำงานอัตโนมัติของการทดสอบ คุณสามารถเปิดใช้งานไฟล์ทดสอบสำหรับกรณีหนึ่งๆ ชุดทดสอบ หรือทดสอบทั้งหมดที่มีได้ หากเกิดข้อผิดพลาดร้ายแรงระหว่างการดำเนินการ (เช่น ข้อผิดพลาดบางอย่างของ API หรือข้อขัดข้อง) การทดสอบจะหยุดดำเนินการ สําหรับการทดสอบรีเกรดชัน วิธีที่ดีที่สุดคือการเรียกใช้ไบนารีทดสอบสําหรับแต่ละกรณีหรือชุดทดสอบขนาดเล็กแยกกัน เพื่อให้ได้ผลลัพธ์บางส่วนในกรณีที่เกิดความล้มเหลว

deqp มาพร้อมกับเครื่องมือการทดสอบการเรียกใช้บรรทัดคำสั่งที่สามารถใช้ร่วมกับบริการการเรียกใช้เพื่อให้การผสานรวมมีประสิทธิภาพมากขึ้น ผู้ดำเนินการจะตรวจหาการสิ้นสุดกระบวนการทดสอบและจะดำเนินการทดสอบต่อในเคสถัดไปที่พร้อมใช้งาน ระบบจะสร้างไฟล์บันทึกไฟล์เดียวจากเซสชันการทดสอบทั้งหมด การตั้งค่านี้เหมาะสําหรับระบบการทดสอบแบบเบาๆ ที่ไม่มีห้องทดลองกู้คืนข้อขัดข้อง

เครื่องมือการเรียกใช้การทดสอบบรรทัดคำสั่ง

ชุดเครื่องมือบรรทัดคำสั่งปัจจุบันประกอบด้วยเครื่องมือการทดสอบระยะไกล เครื่องมือสร้างการเปรียบเทียบบันทึกการทดสอบสําหรับการวิเคราะห์การถดถอย ตัวแปลงบันทึกการทดสอบเป็น CSV ตัวแปลงบันทึกการทดสอบเป็น XML และตัวแปลงบันทึกการทดสอบเป็น JUnit

แหล่งที่มาของเครื่องมือเหล่านี้อยู่ในไดเรกทอรี executor และไฟล์ไบนารีจะฝังอยู่ในไดเรกทอรี <builddir>/executor

ผู้ดำเนินการทดสอบบรรทัดคำสั่ง

ผู้ดำเนินการทดสอบบรรทัดคำสั่งเป็นเครื่องมือ C++ แบบพกพาสำหรับการเปิดการทดสอบในอุปกรณ์และรวบรวมบันทึกผลลัพธ์จากอุปกรณ์ผ่าน TCP/IP Executor จะสื่อสารกับบริการการเรียกใช้ (execserver) ในอุปกรณ์เป้าหมาย ซึ่งร่วมกันให้ฟังก์ชันการทำงานต่างๆ เช่น การกู้คืนจากการขัดข้องของกระบวนการทดสอบ ตัวอย่างต่อไปนี้แสดงวิธีใช้โปรแกรมดำเนินการทดสอบบรรทัดคำสั่ง (ใช้ --help เพื่อดูรายละเอียดเพิ่มเติม)

ตัวอย่างที่ 1: เรียกใช้การทดสอบฟังก์ชันการทำงาน GLES2 ในอุปกรณ์ Android

executor --connect=127.0.0.1 --port=50016 --binaryname=
com.drawelements.deqp/android.app.NativeActivity
--caselistdir=caselists
--testset=dEQP-GLES2.* --out=BatchResult.qpa
--cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable
--deqp-gl-config-name=rgba8888d24s8"

ตัวอย่างที่ 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 จะมีรายการชุดทดสอบและผลลัพธ์ นอกจากนี้ เครื่องมือนี้ยังเปรียบเทียบผลลัพธ์กลุ่มตั้งแต่ 2 กลุ่มขึ้นไปและแสดงเฉพาะกรณีทดสอบที่มีรหัสสถานะต่างกันในผลลัพธ์กลุ่มอินพุตได้ด้วย การเปรียบเทียบจะพิมพ์จํานวนกรณีที่ตรงกันด้วย

เอาต์พุตในรูปแบบ 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: แสดงรายการความแตกต่างของผลการทดสอบระหว่างบันทึกการทดสอบ 2 รายการ

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

หมายเหตุ: อาร์กิวเมนต์ --value=code จะแสดงผลรหัสผลการทดสอบ เช่น "ผ่าน" หรือ "ไม่ผ่าน" อาร์กิวเมนต์ --value=details จะเลือกคำอธิบายเพิ่มเติมเกี่ยวกับผลลัพธ์หรือค่าตัวเลขที่เกิดจากการทดสอบประสิทธิภาพ ความสามารถ หรือความแม่นยำ

ทดสอบการส่งออกบันทึกในรูปแบบ XML

ไฟล์บันทึกการทดสอบสามารถแปลงเป็นเอกสาร XML ที่ถูกต้องได้โดยใช้ยูทิลิตี testlog-to-xml รองรับโหมดเอาต์พุต 2 โหมด ได้แก่

• โหมดเอกสารแยกต่างหาก ซึ่งระบบจะเขียนแต่ละกรณีทดสอบและcaselist.xmlเอกสารสรุป ไปยังไดเรกทอรีปลายทาง
• โหมดไฟล์เดียว ซึ่งระบบจะเขียนผลลัพธ์ทั้งหมดในไฟล์ .qpa ลงในเอกสาร XML ไฟล์เดียว

คุณสามารถดูไฟล์บันทึกการทดสอบที่ส่งออกในเบราว์เซอร์ได้โดยใช้สไตล์ชีต XML เอกสารตัวอย่างชีตสไตล์ (testlog.xsl และ testlog.css) มีอยู่ในไดเรกทอรี doc/testlog-stylesheet หากต้องการแสดงผลไฟล์บันทึกในเบราว์เซอร์ ให้คัดลอกไฟล์สไตล์ชีต 2 ไฟล์ไปยังไดเรกทอรีเดียวกับที่มีเอกสาร XML ที่ส่งออก

หากใช้ Google Chrome คุณต้องเข้าถึงไฟล์ผ่าน HTTP เนื่องจาก Chrome จำกัดการเข้าถึงไฟล์ในเครื่องด้วยเหตุผลด้านความปลอดภัย การติดตั้ง Python มาตรฐานจะรวมเซิร์ฟเวอร์ HTTP พื้นฐานที่เปิดใช้งานเพื่อแสดงไดเรกทอรีปัจจุบันด้วยคำสั่ง python –m SimpleHTTPServer 8000 หลังจากเปิดเซิร์ฟเวอร์แล้ว ให้ไปที่เบราว์เซอร์ Chrome แล้วไปที่ http://localhost:8000 เพื่อดูบันทึกการทดสอบ

การแปลงเป็นบันทึกการทดสอบ JUnit

ระบบการทดสอบอัตโนมัติหลายระบบสามารถสร้างรายงานผลการทดสอบการเรียกใช้จากเอาต์พุต JUnit ได้ ไฟล์บันทึกการทดสอบ deqp สามารถแปลงเป็นรูปแบบเอาต์พุต JUnit ได้โดยใช้เครื่องมือ testlog-to-junit

ปัจจุบันเครื่องมือรองรับการแปลผลการตรวจสอบของเคสทดสอบเท่านั้น เนื่องจาก JUnit รองรับเฉพาะผลลัพธ์ "ผ่าน" และ "ไม่ผ่าน" ระบบจะจับคู่ผลลัพธ์ที่ผ่านของ deqp กับ "ผ่าน JUnit" และผลลัพธ์อื่นๆ จะถือว่าไม่ผ่าน โค้ดผลลัพธ์ deqp เดิมจะอยู่ในเอาต์พุต JUnit ระบบจะไม่เก็บข้อมูลอื่นๆ เช่น ข้อความบันทึกและรูปภาพผลลัพธ์ไว้ใน Conversion

ใช้กลุ่มทดสอบพิเศษ

กลุ่มทดสอบบางกลุ่มอาจต้องใช้หรือรองรับตัวเลือกบรรทัดคำสั่งพิเศษ หรือต้องใช้ความระมัดระวังเป็นพิเศษเมื่อใช้ในระบบบางระบบ

การทดสอบความเครียดการจัดสรรหน่วยความจำ

การทดสอบความเครียดของการจัดสรรหน่วยความจำจะทดสอบเงื่อนไขหน่วยความจําไม่เพียงพอโดยการจัดสรรทรัพยากรบางอย่างซ้ำๆ จนกว่าไดรเวอร์จะรายงานข้อผิดพลาดหน่วยความจําไม่เพียงพอ

ในบางแพลตฟอร์ม เช่น 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.*