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 יכללו את |
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 | רשימת מקור יציאות הפלטפורמה. מקורות ברירת המחדל נקבעים על סמך היכולות ומערכת ההפעלה. הערה: הנתיבים הם יחסיים ל: |
קובץ בניית היעד יכול להוסיף נתיבי 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_COMPILER | סוג מהדר. הערכים הנתמכים הם: |
DE_CPU | סוג מעבד. הערכים הנתמכים הם: |
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/qphelper/qpCrashHandler.c | אופציונלי: יישום עבור מערכת ההפעלה שלך. |
framework/qphelper/qpWatchDog.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 | קרא את רשימת המקרים מ-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-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.*
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2024-04-29 (שעון UTC).