בדוק את מצב המערכת

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

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

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

הגדרת 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 . כתוצאה מכך, ריצת בדיקה מוצגת ככשלה כשהסיבה לכישלון היא בדיקה מסוימת של בודק המצב.