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

‫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

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