اجرای تست ها (Atest)

Atest یک ابزار خط فرمان است که به کاربران امکان می‌دهد تست‌های اندروید را به صورت محلی بسازند، نصب کنند و اجرا کنند و بدون نیاز به دانش در مورد گزینه‌های خط فرمان کنترل تست Trade Federation ، سرعت اجرای مجدد تست‌ها را تا حد زیادی افزایش دهند. این صفحه نحوه استفاده از Atest برای اجرای تست‌های اندروید را توضیح می‌دهد.

برای اطلاعات کلی در مورد نوشتن تست برای اندروید، به بخش تست پلتفرم اندروید مراجعه کنید.

برای اطلاعات در مورد ساختار کلی Atest، به راهنمای توسعه‌دهندگان Atest مراجعه کنید.

برای اطلاعات در مورد اجرای تست‌ها در فایل‌های TEST_MAPPING از طریق Atest، به اجرای تست‌ها در فایل‌های TEST_MAPPING مراجعه کنید.

برای افزودن یک ویژگی به Atest، گردش کار توسعه‌دهندگان Atest را دنبال کنید.

Set up your environment

برای راه‌اندازی محیط Atest خود، دستورالعمل‌های موجود در بخش‌های راه‌اندازی محیط ، انتخاب هدف و ساخت کد را دنبال کنید.

کاربرد اولیه

Atest commands take the following form:

atest test-to-run [optional-arguments]

آرگومان‌های اختیاری

جدول زیر آرگومان‌های پرکاربرد را فهرست می‌کند. فهرست کامل از طریق atest --help قابل دسترسی است.

گزینه Long option توضیحات
-b --build Builds test targets. (default)
-i --install مصنوعات آزمایشی (APK) را روی دستگاه نصب می‌کند. (پیش‌فرض)
-t --test تست‌ها را اجرا می‌کند. (پیش‌فرض)
-s --serial تست‌ها را روی دستگاه مشخص شده اجرا می‌کند. می‌توان هر دستگاه را به طور همزمان تست کرد.
-d --disable-teardown Disables test teardown and cleanup.
--dry-run Atest را بدون ساخت، نصب یا اجرای تست‌های واقعی، به صورت آزمایشی اجرا می‌کند.
-m --rebuild-module-info Forces a rebuild of the module-info.json file.
-w --wait-for-debugger Waits for debugger to finish before executing.
-v --verbose Displays DEBUG level logging.
--iterations حلقه، تست‌ها را تا رسیدن به حداکثر تکرار اجرا می‌کند. (به طور پیش‌فرض ۱۰)
--rerun-until-failure [COUNT=10] تمام تست‌ها را تا زمان وقوع خطا یا رسیدن به حداکثر تکرار، دوباره اجرا می‌کند. (به طور پیش‌فرض ۱۰)
--retry-any-failure [COUNT=10] تست‌های ناموفق را تا زمان قبولی یا رسیدن به حداکثر تکرار، دوباره اجرا می‌کند. (به طور پیش‌فرض ۱۰)
--start-avd به طور خودکار یک AVD ایجاد می‌کند و تست‌هایی را روی دستگاه مجازی اجرا می‌کند.
--acloud-create Creates an AVD using the acloud command.
--[CUSTOM_ARGS] Specifies custom arguments for the test runners.
-a --all-abi آزمایش‌ها را برای تمام معماری‌های دستگاه موجود اجرا می‌کند.
--host تست را به طور کامل روی میزبان و بدون دستگاه اجرا می‌کند.
توجه: اجرای تست میزبان که به دستگاهی با --host نیاز دارد، با شکست مواجه خواهد شد.
--history Shows test results in chronological order.
--latest-result Prints the latest test result.

برای اطلاعات بیشتر در مورد -b ‎، -i ‎ و -t ‎، به بخش «مراحل مشخص کردن: ساخت، نصب یا اجرا» مراجعه کنید.

تست‌ها را مشخص کنید

برای اجرای تست‌ها، یک یا چند تست را با استفاده از یکی از شناسه‌های زیر مشخص کنید:

  • نام ماژول
  • ماژول:کلاس
  • نام کلاس
  • Tradefed integration test
  • File path
  • نام بسته

ارجاعات به چندین تست را با فاصله از هم جدا کنید، مانند این:

atest test-identifier-1 test-identifier-2

نام ماژول

برای اجرای کل یک ماژول آزمایشی، از نام ماژول آن استفاده کنید. نام را همانطور که در متغیرهای LOCAL_MODULE یا LOCAL_PACKAGE_NAME در فایل Android.mk یا Android.bp آن تست آمده است، وارد کنید.

مثال‌ها:

atest FrameworksServicesTests
atest CtsVideoTestCases

ماژول:کلاس

برای اجرای یک کلاس واحد درون یک ماژول، از Module:Class استفاده کنید. Module همان چیزی است که در Module name توضیح داده شده است. 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 از اجرای تست‌های مبتنی بر ماژول و تست‌های مبتنی بر ادغام با وارد کردن مسیر فایل یا دایرکتوری تست آنها به صورت مناسب پشتیبانی می‌کند. همچنین از اجرای یک کلاس واحد با مشخص کردن مسیر فایل جاوای کلاس پشتیبانی می‌کند. هر دو مسیر نسبی و مطلق پشتیبانی می‌شوند.

اجرای یک ماژول

مثال‌های زیر دو روش برای اجرای ماژول CtsVideoTestCases با استفاده از یک مسیر فایل را نشان می‌دهند.

اجرا از طریق repo-root اندروید:

atest cts/tests/video

از مسیر repo-root/cts/tests/video اندروید اجرا کنید:

    atest .

اجرای کلاس تست

مثال زیر نحوه اجرای یک کلاس خاص را در ماژول CtsVideoTestCases با استفاده از یک مسیر فایل نشان می‌دهد.

از 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 از اجرای متدهای خاص در یک کلاس تست پشتیبانی می‌کند. اگرچه کل ماژول باید ساخته شود، اما این کار زمان لازم برای اجرای تست‌ها را کاهش می‌دهد. برای اجرای متدهای خاص، کلاس را با استفاده از هر یک از روش‌های پشتیبانی شده برای شناسایی یک کلاس (Module:Class، مسیر فایل و غیره) شناسایی کنید و نام متد را اضافه کنید: 

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 را نشان می‌دهند. این مثال‌ها نسبت به استفاده‌ی صرف از نام کلاس ارجحیت دارند، زیرا مشخص کردن ماژول یا محل فایل جاوا به Atest اجازه می‌دهد تا تست را بسیار سریع‌تر پیدا کند.

استفاده از ماژول:کلاس: 

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

از 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-bit) و arm64-v8a (ARM 64-bit) هستند.

نمونه تست ورودی: 

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 اجرا کند.

اجرای تست‌های پیش‌ارسال به صورت ضمنی

تست‌های presubmit را در فایل‌های TEST_MAPPING در دایرکتوری‌های فعلی و والد اجرا کنید: 

atest

تست‌های presubmit را در فایل‌های 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 ده بار تکرار می‌شود. تعداد تکرارها باید یک عدد صحیح مثبت باشد. 

atest test-to-run --iterations
atest test-to-run --iterations 5

رویکردهای زیر تشخیص تست‌های ناقص را آسان‌تر می‌کنند:

رویکرد ۱: تمام تست‌ها را تا زمانی که یک شکست رخ دهد یا به حداکثر تکرار برسد، اجرا کنید.

  • زمانی که یک شکست رخ می‌دهد یا تکرار به دور دهم (به طور پیش‌فرض) می‌رسد، متوقف می‌شود. 
    atest test-to-run --rerun-until-failure
  • زمانی که یک شکست رخ می‌دهد یا تکرار به دور صدم می‌رسد، متوقف شوید. 
    atest test-to-run --rerun-until-failure 100

رویکرد ۲: فقط تست‌های ناموفق را تا زمان قبولی یا رسیدن به حداکثر تکرار اجرا کنید.

  • فرض کنید test-to-run چندین مورد تست دارد و یکی از تست‌ها با شکست مواجه می‌شود. فقط تست ناموفق را 10 بار (به طور پیش‌فرض) یا تا زمانی که تست با موفقیت انجام شود، اجرا کنید. 
    atest test-to-run --retry-any-failure
  • وقتی تست ناموفق اجرا شد یا به صدمین دور رسید، اجرای آن را متوقف کنید. 
    atest test-to-run --retry-any-failure 100

اجرای تست‌ها روی AVDها

Atest قادر است تست‌ها را روی یک AVD تازه ایجاد شده اجرا کند. برای ایجاد یک AVD و ساخت مصنوعات، acloud create اجرا کنید، سپس از مثال‌های زیر برای اجرای تست‌های خود استفاده کنید.

یک 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

گزینه‌ها را به یک نوع یا کلاس runner ارسال کنید: 

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

برای اطلاعات بیشتر در مورد گزینه‌های فقط آزمایشی، به بخش «ارسال گزینه‌ها به ماژول‌ها» مراجعه کنید.