Atest هي أداة سطر أوامر تتيح للمستخدمين إنشاء اختبارات Android وتثبيتها وتشغيلها محليًا، ما يؤدي إلى تسريع عمليات إعادة تشغيل الاختبارات بشكل كبير بدون الحاجة إلى معرفة خيارات سطر الأوامر لأداة اختبار Trade Federation. توضّح هذه الصفحة كيفية استخدام أداة Atest لتشغيل اختبارات Android.
للحصول على معلومات عامة حول كتابة اختبارات لنظام Android، راجِع اختبار منصة Android.
للحصول على معلومات حول البنية العامة لأداة Atest، يُرجى الرجوع إلى دليل مطوّري Atest.
للحصول على معلومات حول إجراء الاختبارات في ملفات TEST_MAPPING من خلال Atest، يُرجى الاطّلاع على إجراء الاختبارات في ملفات TEST_MAPPING.
لإضافة ميزة إلى Atest، اتّبِع سير عمل مطوّري Atest.
إعداد البيئة
لإعداد بيئة Atest، اتّبِع التعليمات الواردة في إعداد البيئة واختيار هدف وإنشاء الرمز.
الاستخدام الأساسي
تتّخذ أوامر Atest الشكل التالي:
atest test-to-run [optional-arguments]
الوسيطات الاختيارية
يسرد الجدول التالي الوسيطات الأكثر استخدامًا. تتوفّر قائمة كاملة من خلال atest --help
.
خيار | خيار طويل | الوصف |
---|---|---|
-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 |
تنشئ هذه الأداة تلقائيًا جهازًا افتراضيًا لنظام التشغيل Android (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 FrameworksServicesTests
atest CtsVideoTestCases
الوحدة:الفئة
لتشغيل صف واحد ضمن وحدة، استخدِم Module:Class. الوحدة هي نفسها الموضّحة في اسم الوحدة. Class هو اسم فئة الاختبار في ملف .java
، ويمكن أن يكون اسم الفئة المؤهَّل بالكامل أو الاسم الأساسي.
أمثلة:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
اسم الصف
لتشغيل فئة واحدة بدون تحديد اسم وحدة بشكل صريح، استخدِم اسم الفئة.
أمثلة:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
اختبار الدمج في Tradefed
لتنفيذ اختبارات مدمجة مباشرةً في TradeFed (غير الوحدات)، أدخِل الاسم كما يظهر في ناتج الأمر tradefed.sh list configs
. على سبيل المثال:
لإجراء اختبار
reboot.xml
، اتّبِع الخطوات التالية:
atest example/reboot
لإجراء اختبار
native-benchmark.xml
، اتّبِع الخطوات التالية:
atest native-benchmark
مسار الملف
تتيح أداة Atest إجراء اختبارات مستندة إلى الوحدات واختبارات مستندة إلى الدمج من خلال إدخال مسار ملف الاختبار أو الدليل حسب الاقتضاء. يتيح أيضًا تشغيل فئة واحدة من خلال تحديد مسار ملف Java الخاص بالفئة. يمكن استخدام المسارات النسبية والمطلقة.
تشغيل وحدة
تعرض الأمثلة التالية طريقتَين لتشغيل الوحدة CtsVideoTestCases
باستخدام مسار ملف.
التشغيل من جهاز Android repo-root
:
atest cts/tests/video
التشغيل من جهاز Android repo-root/cts/tests/video
:
atest .
إجراء صف تجريبي
يوضّح المثال التالي كيفية تشغيل فئة معيّنة ضمن الوحدة CtsVideoTestCases
باستخدام مسار ملف.
من جهاز Android repo-root
:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
إجراء اختبار تكاملي
يوضِّح المثال التالي كيفية تنفيذ اختبار تكاملي باستخدام مسار ملف
من Android repo-root
:
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 الاختبار على تخطّي خطوة التنظيف أو الإيقاف. تؤدي العديد من الاختبارات، مثل اختبار التوافق مع نظام التشغيل Android، إلى تنظيف الجهاز بعد إجراء الاختبار، لذا ستؤدي محاولة إعادة تشغيل الاختبار باستخدام -t
إلى حدوث خطأ بدون المَعلمة --disable-teardown
. استخدِم -d
قبل
-t
لتخطّي خطوة تنظيف الاختبار وإجراء الاختبار بشكل متكرّر.
atest -d test-to-run
atest -t test-to-run
تنفيذ طرق محدّدة
يتيح Atest تنفيذ طرق معيّنة ضمن فئة اختبار. على الرغم من أنّه يجب إنشاء الوحدة بأكملها، إلا أنّ ذلك يقلّل من الوقت اللازم لتشغيل الاختبارات. لتنفيذ طرق معيّنة، حدِّد الفئة باستخدام أي من الطرق المتاحة لتحديد فئة (الوحدة:الفئة أو مسار الملف أو غير ذلك)، ثم أضِف اسم الطريقة:
atest reference-to-class#method1
عند تحديد طرق متعددة، افصل بينها باستخدام فواصل:
atest reference-to-class#method1,method2,method3
أمثلة:
atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval
يوضّح المثالان التاليان الطرق المفضّلة لتشغيل طريقة واحدة،
testFlagChange
. يُفضّل استخدام هذه الأمثلة على استخدام اسم الفئة فقط، لأنّ تحديد موقع الوحدة أو ملف Java يتيح لأداة Atest العثور على الاختبار بشكل أسرع بكثير.
استخدام Module:Class:
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
تشغيل اختبارات الخط الرئيسي في ملفات 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 --iterations
atest test-to-run --iterations 5
تسهّل الطرق التالية رصد الاختبارات غير المستقرة:
الطريقة 1: تشغيل جميع الاختبارات إلى أن يحدث خطأ أو يتم بلوغ الحدّ الأقصى للتكرار
- تتوقّف العملية عند حدوث خطأ أو عند وصول التكرار إلى الجولة العاشرة (تلقائيًا).
atest test-to-run --rerun-until-failure
- تتوقف العملية عند حدوث خطأ أو عند وصول التكرار إلى الجولة رقم 100.
atest test-to-run --rerun-until-failure 100
الطريقة 2: تشغيل الاختبارات التي تعذّر إجراؤها فقط إلى أن يتم إجراؤها بنجاح أو يتم الوصول إلى الحد الأقصى لعدد التكرارات
- لنفترض أنّ
test-to-run
يتضمّن عدة حالات اختبار وأنّ إحدى هذه الحالات لم تنجح. نفِّذ الاختبار الفاشل 10 مرات فقط (تلقائيًا) أو إلى أن ينجح الاختبار.atest test-to-run --retry-any-failure
- أوقِف الاختبار غير الناجح عند اجتيازه أو وصوله إلى الجولة رقم 100.
atest test-to-run --retry-any-failure 100
إجراء اختبارات على أجهزة AVD
يمكن لأداة Atest تنفيذ الاختبارات على جهاز محاكاة Android افتراضي تم إنشاؤه حديثًا. نفِّذ الأمر acloud create
لإنشاء جهاز افتراضي يعمل بنظام التشغيل Android (AVD) وإنشاء عناصر، ثم استخدِم الأمثلة التالية لتنفيذ اختباراتك.
ابدأ تشغيل محاكي Android وقم بإجراء الاختبارات عليه:
acloud create --local-instance --local-image && atest test-to-run
ابدأ جهاز محاكاة Android كجزء من عملية اختبار:
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-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
تمرير الخيارات إلى نوع أو فئة مشغّل:
atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
لمزيد من المعلومات حول خيارات الاختبار فقط، يُرجى الاطّلاع على تمرير الخيارات إلى الوحدات.