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

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

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

للحصول على معلومات حول البنية العامة لأداة Atest، يُرجى الرجوع إلى دليل مطوّري Atest.

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

لإضافة ميزة إلى Atest، يُرجى اتّباع سير عمل مطوّري Atest.

إعداد البيئة

لإعداد بيئة Atest، يُرجى اتّباع التعليمات الواردة في إعداد البيئة واختيار هدف وإنشاء الرمز.

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

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

atest test-to-run [optional-arguments]

الوسيطات الاختيارية

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

Option Long 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 يعرض تسجيل الأحداث على مستوى 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

الوحدة:الصف

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

التشغيل من repo-root في Android:

atest cts/tests/video

التشغيل من repo-root/cts/tests/video في Android:

    atest .

تشغيل صف اختبار

يوضّح المثال التالي كيفية تشغيل صف معيّن ضمن وحدة CtsVideoTestCases باستخدام مسار ملف.

من repo-root في Android:

    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.

لتشغيل اختبارات الإرسال اللاحق في ملفات TEST_MAPPING في الدليلَين الحالي والأعلى:

atest :postsubmit

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

atest :all

لتشغيل اختبارات الإرسال اللاحق في ملفات TEST_MAPPING في /path/to/project و الأدلة الرئيسية الخاصة به:

atest --test-mapping /path/to/project:postsubmit

لتشغيل اختبارات Mainline في ملفات 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
    
  • يتم التوقف عند حدوث خطأ أو وصول التكرار إلى الجولة المئة.
    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
    

تشغيل الاختبارات على أجهزة 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

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