إعدادات التصميم البسيط

يجب أن تحتوي كل وحدة اختبار جديدة على ملفّ ضبط لتوجيه نظام الإنشاء مع البيانات الوصفية للوحدة والتبعيات في وقت الترجمة وتعليمات الحزمة. يستخدم نظام التشغيل Android الآن نظام إنشاء Soong لإعداد الاختبار بشكلٍ أبسط.

يستخدم Soong ملفات Blueprint أو .bp، وهي أوصاف بسيطة декларативная للوحدات التي سيتم إنشاؤها، وتشبه ملفات JSON. يحل هذا التنسيق محل النظام المستند إلى الصنع المستخدم في الإصدارات السابقة. يمكنك الاطّلاع على ملفات Soong المرجعية في لوحة بيانات الدمج المستمر للحصول على التفاصيل الكاملة.

لاستيعاب الاختبار المخصّص أو استخدام مجموعة أدوات اختبار التوافق (CTS) في Android، اتّبِع إعداد الاختبار المعقد بدلاً من ذلك.

مثال

تأتي الإدخالات أدناه من مثال ملف إعداد Blueprint هذا: /platform_testing/tests/example/instrumentation/Android.bp

تم تضمين لقطة شاشة هنا للتيسير:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

يُرجى العلم أنّ بيان android_test في البداية يشير إلى أنّ هذا اختبار. في المقابل، يشير تضمين android_app إلى أنّ هذا ملف برمجي حزمة.

الإعدادات

في ما يلي شرح للإعدادات التالية:

    name: "HelloWorldTests",

يجب ضبط الإعداد name عند تحديد نوع الوحدة android_test (في بداية الحظر). يمنح هذا الإجراء اسمًا لمكوّنك، وسيتم تسمية حزمة APK الناتجة بالاسم نفسه مع إضافة اللاحقة .apk، على سبيل المثال، في هذه الحالة، يتم تسمية حزمة APK الاختبارية الناتجة باسم HelloWorldTests.apk. بالإضافة إلى ذلك، يؤدي ذلك أيضًا إلى تحديد اسم هدف إنشاء لوحدتك، حتى تتمكّن من استخدام make [options] <HelloWorldTests> لإنشاء الوحدة الاختبارية وجميع التبعيات المرتبطة بها.

    static_libs: ["androidx.test.runner"],

يوجّه الإعداد static_libs نظام الإنشاء إلى دمج محتويات الوحدات المُسمّاة في حزمة APK الناتجة عن الوحدة الحالية. وهذا يعني أنّه من المتوقّع أن تُنشئ كل وحدة مُسمّاة ملفًا بتنسيق .jar، وسيتم استخدام محتواه لحلّ مراجع مسار الطباعة أثناء وقت الترجمة، بالإضافة إلى دمجه في حزمة APK الناتجة.

وحدة androidx.test.runner هي الإصدار المُنشئ مسبقًا لـ "مكتبة" "مشغّل اختبارات AndroidX"، والتي تتضمّن مشغّل الاختبار AndroidJUnitRunner. يتوافق "AndroidJUnitRunner" مع إطار عمل اختبار JUnit4 وتم استبداله InstrumentationTestRunner في الإصدار 10 من نظام التشغيل Android. يمكنك الاطّلاع على مزيد من المعلومات عن اختبار تطبيقات Android على الرابط اختبار التطبيقات على Android.

إذا كنت بصدد إنشاء وحدة أدوات قياس جديدة، يجب دائمًا البدء باستخدام مكتبة androidx.test.runner بصفتها أداة تشغيل الاختبار. وتتضمّن شجرة مصادر المنصة أيضًا أطر عمل أخرى مفيدة للاختبار، مثل ub-uiautomator وmockito-target وeasymock وغيرها.

    certificate: "platform",

يوجّه الإعداد certificate نظام الإنشاء إلى توقيع حزمة APK باستخدام الشهادة نفسها التي تستخدمها المنصة الأساسية. يكون ذلك مطلوبًا إذا كان الاختبار يستخدم إذنًا أو واجهة برمجة تطبيقات محمية بالتوقيع. تجدر الإشارة إلى أنّ هذه الطريقة مناسبة للاختبار المستمر على المنصة، ولكن لا يجب استخدامها في وحدات اختبار CTS. يُرجى العِلم أنّ هذا المثال يستخدم إعداد الشهادة هذا لأغراض توضيحية فقط: لا يحتاج الرمز الاختباري في المثال إلى توقيع ملف APK الاختباري باستخدام شهادة المنصة الخاصة.

إذا كنت بصدد كتابة أداة قياس أداء لمكوّن خارج خادم النظام، أي أنّه مُجمَّع تقريبًا مثل حزمة apk للتطبيق العادي، باستثناء أنّه مُدمَج في صورة النظام وقد يكون تطبيقًا مفوَّضًا، من المرجّح أن تستهدف أداة القياس حزمة التطبيق (راجِع أدناه القسم عن البيان) لمكوّنك. في هذه الحالة، قد يحتوي ملف makefile الخاص بالتطبيق على إعداد certificate خاص به، ويجب أن تحتفظ وحدة instrumentation بالإعداد نفسه. ويعود السبب في ذلك إلى أنّه لاستهداف أدوات جمع البيانات في التطبيق الذي يتم اختباره، يجب توقيع حِزم APK الخاصة بالاختبار والتطبيق باستخدام الشهادة نفسها.

وفي الحالات الأخرى، لا تحتاج إلى ضبط هذا الإعداد على الإطلاق: سيوقعه نظام الإنشاء ببساطة باستخدام شهادة مضمّنة تلقائيًا، استنادًا إلى نوع البناء، ويُعرف هذا النوع عادةً باسم dev-keys.

    test_suites: ["device-tests"],

يجعل الإعداد test_suites الاختبار سهل الاكتشاف من خلال حزمة اختبار Trade Federation. يمكن إضافة مجموعات أخرى هنا، مثل CTS، حتى تتمكّن من مشاركة هذا الاختبار.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

الإعدادات الاختيارية

في ما يلي شرح للإعدادات الاختيارية التالية:

    test_config: "path/to/hello_world_test.xml"

يوجّه الإعداد test_config نظام الإنشاء إلى أنّ الهدف التجريبي يحتاج إلى ملف تكوين محدّد. يتم تلقائيًا ربط الرمز AndroidTest.xml بجانب الرمز Android.bp بالإعداد.

    auto_gen_config: true

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

    require_root: true

يوجّه الإعداد require_root نظام الإنشاء إلى إضافة RootTargetPreparer إلى إعداد الاختبار الذي تم إنشاؤه تلقائيًا. يضمن ذلك إجراء الاختبار باستخدام أذونات root.

    test_min_api_level: 29

يوجّه الإعداد test_min_api_level نظام الإنشاء إلى إضافة MinApiLevelModuleController إلى إعدادات الاختبار التي يتم إنشاؤها تلقائيًا. عندما تُجري ميزة "اتحاد التجارة" عملية إعداد الاختبار، سيتم تخطّي الاختبار إذا كانت قيمة سمة الجهاز ro.product.first_api_level < test_min_api_level.