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

AOSP כולל את חבילת בדיקות ה-GPU של pullElements בתוכנית האיכות (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
modules/gles2	מודול GLES2
modules/gles3	מודול GLES3
modules/gles31	מודול GLES3.1
modules/gles32	מודול GLES3.2
targets	קובצי תצורת build ספציפיים ליעד
framework	framework ותכליות של מודול בדיקה deqp
framework/delibs	ספריות בסיסיות של ניידות ופיתוח
framework/platform	יציאות לפלטפורמה
framework/qphelper	ספריית שילוב של תוכנית בדיקות (C)
framework/common	מסגרת Deqp (C++ )
framework/opengl, framework/egl	תוכניות שירות ספציפיות ל-API
execserver	מקור ExecServer בצד המכשיר
executor	כלי עזר לבדיקה של המעטפת של מנהל הבדיקה בצד המארח
external	בניית ספריית stub עבור libs חיצוניים ו-zlib

רכיבי קוד פתוח

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

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

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

מערכת build ל-CMake

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

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

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

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

אפשרות הגדרה	תיאור
DEQP_TARGET	שם יעד, למשל: 'android' הסקריפטים של deqp CMake יכללו את הקובץ targets/DEQP_TARGET/DEQP_TARGET.cmake וסביר להניח שאמצא ספציפיות ליעד ספציפי של build.
CMAKE_TOOLCHAIN_FILE	נתיב לקובץ Toolchain של CMake. משמש להידור מוצלב.
CMAKE_BUILD_TYPE	סוג ה-build ליעדים מסוג makefile. הערכים החוקיים הם: "ניפוי באגים" ו-"Release" חשוב לשים לב שהפרשנות וסוג ברירת המחדל תלויים במערכת ה-build המטורגטת. פרטים נוספים זמינים במסמכי התיעוד של CMake.

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

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

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

משתנה	תיאור
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	רשימת הספריות שמועתקות לכל ספרייה של גרסת build בינארית לבדיקה. יכול להיות משמשת להעתקת ספריות שנחוצות להרצת בדיקות אבל לא מוגדרות כברירת מחדל נתיב החיפוש.
TCUTIL_PLATFORM_SRCS	רשימת המקורות של יציאות הפלטפורמה. מקורות ברירת המחדל נקבעים לפי היכולות ומערכת ההפעלה. הערה: הנתיבים הם יחסיים אל: framework/platform

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

גרסת build של Win32

הדרך הקלה ביותר לפתח מודולים של deqp ל-Windows היא להשתמש ב-CMake build המערכת. יש צורך ב-CMake 2.6.12 ואילך וב-Microsoft Visual C/C++ מהדר (compiler) . ה-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"

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

גרסת build של Android

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

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

• הגרסה העדכנית ביותר של Android NDK; קובץ android/scripts/common.py מפרט את הגרסה הנדרשת
• SDK עצמאי ל-Android עם API 13, כלי SDK, כלים לפלטפורמות SDK ו-SDK חבילות של כלי build מותקנות
• Apache Ant 1.9.4 (נדרש באמצעות ה-build של קוד Java)
• CMake 2.8.12 ואילך
• ֶPython 2.6 ואילך בסדרת 2.x; אין תמיכה ב-Python 3.x
• ל-Windows: NMake או JOM ב-PATH
  • JOM מאפשר פיתוחים מהירים יותר
• אופציונלי: יצרן הנינג'ה נתמך גם ב-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. קובץ ה-APK הסופי נוצר ב- android/package/bin וניתן להתקין אותם באמצעות הסקריפט install.py. אם נעשה שימוש במנהל שורת הפקודה (CLI), וה-ExecService מופעל. עם סקריפט launch.py במכשיר דרך ADB. ניתן להריץ את הסקריפטים מכל ספרייה.

גרסת build של Linux

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

יצירת יעד	תיאור
default	יעד ברירת המחדל שמשתמש בבחינה עצמית של פלטפורמת CMake כדי לקבוע תמיכה בממשקי 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 ביט ב-toolchain של 64 ביט.

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

דוגמה לשורת פקודה מלאה שמשמשת ליצירת גרסת build של ניפוי באגים בגרסת 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

הידור מוצלב

ניתן לבצע הידור מוצלב באמצעות קובץ Toolchain של 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	סוג המעבד (CPU). הערכים הנתמכים הם: DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE	sizeof(pause*) בפלטפורמה. הערכים הנתמכים הם: 4 ו-8

אפשר לבחור את קובץ ה-toolchain באמצעות פרמטר ה-build CMAKE_TOOLCHAIN_FILE. לדוגמה, הדוגמה הבאה תגרום ליצירת קובצי makefile עבור build באמצעות ה-Cross-compiler של 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

לא צריך נקודות כניסה ל-API בבדיקה במהלך הקישור ב-Deqp. קוד הבדיקה תמיד ניגש לממשקי ה-API באמצעות מצביעי פונקציות. נקודות הכניסה יכולות ייטענו באופן דינמי בזמן הריצה או שיציאת הפלטפורמה יכולה לספק אותם זמן הקישור.

אם התמיכה ב-API מופעלת בהגדרות ה-build ובספריות הקישורים לא צוין, ה-deqp יטען את נקודות הכניסה הנדרשות בזמן הריצה. אם רצוי להוסיף קישור סטטי. צריך לספק את ספריות הקישורים הנדרשות ב-DEQP_<API>_LIBRARIES של תצורת build.

ניוד של מסגרת הבדיקה

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

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

מיקום	תיאור
framework/delibs/debase framework/delibs/dethread framework/delibs/deutil	הטמעות נחוצות של קוד ספציפי למערכת הפעלה.
framework/qphelper/qpCrashHandler.c	אופציונלי: הטמעה למערכת ההפעלה שלכם.
framework/qphelper/qpWatchDog.c	הטמעה עבור מערכת ההפעלה שלך. הנוכחית מבוססת על dethread ועל ספריית C רגילה.
framework/platform	ניתן להטמיע יציאת פלטפורמה חדשה ו-stub של אפליקציה כפי שמתואר ב בודקים את יציאת הפלטפורמה של framework.

ספריות ניידות בסיסית

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

בדיקת יציאת הפלטפורמה של framework

ליציאת הפלטפורמה של 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 כדי להפעיל build בפלטפורמה יעדים אחרים.

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

Android

חבילת האפליקציה ל-Android מכילה את כל הרכיבים הנדרשים, כולל שירות ביצוע הבדיקה, הקבצים הבינאריים של הבדיקה וקובצי הנתונים. פעילות הבדיקה היא NativeActivity שמשתמש ב-EGL (דורש Android 3.2 ואילך).

ניתן להתקין את חבילת האפליקציה באמצעות הפקודה הבאה (שם מוצג שם ה-APK בחבילת CTS של Android. איזה שם תלוי ):

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

כדי להתחיל באופן ידני את פעילות הביצוע של הבדיקה, צריך ליצור Intent של Android שמטרגטות את android.app.NativeActivity. הפעילויות יכולות להיות שנמצא בחבילה com.drawelements.deqp. חובה שבשורת הפקודה מסופק כמחרוזת נוספת עם מפתח "cmdLine" ב-Intent.

יומן בדיקה נכתב אל /sdcard/dEQP-log.qpa. אם הרצת הבדיקה לא מתחיל כרגיל, יש מידע נוסף על תוצאות ניפוי הבאגים במכשיר יומן.

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

python android/scripts/build.py --native-build-type=Debug
python android/scripts/install.py

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

הערה: ניפוי באגים של קוד Native לא פועל מלאי Android 4.3; לקבלת דרכים לעקוף את הבעיה, עיינו בכתובת הבאג הציבורי הזה. Android 4.4 ואילך לא מכיל את הבאג הזה.

אוטומציה של הבדיקות

אפשר לשלב מודולים של בדיקות Deqp במערכות בדיקה אוטומטיות בכמה דרכים. הגישה הטובה ביותר תלויה בתשתית הבדיקה וביעד הקיימים הסביבה.

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

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

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

כלי ביצוע לבדיקה של שורת הפקודה

קבוצת כלי שורת הפקודה הנוכחית כוללת כלי ביצוע בדיקה מרחוק, מחולל השוואות יומנים לניתוח רגרסיה, כלי להמרת יומנים ל-CSV לבדיקה, ממיר יומן בדיקה ל-XML וממיר בדיקה ל-JUnit.

קוד המקור של הכלים האלה נמצא בספרייה executor, והקבצים הבינאריים שמובנית בספרייה <builddir>/executor.

תוכנת הרצת בדיקת שורת הפקודה

הכלי לבדיקת שורת הפקודה (CLI) הוא כלי נייד של C++ להפעלת הרצת בדיקה. במכשיר ולאסוף ממנו את היומנים שנוצרו באמצעות TCP/IP. המוציא לפועל מתקשר עם שירות הביצוע (execserver) במכשיר היעד. ביחד הם מספקים פונקציונליות כמו התאוששות מקריסות של תהליך הבדיקה. בדוגמאות הבאות מוסבר איך להשתמש ב-Test Executor בשורת הפקודה (יש להשתמש ב--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" או 'נכשל'. הארגומנט --value=details בוחר עוד הסבר על התוצאה או הערך המספרי שמתקבל מבדיקה של ביצועים, יכולות או דיוק.

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

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

• מצב מסמכים נפרדים, שבו כל תרחיש בדיקה והסיכום של 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' תוצאות מעבר, מתבצע מיפוי של תוצאת ה-deqp אל 'JUnit Pass' ותוצאות אחרות נחשבות לכשלים. ה-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.*