יכול להיות שיהיה קשה להפוך את בדיקת המשחקים לאוטומטית כשאפליקציות המשחקים מבוססות על מסגרות UI שונות. בדיקות לולאת משחקים מאפשרות לך לשלב את הבדיקות המקוריות עם Test Lab ולהריץ אותם בקלות במכשירים נבחרים. בבדיקה של Game Loop, הבדיקה מתבצעת באפליקציית המשחק תוך סימולציה של הפעולות של שחקן אמיתי. הזה מדריך שמראה איך להריץ בדיקה של לולאת משחקים ולאחר מכן להציג ולנהל את הבדיקה התוצאות במסוף Firebase.
בהתאם למנוע המשחק, אפשר להטמיע בדיקות עם אפשרות אחת או יותר לולאות. לולאה היא הרצה מלאה או חלקית של הבדיקה. באפליקציית המשחקים. אפשר להשתמש בלולאות משחקים כדי:
- הפעלת שלב במשחק באותו אופן שבו משתמש קצה יכול לשחק בו. אפשר לכתוב סקריפט של הקלט של המשתמש, לאפשר למשתמש להיות במצב חוסר פעילות או להחליף את המשתמש ב-AI אם זה הגיוני במשחק (לדוגמה, אם יש לכם אפליקציית משחק מכוניות מרוץ שכבר הטמעתם בה AI. אפשר ליישם בקלות נהג/ת שאחראי על הקלט של המשתמש).
- אפשר להריץ את המשחק בהגדרה של האיכות הגבוהה ביותר כדי לראות אם מכשירים תומכים בו.
- מריצים בדיקה טכנית (צריך להדר מספר תוכנות הצללה (shader), לבצע אותם ולוודא הפלט אמור לעבוד כמצופה וכו').
אפשר להריץ בדיקה של לולאת משחקים במכשיר בדיקה יחיד, בקבוצה של מכשירי בדיקה או בתאריך Test Lab. עם זאת, לא מומלץ להריץ בדיקות של Game Loop במכשירים וירטואליים כי שיעור הפריימים של הגרפיקה שלהם נמוך יותר מאשר במכשירים פיזיים.
לפני שמתחילים
כדי להטמיע בדיקה, קודם צריך להגדיר את האפליקציה לבדיקות לולאת משחקים.
בקובץ המניפסט של האפליקציה, מוסיפים מסנן Intent חדש לפעילות:
<activity android:name=".MyActivity"> <intent-filter> <action android:name="com.google.intent.action.TEST_LOOP"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="application/javascript"/> </intent-filter> <intent-filter> ... (other intent filters here) </intent-filter> </activity>
כך יתאפשר ל-Test Lab להפעיל את המשחק על ידי הפעלתו באמצעות בכוונה טובה.
.בקוד (מומלץ בתוך ההצהרה של ה-method
onCreate
), מוסיפים את הבאים:Kotlin+KTX
val launchIntent = intent if (launchIntent.action == "com.google.intent.action.TEST_LOOP") { val scenario = launchIntent.getIntExtra("scenario", 0) // Code to handle your game loop here }
Java
Intent launchIntent = getIntent(); if(launchIntent.getAction().equals("com.google.intent.action.TEST_LOOP")) { int scenario = launchIntent.getIntExtra("scenario", 0); // Code to handle your game loop here }
כך הפעילות שלכם תוכל לבדוק את הכוונה שמקיפה אותה. אפשר גם להוסיף את הקוד הזה מאוחר יותר, אם רוצים (למשל, אחרי הטעינה הראשונית של מנוע המשחק).
מומלץ: בסוף הבדיקה, מוסיפים:
Kotlin+KTX
yourActivity.finish()
Java
yourActivity.finish();
הפעולה הזו גורמת לסגירת האפליקציה כשהבדיקה של לולאת המשחק מסתיימת. הבדיקה מסתמכת על ה-framework של ממשק המשתמש של האפליקציה כדי להתחיל את הלולאה הבאה, וסגירת האפליקציה מציינת זאת שהבדיקה הסתיימה.
יצירה והפעלה של בדיקה ללולאת משחקים
אחרי שהגדרתם את האפליקציה לבדיקות של לולאת משחקים, אפשר ליצור מיד לבדוק ולהריץ אותו באפליקציית המשחקים שלך. אפשר להריץ בדיקה Test Lab באמצעות המסוף של Firebase או באמצעות gcloud בממשק שורת הפקודה (CLI) או במכשיר מקומי שמשתמש בלולאת הבדיקה מנהל.
הפעלה במכשיר מקומי
Test Loop Manager של Test Lab היא אפליקציה בקוד פתוח שבעזרתה אפשר לשלב בדיקות של Game Loop ולהריץ אותן במכשירים המקומיים. היא גם מאפשרת צוות הבטחת האיכות יפעיל את אותם לולאות משחקים במכשירים שלהם.
כדי להריץ בדיקה במכשיר מקומי באמצעות מנהל לולאת הבדיקה:
- מורידים את מנהל לולאת הבדיקה
בטלפון או בטאבלט, ולהתקין אותם באמצעות:
adb install testloopmanager.apk
- במכשיר, פותחים את האפליקציה אפליקציות לבדיקה של לולאת בדיקה בטלפון או הטאבלט. האפליקציה מציגה במכשיר רשימה של אפליקציות שניתן להריץ עם לולאות של משחקים. אם אפליקציית המשחקים שלך לא מופיעה כאן, עליך לוודא מסנן Intent תואם לזה שמתואר בשלב הראשון של לפני שמתחילים את הקטע.
- בוחרים את אפליקציית המשחקים ולאחר מכן בוחרים את מספר הלולאות שרוצים להפעיל. הערה: בשלב הזה, אפשר להריץ קבוצת משנה של לולאות במקום רק לולאה אחת. מידע נוסף על הפעלת מספר לולאות בו-זמנית. ראו תכונות אופציונליות.
- לוחצים על הפעלת בדיקה. הבדיקה תתחיל לפעול באופן מיידי.
הפעלה ב-Test Lab
אפשר להריץ בדיקה של לולאת משחקים ב-Test Lab באמצעות המסוף של Firebase או של ה-CLI של gcloud. לפני שמתחילים מתחילים, אם עדיין לא עשיתם זאת, פותחים את במסוף Firebase ויוצרים פרויקט.
שימוש במסוף Firebase
- במסוף Firebase, לוחצים על Test Lab בחלונית הימנית.
- לוחצים על Run Your First Test (הרצת הבדיקה הראשונה) (או על Run a Test, אם הפרויקט כולל בעבר להריץ בדיקה).
- בוחרים באפשרות לולאת משחקים בתור סוג הבדיקה, ואז לוחצים על המשך.
- לוחצים על עיון ועוברים לקובץ
.apk
של האפליקציה. הערה: בשלב הזה, אפשר להפעיל קבוצת משנה של לולאות במקום רק לולאה אחת. מידע נוסף על להפעיל כמה לולאות בו-זמנית, תכונות אופציונליות. - לוחצים על המשך.
- בחירת המכשירים הפיזיים שישמשו לבדיקת האפליקציה שלך.
- לוחצים על Start Tests (התחלת הבדיקות).
לקבלת מידע נוסף על תחילת העבודה עם המסוף של Firebase, ניתן לעיין במאמר התחלת הבדיקה באמצעות המסוף של Firebase.
שימוש בשורת הפקודה של gcloud (CLI)
אם עדיין לא עשיתם זאת, מורידים ומתקינים את Google Cloud SDK.
נכנסים ל-CLI של gcloud באמצעות חשבון Google:
gcloud auth login
מגדירים את פרויקט Firebase ב-gcloud, שבו
PROJECT_ID
המזהה של פרויקט Firebase:gcloud config set project PROJECT_ID
הריצו את הבדיקה הראשונה:
gcloud firebase test android run \ --type=game-loop --app=<var>path-to-apk</var> \ --device model=herolte,version=23
למידע נוסף על תחילת העבודה עם ה-CLI של gcloud: התחלת הבדיקה משורת הפקודה של gcloud.
תכונות אופציונליות
ב-Test Lab יש כמה תכונות אופציונליות שמאפשרות להתאים אישית את הבדיקות עוד יותר, כולל היכולת לכתוב נתוני פלט, תמיכה במספר לולאות משחק ותוויות ללולאות קשורות.
כתיבת נתוני פלט
הבדיקה של לולאת המשחק יכולה לכתוב פלט לקובץ שצוין ב
אמצעי תשלום אחד (launchIntent.getData()
). אחרי שמריצים בדיקה, אפשר לגשת לנתוני הפלט האלה בקטע Test Lab במסוף Firebase (ראו דוגמה לקובץ פלט של בדיקת Game Loop).
האפליקציה Test Lab פועלת לפי השיטות המומלצות לשיתוף קובץ בין האפליקציות שמתוארות ב
שיתוף קובץ.
בשיטת onCreate()
של הפעילות, שבה נמצאת הכוונה שלך,
כדי לבדוק את קובץ פלט הנתונים באמצעות הרצת הקוד הבא:
Kotlin+KTX
val launchIntent = intent val logFile = launchIntent.data logFile?.let { Log.i(TAG, "Log file ${it.encodedPath}") // ... }
Java
Intent launchIntent = getIntent(); Uri logFile = launchIntent.getData(); if (logFile != null) { Log.i(TAG, "Log file " + logFile.getEncodedPath()); // ... }
אם רוצים לכתוב לקובץ מהצד C++ של אפליקציית המשחק, אפשר מעבירים את מתאר הקובץ במקום את נתיב הקובץ:
Kotlin+KTX
val launchIntent = intent val logFile = launchIntent.data var fd = -1 logFile?.let { Log.i(TAG, "Log file ${it.encodedPath}") fd = try { contentResolver .openAssetFileDescriptor(logFile, "w")!! .parcelFileDescriptor .fd } catch (e: FileNotFoundException) { e.printStackTrace() -1 } catch (e: NullPointerException) { e.printStackTrace() -1 } } // C++ code invoked here. // native_function(fd);
Java
Intent launchIntent = getIntent(); Uri logFile = launchIntent.getData(); int fd = -1; if (logFile != null) { Log.i(TAG, "Log file " + logFile.getEncodedPath()); try { fd = getContentResolver() .openAssetFileDescriptor(logFile, "w") .getParcelFileDescriptor() .getFd(); } catch (FileNotFoundException e) { e.printStackTrace(); fd = -1; } catch (NullPointerException e) { e.printStackTrace(); fd = -1; } } // C++ code invoked here. // native_function(fd);
C++
#include <unistd.h> JNIEXPORT void JNICALL Java_my_package_name_MyActivity_native_function(JNIEnv *env, jclass type, jint log_file_descriptor) { // The file descriptor needs to be duplicated. int my_file_descriptor = dup(log_file_descriptor); }
דוגמה לקובץ פלט
אפשר להשתמש בקובצי פלט של נתוני פלט (בפורמט של הדוגמה בהמשך) כדי להציג את המשחק
תוצאות בדיקת הלולאה בקטע Test Lab במסוף Firebase.
האזורים שמוצגים בתור /.../
יכולים להכיל כל שדה בהתאמה אישית שדרוש לך, כל עוד
הם לא מתנגשים עם שמות של שדות אחרים שמופיעים בקובץ הזה:
{ "name": "test name", "start_timestamp": 0, // Timestamp of the test start (in us). Can be absolute or relative "driver_info": "...", "frame_stats": [ { "timestamp": 1200000, // Timestamp at which this section was written It contains value regarding the period start_timestamp(0) -> this timestamp (1200000 us) "avg_frame_time": 15320, // Average time to render a frame in ns "nb_swap": 52, // Number of frame rendered "threads": [ { "name": "physics", "Avg_time": 8030 // Average time spent in this thread per frame in us }, { "name": "AI", "Avg_time": 2030 // Average time spent in this thread per frame in us } ], /.../ // Any custom field you want (vertices display on the screen, nb units …) }, { // Next frame data here, same format as above } ], "loading_stats": [ { "name": "assets_level_1", "total_time": 7850, // in us /.../ }, { "name": "victory_screen", "total_time": 554, // in us /.../ } ], /.../, // You can add custom fields here }
מספר לולאות של משחקים
כדאי להפעיל כמה לולאות משחקים באפליקציה. לולאה היא את כל הרצת המשחק של אפליקציית המשחקים שלך מתחילתה ועד סופה. לדוגמה, אם יש כמה שלבים במשחק, כדאי שיהיה לולאה אחת להפעיל כל שלב במקום ליצור לולאה אחת שחוזרת על עצמה פעם אחת בכל שלב. כך, אם האפליקציה קורסת ברמה 32, אפשר להפעיל את המשחק ישירות כדי לשחזר את הקריסה ולבדוק תיקוני באגים.
כדי לאפשר לאפליקציה להריץ מספר לולאות בו-זמנית:
אם אתם מריצים בדיקה באמצעות מנהל לולאת הבדיקה:
מוסיפים את השורה הבאה למניפסט של האפליקציה, בתוך הרכיב
<application>
:<meta-data android:name="com.google.test.loops" android:value="5" />
כוונת ההפעלה הזו מכילה את לולאת היעד כפרמטר של מספר שלם. בשדה
android:value
אפשר לציין מספר שלם מ-1 עד 1,024 (מספר הלולאות המקסימלי המותר לבדיקה אחת). הערה שלולאות נוספות לאינדקס החל מ-1 ולא מ-0.באפליקציה 'מנהל לולאת הבדיקה', מופיע מסך בחירה מאפשרת לבחור אילו לולאות רוצים להפעיל. אם בוחרים כמה אפשרויות לולאות, כל לולאה מופעלת ברצף אחרי הלולאה הקודמת שהושלמו.
אם מתבצעת בדיקה באמצעות מסוף Firebase, צריך להזין רשימה או טווח מספרי הלולאה בשדה תרחישים.
אם מריצים בדיקה באמצעות ה-CLI של gcloud, מציינים רשימה של מספרי לולאות באמצעות הדגל
--scenario-numbers
. לדוגמה, הערך--scenario-numbers=1,3,5
מפעיל את הלולאות 1, 3 ו-5.אם אתם כותבים C++ ואתם רוצים לשנות את ההתנהגות של הלולאה, העבירו את שבהמשך לקוד C++ המקורי:
Kotlin+KTX
val launchIntent = intent val scenario = launchIntent.getIntExtra("scenario", 0)
Java
Intent launchIntent = getIntent(); int scenario = launchIntent.getIntExtra("scenario", 0);
עכשיו אפשר לשנות את התנהגות הלולאה על סמך ה-
int
שמתקבל עם ערך מסוים.
מתן תוויות ל-game loops
כשאתם מסמנים את מחזורי המשחק שלכם בתווית תרחיש אחת או יותר, אתם וצוות בקרת האיכות יכולים להפעיל בקלות קבוצה של מחזורי משחק קשורים (למשל, "כל לולאות המשחקים התואמות") ולבדוק אותן במטריצה אחת. אתם יכולים ליצור תוויות משלכם או להשתמש בתוויות המוגדרות מראש שמוצעות על ידי Test Lab:
com.google.test.loops.player_experience
: ללולאות שמשמשות לשחזר חוויה של משתמש אמיתי בזמן המשחק. המטרה של במסגרת לולאות אלה, נוכל לגלות בעיות שמשתמש אמיתי ייתקל בהן לשחק את המשחק.com.google.test.loops.gpu_compatibility
: ללולאות שמשמשות לבדיקה בעיות שקשורות ל-GPU. מטרת הבדיקה באמצעות לולאות אלה היא להפעיל GPU שייתכן שלא יפעל כראוי בסביבת הייצור, כדי לחשוף בעיות חומרה ומנהלי התקנים.com.google.test.loops.compatibility
: לולאות For שמשמשות לבדיקת מגוון רחב של בעיות תאימות, כולל בעיות קלט/פלט ובעיות ב-OpenSSL.com.google.test.loops.performance
: ללולאות שמשמשות לבדיקת הביצועים של המכשיר. לדוגמה, משחק עשוי לפעול ברמת המורכבות ביותר הגרפיקה כדי לראות את ההתנהגות של מכשיר חדש.
כדי לאפשר לאפליקציה להריץ לולאות עם אותה תווית:
אם אתם מריצים בדיקה באמצעות Test Loop Manager:
במניפסט של האפליקציה, צריך להוסיף את שורת המטא-נתונים הבאה ולהחליף LABEL_NAME בתווית לבחירתכם:
<meta-data android:name="com.google.test.loops.LABEL_NAME" android:value="1,3-5" />
בשדה
android:value
אפשר לציין טווח או קבוצה של מספרים שלמים מ-1 עד 1,024 (מספר הלולאות המקסימלי המותר בבדיקה יחידה) שמייצגים את הלולאות שרוצים להוסיף להן תווית. חשוב לשים לב שלולאות נוספות לאינדקס החל מ-1 ולא מ-0. לדוגמה,android:value="1,3-5"
מחילה את LABEL_NAME על הלולאות 1, 3, 4 ו-5.באפליקציה 'מנהל לולאת הבדיקה', מזינים תווית אחת או יותר בקטע תוויות השדה הזה.
אם מתבצעת בדיקה באמצעות מסוף Firebase, צריך להזין לפחות שם אחד תוויות בשדה תוויות.
אם מריצים בדיקה באמצעות ה-CLI של gcloud, מציינים תווית אחת או יותר של תרחיש באמצעות הדגל
--scenario-labels
(למשל,--scenario-labels=performance,gpu
).
תמיכה ברישוי אפליקציות
Test Lab תומך באפליקציות שמשתמשות בשירות רישוי אפליקציות ש-Google Play מציעה. איך לבדוק את הרישיון במהלך הבדיקה את האפליקציה ב-Test Lab, חובה לפרסם את האפליקציה בערוץ הייצור בחנות Play. כדי לבדוק את האפליקציה בערוץ אלפא או בטא באמצעות Test Lab, יש להסיר את בדיקת הרישיון לפני העלאת האפליקציה אל Test Lab
בעיות מוכרות
בבדיקות של לולאת המשחק ב-Test Lab זוהו הבעיות הידועות הבאות:
- בחלק מהקריסות אין תמיכה במעקב לאחור. לדוגמה, בחלק מהגרסאות ה-build של גרסאות זמינות, הפלט של התהליך
debuggerd
עשוי להיות מושתק באמצעותprctl(PR_SET_DUMPABLE, 0)
. מידע נוסף זמין במאמרdebuggerd
. - רמת ה-API ברמה 19 לא נתמכת כרגע עקב שגיאות בהרשאות הקובץ.