إجراء الاختبارات (Atest)

Atest هي أداة سطر أوامر تتيح للمستخدمين إنشاء اختبارات Android وتثبيتها وتشغيلها محليًا ، مما يسرع بشكل كبير عمليات إعادة تشغيل الاختبار دون الحاجة إلى معرفة خيارات سطر أوامر اختبار الاتحاد التجاري . تشرح هذه الصفحة كيفية استخدام Atest لإجراء اختبارات Android.

للحصول على معلومات عامة حول كتابة الاختبارات لنظام Android ، راجع اختبار نظام Android الأساسي .

للحصول على معلومات حول الهيكل العام لـ Atest ، راجع دليل مطور Atest .

للحصول على معلومات حول تشغيل الاختبارات في ملفات TEST_MAPPING من خلال Atest ، راجع تشغيل الاختبارات في ملفات TEST_MAPPING .

لإضافة ميزة إلى Atest ، اتبع Atest Developer Workflow .

قم بإعداد بيئتك

لإعداد بيئة Atest الخاصة بك ، اتبع التعليمات الواردة في إعداد البيئة واختيار الهدف وبناء الكود .

الاستخدام الأساسي

تأخذ أوامر Atest الشكل التالي:

atest test-to-run [optional-arguments]

الحجج الاختيارية

يسرد الجدول التالي الوسائط الأكثر استخدامًا. قائمة كاملة متاحة من خلال atest --help .

خيار	خيار طويل	وصف
-b	--build	يبني أهداف الاختبار. (إفتراضي)
-i	--install	تثبيت أدوات الاختبار (ملفات APK) على الجهاز. (إفتراضي)
-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 ، راجع قسم تحديد الخطوات: الإنشاء أو التثبيت أو التشغيل .

حدد الاختبارات

لإجراء الاختبارات ، حدد اختبارًا واحدًا أو أكثر باستخدام أحد المعرفات التالية:

• اسم وحدة
• الوحدة: فئة
• اسم الفصل
• اختبار التكامل التجاري
• مسار الملف
• اسم الحزمة

إشارات منفصلة لاختبارات متعددة بمسافات ، مثل هذا:

atest test-identifier-1 test-identifier-2

اسم وحدة

لتشغيل وحدة اختبار كاملة ، استخدم اسم الوحدة الخاصة بها. أدخل الاسم كما يظهر في متغيرات LOCAL_MODULE أو LOCAL_PACKAGE_NAME في ملف Android.bp أو Android.mk لهذا الاختبار.

أمثلة:

atest FrameworksServicesTests
atest CtsVideoTestCases

الوحدة: فئة

لتشغيل فصل دراسي واحد داخل وحدة نمطية ، استخدم الوحدة النمطية: فئة . الوحدة النمطية هي نفسها الموضحة في اسم الوحدة النمطية . 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

قم بإجراء اختبار التكامل

يوضح المثال التالي كيفية إجراء اختبار تكامل باستخدام مسار ملف من 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-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 .

قم بتشغيل اختبارات postubmit في ملفات TEST_MAPPING في الدلائل الحالية والأصلية:

atest :postsubmit

تشغيل الاختبارات من كل المجموعات في ملفات TEST_MAPPING:

atest :all

قم بتشغيل اختبارات postubmit في ملفات 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 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
  

• توقف عند حدوث فشل أو وصول التكرار إلى الجولة المائة.

  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
  

قم بإجراء الاختبارات على AVDs

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

لمزيد من المعلومات حول خيارات الاختبار فقط ، راجع خيارات المرور إلى الوحدات النمطية .