بررسیکنندههای وضعیت سیستم (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 در XML پیکربندی Tradefed تعریف میشوند.
پیادهسازی
هر SSC باید رابط ISystemStatusChecker پیادهسازی کند، که دو متد اصلی preExecutionCheck و postExecutionCheck را ارائه میدهد که قبل و بعد از هر اجرای ماژول اجرا میشوند.
یک بررسیکننده میتواند فقط یکی از این دو را پیادهسازی کند، یا اگر نیاز به بررسی وضعیت قبل از ماژول و مقایسه آن با وضعیت بعد از ماژول باشد، هر دو را پیادهسازی کند.
چندین پیادهسازی نمونه در Tradefed وجود دارد. توصیه میشود هر پیادهسازی روی یک بررسی واحد تمرکز کند تا قابلیت استفاده مجدد بهبود یابد. به عنوان مثال، SystemServerStatusCheck بررسی میکند که آیا فرآیند system_server در طول اجرای مجموعه تست روی دستگاه مجدداً راهاندازی شده است یا خیر. در postExecutionCheck ، deviceSoftRestarted را فراخوانی میکند که در NativeDevice تعریف شده است تا بررسی کند که آیا فرآیند system_server مجدداً راهاندازی شده است یا خیر.
هر عملیات StatusCheckerResult را برمیگرداند، که به Harness اجازه میدهد تصمیم بگیرد که آیا اطلاعات اضافی، مانند گزارش اشکال، باید ثبت شود یا خیر.
آنها در 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 ، گزارش بررسیکننده سیستم را به عنوان یک شکست آزمایشی تنظیم کرد. این کار باعث میشود که اجرای آزمایشی به عنوان شکست خورده نمایش داده شود و دلیل شکست، بررسی خاص بررسیکننده وضعیت باشد.