Atest هي أداة سطر أوامر تتيح للمستخدمين إنشاء اختبارات Android وتثبيتها وتشغيلها محليًا، ما يؤدي إلى تسريع عمليات إعادة تشغيل الاختبارات بشكل كبير بدون الحاجة إلى معرفة خيارات سطر الأوامر في Trade Federation test harness. توضّح هذه الصفحة كيفية استخدام Atest لتشغيل اختبارات Android.
للحصول على معلومات عامة حول كتابة الاختبارات لنظام Android، يُرجى الاطّلاع على اختبار منصة Android.
للحصول على معلومات حول البنية العامة لأداة Atest، يُرجى الرجوع إلى دليل مطوّري Atest.
للحصول على معلومات حول تشغيل الاختبارات في ملفات TEST_MAPPING من خلال Atest، يُرجى الاطّلاع على تشغيل الاختبارات في ملفات TEST_MAPPING.
لإضافة ميزة إلى Atest، يُرجى اتّباع سير عمل مطوّري Atest.
إعداد البيئة
لإعداد بيئة Atest، يُرجى اتّباع التعليمات الواردة في إعداد البيئة واختيار هدف وإنشاء الرمز.
الاستخدام الأساسي
تأخذ أوامر Atest الشكل التالي:
atest test-to-run [optional-arguments]
الوسيطات الاختيارية
يسرد الجدول التالي الوسيطات الأكثر استخدامًا. تتوفّر قائمة كاملة من خلال atest --help.
| Option | Long option | الوصف |
|---|---|---|
-b |
--build |
ينشئ أهداف الاختبار. (تلقائي) |
-i |
--install |
يثبِّت مواد الاختبار (ملفات APK) على الجهاز. (تلقائي) |
-t |
--test |
يُجري الاختبارات. (تلقائي) |
-s |
--serial |
يُجري الاختبارات على الجهاز المحدّد. يمكن اختبار جهاز واحد في كل مرة. |
-d |
--disable-teardown |
يوقف عملية إزالة الاختبار وتنظيفه. |
|
--dry-run |
يُجري Atest تشغيلًا تجريبيًا بدون إنشاء الاختبارات أو تثبيتها أو تشغيلها فعليًا. |
-m |
--rebuild-module-info |
يفرض إعادة إنشاء ملف module-info.json. |
-w |
--wait-for-debugger |
ينتظر اكتمال عملية تصحيح الأخطاء قبل التنفيذ. |
-v |
--verbose |
يعرض تسجيل الأحداث على مستوى DEBUG. |
|
--iterations |
يُجري الاختبارات بشكل متكرّر إلى أن يتم الوصول إلى الحد الأقصى للتكرار. (10 تلقائيًا) |
|
--rerun-until-failure [COUNT=10] |
يُعيد تشغيل جميع الاختبارات إلى أن يحدث خطأ أو يتم الوصول إلى الحد الأقصى للتكرار. (10 تلقائيًا) |
|
--retry-any-failure [COUNT=10] |
يُعيد تشغيل الاختبارات التي تعذّر إجراؤها إلى أن يتم اجتيازها أو يتم الوصول إلى الحد الأقصى للتكرار. (10 تلقائيًا) |
|
--start-avd |
ينشئ تلقائيًا جهاز AVD ويُجري الاختبارات على الجهاز الافتراضي. |
|
--acloud-create |
ينشئ جهاز AVD باستخدام الأمر acloud. |
|
--[CUSTOM_ARGS] |
يحدّد وسيطات مخصّصة لمشغّلات الاختبار. |
-a |
--all-abi |
يُجري الاختبارات لجميع بُنى الأجهزة المتوفّرة. |
|
--host |
يُجري الاختبار بالكامل على المضيف بدون جهاز. ملاحظة: سيؤدي تشغيل اختبار مضيف يتطلّب جهازًا باستخدام --host
سيؤدي إلى حدوث خطأ. |
|
--history |
يعرض نتائج الاختبار بترتيب زمني. |
|
--latest-result |
يطبع أحدث نتيجة اختبار. |
لمزيد من المعلومات عن -b و-i و-t، يُرجى الاطّلاع على قسم
تحديد الخطوات: الإنشاء أو التثبيت أو التشغيل.
تحديد الاختبارات
لتشغيل الاختبارات، يُرجى تحديد اختبار واحد أو أكثر باستخدام أحد المعرّفات التالية:
- اسم الوحدة
- الوحدة:الصف
- اسم الصف
- اختبار الدمج في Tradefed
- مسار الملف
- اسم الحزمة
يُرجى الفصل بين مراجع الاختبارات المتعدّدة باستخدام مسافات، على النحو التالي:
atest test-identifier-1 test-identifier-2
اسم الوحدة
لتشغيل وحدة اختبار كاملة، يُرجى استخدام اسم الوحدة. يُرجى إدخال الاسم كما يظهر في المتغيّرات LOCAL_MODULE أو LOCAL_PACKAGE_NAME في ملف Android.mk أو Android.bp الخاص بهذا الاختبار.
أمثلة:
atest FrameworksServicesTestsatest CtsVideoTestCases
الوحدة:الصف
لتشغيل صف واحد ضمن وحدة، يُرجى استخدام الوحدة:الصف. الوحدة هي نفسها الموضّحة في اسم الوحدة. الصف هو اسم صف الاختبار في ملف .java، ويمكن أن يكون اسم الصف المؤهّل بالكامل أو الاسم الأساسي.
أمثلة:
atest CtsVideoTestCases:VideoEncoderDecoderTestatest FrameworksServicesTests:ScreenDecorWindowTestsatest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
اسم الصف
لتشغيل صف واحد بدون تحديد اسم وحدة بشكل صريح، يُرجى استخدام اسم الصف.
أمثلة:
atest ScreenDecorWindowTestsatest VideoEncoderDecoderTest
اختبار الدمج في Tradefed
لتشغيل الاختبارات المدمَجة مباشرةً في TradeFed (غير الوحدات)، يُرجى إدخال الاسم كما يظهر في ناتج الأمر tradefed.sh list configs. على سبيل المثال:
لتشغيل اختبار
reboot.xml:
atest example/reboot
لتشغيل اختبار
native-benchmark.xml:
atest native-benchmark
مسار الملف
تتيح أداة Atest تشغيل الاختبارات المستندة إلى الوحدات والاختبارات المستندة إلى الدمج من خلال إدخال مسار ملف الاختبار أو دليله حسب الاقتضاء. تتيح أيضًا تشغيل صف واحد من خلال تحديد مسار ملف Java الخاص بالصف. يمكن استخدام المسارات النسبية والمطلقة.
تشغيل وحدة
توضّح الأمثلة التالية طريقتَين لتشغيل وحدة CtsVideoTestCases باستخدام مسار ملف.
التشغيل من repo-root في Android:
atest cts/tests/video
التشغيل من repo-root/cts/tests/video في Android:
atest .
تشغيل صف اختبار
يوضّح المثال التالي كيفية تشغيل صف معيّن ضمن وحدة CtsVideoTestCases باستخدام مسار ملف.
من repo-root في Android:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
تشغيل اختبار دمج
يوضّح المثال التالي كيفية تشغيل اختبار دمج باستخدام مسار ملف من repo-root في Android:
atest tools/tradefederation/contrib/res/config/example/reboot.xml
اسم الحزمة
تتيح أداة Atest البحث عن الاختبارات حسب اسم الحزمة.
أمثلة:
atest com.android.server.wm
atest com.android.uibench.janktests
تحديد الخطوات: الإنشاء أو التثبيت أو التشغيل
يُرجى استخدام الخيارات -b و-i و-t لتحديد الخطوات التي يجب تشغيلها. إذا لم تحدّد خيارًا، يتم تشغيل جميع الخطوات.
- إنشاء الأهداف فقط:
atest -b test-to-run - تشغيل الاختبارات فقط:
atest -t test-to-run - تثبيت ملف APK وتشغيل الاختبارات:
atest -it test-to-run - الإنشاء والتشغيل، ولكن بدون التثبيت:
atest -bt test-to-run
يمكن أن تفرض أداة Atest على الاختبار تخطّي خطوة التنظيف أو الإزالة. تؤدي العديد من الاختبارات، مثل
اختبارات CTS، إلى تنظيف الجهاز بعد تشغيل الاختبار، لذا ستتعذّر محاولة إعادة تشغيل الاختبار
باستخدام -t بدون المعلمة --disable-teardown. يُرجى استخدام -d قبل -t لتخطّي خطوة تنظيف الاختبار واختباره بشكل متكرّر.
atest -d test-to-runatest -t test-to-run
تشغيل طرق محدّدة
تتيح أداة Atest تشغيل طرق محدّدة ضمن صف اختبار. على الرغم من أنّه يجب إنشاء الوحدة بأكملها، فإنّ هذا يقلّل الوقت اللازم لتشغيل الاختبارات. لتشغيل طرق محدّدة، يُرجى تحديد الصف باستخدام أيّ من الطرق المتاحة لتحديد صف (الوحدة:الصف أو مسار الملف وما إلى ذلك) وإلحاق اسم الطريقة:
atest reference-to-class#method1
عند تحديد طرق متعدّدة، يُرجى الفصل بينها باستخدام فواصل:
atest reference-to-class#method1,method2,method3
أمثلة:
atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecorsatest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval
يوضّح المثالان التاليان الطرق المفضّلة لتشغيل طريقة واحدة، وهي testFlagChange. يُفضّل استخدام هذين المثالَين على استخدام اسم الصف فقط لأنّ تحديد الوحدة أو موقع ملف Java يسمح لأداة Atest بالعثور على الاختبار بسرعة أكبر بكثير.
باستخدام الوحدة:الصف:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
من Android repo-root:
atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
يمكن تشغيل طرق متعدّدة من صفوف ووحدات مختلفة:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors
تشغيل صفوف متعدّدة
لتشغيل صفوف متعدّدة، يُرجى الفصل بينها باستخدام مسافات بالطريقة نفسها التي يتم بها تشغيل اختبارات متعدّدة. تنشئ أداة Atest الصفوف وتشغّلها بكفاءة، لذا فإنّ تحديد مجموعة فرعية من الصفوف في وحدة يحسّن الأداء مقارنةً بتشغيل الوحدة بأكملها.
لتشغيل صفَين في الوحدة نفسها:
atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
لتشغيل صفَين في وحدتَين مختلفتَين:
atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
تشغيل ملفات GTest الثنائية
يمكن لأداة Atest تشغيل ملفات GTest الثنائية. يُرجى استخدام -a لتشغيل هذه الاختبارات لجميع بُنى الأجهزة المتوفّرة، وهي في هذا المثال armeabi-v7a (بنية ARM 32 بت) وarm64-v8a (بنية ARM 64 بت).
اختبار الإدخال النموذجي:
atest -a libinput_tests inputflinger_tests
لاختيار ملف GTest ثنائي معيّن لتشغيله، يُرجى استخدام نقطتَين رأسيتَين (:) لتحديد اسم الاختبار ، وعلامة تصنيف (#) لتحديد طريقة فردية بشكل إضافي.
على سبيل المثال، لتعريف الاختبار التالي:
TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)
يُرجى تشغيل ما يلي لتحديد الاختبار بأكمله:
atest inputflinger_tests:InputDispatcherTest
أو يُرجى تشغيل اختبار فردي باستخدام ما يلي:
atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents
تشغيل الاختبارات في TEST_MAPPING
يمكن لأداة Atest تشغيل الاختبارات في ملفات TEST_MAPPING.
تشغيل اختبارات الإرسال المسبق ضمنيًا
لتشغيل اختبارات الإرسال المسبق في ملفات TEST_MAPPING في الدليلَين الحالي والأعلى:
atest
لتشغيل اختبارات الإرسال المسبق في ملفات TEST_MAPPING في /path/to/project و
الأدلة الرئيسية الخاصة به:
atest --test-mapping /path/to/project
تشغيل مجموعة اختبار محدّدة
مجموعات الاختبار المتوفّرة هي: presubmit(تلقائي) وpostsubmit و
mainline-presubmit وall.
لتشغيل اختبارات الإرسال اللاحق في ملفات TEST_MAPPING في الدليلَين الحالي والأعلى:
atest :postsubmit
لتشغيل الاختبارات من جميع المجموعات في ملفات TEST_MAPPING:
atest :all
لتشغيل اختبارات الإرسال اللاحق في ملفات TEST_MAPPING في /path/to/project و الأدلة الرئيسية الخاصة به:
atest --test-mapping /path/to/project:postsubmit
لتشغيل اختبارات Mainline في ملفات TEST_MAPPING في /path/to/project و الأدلة الرئيسية الخاصة به:
atest --test-mapping /path/to/project:mainline-presubmit
تشغيل الاختبارات في الأدلة الفرعية
تلقائيًا، تبحث أداة Atest عن الاختبارات في ملفات TEST_MAPPING للأعلى فقط (من الدليل الحالي أو الدليل المحدّد إلى الأدلة الرئيسية الخاصة به). إذا كنت تريد أيضًا تشغيل الاختبارات في ملفات TEST_MAPPING في الأدلة الفرعية، يُرجى استخدام --include-subdirs لإجبار أداة Atest على تضمين هذه الاختبارات أيضًا:
atest --include-subdirs /path/to/projectتشغيل الاختبارات بشكل متكرّر
لتشغيل الاختبارات بشكل متكرّر، يُرجى تمرير الوسيطة --iterations. سواء تم اجتياز الاختبار أو تعذّر إجراؤه، ستكرّر أداة Atest الاختبار إلى أن يتم الوصول إلى الحد الأقصى للتكرار.
أمثلة:
تلقائيًا، تكرّر أداة Atest الاختبار 10 مرات. يجب أن يكون عدد التكرارات عددًا صحيحًا موجبًا.
atest test-to-run --iterationsatest test-to-run --iterations 5
تسهّل الطرق التالية رصد الاختبارات غير الموثوقة:
الطريقة 1: تشغيل جميع الاختبارات إلى أن يحدث خطأ أو يتم الوصول إلى الحد الأقصى للتكرار
- يتم التوقف عند حدوث خطأ أو وصول التكرار إلى الجولة العاشرة (تلقائيًا).
atest test-to-run --rerun-until-failure - يتم التوقف عند حدوث خطأ أو وصول التكرار إلى الجولة المئة.
atest test-to-run --rerun-until-failure 100
الطريقة 2: تشغيل الاختبارات التي تعذّر إجراؤها فقط إلى أن يتم اجتيازها أو يتم الوصول إلى الحد الأقصى للتكرار
- لنفترض أنّ
test-to-runيتضمّن حالات اختبار متعدّدة وأنّ أحد الاختبارات يتعذّر إجراؤه. يتم تشغيل الاختبار الذي تعذّر إجراؤه فقط 10 مرات (تلقائيًا) أو إلى أن يتم اجتيازه.atest test-to-run --retry-any-failure - يتم إيقاف تشغيل الاختبار الذي تعذّر إجراؤه عند اجتيازه أو وصوله إلى الجولة المئة.
atest test-to-run --retry-any-failure 100
تشغيل الاختبارات على أجهزة AVD
تستطيع أداة Atest تشغيل الاختبارات على جهاز AVD تم إنشاؤه حديثًا. يُرجى تشغيل acloud create لإنشاء جهاز AVD وإنشاء مواد، ثم استخدام الأمثلة التالية لتشغيل الاختبارات.
لبدء جهاز AVD وتشغيل الاختبارات عليه:
acloud create --local-instance --local-image && atest test-to-run
لبدء جهاز AVD كجزء من تشغيل الاختبار:
atest test-to-run --acloud-create "--local-instance --local-image"
لمزيد من المعلومات، يُرجى تشغيل acloud create --help.
تمرير الخيارات إلى الوحدة
تستطيع أداة Atest تمرير الخيارات إلى وحدات الاختبار. لإضافة خيارات سطر أوامر TradeFed إلى تشغيل الاختبار، يُرجى استخدام البنية التالية والتأكّد من أنّ الوسيطات المخصّصة تتّبع تنسيق خيار سطر أوامر Tradefed.
atest test-to-run -- [CUSTOM_ARGS]
لتمرير خيارات وحدة الاختبار إلى أدوات إعداد الهدف أو مشغّلات الاختبار المحدّدة في ملف إعداد الاختبار:
atest test-to-run -- --module-arg module-name:option-name:option-valueatest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
لتمرير الخيارات إلى نوع مشغّل أو صف:
atest test-to-run -- --test-arg test-class:option-name:option-valueatest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
لمزيد من المعلومات عن الخيارات الخاصة بالاختبار فقط، يُرجى الاطّلاع على تمرير الخيارات إلى الوحدات.