هذه مقدمة مختصرة عن تخطيط الاختبار وشرح لكيفية البدء في تكوين الاختبارات بسهولة في مشروع Android مفتوح المصدر (AOSP).
حول اختبار رسم الخرائط
تعيين الاختبار هو أسلوب قائم على Gerrit يسمح للمطورين بإنشاء قواعد اختبار ما قبل وبعد الإرسال مباشرة في شجرة مصدر Android وترك قرارات الفروع والأجهزة ليتم اختبارها للبنية التحتية للاختبار نفسها. تعريفات تعيين الاختبار هي ملفات JSON تسمى TEST_MAPPING والتي يمكن وضعها في أي دليل مصدر.
يمكن لـ Atest استخدام ملفات TEST_MAPPING لتشغيل اختبارات الإرسال المسبق في الدلائل المرتبطة. باستخدام تعيين الاختبار، يمكنك إضافة نفس مجموعة الاختبارات لإرسال الشيكات مسبقًا مع تغيير بسيط داخل شجرة مصدر Android.
انظر هذه الأمثلة:
أضف اختبارات الإرسال المسبق إلى TEST_MAPPING لـservices.core
أضف اختبارات الإرسال المسبق إلى TEST_MAPPING للأدوات/dexter باستخدام عمليات الاستيراد
يعتمد رسم خرائط الاختبار على أداة اختبار الاتحاد التجاري (TF) لتنفيذ الاختبارات والإبلاغ عن النتائج.
تحديد مجموعات الاختبار
اختبار تعيين مجموعات الاختبارات عبر مجموعة اختبار . يمكن أن يكون اسم مجموعة الاختبار أي سلسلة. على سبيل المثال، يمكن أن يكون الإرسال المسبق لمجموعة من الاختبارات ليتم تشغيلها عند التحقق من صحة التغييرات. ويمكن استخدام اختبارات ما بعد الإرسال للتحقق من صحة البنيات بعد دمج التغييرات.
قواعد البرنامج النصي لبناء الحزمة
لكي يتمكن جهاز اختبار الاتحاد التجاري من تشغيل وحدات اختبار تعيين الاختبار لبناء معين، يجب أن تحتوي هذه الوحدات على مجموعة test_suite لـ Soong أو مجموعة LOCAL_COMPATIBILITY_SUITE لـ Make لأحد هاتين المجموعتين:
- الاختبارات العامة - الاختبارات التي لا تعتمد على وظائف خاصة بالجهاز (مثل الأجهزة الخاصة بالمورد والتي لا تتوفر في معظم الأجهزة). يجب أن تكون معظم الاختبارات في مجموعة الاختبارات العامة، حتى لو كانت خاصة بواجهة برمجة التطبيقات (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"
}
]
}
تعيين السمات
في المثال أعلاه، يعد presubmit
و postsubmit
أسماء كل مجموعة اختبار . راجع تعريف مجموعات الاختبار لمزيد من المعلومات حول مجموعات الاختبار.
يمكن تعيين اسم وحدة الاختبار أو اسم اختبار تكامل الاتحاد التجاري (مسار المورد إلى ملف اختبار XML، على سبيل المثال، uiautomator/uiautomator-demo ) في قيمة سمة name
. لاحظ أن حقل الاسم لا يمكنه استخدام name
الفئة أو name
طريقة الاختبار. لتضييق نطاق الاختبارات المراد تشغيلها، يمكنك استخدام خيارات مثل include-filter
هنا. راجع ( استخدام عينة من مرشح التضمين ).
يشير إعداد المضيف للاختبار إلى ما إذا كان الاختبار عبارة عن اختبار بدون جهاز يتم تشغيله على المضيف أم لا. القيمة الافتراضية خاطئة ، مما يعني أن الاختبار يتطلب جهازًا للتشغيل. أنواع الاختبار المدعومة هي HostGTest لثنائيات GTest و HosTest لاختبارات JUnit.
تسمح لك سمة file_patterns بتعيين قائمة من سلاسل regex لمطابقة المسار النسبي لأي ملف كود مصدر (بالنسبة للدليل الذي يحتوي على ملف TEST_MAPPING). في المثال أعلاه، سيتم تشغيل اختبار CtsWindowManagerDeviceTestCases
في الإرسال المسبق فقط عندما يبدأ أي ملف Java بـ Window أو يتم تغيير النشاط، الموجود في نفس الدليل لملف TEST_MAPPING أو أي من دلائله الفرعية. يجب الهروب من الخطوط المائلة العكسية \ لأنها موجودة في ملف JSON.
تسمح لك سمة الاستيراد بتضمين الاختبارات في ملفات TEST_MAPPING الأخرى دون نسخ المحتوى. لاحظ أنه سيتم أيضًا تضمين ملفات TEST_MAPPING الموجودة في الدلائل الأصلية للمسار المستورد. يسمح تعيين الاختبار بالاستيراد المتداخل؛ وهذا يعني أنه يمكن لملفين TEST_MAPPING استيراد بعضهما البعض، كما أن اختبار التعيين قادر على دمج الاختبارات المضمنة بشكل صحيح.
تحتوي سمة الخيارات على خيارات سطر أوامر TradeFed إضافية.
للحصول على قائمة كاملة بالخيارات المتاحة لاختبار معين، قم بتشغيل:
tradefed.sh run commandAndExit [test_module] --help
ارجع إلى TradeFed Option Handling للحصول على مزيد من التفاصيل حول كيفية عمل الخيارات.
قم بإجراء الاختبارات باستخدام Atest
لتنفيذ قواعد اختبار الإرسال المسبق محليًا:
- انتقل إلى الدليل الذي يحتوي على ملف TEST_MAPPING.
- قم بتشغيل الأمر:
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. سيقوم الأمر التالي بتشغيل جميع اختبارات ما بعد الإرسال المتعلقة بالملفات الموجودة في الدليل 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 اختبارين (A، B).
يتم دعم التعليق على مستوى الخط
يمكنك إضافة تعليق على مستوى السطر //
-format لتوضيح ملف TEST_MAPPING مع وصف الإعداد التالي. سيقوم ATest وTrade Union بمعالجة TEST_MAPPING مسبقًا إلى تنسيق JSON صالح بدون تعليقات. للحفاظ على ملف JSON نظيفًا وسهل القراءة، يتم دعم التعليق بتنسيق //
على مستوى السطر فقط.
مثال:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}