تشغيل الاختبارات (أتيست)

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

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