ربط الاختبار

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

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

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

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

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

يُرجى الاطّلاع على الأمثلة التالية:

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

• إضافة اختبارات الفحص المُسبَق إلى TEST_MAPPING لـ tools/dexter باستخدام عمليات الاستيراد

يعتمد ربط الاختبارات على مجموعة اختبارات Trade Federation (TF) ل ejecutang الاختبارات وإعداد تقارير النتائج.

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

اختبِر مجموعات عمليات الربط باستخدام مجموعة اختبار. يمكن إدخال اسم مجموعة الاختبار أي سلسلة. على سبيل المثال، يمكن أن يكون presubmit اسمًا لمجموعة من الاختبارات التي يتم إجراؤها عند التحقّق من التغييرات. ويمكن أن تكون postsubmit هي الاختبارات المستخدَمة للتحقّق من صحة الإصدارات بعد دمج التغييرات.

قواعد نص إنشاء الحِزم

من أجل سلسلة اختبار الاتحاد التجاري لتشغيل وحدات اختبارية لإصدار معيّن، يجب أن تتوفر في هذه الوحدات تم ضبط test_suites على Soong أو مجموعة LOCAL_COMPATIBILITY_SUITE لـ Make to إحدى هاتين الجناتين:

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

أمثلة:

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": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

ضبط السمات

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

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

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

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

تتيح لك السمة imports تضمين الاختبارات في ملفات TEST_MAPPING أخرى. بدون نسخ المحتوى. الملفات البالغ عددها TEST_MAPPING في المجلد الرئيسي أيضًا أدلة المسار المستورد. يسمح ربط الاختبار بعمليات الاستيراد المُدمجة، ما يعني أنّه يمكن لملفَّي TEST_MAPPING استيراد بعضهما، ويمكن لربط الاختبار دمج الاختبارات المضمّنة.

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

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

tradefed.sh run commandAndExit [test_module] --help

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

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

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

1. انتقِل إلى الدليل الذي يحتوي على الملف TEST_MAPPING.

2. شغِّل الأمر:

   atest
   

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

هذه هي الطريقة الأكثر وضوحًا لإجراء اختبارات الفحص قبل الإرسال في TEST_MAPPING الملفات في الدليل الحالي للعمل (CWD) والأدلة الرئيسية. قبل لتحديد موقع ملف 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 الاختبار A فقط. باستخدام الخيار --include-subdir، يُجري Atest اختبارَين (أ، ب).

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

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

مثال:

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