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

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

כדי לעבוד עם הקוד האחרון שנשלח, השתמש בסניף deqp-dev . עבור קוד התואם לגרסה ספציפית של Android CTS, השתמש בענף 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 framework (C++)
framework/opengl, framework/egl	כלי עזר ספציפיים ל-API
execserver	מקור ExecServer בצד התקן
executor	כלי ועזרי עזר של מעטפת ביצוע בדיקות בצד המארח
external	בניית ספריית stub עבור libs חיצוניות libpng ו- zlib

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

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

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

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

מערכת בניית CMake

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

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

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

אפשרויות תצורה ניתנות ל-CMake באמצעות -D OPTION_NAME = VALUE תחביר. כמה אפשרויות נפוצות עבור deqp מפורטות להלן.

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

צור קובץ בניית יעד

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

קובץ בניית היעד יכול להוסיף נתיבי 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"

ניתן לבצע בנייה של 64 סיביות על ידי בחירת "Visual Studio VERSION Win64" כמחולל הבנייה:

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

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

תמיכה ב-EGL

ה-deqp בנוי עם טעינה דינמית עבור EGL ב-Windows אם DEQP_SUPPORT_EGL מופעל. זוהי ברירת המחדל ברוב היעדים. לאחר מכן, אם למארח יש ספריות EGL זמינות, אפשר להריץ איתם בדיקות עם פרמטר שורת הפקודה: --deqp-gl-context-type=egl

בניית אנדרואיד

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

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

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

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

בניית לינוקס

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

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

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

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

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

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

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

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

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

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

יציאת פלטפורמת מסגרת בדיקה

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

נקודת הכניסה לאפליקציה אחראית על יצירת אובייקט הפלטפורמה, יצירת אובייקט שורת פקודה ( 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 test module build עבור יעדי PC. אתה יכול לשנות את execserver/CMakeLists.txt כדי לאפשר בנייה על יעדים אחרים.

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

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

הרץ את הבדיקות

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

סביבות לינוקס ו-Windows

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

מודול	מַדרִיך	יַעַד
שרת ביצוע	build/execserver/execserver	<dst>/execserver
מודול EGL	build/modules/egl/deqp-egl	<dst>/deqp-egl
מודול GLES2	build/modules/gles2/deqp-gles2	<dst>/deqp-gles2
	data/gles2	<dst>/gles2
מודול GLES3	build/modules/gles3/deqp-gles3	<dst>/deqp-gles3
	data/gles3	<dst>/gles3
מודול GLES3.1	build/modules/gles31/deqp-gles31	<dst>/deqp-gles31
	data/gles31	<dst>/gles31
מודול GLES3.2	build/modules/gles32/deqp-gles32	<dst>/deqp-gles32
	data/gles32	<dst>/gles32

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

ארגומנטים של שורת הפקודה

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

טַעֲנָה	תיאור
--deqp-case=<casename>	הפעל מקרים התואמים דפוס נתון. תו כללי (*) נתמך.
--deqp-log-filename=<filename>	כתוב את תוצאות הבדיקה לקובץ שאת שמו אתה מספק. שירות ביצוע הבדיקה יגדיר את שם הקובץ בעת התחלת בדיקה.
--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>	קרא את רשימת המקרים מ-stdin או מארגומנט נתון. שירות ביצוע הבדיקה יקבע את הטיעון בהתאם לבקשת הביצוע שהתקבלה. עיין בסעיף הבא לתיאור של פורמט רשימת התיקים.
--deqp-test-iteration-count=<count>	עוקף את ספירת האיטרציות עבור בדיקות התומכות במספר משתנה של איטרציות.
--deqp-base-seed=<seed>	סיד בסיס למקרי הבדיקה המשתמשים באקראי.

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

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

טַעֲנָה	תיאור
--deqp-gl-context-type=<type>	סוג ההקשר של OpenGL. סוגי הקשר זמינים תלויים בפלטפורמה. בפלטפורמות התומכות ב-EGL, ניתן להשתמש בערך egl כדי לבחור את ההקשר של EGL.
--deqp-gl-config-id=<id>	הפעל בדיקות עבור מזהה תצורת ה-GL שסופק. הפרשנות תלויה בפלטפורמה. בפלטפורמת EGL, זהו מזהה תצורת EGL.
--deqp-gl-config-name=<name>	הפעל בדיקות עבור תצורת GL בשם. הפרשנות תלויה בפלטפורמה. עבור EGL, הפורמט הוא rgb(a)<bits>d<bits>s<bits> . לדוגמה, ערך של rgb888s8 יבחר את התצורה הראשונה שבה מאגר הצבע הוא RGB888 ומאגר הסטנסיל כולל 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 ומעלה).

ניתן להתקין את חבילת האפליקציה באמצעות הפקודה הבאה (השם המוצג הוא שם ה-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 CTS

כדי להתחיל באופן ידני את פעילות ביצוע הבדיקה, בנה כוונת 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"'

ניפוי באגים באנדרואיד

כדי להפעיל את הבדיקות תחת מאתר הבאגים של GDB ב-Android, תחילה הידור והתקן את ה-bug build על ידי הפעלת שני הסקריפטים הבאים:

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

לאחר התקנת ה-bug 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.

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

הפוך את הבדיקות לאוטומטיות

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

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

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

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

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

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

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

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

מבצע הבדיקה של שורת הפקודה הוא כלי נייד C++ להפעלת ריצת בדיקה במכשיר ואיסוף היומנים המתקבלים ממנו באמצעות TCP/IP. ה-Executor מתקשר עם שירות הביצוע (Execserver) במכשיר היעד. יחד הם מספקים פונקציונליות כגון התאוששות מקריסות תהליכי בדיקה. הדוגמאות הבאות מדגימות כיצד להשתמש בשורת הפקודה Test Executor (השתמש --help לפרטים נוספים):

דוגמה 1: הפעל בדיקות פונקציונליות של 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 של יומן בדיקה והשוואה

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