Atest هي أداة سطر أوامر تتيح للمستخدمين إنشاء وتثبيت وتشغيل يجري Android اختبارات محليًا، ما يُسرّع عمليات إعادة إجراء الاختبارات بشكل كبير بدون الحاجة إلى معرفة بتسخير اختبار الاتحاد التجاري خيارات سطر الأوامر. توضّح هذه الصفحة كيفية استخدام Atest لتشغيل Android الاختبار.
للحصول على معلومات عامة حول كتابة الاختبارات على نظام التشغيل Android، راجع اختبار النظام الأساسي Android:
للحصول على معلومات حول التركيبة الشاملة لـ Atest، راجع ورقة البيانات دليل المطوّر الأخير
للحصول على معلومات حول إجراء الاختبارات في ملفات TEST_MAPPING من خلال Atest، راجع إجراء اختبارات في ملفات TEST_MAPPING.
لإضافة ميزة إلى Atest، اتبع الخطوات التالية: أحدث سير عمل للمطوّرين
إعداد البيئة
لإعداد بيئة Atest، اتبع التعليمات الواردة في إعداد بيئة واختيار هدف وإنشاء الرمز.
الاستخدام الأساسي
تأخذ أوامر Atest الشكل التالي:
atest test-to-run [optional-arguments]
الوسيطات الاختيارية
يسرد الجدول التالي الوسيطات الأكثر استخدامًا. القائمة الكاملة عبارة عن
متاحة من خلال atest --help
.
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 |
تعرِض هذه القيمة التسجيل على مستوى تصحيح الأخطاء. |
|
--iterations |
يتم إجراء اختبارات بشكل متكرّر حتى الوصول إلى الحد الأقصى للتكرار. (10 بشكل تلقائي) |
|
--rerun-until-failure [COUNT=10] |
يعيد تشغيل جميع الاختبارات إلى أن يحدث إخفاق أو يصل الحد الأقصى للتكرار . (10 بشكل تلقائي) |
|
--retry-any-failure [COUNT=10] |
تتم إعادة تشغيل الاختبارات التي لم يتم اجتيازها إلى أن يتم اجتيازها أو الوصول إلى الحد الأقصى المسموح به للتكرار. (10 بشكل تلقائي) |
|
--start-avd |
تعمل هذه السياسة على إنشاء متوسّط مدة المشاهدة تلقائيًا وإجراء الاختبارات على الجهاز الافتراضي. |
|
--acloud-create |
تنشئ هذه السياسة متوسّط مدة المشاهدة باستخدام الأمر acloud . |
|
--[CUSTOM_ARGS] |
تُستخدَم لتحديد الوسيطات المخصّصة لأدوات الاختبار. |
-a |
--all-abi |
يُجري الاختبارات لجميع تصاميم الأجهزة المتاحة. |
|
--host |
يجري الاختبار بالكامل على المضيف بدون جهاز. ملاحظة: لن يتمكّن الجهاز من إجراء اختبار المضيف الذي يتطلّب جهازًا مزوّدًا بنظام التشغيل --host
. |
|
--history |
عرض نتائج الاختبارات بترتيب زمني. |
|
--latest-result |
يطبع آخر نتيجة اختبار. |
لمزيد من المعلومات عن -b
و-i
و-t
، يُرجى الاطّلاع على
حدِّد الخطوات: قسم الإنشاء أو التثبيت أو التشغيل.
تحديد الاختبارات
لإجراء الاختبارات، حدِّد اختبارًا واحدًا أو أكثر باستخدام أحد الخيارات التالية: المعرفات:
- اسم الوحدة
- الوحدة:الفئة
- اسم الصف
- اختبار التكامل المقايض
- مسار الملف
- اسم الحزمة
مراجع منفصلة لاختبارات متعددة باستخدام مسافات، مثل ما يلي:
atest test-identifier-1 test-identifier-2
اسم الوحدة
لتشغيل وحدة اختبار بالكامل، استخدم اسم الوحدة. أدخل الاسم كما يظهر
في متغير LOCAL_MODULE
أو LOCAL_PACKAGE_NAME
ضمن ذلك الاختبار
ملف Android.mk
أو Android.bp
أمثلة:
atest FrameworksServicesTests
atest CtsVideoTestCases
الوحدة:الفئة
لتشغيل فئة واحدة داخل وحدة معيّنة، استخدِم Module:Class. الوحدة هي
كما هو موضّح في اسم الوحدة. الفئة هي اسم
في ملف .java
، ويمكن أن يكون اسم الفئة المؤهلة بالكامل أو
اسمك الأساسي.
أمثلة:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
اسم الصف
لتشغيل فئة واحدة دون ذكر اسم الوحدة صراحة، استخدم الفئة الاسم.
أمثلة:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
اختبار التكامل المقايض
لإجراء اختبارات تم دمجها مباشرةً في 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 اختبارًا لتخطّي خطوة التنظيف أو الإيقاف. العديد من الاختبارات، مثل
CTS، يُرجى تنظيف الجهاز بعد إجراء الاختبار، لذا تحاول إعادة إجراء الاختبار
مع -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 بالعثور على
للاختبار بسرعة أكبر.
استخدام الوحدة النمطية:الفئة:
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
إجراء اختبارات على متوسّط مدة المشاهدة
يمكن لتطبيق Atest إجراء اختبارات على متوسّط مدة مشاهدة تم إنشاؤه حديثًا. تنفيذ acloud create
لإنشاء
متوسّط مدة المشاهدة وإنشاء الأدوات، استخدِم الأمثلة التالية لإجراء اختباراتك.
ابدأ متوسّط مدة المشاهدة ونفِّذ الاختبارات عليه:
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
لمزيد من المعلومات عن خيارات الاختبار فقط، راجع تمرير الخيارات إلى الوحدات: