بررسی‌کننده‌های وضعیت سیستم (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" />
SSCها تحت تگ system_checker در پیکربندی Tradefed XML تعریف می شوند.
پیاده سازی
هر 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 گزارش بررسی سیستم را به عنوان یک خطای آزمایشی تبدیل کنید. این منجر به اجرای آزمایشی می‌شود که ناموفق نشان داده می‌شود و دلیل شکست بررسی خاص بررسی‌کننده وضعیت است.