בודקי סטטוס המערכת (SSC) מוגדרים ברמת חבילת ההגדרות ומופעלים בין כל מודול. הם מבצעים בדיקות כדי לקבוע אם המודול השתנה ולא שחזר מצבים מסוימים, למשל שינוי ערך של מאפיין מערכת.
השימוש העיקרי ב-SSC הוא כדי לוודא שכותבי מודולים לא ישכחו לנקות אחרי הבדיקות שלהם, אבל אם הם ישכחו, המערכת תספק מעקב כדי שיהיה אפשר לטפל בבעיה.
שימוש משני הוא גם לשחזר את המצב המקורי כשאפשר, למשל, לסגור את מסך הנעילה אם הוא נשאר פתוח.
הגדרת XML של בודק סטטוס המערכת
<system_checker class="com.android.tradefed.suite.checker.KeyguardStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.LeakedThreadStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.SystemServerStatusChecker" />
ה-SSCs מוגדרים בתג system_checker בקובץ ה-XML של הגדרת Tradefed.
הטמעה
כל SSC צריך להטמיע את ISystemStatusChecker
הממשק,
שמספק את שתי השיטות העיקריות preExecutionCheck ו-postExecutionCheck
שפועלות לפני ואחרי כל הרצת מודול.
יכול להיות שבודק יטמיע רק אחת משתי האפשרויות, או שיטמיע את שתיהן אם יש צורך לבדוק את המצב לפני המודול ולהשוות אותו למצב אחרי המודול.
יש כמה דוגמאות להטמעה ב-Tradefed. מומלץ להתמקד בבדיקה אחת בכל הטמעה כדי לשפר את האפשרות לשימוש חוזר. לדוגמה,
SystemServerStatusCheck
בודק אם התהליך system_server הופעל מחדש במכשיר במהלך
ההרצה של חבילת הבדיקה. ב-postExecutionCheck, הפונקציה קוראת ל-deviceSoftRestarted,
שמוגדר ב-NativeDevice
כדי לבדוק אם התהליך system_server הופעל מחדש.
כל פעולה מחזירה את הערך
StatusCheckerResult,
שמאפשר למערכת להחליט אם צריך לתעד מידע נוסף, כמו דוח באגים.
איפה הם מוגדרים ב-CTS?
בודקי הסטטוס של מערכת CTS מוגדרים בכתובת /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml.
איך מוצאים כשלים בבדיקה
כברירת מחדל, כשלים בבדיקת המערכת מוצגים רק ביומנים ובדוחות על באגים שצולמו עבור הקריאה עם שם בפורמט bugreport-checker-post-module-<module name>.zip.
כך תוכלו לדעת אחרי איזה מודול נוצר דוח הבאגים.
אפשר להגדיר את האפשרות --report-system-checkers לערך true כדי שהדוח של בודק המערכת יופיע ככשל בבדיקה. כתוצאה מכך, הפעלת הבדיקה תוצג כנכשלה, והסיבה לכשל תהיה הבדיקה הספציפית של בודק הסטטוס.