کنسول فرمان CTS v2

از کنسول CTS v2 استفاده کنید

برای Android 7.0 یا بالاتر، از CTS v2 استفاده کنید.

طرح ها را انتخاب کنید

برنامه های آزمون موجود شامل موارد زیر است:

  • cts - CTS را از یک نصب CTS از قبل موجود اجرا می کند.
  • cts-camera — دوربین CTS را از یک نصب CTS از قبل موجود اجرا می کند.
  • cts-java - آزمایش‌های جاوای هسته‌ای را از یک نصب CTS از قبل موجود اجرا می‌کند.
  • cts-pdk - آزمایش‌هایی را اجرا می‌کند که برای اعتبارسنجی ساخت fusion PDK مفید هستند.
  • همه چیز - پیکربندی رایج برای مجموعه های سازگاری.

سایر تنظیمات موجود شامل موارد زیر است:

  • Basic-Reporters - پیکربندی با گزارشگران اصلی CTS.
  • collect-tests-only - CTS را از یک نصب CTS از قبل موجود اجرا می کند.
  • common-compatibility-config - پیکربندی رایج برای مجموعه های سازگاری.
  • cts-filtered-sample — پیکربندی رایج برای مجموعه های سازگاری.
  • cts-known-failures — پیکربندی با خرابی های شناخته شده CTS.
  • cts-preconditions - تنظیمات پیش شرط CTS.
  • میزبان - یک آزمایش مبتنی بر میزبان را روی یک دستگاه موجود اجرا می کند.
  • ابزار - یک تست ابزار دقیق اندروید را روی یک دستگاه موجود اجرا می کند.
  • Native-Benchmark - تست استرس بومی را روی دستگاه موجود اجرا می کند.
  • Native-stress - یک تست استرس بومی را روی یک دستگاه موجود اجرا می کند.
  • شارژ مجدد - یک آزمایش جعلی که منتظر دستگاه‌های تقریباً تخلیه شده است و آنها را برای شارژ نگه می‌دارد.
  • testdef - آزمایش‌های موجود در فایل‌های test_def.xml را روی دستگاه موجود اجرا می‌کند.
  • util/wifi — پیکربندی ابزار برای پیکربندی Wi-Fi در دستگاه.
  • util/wipe - داده های کاربر را روی دستگاه پاک می کند.

تمام این پلان ها و تنظیمات را می توان با دستور run cts اجرا کرد.

مرجع فرمان کنسول CTS v2

این جدول دستورات کنسول CTS v2 را برای کاربردهای مختلف خلاصه می کند.

میزبان شرح
help نمایش خلاصه ای از متداول ترین دستورات
help all نمایش لیست کامل دستورات موجود
version نسخه را نشان دهید.
exit به آرامی از کنسول CTS خارج شوید. زمانی که تمام تست‌های در حال اجرا به پایان رسید، کنسول بسته می‌شود.
extdir

فایل زیپ شده دانلودها به extdir از حالت فشرده خارج می شود. اگر می خواهید از شر خروجی باد شده خلاص شوید، از گزینه -q استفاده کنید:

unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir

اگر می خواهید از حالت فشرده به دایرکتوری فعلی خارج شوید، از گزینه -d استفاده نکنید، به سادگی اجرا کنید:

unzip -q android-cts-9.0_r15-linux_x86-arm.zip

اجرا کن شرح
run cts

در اندروید 10، برنامه پیش‌فرض CTS و CTS-Instant را با هم اجرا کنید (یعنی فراخوانی کامل CTS). برای اندروید 9 یا پایین‌تر، فقط طرح پیش‌فرض CTS را اجرا کنید. از این گزینه جامع (شامل پیش شرط ها) برای اعتبارسنجی دستگاه استفاده کنید. برای گنجاندن به cts.xml مراجعه کنید.

کنسول CTS می تواند دستورات دیگر را در حین انجام آزمایش بپذیرد.

اگر هیچ دستگاهی متصل نباشد، دستگاه دسکتاپ CTS (یا میزبان) قبل از شروع آزمایش منتظر می‌ماند تا دستگاهی متصل شود. اگر بیش از یک دستگاه متصل باشد، میزبان CTS یک دستگاه را به طور خودکار انتخاب می کند.

run cts-instant

برای اندروید 9، طرح پیش‌فرض CTS-Instant را اجرا کنید.

run cts --module-parameter INSTANT_APP

در اندروید 10، طرح پیش‌فرض CTS-Instant را اجرا کنید.

run cts --module-parameter INSTANT_APP --module/-m test_module_name

در اندروید 10، ماژول یا ماژول های تست CTS-Instant مشخص شده را اجرا کنید.

run retry

فقط برای اندروید 9 یا بالاتر. تمام تست هایی که در جلسات قبلی شکست خورده اند یا اجرا نشده اند را دوباره امتحان کنید. به عنوان مثال، run retry --retry -s یا run retry --retry --shard-count .

run cts --retry برای اندروید 9 یا بالاتر مجاز نیست.

run cts-sim

برای اندروید 11 یا نسخه های بالاتر. زیرمجموعه آزمایش ها را روی دستگاهی با سیم کارت اجرا می کند.

--device-token

برای اندروید 8.1 یا نسخه های پایین تر. مشخص می کند که یک دستگاه معین دارای نشانه داده شده است. به عنوان مثال، --device-token 1a2b3c4d:sim-card .

--enable-token-sharding

فقط برای اندروید 10 یا بالاتر . به طور خودکار آزمایشی را که به نوع سیم کارت مربوطه نیاز دارد مطابقت می دهد. بدون نیاز به ارائه شماره سریال دستگاه برای اجرای تست های مربوط به سیم کارت. سیم‌کارت‌های پشتیبانی‌شده: SIM_CARD ، UICC_SIM_CARD ، و SECURE_ELEMENT_SIM_CARD .

run cts-dev

طرح پیش‌فرض CTS را اجرا کنید (یعنی فراخوانی کامل CTS) اما برای صرفه‌جویی در زمان اجرا برای توسعه تکراری یک تست جدید، از پیش‌شرط‌ها صرفنظر کنید. این کار تأیید و تنظیم پیکربندی دستگاه را دور می‌زند، مانند فشار دادن فایل‌های رسانه یا بررسی اتصال Wi-Fi، همانطور که هنگام استفاده از گزینه --skip-preconditions انجام می‌شود. این دستور همچنین از جمع‌آوری اطلاعات دستگاه و تمام بررسی‌کننده‌های وضعیت سیستم صرفنظر می‌کند. همچنین تست ها را تنها روی یک ABI اجرا می کند. برای اعتبار سنجی دستگاه، از این بهینه سازی اجتناب کنید و همه پیش شرط ها و بررسی ها را شامل شود. برای موارد استثنا به cts-dev.xml مراجعه کنید.

کنسول CTS می تواند دستورات دیگری را در حین انجام آزمایش بپذیرد.

اگر هیچ دستگاهی متصل نباشد، دستگاه دسکتاپ CTS (یا میزبان) قبل از شروع آزمایش منتظر می‌ماند تا دستگاهی متصل شود. اگر بیش از یک دستگاه متصل باشد، میزبان CTS یک دستگاه را به طور خودکار انتخاب می کند.

--subplan subplan_name طرح فرعی مشخص شده را اجرا کنید.
--module/-m test_module_name --test/-t test_name ماژول مشخص شده را اجرا کرده و تست کنید. برای مثال، run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes بسته، کلاس یا تست خاص را اجرا می کند.
--retry تمام تست هایی که در جلسات قبلی شکست خورده یا اجرا نشده اند را دوباره امتحان کنید. list results برای دریافت شناسه جلسه استفاده کنید.
--retry-type NOT_EXECUTED فقط تست هایی را امتحان کنید که از جلسات قبلی اجرا نشده اند. list results برای دریافت شناسه جلسه استفاده کنید.
--shards number_of_shards برای اندروید 8.1 یا نسخه های پایین تر . یک CTS را به تعداد معینی از قطعات مستقل تقسیم کنید تا روی چندین دستگاه به صورت موازی اجرا شود.
--shard-count number_of_shards برای اندروید 9 . یک CTS را به تعداد معینی از قطعات مستقل تقسیم کنید تا روی چندین دستگاه به صورت موازی اجرا شود.
--serial/-s deviceID CTS را روی دستگاه خاص اجرا کنید.
--include-filter "test_module_name test_name" با ماژول های مشخص شده یا بسته های آزمایشی، کلاس ها و موارد اجرا کنید. به عنوان مثال، run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" شامل ماژول مشخص شده است.

این گزینه فرمان در هنگام اجرای دوباره امتحان پشتیبانی نمی شود.

--exclude-filter "test_module_name test_name" ماژول های مشخص شده یا بسته های آزمایشی، کلاس ها و موارد را از اجرا حذف کنید. برای مثال، run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" ماژول مشخص شده را مستثنی می کند.
--log-level-display/-l log_level اجرا با حداقل سطح گزارش مشخص شده در STDOUT نمایش داده شده است. مقادیر معتبر: [ VERBOSE , DEBUG , INFO , WARN , ERROR , ASSERT ].
--abi abi_name آزمایش را مجبور کنید روی ABI، 32 یا 64 داده شده اجرا شود. به طور پیش فرض CTS یک آزمایش برای هر ABI که دستگاه پشتیبانی می کند یک بار اجرا می کند.
--logcat-on-failure ،
--bugreport-on-failure ،
--screenshoot-on-failure
به خرابی ها دید بیشتری بدهید و می تواند به تشخیص کمک کند.
--device-token مشخص می کند که یک دستگاه معین دارای نشانه داده شده باشد، مانند --device-token 1a2b3c4d:sim-card .
--skip-device-info جمع آوری اطلاعات مربوط به دستگاه را نادیده می گیرد.
--skip-preconditions برای صرفه جویی در زمان اجرا برای توسعه تکراری یک تست جدید، از پیش شرط ها صرف نظر کنید. این کار تأیید و تنظیم پیکربندی دستگاه را دور می‌زند، مانند فشار دادن فایل‌های رسانه یا بررسی اتصال Wi-Fi.
فهرست کنید شرح
list modules تمام ماژول های آزمایشی موجود در مخزن را فهرست کنید.
list plans یا list configs تمام طرح‌های آزمایشی موجود (پیکربندی‌ها) را در مخزن فهرست کنید.
list subplans تمام طرح های فرعی موجود در مخزن را فهرست کنید.
list invocations دستورات اجرا را که در حال حاضر روی دستگاه ها اجرا می شوند فهرست کنید.
list commands لیست تمام دستورات اجرا شده در حال حاضر در صف انتظار برای تخصیص به دستگاه ها.
list results فهرست نتایج CTS که در حال حاضر در مخزن ذخیره شده است.
list devices دستگاه های متصل فعلی و وضعیت آنها را فهرست کنید.

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

دستگاه‌های در دسترس دستگاه‌هایی هستند که از طریق adb قابل مشاهده هستند، اما به دستورات adb پاسخ نمی‌دهند و برای آزمایش اختصاص داده نمی‌شوند.

دستگاه‌های اختصاص‌یافته دستگاه‌هایی هستند که در حال حاضر در حال آزمایش هستند.

زباله شرح
dump logs لاگ های تجارت شده را برای همه فراخوان های در حال اجرا تخلیه کنید.
اضافه کردن شرح
add subplan --name/-n subplan_name
--result-type
[passed | failed | not_executed]
[--session session_id ]
ایجاد یک طرح فرعی برگرفته از جلسه قبلی؛ این گزینه یک طرح فرعی ایجاد می کند که می تواند برای اجرای زیرمجموعه ای از تست ها استفاده شود.

تنها گزینه مورد نیاز --session است. سایر موارد اختیاری هستند، اما، در صورت گنجاندن، باید با یک مقدار دنبال شوند. گزینه --result-type قابل تکرار است. برای مثال add subplan --session 0 --result-type passed --result-type failed معتبر است.