בדיקות של תוכנית האיכות drawElements

‫AOSP כולל את חבילת הבדיקות של מעבד גרפי (GPU) drawElements Quality Program (deqp) בכתובת https://android.googlesource.com/platform/external/deqp. בדף הזה מוסבר איך פורסים את חבילת הבדיקה deqp בסביבה חדשה.

כדי לעבוד עם הקוד האחרון שנשלח, משתמשים בענף deqp-dev. כדי להשתמש בקוד שתואם לגרסה ספציפית של Android CTS, צריך להשתמש בענף release-code-name-release (לדוגמה, כדי להשתמש ב-Android 6.0, צריך להשתמש בענף marshmallow-release).

פריסת המקור

פריסת קוד המקור של מודולי הבדיקה של deqp וספריות התמיכה מוצגת בטבלה שלמטה (הרשימה לא מקיפה, אבל היא מדגישה את הספריות החשובות ביותר).

ספרייה תיאור
android

מקורות לבדיקה וסקריפטים לבנייה ב-Android
data

קובצי נתוני בדיקה
modules

בדיקת מקורות מודולים
modules/egl

EGL module
modules/gles2

מודול GLES2
modules/gles3

מודול GLES3
modules/gles31

מודול GLES3.1
modules/gles32

מודול GLES3.2
targets

קובצי תצורת build ספציפיים ליעד
framework

מסגרת מודול הבדיקה deqp וכלי השירות
framework/delibs

ניידות בסיסית ובניית ספריות
framework/platform

יציאות בפלטפורמה
framework/qphelper

ספרייה לשילוב תוכניות בדיקה (C)
framework/common

מסגרת Deqp ‏ (C++)
framework/opengl, framework/egl

תוכניות שירות ספציפיות ל-API
execserver

מקור ExecServer בצד המכשיר
executor

כלי מעטפת וכלי עזר להרצת בדיקות בצד המארח
external

יצירת ספריות stub לספריות חיצוניות libpng ו-zlib

רכיבים של קוד פתוח

ה-deqp משתמש ב-libpng וב-zlib, שאפשר לאחזר באמצעות הסקריפט platform/external/deqp/external/fetch_sources.py או באמצעות git מ-platform/external/[libpng,zlib].

יצירת תוכניות לבדיקה

מסגרת הבדיקה תוכננה כך שתהיה ניידת. הדרישות המנדטוריות היחידות הן תמיכה מלאה ב-C++‎ וספריות מערכת סטנדרטיות לקלט/פלט, לשרשורים ולשקעים.

מערכת build של CMake

במקורות של deqp יש סקריפטים לבנייה של CMake, שהוא הכלי המועדף להידור של תוכניות הבדיקה.

‫CMake היא מערכת קוד פתוח לבנייה שתומכת בפלטפורמות ובשרשראות כלים רבות. ‫CMake יוצר קובצי makefile מקוריים או קובצי פרויקט של IDE מקובצי תצורה שלא תלויים ביעד. מידע נוסף על CMake זמין בתיעוד של CMake.

‫CMake תומך בבנייה מחוץ לעץ המקור וממליץ על כך. כלומר, תמיד צריך ליצור קובצי makefile או קובצי פרויקט בספריית בנייה נפרדת מחוץ לעץ המקור. ל-CMake אין יעד מסוג distclean, ולכן צריך להסיר באופן ידני את כל הקבצים שנוצרו על ידי CMake.

אפשרויות ההגדרה מועברות ל-CMake באמצעות התחביר -DOPTION_NAME=VALUE. בהמשך מפורטות כמה אפשרויות נפוצות לשימוש ב-deqp.

אפשרות הגדרה תיאור
DEQP_TARGET

שם היעד, לדוגמה: android

סקריפטים של deqp CMake יכללו את הקובץ targets/DEQP_TARGET/DEQP_TARGET.cmake ויצפו למצוא בו אפשרויות בנייה ספציפיות ליעד.
CMAKE_TOOLCHAIN_FILE

הנתיב לקובץ toolchain עבור CMake. משמש לקומפילציה צולבת.
CMAKE_BUILD_TYPE

סוג ה-Build ליעדי makefile. הערכים התקינים הם: Debug ו-Release

הערה: הפרשנות וסוג ברירת המחדל תלויים במערכת הבנייה המטורגטת. פרטים נוספים זמינים במסמכי התיעוד של CMake.

יצירת קובץ build של יעד

מערכת ה-build של deqp מוגדרת ליעדים חדשים באמצעות קובצי build של יעדים. קובץ build של יעד מגדיר אילו תכונות הפלטפורמה תומכת בהן ואילו ספריות או נתיבי הכללה נוספים נדרשים. שמות קובצי היעד הם בפורמט targets/NAME/NAME.cmake והיעד נבחר באמצעות פרמטר הבנייה DEQP_TARGET.

נתיבי הקבצים בקובצי היעד הם יחסי לספריית הבסיס deqp, ולא לספרייה targets/NAME. אפשר להגדיר את המשתנים הרגילים הבאים באמצעות קובץ ה-build של היעד.

משתנה תיאור
DEQP_TARGET_NAME

שם היעד (ייכלל ביומני הבדיקה)
DEQP_SUPPORT_GLES2

האם יש תמיכה ב-GLES2 (ברירת מחדל: מושבת)
DEQP_GLES2_LIBRARIES

ספריות GLES2 (משאירים ריק אם אין תמיכה או אם נעשה שימוש בטעינה דינמית)
DEQP_SUPPORT_GLES3

האם יש תמיכה ב-GLES3.x (ברירת מחדל: OFF)
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

רשימת מקורות להעברת נתונים בין פלטפורמות. מקורות ברירת המחדל נקבעים על סמך היכולות ומערכת ההפעלה.

הערה: הנתיבים הם יחסיים ל: framework/platform

בקובץ ה-build של היעד אפשר להוסיף עוד נתיבי include או קישור באמצעות הפונקציות include_directories() ו-link_directories() של CMake.

גרסת Win32

הדרך הקלה ביותר ליצור מודולים של deqp ל-Windows היא באמצעות מערכת ה-build של CMake. תצטרכו CMake בגרסה 2.6.12 ומעלה, ואת מהדר Microsoft Visual C/C++‎. הכלי deqp נבדק באמצעות Visual Studio 2013.

אפשר ליצור קובצי פרויקט של Visual Studio באמצעות הפקודה הבאה:

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

אפשר ליצור גרסת build של 64 ביט על ידי בחירה באפשרות Visual Studio VERSION Win64 כגנרטור של גרסת ה-build:

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

אפשר גם ליצור קובצי make של NMake באמצעות האפשרות -G "NMake Makefiles" וסוג ה-build (-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 מוגדר כ-ON. זוהי ברירת המחדל ברוב יעדי התקציב. לאחר מכן, אם למארח יש ספריות EGL זמינות, אפשר להריץ איתן בדיקות באמצעות פרמטר שורת הפקודה: --deqp-gl-context-type=egl

‫Android build

ה-build של Android משתמש בסקריפטים של CMake build כדי לבנות את קוד הבדיקה המקורי. חלקי Java, כלומר שרת הרצת הבדיקות ו-stub של אפליקציית הבדיקה, עוברים קומפילציה באמצעות כלי ה-build הרגילים של Android.

כדי לקמפל תוכניות בדיקה של deqp ל-Android באמצעות סקריפטים של build שסופקו, תצטרכו:

  • הגרסה האחרונה של Android NDK. הגרסה הנדרשת מפורטת בקובץ android/scripts/common.py.
  • ‫Android stand-alone SDK עם API 13,‏ SDK Tools,‏ SDK Platform-tools ו-SDK Build-tools packages מותקנים
  • ‫Apache Ant 1.9.4 (נדרש לבניית קוד Java)
  • ‫CMake 2.8.12 ואילך
  • ‫Python 2.6 או גרסה חדשה יותר בסדרה 2.x; אין תמיכה ב-Python 3.x
  • ב-Windows: NMake או JOM ב-PATH
    • JOM מאפשרת בנייה מהירה יותר
  • אופציונלי: יש תמיכה גם ב-Ninja make ב-Linux

קובצי ה-binary של 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

אפשר ליצור קובצי makefile באמצעות CMake כדי לבנות קבצים בינאריים לבדיקה וכלי שורת פקודה ל-Linux. יש כמה יעדי בנייה מוגדרים מראש ששימושיים כשבונים ל-Linux.

יעד Build תיאור
default

יעד ברירת המחדל שמשתמש ב-CMake platform introspection כדי לקבוע את התמיכה בממשקי API שונים.
x11_glx

משתמש ב-GLX כדי ליצור הקשרים של OpenGL (ES).
x11_egl

משתמש ב-EGL כדי ליצור הקשרים של OpenGL (ES).
x11_egl_glx

תמיכה ב-GLX וב-EGL עם X11.

תמיד משתמשים ב--DCMAKE_BUILD_TYPE=<Debug|Release> כדי להגדיר את סוג ה-build. Release היא ברירת מחדל טובה. בלי זה, המערכת תיצור גרסת build של גרסה לא אופטימלית שמוגדרת כברירת מחדל.

אפשר להשתמש בארגומנטים של שורת הפקודה -DCMAKE_C_FLAGS ו--DCMAKE_CXX_FLAGS כדי להעביר ארגומנטים נוספים לקומפיילר. לדוגמה, אפשר ליצור גרסת build של 32 ביט או 64 ביט על ידי הגדרת -DCMAKE_C(XX)_FLAGS="-m32" או "-m64" בהתאמה. אם לא מציינים ארכיטקטורה, נעשה שימוש בארכיטקטורה המקורית של ערכת הכלים, בדרך כלל 64 ביט בערכת כלים של 64 ביט.

אפשר להשתמש בארגומנטים -DCMAKE_LIBRARY_PATH ו--DCMAKE_INCLUDE_PATH עבור CMake כדי לספק ל-CMake נתיבי חיפוש נוספים לספריות או לקבצים שכוללים.

דוגמה לשורת פקודה מלאה שמשמשת ליצירת גרסת ניפוי באגים של 32 ביט מול כותרות וספריות של מנהלי התקנים במיקום מותאם אישית:

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

עיבוד בין מערכות

כדי לבצע קומפילציה חוצה, אפשר להשתמש בקובץ שרשרת כלים של CMake. קובץ toolchain מציין את הקומפיילר שבו יש להשתמש, יחד עם נתיבי חיפוש בהתאמה אישית לספריות ולקובצי כותרות. חבילת הגרסה כוללת כמה קבצים של שרשרת הכלים לתרחישים נפוצים, בספרייה framework/delibs/cmake.

בנוסף למשתני CMake רגילים, אפשר להגדיר את המשתנים הבאים שספציפיים ל-deqp באמצעות קובץ ה-toolchain. ‫CMake בדרך כלל יכול לזהות את DE_OS, DE_COMPILER ו-DE_PTR_SIZE בצורה נכונה, אבל צריך להגדיר את DE_CPU בקובץ toolchain.

משתנה תיאור
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

סוג המעבד. ערכים נתמכים: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE

‫sizeof(void*) בפלטפורמה. הערכים הנתמכים הם: 4 ו-8

אפשר לבחור את קובץ ה-toolchain באמצעות פרמטר ה-build‏ CMAKE_TOOLCHAIN_FILE. לדוגמה, הפקודה הבאה תיצור קובצי makefile ל-build באמצעות קומפיילר חוצה של 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 מופעלת בהגדרות ה-build ולא מסופקות ספריות קישור, ה-deqp יטען את נקודות הכניסה הנדרשות בזמן הריצה. אם רוצים להשתמש בקישור סטטי, צריך לספק את ספריות הקישור הנדרשות במשתנה הגדרת ה-build‏ DEQP_<API>_LIBRARIES.

העברת מסגרת הבדיקה

העברת ה-deqp כוללת שלושה שלבים: התאמת ספריות בסיסיות להעברה, הטמעה של ממשקי שילוב פלטפורמה של framework לבדיקה והעברה של שירות ההפעלה.

בטבלה הבאה מפורטים מיקומים שבהם סביר שיהיו שינויים בהעברה. כל מה שמעבר לכך הוא כנראה אקזוטי.

מיקום תיאור
framework/delibs/debase
framework/delibs/dethread
framework/delibs/deutil

הטמעות נדרשות של קוד ספציפי למערכת ההפעלה.
framework/qphelper/qpCrashHandler.c

אופציונלי: הטמעה למערכת ההפעלה.
framework/qphelper/qpWatchDog.c

הטמעה במערכת ההפעלה. הנוכחי מבוסס על dethread ועל ספריית C רגילה.
framework/platform

אפשר להטמיע יציאה חדשה של פלטפורמה וקובץ stub של אפליקציה כמו שמתואר במאמר יציאה של פלטפורמה למסגרת בדיקה.

ספריות בסיסיות לניידות מידע

ספריות הניוד הבסיסיות כבר תומכות ב-Windows, ברוב הגרסאות של Linux, ב-Mac OS, ב-iOS וב-Android. אם יעד הבדיקה פועל באחת ממערכות ההפעלה האלה, סביר להניח שלא צריך לגעת בספריות הבסיסיות של הניידות בכלל.

העברה של פלטפורמת בדיקות

העברת הפלטפורמה של ה-framework לבדיקת deqp דורשת שני רכיבים: נקודת כניסה לאפליקציה והטמעה של ממשק פלטפורמה.

נקודת הכניסה של האפליקציה אחראית ליצירת אובייקט הפלטפורמה, ליצירת אובייקט של שורת פקודה (tcu::CommandLine), לפתיחת יומן בדיקה (tcu::TestLog) ולביצוע איטרציה של אפליקציית הבדיקה (tcu::App). אם מערכת ההפעלה של היעד תומכת בנקודת כניסה רגילה של main(), אפשר להשתמש ב-tcuMain.cpp כהטמעה של נקודת הכניסה.

התיאור המפורט של ה-API של פלטפורמת deqp מופיע בקבצים הבאים.

קובץ תיאור
framework/common/tcuPlatform.hpp

מחלקת בסיס לכל ההעברות של פלטפורמות
framework/opengl/gluPlatform.hpp

ממשק פלטפורמת OpenGL
framework/egl/egluPlatform.hpp

ממשק פלטפורמה של EGL
framework/platform/tcuMain.cpp

נקודת כניסה רגילה לאפליקציה

מחלקת הבסיס לכל ההעברות של הפלטפורמה היא tcu::Platform. היציאה של הפלטפורמה יכולה לתמוך בממשקים ספציפיים ל-GL ול-EGL. בטבלה הבאה מופיעה סקירה כללית של מה שצריך להטמיע כדי להריץ את הבדיקות.

מודול ממשק

מודולים של בדיקות OpenGL (ES)

ממשק פלטפורמת GL

מודול בדיקה של EGL

ממשק פלטפורמה של EGL

הוראות מפורטות להטמעת יציאות של פלטפורמות מופיעות בכותרות של שכבת ההעברה.

שירות ביצוע בדיקות

כדי להשתמש בתשתית להרצת בדיקות deqp או בכלי להרצת בדיקות משורת הפקודה, שירות הרצת הבדיקות צריך להיות זמין ביעד. הטמעה ניידת של השירות ב-C++‎ מסופקת בספרייה execserver. הקובץ הבינארי העצמאי נוצר כחלק מהגרסה של מודול הבדיקה deqp למחשבים. אפשר לשנות את execserver/CMakeLists.txt כדי להפעיל בנייה ביעדים אחרים.

גרסת C++‎ של שירות הרצת הבדיקות מקבלת שני פרמטרים של שורת פקודה:

  • ‫--port=<port> יגדיר את יציאת ה-TCP שהשרת מאזין לה. ערך ברירת המחדל הוא 50016.
  • הפקודה --single תסיים את תהליך השרת כשהלקוח יתנתק. כברירת מחדל, תהליך השרת ימשיך לפעול כדי לטפל בבקשות נוספות להרצת בדיקות.

הרצת הבדיקות

בדף הזה מוסבר איך להריץ בדיקות deqp בסביבות Linux ו-Windows באמצעות ארגומנטים של שורת פקודה, ואיך לעבוד עם חבילת האפליקציה של Android.

סביבות Linux ו-Windows

מתחילים בהעתקה של הקבצים והספריות הבאים אל היעד.

מודול ספרייה לוח קליעה למטרה
שרת הביצוע build/execserver/execserver <dst>/execserver
מודול EGL build/modules/egl/deqp-egl <dst>/deqp-egl
GLES2 Module build/modules/gles2/deqp-gles2 <dst>/deqp-gles2
data/gles2 <dst>/gles2
GLES3 Module build/modules/gles3/deqp-gles3 <dst>/deqp-gles3
data/gles3 <dst>/gles3
GLES3.1 Module build/modules/gles31/deqp-gles31 <dst>/deqp-gles31
data/gles31 <dst>/gles31
GLES3.2 Module 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> ערך הבסיס של ה-seed לתרחישי הבדיקה שמשתמשים באקראיות.

ארגומנטים ספציפיים ל-GLES2 ול-GLES3

בטבלה הבאה מפורטים הארגומנטים הספציפיים ל-GLES2 ול-GLES3.
ארגומנט תיאור
--deqp-gl-context-type=<type> סוג ההקשר של OpenGL. סוגי ההקשר הזמינים תלויים בפלטפורמה. בפלטפורמות שתומכות ב-EGL, אפשר להשתמש בערך egl כדי לבחור את ההקשר של EGL.
--deqp-gl-config-id=<id> מריצים בדיקות למזהה ההגדרה של GL שצוין. הפירוש תלוי בפלטפורמה. בפלטפורמת EGL, זהו מזהה ההגדרה של EGL.
--deqp-gl-config-name=<name> מריצים בדיקות להגדרה של GL שקיבלה שם. הפירוש תלוי בפלטפורמה. ב-EGL, הפורמט הוא rgb(a)<bits>d<bits>s<bits>. לדוגמה, ערך של rgb888s8 יבחר את ההגדרה הראשונה שבה מאגר הצבעים הוא RGB888 ומאגר השבלונות הוא 8 ביט.
--deqp-gl-context-flags=<flags> יוצר הקשר. מציינים robust או debug.
--deqp-surface-width=<width>
--deqp-surface-height=<height>		 מנסים ליצור משטח בגודל מסוים. התמיכה בזה היא אופציונלית.
--deqp-surface-type=<type> שימוש בסוג נתון של פלטפורמה כיעד העיקרי של בדיקת העיבוד. הסוגים האפשריים הם window,‏ pixmap,‏ pbuffer ו-fbo.
--deqp-screen-rotation=<rotation> כיוון המסך במרווחים של 90 מעלות בפלטפורמות שתומכות בכך.

הפורמט של רשימת תרחישי הבדיקה

אפשר להציג את רשימת תרחישי הבדיקה בשני פורמטים. האפשרות הראשונה היא ליצור רשימה של השם המלא של כל בדיקה בשורה נפרדת בקובץ ASCII רגיל. ככל שמערכי הבדיקה גדלים, הקידומות החוזרות יכולות להיות מסורבלות. כדי להימנע מחזרה על הקידומות, אפשר להשתמש בתחביר של עץ חיפוש (trie), שנקרא גם עץ קידומות, שמוצג בהמשך.

{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 ומעלה).

אפשר להתקין את חבילת האפליקציה באמצעות הפקודה הבאה (השם שמוצג הוא השם של ה-APK בחבילת Android CTS; השם תלוי בגרסת ה-build):

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, קודם צריך להדר ולהתקין את גרסת הניפוי באגים על ידי הרצת שני הסקריפטים הבאים:

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 מכיל רשימה של תרחישי בדיקה והתוצאות שלהם. הכלי יכול גם להשוות בין שתי תוצאות או יותר של חבילות ולפרט רק את תרחישי הבדיקה שיש להם קודי סטטוס שונים בתוצאות של חבילות הקלט. בנוסף, בהשוואה יודפס מספר המקרים התואמים.

הפלט בפורמט CSV מאוד שימושי לעיבוד נוסף באמצעות כלי שורת פקודה רגילים או באמצעות עורך גיליונות אלקטרוניים. אפשר לבחור פורמט נוסף של טקסט פשוט שקל לקרוא באמצעות ארגומנט שורת הפקודה הבא: --format=text

דוגמה 1: ייצוא יומן בדיקה בפורמט CSV
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
דוגמה 2: רשימת ההבדלים בתוצאות הבדיקה בין שני יומני בדיקה
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

הערה: הארגומנט --value=code מחזיר את קוד תוצאת הבדיקה, כמו Pass או Fail. הארגומנט --value=details בוחר את ההסבר הנוסף של התוצאה או הערך המספרי שנוצר על ידי בדיקת ביצועים, יכולת או דיוק.

בדיקת ייצוא של יומן ל-XML

אפשר להמיר קובצי יומן של בדיקות למסמכי XML תקינים באמצעות כלי השירות testlog-to-xml. יש תמיכה בשני מצבי פלט:

  • מצב מסמכים נפרדים, שבו כל מקרה בדיקה ומסמך הסיכום caselist.xml נכתבים לספריית יעד
  • מצב קובץ יחיד, שבו כל התוצאות בקובץ .qpa נכתבות במסמך XML יחיד.

אפשר להציג בדפדפן קבצים של יומני בדיקה שיוצאו באמצעות גיליון סגנונות XML. מסמכי גיליון סגנונות לדוגמה (testlog.xsl ו-testlog.css) מסופקים בספרייה doc/testlog-stylesheet. כדי לעבד את קובצי היומן בדפדפן, מעתיקים את שני קובצי הגיליון הראשי לאותה ספרייה שבה נמצאים מסמכי ה-XML שיוצאו.

אם אתם משתמשים ב-Google Chrome, צריך לגשת לקבצים באמצעות HTTP כי Chrome מגביל את הגישה לקבצים מקומיים מטעמי אבטחה. ההתקנה הרגילה של Python כוללת שרת HTTP בסיסי שאפשר להפעיל כדי לשרת את הספרייה הנוכחית באמצעות הפקודה python –m SimpleHTTPServer 8000. אחרי שמפעילים את השרת, פשוט מפנים את דפדפן Chrome אל http://localhost:8000 כדי לראות את יומן הבדיקה.

המרת יומן בדיקה של JUnit

הרבה מערכות אוטומטיות לבדיקות יכולות ליצור דוחות של תוצאות הרצת בדיקות מתוך פלט של JUnit. אפשר להמיר את קובצי היומן של בדיקת deqp לפורמט הפלט של JUnit באמצעות הכלי testlog-to-junit.

בשלב הזה, הכלי תומך רק בתרגום של פסיקת המקרה לבדיקה. מכיוון ש-JUnit תומך רק בתוצאות pass (עבר) ו-fail (נכשל), תוצאה pass של deqp ממופה ל-JUnit pass, ותוצאות אחרות נחשבות לתוצאות fail. קוד התוצאה המקורי של deqp זמין בפלט של JUnit. נתונים אחרים, כמו הודעות יומן ותמונות של תוצאות, לא נשמרים בהמרה.

שימוש בקבוצות בדיקה מיוחדות

יכול להיות שקבוצות בדיקה מסוימות יצטרכו או יתמכו באפשרויות מיוחדות של שורת הפקודה, או שידרשו טיפול מיוחד כשמשתמשים בהן במערכות מסוימות.

בדיקות מאמץ של הקצאת זיכרון

בדיקות מאמץ של הקצאת זיכרון בודקות מצבים של חוסר בזיכרון פנוי על ידי הקצאה חוזרת של משאבים מסוימים עד שהדרייבר מדווח על שגיאה של חוסר בזיכרון פנוי.

בפלטפורמות מסוימות, כמו Android ורוב הווריאציות של Linux, יכול לקרות הדבר הבא: מערכת ההפעלה עשויה להפסיק את תהליך הבדיקה במקום לאפשר לדרייבר לטפל בשגיאה של חוסר זיכרון או לספק אותה בדרך אחרת. בפלטפורמות כאלה, בדיקות שנועדו לגרום לשגיאות של חוסר זיכרון מושבתות כברירת מחדל, וצריך להפעיל אותן באמצעות הארגומנט --deqp-test-oom=enable בשורת הפקודה. מומלץ להפעיל בדיקות כאלה באופן ידני כדי לבדוק אם המערכת מתנהגת בצורה נכונה כשיש עומס על המשאבים. עם זאת, במצב כזה, קריסה של תהליך הבדיקה צריכה להתפרש כהצלחה.

קבוצות בדיקה

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

בדיקות מאמץ ארוכות של רינדור

בדיקות עומס של רינדור נועדו לחשוף בעיות עמידות תחת עומס רינדור מתמשך. כברירת מחדל, הבדיקות יפעלו רק כמה איטרציות, אבל אפשר להגדיר אותן לפעול ללא הגבלה באמצעות אספקת --deqp-test-iteration-count=-1ארגומנט של שורת הפקודה. צריך להשבית את מנגנון ה-watchdog של הבדיקה (--deqp-watchdog=disable) כשמריצים את הבדיקות האלה למשך זמן ארוך.

קבוצות בדיקה

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