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

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

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

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

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

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

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

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

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

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

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

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

لكي يتمكّن برنامج اختبار Trade Federation من تشغيل وحدات اختبار لإصدار معيّن، يجب أن تكون هذه الوحدات قد تم ضبط test_suites لها على Soong أو LOCAL_COMPATIBILITY_SUITE لـ Make على إحدى الحِزمتَين التاليتَين:

• general-tests مخصّص للاختبارات التي لا تعتمد على أجهزة محدّدة. (مثل الأجهزة الخاصة بالمورّد والتي لا تستخدمها معظم الأجهزة يمتلكها). يجب أن تكون معظم الاختبارات في حزمة general-tests، حتى إذا كانت الخاصة بـ ABI أو بت أو ميزات أجهزة مثل HWASan (هناك هدف test_suites منفصل لكل واجهة تطبيق ثنائية (ABI)، حتى إذا كان يجب تنفيذها على الجهاز.
• device-tests مخصّص للاختبارات التي تعتمد على إمكانات خاصة بجهاز محدّد. يتم عادةً العثور على هذه الاختبارات ضمن فئة "vendor/". مخصَّصة للجهاز يشير ذلك إلى الإمكانات الفريدة لأحد الأجهزة، لذلك ينطبق إلى اختبارات 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": "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.sh run commandAndExit [test_module] --help

ارجع إلى التعامل مع الخيارات في الوضع "مقايضة" للاطّلاع على مزيد من التفاصيل حول آلية عمل الخيارات

إجراء الاختبارات باستخدام 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 واتحاد تجاري معالجة TEST_MAPPING مسبقًا إلى تنسيق JSON صالح بدون تعليقات للاحتفاظ يكون ملف JSON نظيفًا، فقط التعليق بتنسيق // على مستوى السطر

مثال:

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