اختبار التعيين

هذه مقدمة موجزة عن الخرائط التجريبية وشرح لكيفية البدء في ضبط الاختبارات بسهولة في "المشروع المفتوح المصدر لنظام Android" (AOSP).

لمحة عن تخطيط الاختبارات

وهو نهج يستند إلى Gerrit ويتيح للمطوّرين إنشاء قواعد اختبار ما قبل الإرسال وبعده مباشرةً في شجرة مصادر Android وترك قرارات الفروع والأجهزة ليتم اختبارها على البنية الأساسية التجريبية. تعريفات ربط الاختبار هي ملفات JSON اسمها TEST_MAPPING ويمكن وضعها في أي دليل مصدر.

بإمكان Atest استخدام ملفات TEST_MAPPING لإجراء اختبارات الإرسال المسبق في الأدلة المرتبطة. من خلال الربط التجريبي، يمكنك إضافة مجموعة الاختبارات نفسها لإجراء عمليات تحقّق الإرسال المسبق مع إجراء تغيير بسيط في شجرة مصادر Android.

اطّلِع على الأمثلة التالية:

إضافة اختبارات الإرسال المسبق إلى TEST_MAPPING for services.core

إضافة اختبارات الإرسال المسبق إلى TEST_MAPPING للأدوات/ديبكس باستخدام عمليات الاستيراد

يعتمد ربط الاختبارات على أداة اختبار الاتّحاد التجاري (TF) في تنفيذ الاختبارات وإعداد تقارير النتائج.

تحديد مجموعات الاختبار

اختبار مجموعات الربط من خلال مجموعة اختبار يمكن أن يكون اسم مجموعة الاختبار أي سلسلة. على سبيل المثال، يمكن أن يكون الإرسال المسبق لمجموعة من الاختبارات لتنفيذها عند التحقّق من صحة التغييرات. ويمكن استخدام اختبارات بعد الإرسال للتحقّق من صحة التصميمات بعد دمج التغييرات.

قواعد النص البرمجي لإنشاء الحزمة

لكي يتمكّن مجمِّع اختبار الاتحاد التجاري من تشغيل وحدات اختبار الربط التجريبي لإصدار معيّن، يجب ضبط test_suites على Soong أو LOCAL_COMPATIBILITY_SUITE الضبط على "الصنع" في أحد الجناحَتين:

• الاختبارات العامة - الاختبارات التي لا تعتمد على وظائف خاصة بالجهاز (مثل الأجهزة الخاصة بالمورّد والتي لا تحتوي عليها معظم الأجهزة). يجب إجراء معظم الاختبارات في مجموعة الاختبارات العامة، حتى لو كانت خاصة بواجهة تطبيقات ثنائية (ABI) أو وحدة بت أو ميزات أجهزة مثل HWASan (هناك استهداف منفصل لكل واجهة تطبيق ثنائية (test_suites)) وحتى إذا كان يجب تشغيلها على جهاز.
• device-tests - الاختبارات التي تعتمد على وظائف خاصة بجهاز معيّن. سيتم العثور عادةً على هذه الاختبارات ضمن فئة "vendor/". بما أنّ كلمة "خاصة بالجهاز" لا تشير إلى وظائف واجهة التطبيق الثنائية (ABI) أو المنظومة على الرقاقة (SoC) التي قد تتوفر أو لا تتوفّر في الأجهزة الأخرى، بل تشير فقط إلى الوظائف الفريدة لجهاز، ينطبق هذا الأمر على اختبارات JUnit تمامًا مثل اختبارات GTest الأصلية (التي يجب أن تكون عادةً general-tests حتى إذا كانت خاصة بـ ABI).

أمثلة:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

ضبط الاختبارات لتنفيذها في مجموعة اختبارية

لإجراء اختبار داخل مجموعة اختبار، الاختبار:

• يجب ألا يكون له أي موفِّر إصدار.
• تنظيفها بعد انتهائها، على سبيل المثال، عن طريق حذف أي ملفات مؤقتة تم إنشاؤها أثناء الاختبار.
• تغيير إعدادات النظام إلى القيمة التلقائية أو الأصلية
• الأجهزة التي في حالة معينة، مثلاً احتواء الجهاز على جذر. ولا تتطلب معظم الاختبارات امتياز جذر للتشغيل. إذا كان الاختبار يتطلب جذرًا، يجب أن يحدد ذلك مع RootTargetPreparer في AndroidTest.xml الخاص به، كما في المثال التالي:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

إنشاء ملفات تحديد موعد اختبارية

بالنسبة إلى الدليل الذي يتطلب تغطية تجريبية، يمكنك ببساطة إضافة ملف TEST_MAPPING JSON يشبه المثال أدناه. ستضمن هذه القواعد إجراء الاختبارات في فحوصات ما قبل الإرسال عند تعديل أي ملفات في هذا الدليل أو أي من الأدلة الفرعية.

اتّباع مثال

في ما يلي نموذج لملف TEST_MAPPING (بتنسيق JSON ولكن مع إمكانية نشر التعليقات):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

ضبط السمات

في المثال أعلاه، يمثل presubmit وpostsubmit اسم كل مجموعة اختبار. راجِع مقالة تحديد مجموعات الاختبار لمعرفة مزيد من المعلومات عن مجموعات الاختبار.

يمكن ضبط اسم وحدة الاختبار أو اسم اختبار دمج الاتحاد التجاري (مسار المورد إلى ملف XML الاختباري، مثل uiautomator/uiautomator-demo) في قيمة السمة name. يُرجى ملاحظة أنّه لا يمكن أن يستخدم حقل name الفئة name أو طريقة الاختبار name. لتضييق نطاق الاختبارات التي سيتم إجراؤها، يمكنك استخدام خيارات مثل include-filter هنا. يُرجى الاطّلاع على (استخدام نموذج من الفلاتر في التطبيق).

يشير إعداد المضيف للاختبار إلى ما إذا كان الاختبار بدون أجهزة يتم تنفيذه على المضيف أم لا. القيمة التلقائية هي false، ما يعني أنّ الاختبار يتطلب تشغيل جهاز. أنواع الاختبار المتوافقة هي HostGTest لبرامج GTest الثنائية وHostTest لاختبارات JUnit.

تسمح لك السمة file_patterns بإعداد قائمة بسلاسل التعبير العادي لمطابقة المسار النسبي لأي ملف رمز مصدر (بالنسبة إلى الدليل الذي يحتوي على ملف TEST_MAPPING). في المثال أعلاه، لن يتم تشغيل الاختبار CtsWindowManagerDeviceTestCases في الإرسال المسبق إلا عندما يتم تغيير أي ملف جافا يبدأ بنافذة أو النشاط المتوفر في الدليل نفسه لملف TEST_MAPPING أو في أي من أدلته الفرعية. يجب تخطي الشرطة المائلة للخلف \ لأنها موجودة في ملف JSON.

تتيح لك السمة Imports تضمين اختبارات في ملفات TEST_MAPPING أخرى بدون نسخ المحتوى. تجدر الإشارة إلى أنه سيتم أيضًا تضمين ملفات TEST_MAPPING في الأدلّة الرئيسية للمسار المستورَد. يتيح التعيين التجريبي لعمليات الاستيراد المتداخلة؛ أي أن ملفي TEST_MAPPING يمكنهما استيراد بعضهما البعض، ويمكن لاختبار التعيين أن دمج الاختبارات المضمنة بشكل صحيح.

تحتوي السمة options على خيارات سطر أوامر خاصة بـ TradeFed.

للحصول على قائمة كاملة بالخيارات المتاحة لاختبار معيّن، نفِّذ ما يلي:

tradefed.sh run commandAndExit [test_module] --help

يُرجى الاطّلاع على صفحة التعامل مع الخيارات التجارية لمزيد من التفاصيل حول آلية عمل الخيارات.

إجراء الاختبارات باستخدام Atest

لتنفيذ قواعد اختبار الإرسال المسبق محليًا:

1. انتقل إلى الدليل الذي يحتوي على الملف TEST_MAPPING.
2. شغِّل الأمر:

atest

يتم تشغيل جميع اختبارات الإرسال المسبق التي تم ضبطها في ملفات TEST_MAPPING من الدليل الحالي وأدلته الرئيسية. ستعمل Atest على تحديد موقع اختبارين للإرسال المسبق (A وB) وتنفيذهما.

هذه هي أبسط طريقة لإجراء اختبارات الإرسال المسبق في ملفات TEST_MAPPING في دليل العمل الحالي (CWD) والأدلة الرئيسية. ستقوم Atest بتحديد موقع الملف TEST_MAPPING واستخدامه في CWD وجميع الأدلة الأصلية له.

بنية رمز المصدر

يوضح المثال التالي كيف يمكن تهيئة ملفات TEST_MAPPING عبر الشجرة المصدر.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

محتوى src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

محتوى src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

محتوى src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

تحديد الأدلة المستهدفة

يمكنك تحديد دليل مستهدف لإجراء الاختبارات في ملفات TEST_MAPPING في هذا الدليل. سيُجري الأمر التالي اختبارين (أ، ب).

atest --test-mapping src/project_1

تشغيل القواعد التجريبية لما بعد الإرسال

يمكنك أيضًا استخدام هذا الأمر لتشغيل قواعد اختبار ما بعد الإرسال المحدّدة في TEST_MAPPING في src_path (الإعداد التلقائي لـ CWD) والأدلة الرئيسية له:

atest [--test-mapping] [src_path]:postsubmit

إجراء الاختبارات التي لا تتطلب أي جهاز فقط

يمكنك استخدام الخيار --host لإجراء اختبار Atest فقط لإجراء الاختبارات التي تم ضبطها على المضيف الذي لا يتطلب أي جهاز. وبدون هذا الخيار، ستُجري Atest كلا الاختبارين، أحدهما الذي يتطلب جهازًا والآخر يتم تشغيله على المضيف ولا يتطلب أي جهاز. سيتم إجراء الاختبارات في مجموعتين منفصلتين.

atest [--test-mapping] --host

تحديد مجموعات الاختبار

يمكنك تحديد مجموعات الاختبار في الأمر Atest. سيشغِّل الأمر التالي جميع اختبارات postsubmit المتعلقة بالملفات في الدليل src/project_1، والتي تحتوي على اختبار واحد فقط (C).

أو يمكنك استخدام :all لتنفيذ جميع الاختبارات بغض النظر عن المجموعة. يجري الأمر التالي أربعة اختبارات (A، B، C، X):

atest --test-mapping src/project_1:all

تضمين الأدلة الفرعية

بشكل افتراضي، سيؤدي إجراء الاختبارات في TEST_MAPPING مع Atest فقط إلى تشغيل اختبارات الإرسال المسبق التي تم إعدادها في ملف TEST_MAPPING في CWD (أو الدليل المحدد) وأدلته الرئيسية. إذا كنت تريد إجراء اختبارات في جميع ملفات TEST_MAPPING في الأدلّة الفرعية، استخدِم الخيار --include-subdir لفرض إضافة Atest لهذه الاختبارات أيضًا.

atest --include-subdir

بدون الخيار --include-subdir، ستجري Atest الاختبار (أ) فقط. باستخدام الخيار --include-subdir، ستُجري Atest اختبارَين (A، B).

التعليق على مستوى السطر متاح.

يمكنك إضافة تعليق بتنسيق // على مستوى السطر لتوضيح الملف TEST_MAPPING مع وصف للإعداد التالي. سيعمل كل من ATest و Trade Federation على معالجة TEST_MAPPING مسبقًا للحصول على تنسيق JSON صالح بدون تعليقات. وللحفاظ على أنّ ملف JSON خالٍ من الأخطاء وسهولة القراءة، لا يُسمح سوى بالتعليق على مستوى السطر //.

مثال:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}