إعداد الاختبار

مجموعة الاختبار

لكي يكون الاختبار جزءًا من اختبار الفيديوهات القصيرة، يجب أن يتضمّن الإعداد التالي في Android.bp.

test_suites: ["vts"],

بالإضافة إلى ذلك، تسمح إضافة الاختبار إلى المجموعة general-tests بأن يكون جزءًا من مجموعة "ربط الاختبارات" المستخدَمة في عمليات التحقّق من التقديم المُسبَق.

إعدادات الاختبار

في معظم الحالات، يتم تلقائيًا توليد ملف إعداد الاختبار، وهو ملف XML يستخدمه TradeFederation لإجراء اختبار VTS، أثناء عملية الإنشاء. ومع ذلك، يمكنك تخصيص إعدادات الاختبار.

إنشاء ملف إعدادات اختبار مخصّص

قد يكون إنشاء ملف XML جديد للاختبار من البداية أمرًا معقّدًا، لأنّه يتطلّب معرفة كيفية عمل مجموعة الاختبار، بالإضافة إلى الفرق بين كل أداة اختبار. تم تصميم ملف إعداد الاختبار الذي يتم إنشاؤه تلقائيًا لتسهيل هذه العملية.

إذا كان عليك تخصيص ملف XML للاختبار، يمكنك استخدام الملف الذي تم إنشاؤه تلقائيًا كنقطة بداية.

لتحديد موقع ملف إعداد الاختبار الذي تم إنشاؤه تلقائيًا، عليك أولاً تنفيذ الأمر make لإنشاء ملف الإعداد، كما هو موضّح أدناه.

$ m VtsHalUsbV1_1TargetTest

في دليل الإخراج الخاص بالإنشاء، يمكنك البحث عن ملف config استنادًا إلى اسم الوحدة، كما هو موضّح أدناه.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

يمكن أن يكون هناك نُسخ متعددة من الملف ويمكنك استخدام أي منها. انسخ ملف .config إلى الدليل الذي يتضمّن ملف Android.bp.

إذا كانت هناك وحدة اختبار واحدة فقط في ملف Android.bp، يمكنك إعادة تسمية ملف XML إلى AndroidTest.xml، وسيستخدم نظام الإنشاء هذا الملف تلقائيًا كملف إعدادات وحدة الاختبار. بخلاف ذلك، أضِف سمة test_config إلى الوحدة، كما هو موضّح في المثال أدناه.

test_config: "VtsHalUsbV1_1TargetTest.xml",

لديك الآن ملف إعداد اختباري للعمل عليه وتنفيذ customisation.

فرض تشغيل الاختبار باستخدام إذن الوصول إلى الجذر من adb

تتطلّب معظم اختبارات VTS امتياز "المشرف" لتشغيلها. إذا تم إنشاء ملف الإعدادات التجريبية تلقائيًا، يمكنك إضافة السمة التالية إلى Android.bp.

require_root: true,

إذا تم تخصيص ملف الإعداد التجريبي، أضِف العنصر التالي إلى ملف XML التجريبي:

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

إيقاف إطار العمل أثناء الاختبار

لا تتطلّب العديد من اختبارات سلامة النقل (VTS) تشغيل إطار عمل Android، ويسمح تشغيل الاختبار مع إيقاف إطار العمل بإجراء الاختبار بثبات بدون التأثير في أخطاء الأجهزة. إذا تم إنشاء ملف الإعدادات التجريبية تلقائيًا، يمكنك إضافة السمة التالية إلى Android.bp.

disable_framework: true,

إذا تم تخصيص ملف الإعداد التجريبي، أضِف العنصر التالي إلى ملف XML التجريبي:

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

إضافة وسيطات اختبار إضافية

قد تتطلّب بعض اختبارات gtest مزيدًا من الوقت لتنفيذها. في هذه الحالات، يمكنك إضافة options لبرنامج تشغيل الاختبارات في ملف XML.

على سبيل المثال، يسمح الإعداد native-test-timeout في القيمة التالية للاختبار بتنفيذه مع مهلة 3 دقائق بدلاً من القيمة التلقائية التي تبلغ دقيقة واحدة.

   <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>

طلب الحد الأدنى لمستوى واجهة برمجة التطبيقات

لا يمكن تشغيل بعض اختبارات VTS إلا على الأجهزة التي توفّر الحد الأدنى من مستوى واجهة برمجة التطبيقات. إذا تم إنشاءملف إعدادات الاختبار تلقائيًا، يمكنك إضافة السمة التالية إلى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>

خصائص مستوى واجهة برمجة التطبيقات

يحدِّد نظام Android 12 السمتَين ro.board.first_api_level و ro.board.api_level لعرض مستوى واجهة برمجة التطبيقات لصور المورّدين على هذه الأجهزة. من خلال الجمع بين هذه السمات وro.product.first_api_level، تختار مجموعات الاختبار حالات الاختبار المناسبة للأجهزة.

يحدِّد الإصدار 13 من Android ro.vendor.api_level الذي يتم ضبطه تلقائيًا من خلال احتساب المستوى المطلوب لواجهة برمجة التطبيقات الخاصة بالمورّد باستخدام سمات ro.product.first_api_level وro.board.first_api_level و ro.board.api_level.

لمزيد من التفاصيل، يُرجى الاطّلاع على مستوى واجهة برمجة التطبيقات الخاصة بالمورّد.

ro.board.first_api_level

يشير الموقع ro.board.first_api_level إلى مستوى واجهة برمجة التطبيقات عند إصدار صور المصنّع لوحدة المعالجة المركزية (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 الموفّر.

ro.board.api_level

السمة ro.board.api_level هي المستوى الحالي لواجهة برمجة التطبيقات الخاصة بالمورّد للصور التي تستخدم تنسيق YYYYMM والتي تم تجميد واجهة برمجة التطبيقات الخاصة بالمورّد فيها. ويتم ضبطه تلقائيًا من خلال نظام الإنشاء.

ro.vendor.api_level

تمّ تقديم السمة ro.vendor.api_level في الإصدار Android 13 لعرض مستوى واجهة برمجة التطبيقات المطلوب أن تتوافق معه صور المورّدين. يتم ضبط هذا الإعداد تلقائيًا على ro.product.first_api_level أو ro.board.api_level إذا كان ro.board.first_api_level متوفّرًا وتم ضبط ro.board.api_level على مستوى أقدم لواجهة برمجة التطبيقات من ro.product.first_api_level. سيتم استبدال الإصدار بمستوى واجهة برمجة التطبيقات المقابل الخاص بالمورّد إذا تم ضبطه على الإصدار من ro.product.first_api_level الذي يكون أكبر من أو يساوي 35. قد يتم استبعاد اختبارات تنفيذ المورّد التي تتطلّب ترقية صورة المورّد من متطلبات المورّد لوحدة التحكّم في النظام (SoC) من خلال الإشارة إلى هذه السمة.

عملية تقسيم البيانات باستخدام VTS

بالنسبة إلى الإصدار 10 من Android أو الإصدارات الأحدث، يمكنك إجراء عملية التجزئة على أجهزة متعددة أثناء الاختبار باستخدام كل من خطتَي 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 على GSI إلى أجزاء ويشغّلها على عدة أجهزة.