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

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

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

للحصول على معلومات حول التركيبة الشاملة لـ Atest، راجع ورقة البيانات دليل المطوّر الأخير

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

لإضافة ميزة إلى Atest، اتبع الخطوات التالية: أحدث سير عمل للمطوّرين

إعداد البيئة

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

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

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

atest test-to-run [optional-arguments]

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

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

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 عرض تسجيل مستوى تصحيح الأخطاء
--iterations يتم إجراء اختبارات بشكل متكرّر حتى الوصول إلى الحد الأقصى للتكرار. (10 بشكل تلقائي)
--rerun-until-failure [COUNT=10] يعيد تشغيل جميع الاختبارات إلى أن يحدث إخفاق أو يصل الحد الأقصى للتكرار . (10 بشكل تلقائي)
--retry-any-failure [COUNT=10] تتم إعادة تشغيل الاختبارات التي لم يتم اجتيازها إلى أن يتم اجتيازها أو الوصول إلى الحد الأقصى المسموح به للتكرار. (10 بشكل تلقائي)
--start-avd تعمل هذه السياسة على إنشاء متوسّط مدة المشاهدة تلقائيًا وإجراء الاختبارات على الجهاز الافتراضي.
--acloud-create تنشئ هذه السياسة متوسّط مدة المشاهدة باستخدام الأمر 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.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.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
    

إجراء اختبارات على متوسّط مدة المشاهدة

يمكن لتطبيق Atest إجراء اختبارات على متوسّط مدة مشاهدة تم إنشاؤه حديثًا. تنفيذ acloud create لإنشاء متوسّط مدة المشاهدة وإنشاء الأدوات، استخدِم الأمثلة التالية لإجراء اختباراتك.

ابدأ متوسّط مدة المشاهدة ونفِّذ الاختبارات عليه:

acloud create --local-instance --local-image && atest test-to-run

بدء متوسّط مدة المشاهدة كجزء من عملية اختبار:

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

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