اختبار رسم الخرائط

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

ما هو اختبار التعيين؟

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

يمكن لـ Atest استخدام ملفات TEST_MAPPING لتشغيل اختبارات الإرسال المسبق في الدلائل المرتبطة. باستخدام Test Mapping ، يمكنك إضافة نفس مجموعة الاختبارات لتقديم الشيكات مسبقًا مع تغيير بسيط داخل شجرة مصدر Android.

انظر هذه الأمثلة:

قم بإضافة اختبارات مُرسلة مسبقًا إلى TEST_MAPPING من أجل services.core

أضف الاختبارات المُقدمة مسبقًا إلى TEST_MAPPING للأدوات / dexter باستخدام الواردات

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

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

اختبار مجموعات رسم الخرائط من خلال مجموعة اختبار . يمكن أن يكون اسم مجموعة الاختبار أي سلسلة. على سبيل المثال ، يمكن أن يكون التقديم المسبق لمجموعة من الاختبارات ليتم تشغيلها عند التحقق من صحة التغييرات. ويمكن استخدام اختبارات postubmit للتحقق من صحة البنيات بعد دمج التغييرات.

التعبئة والتغليف بناء قواعد البرنامج النصي

من أجل أن تقوم Trade Federation Test Harness بتشغيل وحدات اختبار Test Mapping لبناء معين ، يجب أن تحتوي هذه الوحدات على مجموعة test_suite لـ Soong أو LOCAL_COMPATIBILITY_SUITE لتكوين واحدة من هاتين المجموعتين:

  • الاختبارات العامة - الاختبارات التي لا تعتمد على الوظائف الخاصة بالجهاز (مثل الأجهزة الخاصة بالبائع والتي لا تمتلكها معظم الأجهزة). يجب أن تكون معظم الاختبارات في مجموعة الاختبارات العامة ، حتى لو كانت خاصة بميزة ABI أو الشاهد أو ميزات الأجهزة مثل HWASan (هناك هدف منفصل للاختبار لكل ABI) ، وحتى إذا كان يتعين تشغيلها على أحد الأجهزة.
  • اختبارات الجهاز - الاختبارات التي تعتمد على الوظائف الخاصة بالجهاز. عادةً ما يتم العثور على هذه الاختبارات تحت 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"
    }
  ]
}

تحديد السمات

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

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

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

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

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

تحتوي سمة الخيارات على خيارات سطر أوامر TradeFed إضافية.

للحصول على قائمة كاملة بالخيارات المتاحة لاختبار معين ، قم بتشغيل:

tradefed.sh run commandAndExit [test_module] --help

الرجوع إلى TradeFed Option Handling للحصول على مزيد من التفاصيل حول كيفية عمل الخيارات.

إجراء الاختبارات مع 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

تشغيل قواعد الاختبار postubmit

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

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

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

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

atest [--test-mapping] --host

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

يمكنك تحديد مجموعات الاختبار في الأمر Atest. سيقوم الأمر التالي بتشغيل جميع اختبارات postubmit المتعلقة بالملفات الموجودة في الدليل 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 --include-subdir ، سيُجري Atest الاختبار A. فقط باستخدام الخيار --include --include-subdir ، سيُجري Atest اختبارين (A ، B).

يتم دعم التعليق على مستوى الخط

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

مثال:

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