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

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

سوالات عمومی

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

آزمایش CTS چه نوع چیزهایی را انجام می دهد؟

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

مجوز CTS چگونه است؟

CTS تحت مجوز نرم افزار Apache 2.0 که اکثر اندرویدها از آن استفاده می کنند مجوز دارد.

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

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

سوالات اختصاصی آزمون

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

تفاوت بین CTS Sharding و TF Sharding چیست؟

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

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

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

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

  • برای CTS و CTS Verifier، نسخه های ARM و x86 برای هر معماری وجود دارد. هر کدام از آنها می توانند از حالت 32 یا 64 بیتی پشتیبانی کنند.
  • برای تست‌های CTS، اگر دستگاهی از هر دو ARM و x86 پشتیبانی می‌کند، باید هر دو تست ARM و x86 CTS را اجرا کرده و بگذراند.

CDD 3.3.1 را ببینید. کاربرد رابط های باینری برای الزامات CDD در ABI.

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

نه. یک برنامه اندروید با زمان اجراهای 32 بیتی یا 64 بیتی خود اجرا می شود. کد واقعی ماشین، مسیر کد، و وضعیت بین 32 و 64 متفاوت است. اگر از یک حالت رد شوید، فقط 50٪ از ABI دستگاه را پوشش می دهید.

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

شما باید شماره Module Done را به جای Not Executed بررسی کنید.

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

یک ماژول اجرا شده تا تکمیل، ماژول انجام نشده را در آخرین فراخوانی (انجام شده = "نادرست") در گزارش در طی موارد زیر گزارش می دهد:

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

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

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

برای به دست آوردن وضعیت ماژول انجام شده (انجام شد = "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 یک مشکل شناخته شده به دلیل محدودیت linux/OS در args دارد. ماژول را می توان به صورت مجزا از طریق run cts -m CtsNNAPITestCases به طور مستقیم اجرا کرد.

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

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

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

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

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

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

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

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

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

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