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

حزمة الاختبار

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

test_suites: ["vts"],

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

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

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

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

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

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

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

$ m VtsHalUsbV1_1TargetTest

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

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

disable_framework: true,

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

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

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

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

يحدّد Android 13 السمة 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) الذي يحدّد هذه القيمة. تكون القيمة دائمة طوال فترة استخدام وحدة نظام على شريحة (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-on-GSI إلى أجزاء ويشغّلها على أجهزة متعددة.