تجربة الإعداد

حزمة اختبار

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

test_suites: ["vts"],

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

تكوين الاختبار

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

تتطلب الحد الأدنى من مستوى API

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

test_min_api_level: 29,

إذا تم تخصيص ملف تكوين الاختبار، أضف الأمر التالي إلى ملف XML الاختباري.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </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 هي مستوى واجهة برمجة التطبيقات (API) عندما يتم إصدار صور البائع لـ SoC لأول مرة باستخدام هذه الخاصية. لا يعتمد هذا على مستوى واجهة برمجة التطبيقات (API) التي يتم تشغيلها بالجهاز ولكنه يعتمد فقط على مستوى واجهة برمجة التطبيقات (API) الأول لشركة 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 هي مستوى واجهة برمجة التطبيقات (API) الحالي لصور البائع لـ SoC. عند تحديث مستوى واجهة برمجة التطبيقات لصورة البائع التي تحتوي على ro.board.first_api_level ، يجب على الجهاز الذي يستخدم SoC تحديد خاصية ro.board.api_level بمستوى واجهة برمجة التطبيقات الحالي لصورة البائع بدلاً من تحديث ro.board.first_api_level . إذا لم يتم تعيين هذه الخاصية، فسيتم استخدام ro.board.first_api_level افتراضيًا.

لتعيين مستوى ro.board.api_level ، حدد BOARD_API_LEVEL في ملف device.mk بالقيمة المطلوبة.

ro.vendor.api_level

تم تقديم الخاصية ro.vendor.api_level في Android 13 لإظهار مستوى واجهة برمجة التطبيقات (API) الذي يتعين على صور البائع دعمه. يتم ضبط هذا تلقائيًا على الحد الأدنى من ro.board.api_level (أو ro.board.first_api_level إذا لم يتم تعريف ro.board.api_level ) و ro.product.first_api_level . قد يتم استبعاد اختبارات تنفيذ البائع التي تتطلب ترقية صورة البائع من متطلبات البائع الخاصة بـ 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 إلى أجزاء وتشغيلها على أجهزة متعددة.