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

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

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

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

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

מערכת build של CMake

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

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

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

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

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

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

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

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

build של 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' כמכשיר ליצירת הגרסה:

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

כל קובצי ה-binaries של 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 Tools,‏ SDK Platform-tools ו-SDK Build-tools שמותקנות
• Apache Ant 1.9.4 (נדרש ל-build של קוד Java)
• CMake 2.8.12 ואילך
• Python 2.6 ואילך בסדרת 2.x. אין תמיכה ב-Python 3.x
• ב-Windows: NMake או JOM ב-PATH
  • JOM מאפשרת לבנות גרסאות build מהר יותר
• אופציונלי: יש תמיכה ב-Ninja make גם ב-Linux

קובצי ה-bin של Ant ו-SDK נמצאים על סמך משתנה הסביבה PATH, עם ברירת מחדל מסוימת שגוברת על הערך שלו. הלוגיקה נשלטת על ידי android/scripts/common.py.

ספריית ה-NDK צריכה להיות ~/android-ndk-VERSION או C:/android/android-ndk-VERSION, או מוגדרת באמצעות משתנה הסביבה ANDROID_NDK_PATH.

הרכיבים של Deqp במכשיר, שירות ביצוע הבדיקה ותוכניות הבדיקה נוצרים על ידי הרצת הסקריפט android/scripts/build.py. קובץ ה-apk .הסופי נוצר ב-android/package/bin וניתן להתקין אותו באמצעות הסקריפט install.py. אם משתמשים במפעיל שורת הפקודה, שירות ExecService מופעל עם הסקריפט launch.py במכשיר דרך ADB. אפשר להריץ את הסקריפטים מכל ספרייה.

גרסה של Linux

אפשר ליצור קובצי אימג' וביישומי שירות לשורת הפקודה ל-Linux על ידי יצירת קובצי make באמצעות CMake. יש כמה יעדי build מוגדרים מראש שיכולים להיות שימושיים כשמפתחים ל-Linux.

תמיד צריך להשתמש ב--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 ספרייה נוספת או נתיבי חיפוש.

דוגמה לשורת פקודה מלאה שמשמשת ליצירת גרסה לניפוי באגים של 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. קובץ toolchain מציין את המהדרר שבו צריך להשתמש, יחד עם נתיבי חיפוש מותאמים אישית לספריות ולכותרות. כמה קבצים של כלי הפיתוח לתרחישים נפוצים כלולים בחבילת המהדורה בתיקייה framework/delibs/cmake.

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

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

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

ספריות בסיסיות להעברה

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

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

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

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

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

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

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

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

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

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

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

הרצת הבדיקות

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

סביבות Linux ו-Windows

מתחילים בהעתקת הקבצים והתיקיות הבאים ליעד.

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

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

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

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

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

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

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

אחרי שמתקינים את גרסה ה-debug 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. אפשר למצוא פתרונות זמניים ב באג הציבורי הזה. מערכת ההפעלה Android מגרסה 4.4 ואילך לא מכילה את הבאג הזה.

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

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

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

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

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

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

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

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

מנגנון להרצת בדיקות בשורת הפקודה

מנהל הבדיקה של שורת הפקודה הוא כלי נייד ב-C++‏‎ שמאפשר להפעיל בדיקה במכשיר ולאסוף את היומנים שנוצרים כתוצאה ממנה דרך TCP/IP. ה-Executor מתקשר עם שירות הביצוע (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 מניב את קוד התוצאה של הבדיקה, למשל 'הצלחה' או 'כישלון'. הארגומנט --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', ותוצאות אחרות נחשבות לכישלונות. קוד התוצאה המקורי של deqp זמין בפלט של JUnit. נתונים אחרים, כמו הודעות ביומן ותמונות של תוצאות, לא נשמרים בהמרה.

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

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

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

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

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

קבוצות בדיקה

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

בדיקות עומס ממושכות של עיבוד

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

קבוצות בדיקה

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