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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

يستخدم Soong ملفات Blueprint أو .bp، وهي أوصاف بسيطة декларативная للوحدات التي سيتم إنشاؤها، وتشبه ملفات JSON. ويحلّ هذا التنسيق محلّ النظام المستنِد إلى Make الذي كان يُستخدَم في الإصدارات السابقة. اطّلِع على ملفات مرجع 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 في Android 10. يمكنك الاطّلاع على مزيد من المعلومات عن اختبار تطبيقات 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.