Atest هي أداة سطر أوامر تتيح للمستخدمين إنشاء اختبارات Android وتثبيتها وتشغيلها محليًا، مما يؤدي إلى تسريع عمليات إعادة تشغيل الاختبار بشكل كبير دون الحاجة إلى معرفة خيارات سطر أوامر اختبار الاتحاد التجاري . تشرح هذه الصفحة كيفية استخدام Atest لإجراء اختبارات Android.
للحصول على معلومات عامة حول اختبارات الكتابة لنظام Android، راجع اختبار نظام Android الأساسي .
للحصول على معلومات حول الهيكل العام لـ Atest، راجع دليل مطور Atest .
للحصول على معلومات حول تشغيل الاختبارات في ملفات TEST_MAPPING من خلال Atest، راجع تشغيل الاختبارات في ملفات TEST_MAPPING .
لإضافة ميزة إلى Atest، اتبع سير عمل Atest Developer .
قم بإعداد بيئتك
لإعداد بيئة Atest الخاصة بك، اتبع الإرشادات الموجودة في إعداد البيئة واختيار هدف وإنشاء التعليمات البرمجية .
الاستخدام الأساسي
تأخذ أوامر Atest النموذج التالي:
atest test-to-run [optional-arguments]
الحجج الاختيارية
يسرد الجدول التالي الوسائط الأكثر استخدامًا. القائمة الكاملة متاحة من خلال atest --help
.
خيار | خيار طويل | وصف |
---|---|---|
-b | --build | يبني أهداف الاختبار. (تقصير) |
-i | --install | تثبيت عناصر الاختبار (APKs) على الجهاز. (تقصير) |
-t | --test | يدير الاختبارات. (تقصير) |
-s | --serial | يقوم بإجراء الاختبارات على الجهاز المحدد. يمكن اختبار جهاز واحد في كل مرة. |
-d | --disable-teardown | تعطيل اختبار التدمير والتنظيف. |
| --info | يعرض المعلومات ذات الصلة بالأهداف المحددة، ثم يخرج. |
| --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 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 (غير الوحدات)، أدخل الاسم كما يظهر في إخراج أمر 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
قم بإجراء الاختبارات على أجهزة 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-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
لمزيد من المعلومات حول خيارات الاختبار فقط، راجع خيارات التمرير إلى الوحدات النمطية .