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

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

پوشش تست

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

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

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

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

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

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

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

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

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

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

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

  1. یک پیشنهاد آزمایشی بنویسید: یک توسعه‌دهنده برنامه با استفاده از Google Issue Tracker یک پیشنهاد آزمایشی ارائه می‌کند و مشکل شناسایی‌شده را شرح می‌دهد و آزمایشی برای بررسی آن پیشنهاد می‌کند. پیشنهاد باید شامل شناسه الزام CDD مرتبط باشد. تیم اندروید پیشنهاد را بررسی می کند.
  2. توسعه یک آزمون CTS: پس از تایید یک پروپوزال، ارسال کننده آن یک آزمون CTS در AOSP در شاخه اصلی (AOSP/Main) ایجاد می کند. تیم اندروید کد را بررسی می کند.
  3. انتشار تست: CL خود را در AOSP/main ارسال کنید و سپس آن را به آخرین شاخه androidx-tests-dev انتخاب کنید. این آزمایش اکنون برای عموم در دسترس است.

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

  • راهنمای سبک کد جاوا را دنبال کنید.
  • تمام مراحل توضیح داده شده در توسعه CTS را دنبال کنید.
  • تست های خود را به طرح آزمون مناسب اضافه کنید:
    • برای افزودن آزمایش‌های جدید خود به طرح آزمایشی CTS-D include-filters استفاده کنید: 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 می‌شود.
  • با مخاطب مهندسی Google خود کار کنید تا مشخص کنید که آیا مورد آزمایشی شما می تواند در یک ماژول CTS موجود گنجانده شود یا خیر. اگر نمی تواند، آنها به شما کمک می کنند یک ماژول جدید ایجاد کنید.
  • برای هر ماژول تست جدید ایجاد شده، یک فایل OWNERS در فهرست ماژول تست جدید ایجاد کنید.
    • فایل OWNERS شما باید حاوی اطلاعات زیر باشد که از مالک آزمایشی Google که با آن کار می کنید به دست آمده است:
    • # 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، به اجرای آزمایشات CTS مراجعه کنید.

پذیرش و رهایی

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

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