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