CTS مبتنی بر توسعه، CTS با پشتیبانی از توسعه

این صفحه دستورالعمل‌های استفاده از CTS مبتنی بر توسعه‌دهندگان (CTS-D) را شرح می‌دهد.

پوشش تست

CTS-D، مانند CTS و CTS Verifier، فقط می‌تواند موارد زیر را اجرا کند:

• تمام APIهای عمومی که در SDK توسعه‌دهندگان (developer.android.com) برای یک سطح API خاص شرح داده شده‌اند.
• تمام الزامات MUST که در سند تعریف سازگاری اندروید (CDD) برای یک سطح API خاص گنجانده شده است.

الزامات غیر الزامی، مانند STRONGLY RECOMMENDED، SHOULD، MAY، اختیاری هستند و نمی‌توان آنها را با استفاده از CTS آزمایش کرد.

از آنجا که تمام APIها و الزامات CDD به یک سطح API خاص گره خورده‌اند، تمام تست‌های CTS (CTS، CTS-D و CTS Verifier) ​​به همان سطح API مربوط به APIها یا الزامات مرتبط با خود گره خورده‌اند. اگر یک API خاص منسوخ یا تغییر کند، تست مربوطه آن نیز باید منسوخ یا به‌روزرسانی شود.

قوانین ایجاد آزمون CTS

• یک آزمون باید به طور مداوم نتیجه عینی یکسانی را ارائه دهد.
• یک تست باید با یک بار تست کردن دستگاه پس از خارج شدن از جعبه، مشخص کند که آیا دستگاه قبول می‌شود یا خیر.
• طراحان آزمون باید تمام عوامل احتمالی مؤثر بر نتایج آزمون را حذف کنند.
• اگر دستگاهی به شرایط/محیط/تنظیمات سخت‌افزاری خاصی نیاز دارد، آن تنظیمات باید به وضوح در پیام کامیت تعریف شود. برای مثال، دستورالعمل‌های راه‌اندازی، به راه‌اندازی CTS مراجعه کنید.
• این آزمایش نباید بیش از ۶ ساعت در هر بار اجرا شود. اگر نیاز به اجرای بیشتر دارد، لطفاً دلیل آن را در پیشنهاد آزمایش خود ذکر کنید تا بتوانیم آن را بررسی کنیم.

در زیر نمونه‌ای از شرایط آزمایش برای آزمایش محدودیت برنامه آمده است:

• وای‌فای پایدار است (برای آزمایشی که به وای‌فای متکی است).
• دستگاه در طول آزمایش ثابت می‌ماند (یا بسته به نوع آزمایش، ثابت نمی‌ماند).
• دستگاه با X درصد شارژ باتری از هر منبع برقی جدا شده است.
• هیچ برنامه، سرویس پیش‌زمینه یا پس‌زمینه‌ای به جز CTS در حال اجرا نیست.
• هنگام اجرای CTS، صفحه نمایش خاموش است.
• این دستگاه isLowRamDevice نیست.
• محدودیت‌های صرفه‌جویی در مصرف باتری/برنامه‌ها از حالت «از ابتدا» تغییر نکرده‌اند.

واجد شرایط بودن برای آزمون

ما تست‌های جدیدی را می‌پذیریم که رفتاری را اعمال می‌کنند که توسط تست‌های موجود CTS، CTS Verifier یا CTS-D آزمایش نشده است. هر تستی که رفتاری خارج از محدوده پوشش تست ما را بررسی کند، رد خواهد شد.

فرآیند ارسال CTS

1. نوشتن یک پیشنهاد آزمایش: یک توسعه‌دهنده برنامه با استفاده از Google Issue Tracker یک پیشنهاد آزمایش ارسال می‌کند، که در آن مشکل شناسایی شده را شرح می‌دهد و آزمایشی را برای بررسی آن پیشنهاد می‌دهد. این پیشنهاد باید شامل شناسه الزامات CDD مرتبط باشد. تیم اندروید این پیشنهاد را بررسی می‌کند.
2. توسعه یک تست CTS: پس از تأیید یک پیشنهاد، ارائه‌دهنده آن یک تست CTS روی AOSP در آخرین شاخه انتشار اندروید ( android16-qpr1-release ) ایجاد می‌کند. تیم اندروید کد را بررسی می‌کند و در صورت پذیرش، تغییرات را انتخاب کرده و در شاخه توسعه داخلی ادغام می‌کند. برای جزئیات بیشتر، به «کجا باید تغییرات را در AOSP پیشنهاد دهم؟» مراجعه کنید.

دستورالعمل‌های نگارش آزمون CTS-D

• راهنمای سبک کد جاوا را دنبال کنید.
• تمام مراحل شرح داده شده در توسعه CTS را دنبال کنید.
• آزمایش‌های خود را به طرح آزمایش مناسب اضافه کنید:
  • include-filters برای افزودن تست‌های جدید خود به طرح تست CTS-D استفاده کنید: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml .
  • از exclude-filters برای حذف تست‌های جدید خود از طرح تست اصلی CTS استفاده کنید: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml .
• تمام هشدارها و پیشنهادهای errorprone در build_error.log مدیریت کنید.
• تغییرات خود را به head ریبیس کنید. این شامل برنامه‌های تست cts-developer.xml و cts-developer-exclude.xml نیز می‌شود.
• با مسئول مهندسی گوگل خود مشورت کنید تا مشخص شود که آیا نمونه آزمایشی شما می‌تواند در یک ماژول CTS موجود گنجانده شود یا خیر. اگر این امکان وجود نداشته باشد، آنها به شما در ایجاد یک ماژول جدید کمک خواهند کرد.
• برای هر ماژول آزمایشی جدید ایجاد شده، یک فایل OWNERS در دایرکتوری ماژول آزمایشی جدید ایجاد کنید.
  • فایل OWNERS شما باید شامل اطلاعات زیر باشد که از مالک آزمایشی گوگل که با او کار می‌کنید، دریافت شده است:
  • # Bug component: xxx
  • گوگل مالک LDAP را آزمایش می‌کند
• در AndroidTest.xml ، پارامترهای زیر را مشخص کنید. برای مثال به فایل‌های نمونه ( 1 ، 2 ) مراجعه کنید:
  • Instant_app یا not_instant_app
  • secondary_user یا not_secondary_user
  • all_foldable_states یا no_foldable_states
• برای مشخص کردن minSDK صحیح، به مستندات <uses-sdk> مراجعه کنید.
• هنگام بررسی روش‌ها، کلاس‌ها یا ماژول‌های جدید آزمون، آنها را به طرح آزمون CTS-D اضافه کنید و آنها را از طرح آزمون اصلی CTS به همان روشی که برای آزمون‌های جدید استفاده می‌شود، حذف کنید.

آزمون CTS-D خود را اجرا کنید

طرح آزمایشی CTS-D را از خط فرمان با استفاده از run cts --plan cts-developer اجرا کنید.

برای اجرای یک مورد آزمایشی خاص، run cts --include-filter "test_module_name test_name" استفاده کنید.

برای اطلاعات بیشتر در مورد اجرای کامل CTS، به Run CTS tests مراجعه کنید.

پذیرش و رهایی

پس از ارسال درخواست آزمایش، یک تیم داخلی آن را بررسی می‌کند تا مطمئن شود که یک الزام CDD یا یک رفتار API مستند شده را آزمایش می‌کند. اگر مشخص شود که آزمایش در حال بررسی یک الزام یا رفتار معتبر است، تیم این مورد آزمایشی را برای بررسی بیشتر به یک مهندس گوگل ارسال می‌کند. مهندس گوگل قبل از پذیرش در CTS، با شما تماس خواهد گرفت و بازخوردی در مورد چگونگی بهبود آزمایش ارائه خواهد داد.

برای جزئیات بیشتر در مورد برنامه انتشار CTS، به برنامه انتشار و اطلاعات شعبه مراجعه کنید.