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

מערכת build של CMake

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

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

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

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

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

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

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

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

גרסת Win32

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

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

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

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

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

אפשר גם ליצור קובצי makefile של 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

‫Android build

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

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

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

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

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

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

גרסת build של Linux

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

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

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

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

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

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

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

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

אפשר לבחור את קובץ ה-toolchain באמצעות פרמטר ה-build‏ CMAKE_TOOLCHAIN_FILE. לדוגמה, הפקודה הבאה תיצור קובצי makefile ל-build באמצעות קומפיילר חוצה של CodeSourcery ל-ARM/Linux:

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

קישור בזמן ריצה של ספריות GLES ו-EGL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הרצת הבדיקות

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

סביבות Linux ו-Windows

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

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

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

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

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

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

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

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

{nodeName{firstChild{…},…lastChild{…}}}

לדוגמה:

{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}

התרגום לשני תרחישי הבדיקה הבאים:

dEQP-EGL.config_list
dEQP-EGL.create_context.rgb565_depth_stencil

Android

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

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

adb –d install –r com.drawelements.deqp.apk

כדי להפעיל את שירות הרצת הבדיקות ולהגדיר העברת יציאות, משתמשים בפקודות הבאות:

adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter

אפשר להפעיל הדפסות של ניפוי באגים על ידי הפעלת הפקודה הבאה לפני התחלת הבדיקות:

adb –d shell setprop log.tag.dEQP DEBUG

הרצת בדיקות ב-Android בלי Android CTS

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

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

אפשר להפעיל פעילות משורת הפקודה באמצעות כלי השירות am. לדוגמה, כדי להריץ בדיקות dEQP-GLES2.info בפלטפורמה שתומכת ב-NativeActivity,, משתמשים בפקודות הבאות.

adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \
'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'

ניפוי באגים ב-Android

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

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

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

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

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

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

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

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

דוגמה 1: הרצת בדיקות פונקציונליות של GLES2 במכשיר Android

executor --connect=127.0.0.1 --port=50016 --binaryname=
com.drawelements.deqp/android.app.NativeActivity
--caselistdir=caselists
--testset=dEQP-GLES2.* --out=BatchResult.qpa
--cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable
--deqp-gl-config-name=rgba8888d24s8"

דוגמה 2: המשך של הרצת בדיקה חלקית של OpenGL ES 2 באופן מקומי

executor --start-server=execserver/execserver --port=50016
--binaryname=deqp-gles2 --workdir=modules/opengl
--caselistdir=caselists
--testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa
--out=BatchResult.qpa

ייצוא של יומן הבדיקה בפורמט CSV והשוואה

ב-deqp יש כלי להמרת יומני בדיקה (קובצי ‎.qpa) לקובצי CSV. פלט ה-CSV מכיל רשימה של תרחישי בדיקה והתוצאות שלהם. הכלי יכול גם להשוות בין שתי תוצאות או יותר של חבילות, ולפרט רק את תרחישי הבדיקה שיש להם קודי סטטוס שונים בתוצאות של חבילות הקלט. בנוסף, בהשוואה יודפס מספר המקרים התואמים.

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

דוגמה 1: ייצוא יומן בדיקה בפורמט CSV

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

דוגמה 2: רשימת ההבדלים בתוצאות הבדיקה בין שני יומני בדיקה

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

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

בדיקת ייצוא של יומן בפורמט XML

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

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

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

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

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

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

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

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

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

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

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

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

קבוצות בדיקה

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

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

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

קבוצות בדיקה

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