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

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

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

test_suites: ["vts"],

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

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

في معظم الحالات، يتم إنشاء إعدادات الاختبار تلقائيًا أثناء عملية الإنشاء، وهي عبارة عن ملف 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، تختار مجموعات الاختبار حالات الاختبار المناسبة للأجهزة.

يحدّد الإصدار 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-on-GSI إلى أجزاء ويشغّلها على أجهزة متعددة.