تنظیم تست

مجموعه تست

برای اینکه یک تست بخشی از VTS باشد، باید تنظیمات زیر را در Android.bp داشته باشد.

test_suites: ["vts"],

علاوه بر این، افزودن آزمون به مجموعه general-tests به آن اجازه می‌دهد تا بخشی از یک مجموعه نگاشت آزمون باشد که در بررسی‌های پیش از ارسال استفاده می‌شود.

پیکربندی تست

در بیشتر موارد، پیکربندی تست، که یک فایل XML است که توسط فدراسیون تجارت برای اجرای تست VTS استفاده می‌شود، به طور خودکار در طول ساخت ایجاد می‌شود. با این حال، می‌توانید پیکربندی تست را سفارشی کنید.

یک فایل پیکربندی تست سفارشی ایجاد کنید

ایجاد یک فایل XML آزمایشی جدید از ابتدا می‌تواند پیچیده باشد، زیرا شامل درک نحوه عملکرد مهار تست و همچنین تفاوت بین هر اجراکننده تست است. فایل پیکربندی تست خودکار تولید شده برای آسان‌تر کردن این فرآیند طراحی شده است.

اگر مجبور به سفارشی‌سازی فایل XML آزمایشی هستید، می‌توانید از فایل تولید شده خودکار به عنوان نقطه شروع استفاده کنید.

برای یافتن فایل پیکربندی آزمایشی که به صورت خودکار تولید شده است، ابتدا دستور make را برای ساخت پیکربندی اجرا کنید، همانطور که در زیر نشان داده شده است.

$ m VtsHalUsbV1_1TargetTest

در دایرکتوری build out خود، می‌توانید فایل پیکربندی را بر اساس نام ماژول، همانطور که در زیر نشان داده شده است، جستجو کنید.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

می‌تواند چندین کپی از فایل وجود داشته باشد و شما می‌توانید از هر یک از آنها استفاده کنید. فایل .config را در پوشه‌ای که فایل Android.bp قرار دارد کپی کنید.

اگر فقط یک ماژول آزمایشی در فایل Android.bp وجود دارد، می‌توانید نام فایل XML را به AndroidTest.xml تغییر دهید و سیستم ساخت به طور خودکار از آن به عنوان فایل پیکربندی ماژول آزمایشی استفاده می‌کند. در غیر این صورت، همانطور که در مثال زیر نشان داده شده است، یک ویژگی test_config به ماژول اضافه کنید.

test_config: "VtsHalUsbV1_1TargetTest.xml",

اکنون یک فایل پیکربندی آزمایشی برای کار و پیاده‌سازی سفارشی‌سازی دارید.

اجرای تست با adb root را اجباری کنید

اکثر تست‌های VTS برای اجرا به دسترسی روت نیاز دارند. اگر فایل پیکربندی تست به صورت خودکار تولید شده باشد، می‌توانید ویژگی زیر را به Android.bp اضافه کنید.

require_root: true,

اگر فایل پیکربندی آزمایشی سفارشی‌سازی شده است، موارد زیر را به فایل XML آزمایشی اضافه کنید.

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

چارچوب را در طول آزمایش متوقف کنید

بسیاری از تست‌های VTS برای اجرا به چارچوب اندروید نیاز ندارند و اجرای تست با چارچوب متوقف شده به تست اجازه می‌دهد تا بدون تأثیرپذیری از تغییرات دستگاه، با پایداری اجرا شود. اگر فایل پیکربندی تست به صورت خودکار تولید می‌شود، می‌توانید ویژگی زیر را به Android.bp اضافه کنید.

disable_framework: true,

اگر فایل پیکربندی آزمایشی سفارشی‌سازی شده است، موارد زیر را به فایل XML آزمایشی اضافه کنید.

<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>

آرگومان‌های تست اضافی اضافه کنید

برخی از تست‌های gtest ممکن است به زمان بیشتری برای اجرا نیاز داشته باشند. در چنین مواردی، می‌توانید گزینه‌های اجراکننده تست را در فایل XML اضافه کنید.

برای مثال، تنظیم native-test-timeout در ورودی زیر به تست اجازه می‌دهد تا با زمان انقضای ۳ دقیقه اجرا شود، به جای زمان انقضای پیش‌فرض ۱ دقیقه.

   <test class="com.android.tradefed.testtype.GTest" >
       <option name="native-test-device-path" value="/data/local/tmp" />
       <option name="module-name" value="VtsHalNfcV1_0TargetTest" />
       <option name="native-test-timeout" value="180000"/>
   </test>

حداقل سطح API مورد نیاز

برخی از تست‌های VTS فقط می‌توانند روی دستگاه‌هایی با حداقل سطح API اجرا شوند. اگر فایل پیکربندی تست به صورت خودکار تولید می‌شود، می‌توانید ویژگی زیر را به Android.bp اضافه کنید.

min_shipping_api_level: 29,

یا

vsr_min_shipping_api_level: 202404,

اگر فایل پیکربندی آزمایشی سفارشی‌سازی شده است، دستور زیر را به فایل XML آزمایشی اضافه کنید.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

یا

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="vsr-min-api-level" value="202404" />
   </object>

ویژگی‌های سطح API

اندروید ۱۲ ویژگی‌های ro.board.first_api_level و ro.board.api_level را برای نمایش سطح API تصاویر فروشنده در این دستگاه‌ها تعریف می‌کند. با ترکیب این ویژگی‌ها با ro.product.first_api_level ، مجموعه‌های تست، موارد تست مناسب را برای دستگاه‌ها انتخاب می‌کنند.

اندروید ۱۳ سطح ro.vendor.api_level تعریف می‌کند که به طور خودکار با محاسبه سطح API فروشنده مورد نیاز با استفاده از ویژگی‌های ro.product.first_api_level ، ro.board.first_api_level و ro.board.api_level تنظیم می‌شود.

برای جزئیات بیشتر، به سطح API فروشنده مراجعه کنید.

ro.board.first_api_level

ویژگی ro.board.first_api_level سطح API است که در آن ایمیج‌های فروشنده برای یک SoC که واجد شرایط فریز فروشنده است، برای اولین بار با این ویژگی منتشر می‌شوند. این به سطح API راه‌اندازی دستگاه بستگی ندارد، بلکه فقط به اولین سطح API SoC بستگی دارد که این مقدار را تعریف می‌کند. این مقدار در طول عمر SoC دائمی است.

برای تنظیم ro.board.first_api_level ، تولیدکنندگان دستگاه می‌توانند BOARD_SHIPPING_API_LEVEL در فایل device.mk خود تعریف کنند، همانطور که در مثال زیر نشان داده شده است:

  # BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
  # the first api level that the device has been commercially launched on.
  BOARD_SHIPPING_API_LEVEL := 23

این به طور خودکار ویژگی ro.board.first_api_level را در vendor/build.prop روی دستگاه تعریف می‌کند. این ویژگی توسط فرآیند init vendor تنظیم می‌شود.

سطح_api_برد_ro

ویژگی ro.board.api_level سطح API فروشنده فعلی تصاویر فروشنده است که دارای قالب YYYYMM است که در آن API فروشنده ثابت شده است. این ویژگی به طور خودکار توسط سیستم ساخت تنظیم می‌شود.

ro.vendor.api_level

ویژگی ro.vendor.api_level در اندروید ۱۳ معرفی شد تا سطح API مورد نیاز برای پشتیبانی از تصاویر فروشنده را نشان دهد. این ویژگی به طور خودکار روی ro.product.first_api_level یا ro.board.api_level تنظیم می‌شود اگر ro.board.first_api_level وجود داشته باشد و ro.board.api_level روی سطح API قدیمی‌تری نسبت به ro.product.first_api_level تنظیم شده باشد. اگر نسخه ro.product.first_api_level بزرگتر یا مساوی 35 باشد، نسخه با سطح API فروشنده مربوطه جایگزین خواهد شد. تست‌های پیاده‌سازی فروشنده که نیاز به ارتقاء تصویر فروشنده دارند، ممکن است با ارجاع به این ویژگی از الزامات فروشنده برای SoC مستثنی شوند.

فرآیند شاردینگ با استفاده از VTS

برای اندروید نسخه ۱۰ یا بالاتر، می‌توانید فرآیند شاردینگ را روی چندین دستگاه انجام دهید و همزمان با هر دو طرح VTS و CTS-on-GSI، با دنبال کردن دستورالعمل‌های زیر، آزمایش را انجام دهید.

run vts --shard-count <number of devices> -s <device serial> ...

این دستور، طرح VTS را به بخش‌هایی تقسیم کرده و آنها را روی چندین دستگاه اجرا می‌کند.

run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...

این دستور، طرح CTS-on-GSI را به بخش‌هایی تقسیم کرده و آنها را روی چندین دستگاه اجرا می‌کند.