سوالات متداول CTS

برنامه سازگاری اندروید ، محرک اصلی برای حفظ بازخورد مثبت برای اکوسیستم اندروید است. CTS ابزار کلیدی برای تضمین کیفیت سازگاری در مقیاس بزرگ است. تیم اندروید همچنان به بهبود ابزار CTS و پوشش تست ادامه می‌دهد. اضافه شدن منظم موارد تست، بهبود قابل توجهی در کیفیت دستگاه‌های سازگار ایجاد می‌کند.

سوالات عمومی

این بخش سوالات متداول عمومی CTS را ارائه می‌دهد.

آزمایش CTS چه چیزهایی را آزمایش می‌کند؟

CTS آزمایش می‌کند که آیا تمام APIهای پشتیبانی‌شده‌ی اندروید با نوع قوی وجود دارند و به درستی رفتار می‌کنند یا خیر. CTS همچنین سایر رفتارهای سیستمی غیر API مانند چرخه حیات و عملکرد برنامه را آزمایش می‌کند.

مجوز CTS چگونه صادر می‌شود؟

CTS تحت همان مجوز نرم‌افزار آپاچی ۲.۰ است که بخش عمده‌ای از اندروید از آن استفاده می‌کند.

آیا کدک‌ها توسط CTS تأیید شده‌اند؟

بله. تمام کدک‌های اجباری توسط CTS تأیید شده‌اند.

سوالات ویژه آزمون

این بخش سوالات متداولی را ارائه می‌دهد که به اجرای کارآمدتر تست‌های CTS کمک می‌کند.

تفاوت بین شاردینگ CTS و شاردینگ TF چیست؟

CTS Sharding و TF Sharding طرح‌های آزمایشی کاملاً متفاوتی هستند که توسط کدبیس زیرساخت آزمایشی متفاوتی پشتیبانی می‌شوند. در حالی که دستور اجرا در نسخه‌های مختلف یکسان است، نتیجه شاردینگ متفاوت رفتار می‌کند. CTS Sharding به صورت ایستا موارد آزمایشی را به دستگاه‌های تحت آزمایش (DUTs) به شرح زیر اختصاص می‌دهد:

TF Sharding به صورت پویا موارد آزمایش را به DUT های موجود به شرح زیر اختصاص می دهد:

از دستگاهی که از چندین ABI پشتیبانی می‌کند، چه انتظاری می‌رود؟

دستگاه باید تمام تست‌های CTS و CTS Verifier را برای هر حالت ABI که ادعا می‌کند از آن پشتیبانی می‌کند، با موفقیت پشت سر بگذارد. بنابراین، لازم است یک برنامه برای ABI های خاص اجرا شود. دستورالعمل‌ها برای چندین ABI به شرح زیر است:

  • برای CTS و CTS Verifier، نسخه‌های ARM و x86 برای هر معماری وجود دارد. هر یک از آنها می‌توانند از حالت ۳۲ یا ۶۴ بیتی پشتیبانی کنند.
  • برای تست‌های CTS، اگر دستگاهی از هر دو معماری ARM و x86 پشتیبانی کند، باید به ترتیب هر دو تست ARM و x86 CTS را اجرا و با موفقیت پشت سر بگذارد.

برای الزامات CDD در ABI، به CDD 3.3.1 رابط‌های دودویی برنامه مراجعه کنید.

آیا اجرای یک تست فقط روی ABI اصلی (مثلاً ۶۴ بیتی) برای کاهش زمان اجرای تست کافی است؟

خیر. یک برنامه اندروید روی زمان اجرای ۳۲ بیتی یا ۶۴ بیتی خودش اجرا می‌شود. کد ماشین واقعی، مسیر کد و حالت بین ۳۲ و ۶۴ بیتی متفاوت است. اگر از یک حالت صرف نظر کنید، فقط ۵۰٪ از ABI دستگاه را پوشش می‌دهید.

چرا تعداد زیادی از موارد تست به عنوان اجرا نشده گزارش می‌شوند؟

شما باید به جای عدد «اجرا نشده» ، عدد «انجام شده ماژول» را بررسی کنید.

در نسخه‌های قبلی، ماژول‌های CTS قبل از تکمیل شدن، به شدت به عنوان ماژول انجام شده گزارش می‌شدند. بنابراین، حتی زمانی که برخی از دستگاه‌ها مشکل داشتند، بدون اینکه تمام موارد تست کامل شده باشند، عدد ماژول انجام شده گزارش می‌شد. مهار تست جدید محافظه‌کارانه‌تر است و هنگام بروز مشکل، تعداد بیشتری از تست‌های اجرا نشده را گزارش می‌کند.

ماژولی که تا مرحله تکمیل اجرا می‌شود، در آخرین فراخوانی (done="false") در گزارش، در طول موارد زیر، عبارت «ماژول انجام نشده » را گزارش می‌دهد:

  • اجرای آزمایشی ماژول به دلیل مشکل اتصال دستگاه متوقف شد.
  • همه آزمایش‌های مورد انتظار برای ماژول انجام نشد.

  • دوباره امتحان شد (با استفاده از گزینه -r/--retry ) با گزینه‌های فیلترینگ اضافی، مانند:

    • --شامل-فیلتر
    • --حذف-فیلتر
    • ‎-t/--test (این گزینه هنوز در تلاش مجدد پشتیبانی نمی‌شود)
    • --نوع تلاش مجدد ناموفق بود
    • --زیرطرح

برای دریافت وضعیت ماژول انجام شد (done="true") برای این ماژول‌ها، مراحل زیر را برای آخرین فراخوانی دوباره انجام دهید:

run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions

ماژولی که بدون هیچ یک از مشکلات ذکر شده قبلی (حتی با 0 تست باقی مانده) اجرا شود، در گزارش جدید با عنوان ماژول انجام شده علامت گذاری می‌شود.

استثنائات

  • CtsNNAPITestCases به دلیل محدودیت آرگومان‌ها در لینوکس/سیستم‌عامل، یک مشکل شناخته‌شده دارد. این ماژول را می‌توان به‌طور جداگانه و از طریق run cts -m CtsNNAPITestCases مجدداً اجرا کرد.

چگونه می‌توانم از شکست آماده‌سازی آزمون در پشت فایروال شرکت جلوگیری کنم؟

تمام مجموعه‌های تست خودکار سعی می‌کنند فایل‌های رسانه‌ای CTS یا فایل‌های منطق تجاری را در زمان اجرا دانلود کنند. در بسیاری از محیط‌های شرکتی، فایروال و پروکسی رایج هستند که باعث می‌شوند آماده‌سازی تست با شکست مواجه شود. خط زیر را اجرا کنید یا آن را به .profile (در اوبونتو) اضافه کنید.

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

آیا برای CTS مربوط به Secure Element به سیم کارت نیاز دارم؟

اینکه آیا برای آزمایش به سیم کارت نیاز است یا خیر، بستگی به این دارد که آیا دستگاه مورد آزمایش از این ویژگی پشتیبانی می‌کند یا خیر.

  • اگر دستگاه شما نیازی به پشتیبانی از برنامه‌های اندروید که به عناصر امن دسترسی دارند - چه در UICC (مثلاً سیم‌کارت) که توسط اپراتورهای شبکه تلفن همراه (اپراتورها) توزیع شده است و چه در دستگاه تعبیه شده است - ندارد، می‌توانید مانیفست HIDL را طوری پیکربندی کنید که عنصر android.hardware.secure_element HAL را شامل نشود. در این حالت، API مربوط به android.se.omapi.SEService.getReaders() یک لیست خالی گزارش می‌دهد و تست CTS به طور خودکار قبول می‌شود و برای CTS قبولی را گزارش می‌دهد.
  • اگر دستگاه شما نیاز به پشتیبانی از برنامه‌های اندروید برای دسترسی به عناصر امن - چه در UICC (مثلاً سیم‌کارت) توزیع‌شده توسط اپراتورهای شبکه تلفن همراه (اپراتورها) و چه در دستگاه تعبیه‌شده - دارد، باید عنصر امن را به درستی پیاده‌سازی کرده و آن را به‌صورت داخلی آزمایش کنید. تست CTS برای عنصر امن، نحوه آماده‌سازی برای اجرای تست‌های CTS را که تضمین می‌کند بسته API android.se.omapi اضافه‌شده در اندروید ۹ عملکردی دارد، شرح می‌دهد. ما همچنین توصیه می‌کنیم آزمایش‌های اضافی را خودتان انجام دهید زیرا پوشش تست CTS حداقل است.

سیم کارت‌های CTS مربوط به Secure Element را از کجا می‌توانم تهیه کنم؟

می‌توانید با فروشنده سیم‌کارت مورد نظر خود تماس بگیرید.

چرا هنگام اجرای CTS با استفاده از توکن شاردینگ، سیم‌کارت نارنجی روی صفحه قفل نمایش داده می‌شود؟

مورد آزمایشی شروع نمی‌شود زیرا آزمایش سیم‌کارت قفل شده است. قبل از اجرای CTS با تقسیم توکن، قفل سیم‌کارت را در تنظیمات قفل سیم‌کارت غیرفعال کنید.

تست زمانی اجرا می‌شود که feature flags در دستگاه غیرفعال باشند

برای همه پرچم‌های موجود در نسخه‌های منتشر شده، حاشیه‌نویسی @RequiresFlagsEnabled یا @RequiresFlagsDisabled از مقادیر پرچم‌ها از پیکربندی انتشار دودویی CTS استفاده می‌کند، نه از پیکربندی انتشار دستگاه. غیرفعال کردن پرچم‌ها در دستگاه، تست را غیرفعال نمی‌کند زیرا مجموعه تست‌های CTS که برای یک نسخه خاص اجرا می‌شوند، به پیکربندی منتشر شده پلتفرم AOSP ثابت شده‌اند.