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

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

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