آزمون

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

برای اطلاعات بیشتر در نوشتن تست برای آندروید، و پلت فرم تست آندروید .

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

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

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

تنظیم محیط خود

برای اجرای Atest، مراحل زیر را دنبال کنید تا محیط خود را تنظیم کنید.

تنظیم متغیر محیط

مجموعه test_suite برای Soong یا LOCAL_COMPATIBILITY_SUITE برای ساخت در هر بسته بندی قوانین اسکریپت ساخت .

envsetup.sh را اجرا کنید

از ریشه پرداخت منبع Android، اجرا کنید:

source build/envsetup.sh

ناهار بدو

اجرای lunch فرمان به آورد تا منو از دستگاه های پشتیبانی. دستگاه را پیدا کنید و آن دستور را اجرا کنید.

به عنوان مثال، اگر یک دستگاه ARM متصل دارید، دستور زیر را اجرا کنید:

lunch aosp_arm64-eng

این مجموعه متغیرهای محیط های مختلف مورد نیاز برای اجرای Atest و می افزاید: دستور Atest به خود را $PATH .

استفاده اساسی

دستورات Atest به شکل زیر است:

atest test-to-run [optional-arguments]

استدلال های اختیاری

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

گزینه گزینه طولانی شرح
-b --build اهداف آزمایشی را می سازد. (پیش فرض)
-i --install مصنوعات آزمایشی (APK) را روی دستگاه نصب می‌کند. (پیش فرض)
-t --test تست ها را اجرا می کند. (پیش فرض)
-s --serial تست ها را روی دستگاه مشخص شده اجرا می کند. یک دستگاه را می توان در یک زمان آزمایش کرد.
-d --disable-teardown حذف تست و پاکسازی را غیرفعال می کند.
--info اطلاعات مربوط به اهداف و خروجی های مشخص شده را نشان می دهد.
--dry-run اجراهای خشک بدون ساخت، نصب و اجرای آزمایش ها به طور واقعی انجام می شود
-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 ایجاد AVDS با استفاده از acloud command.
--[CUSTOM_ARGS] آرگ های سفارشی را برای دونده های آزمایشی مشخص می کند.
-a --all-abi آزمایش‌ها را برای تمام معماری‌های دستگاه موجود اجرا می‌کند.
--host تست را به طور کامل روی هاست بدون دستگاه اجرا می کند.
(توجه: در حال اجرا یک تست میزبان است که نیاز به یک دستگاه با --host شکست مواجه خواهد شد.)
--flakes-info نتیجه آزمایش را با اطلاعات flakes نشان می دهد.
--history نتیجه آزمایش را به ترتیب زمانی نشان می دهد.
--latest-result آخرین نتیجه آزمایش را چاپ می کند.

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

تست هایی برای اجرا

شما می توانید یک یا چند آزمایش با استفاده از اجرای test-to-run . برای اجرای چندین تست، مراجع آزمون را با فاصله جدا کنید. مثلا:

atest test-to-run-1 test-to-run-2

در اینجا چند نمونه آورده شده است:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

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

شناسایی تست ها

شما می توانید مشخص کنید که test-to-run کلاس، نام کلاس، آزمون ادغام TF، مسیر یا نام فایل بسته بندی: بحث با نام آزمون ماژول، ماژول.

نام ماژول

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

مثال ها:

atest FrameworksServicesTests
atest CtsVideoTestCases

ماژول: کلاس

برای اجرای یک کلاس در یک ماژول، استفاده از ماژول: کلاس. ماژول همان است که در توصیف ماژول . کلاس نام کلاس آزمون در است .java فایل و می تواند نام کامل کلاس واجد شرایط و یا نام اولیه.

مثال ها:

atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest CtsVideoTestCases:VideoEncoderDecoderTest

نام کلاس

برای اجرای یک کلاس بدون ذکر صریح نام ماژول، از نام کلاس استفاده کنید.

مثال ها:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

با استفاده از ماژول: مرجع کلاس است توصیه می شود در صورت امکان از Atest نیاز به زمان بیشتری را برای جستجو درخت منبع کامل برای بازی های بالقوه اگر هیچ ماژول آمده است.

مثال‌ها (به ترتیب از سریع‌ترین به کندترین):

atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest FrameworksServicesTests:ScreenDecorWindowTests
atest ScreenDecorWindowTests

تست ادغام TF

برای اجرای آزمون که به طور مستقیم به TradeFed (غیر ماژول) یکپارچه، نام آن را به عنوان در خروجی ظاهر می شود tradefed.sh list configs فرمان. مثلا:

برای اجرای reboot.xml آزمون :

atest example/reboot

برای اجرای native-benchmark.xml آزمون :

atest native-benchmark

مسیر فایل

شما می توانید هر دو تست مبتنی بر ماژول و تست های مبتنی بر ادغام را با وارد کردن مسیر به فایل آزمایشی یا دایرکتوری آنها در صورت لزوم اجرا کنید. همچنین می توانید با تعیین مسیر فایل جاوای کلاس، یک کلاس را اجرا کنید. هر دو مسیر نسبی و مطلق پشتیبانی می شوند.

به عنوان مثال: دو راه برای اجرای CtsVideoTestCases ماژول از طریق مسیر

  1. ماژول اجرا از آندروید repo-root :

    atest cts/tests/video
    
  2. از آندروید repo-root / CTS / آزمون / ویدئو:

    atest .
    

به عنوان مثال: اجرای یک کلاس خاص در CtsVideoTestCases ماژول از طریق مسیر. از آندروید repo-root :

atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

مثال: تست یکپارچه سازی را از طریق مسیر اجرا کنید. از آندروید 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

اجرای روش های خاص

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

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

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. از آندروید 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
    

اجرای تست های بومی

Atest می تواند تست های بومی را اجرا کند. استفاده از -a برای اجرای آزمون برای همه معماری دستگاه موجود است، که در این مثال می armeabi-v7a (ARM 32 بیتی) و ARM64-v8a (ARM 64 بیتی).

مثال ها:

  • تست های ورودی:

    atest -a libinput_tests inputflinger_tests
    

برای انتخاب یک تست بومی خاص برای اجرا، از کولون (:) برای مشخص کردن نام آزمون و هشتگ (#) برای تعیین بیشتر روش فردی استفاده کنید. به عنوان مثال، برای تعریف آزمون های زیر است:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

شما می توانید کل آزمون با استفاده از اجرای

atest inputflinger_tests:InputDispatcherTest

یا یک روش آزمون فردی با استفاده از

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

در حال اجرای تست در TEST_MAPPING

Atest می‌تواند آزمایش‌ها را در فایل‌های TEST_MAPPING اجرا کند.

  1. آزمایش‌های پیش ارسال را به طور ضمنی در فایل‌های TEST_MAPPING در دایرکتوری‌های فعلی، والد یا خاص اجرا کنید.

    آزمون presubmit اجرا در فایل های TEST_MAPPING در دایرکتوری فعلی و پدر و مادر:

    atest
    

    آزمون presubmit اجرا در فایل های TEST_MAPPING در /path/to/project ها و دایرکتوری ها پدر و مادر خود:

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

  2. اجرای یک گروه آزمون مشخص شده در TEST_MAPPING فایل های. گروه آزمون در دسترس هستند: presubmit (پیش فرض)، postsubmit ، mainline-presubmit و all .

    • آزمون postsubmit اجرا در فایل های TEST_MAPPING در دایرکتوری فعلی و پدر و مادر:

      atest :postsubmit
      

    • آزمون اجرا از همه گروه ها در فایل های TEST_MAPPING:

      atest :all
      

    • آزمون postsubmit اجرا در فایل های 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
      

  3. آزمایش‌ها را در فایل‌های TEST_MAPPING از جمله دایرکتوری‌های فرعی اجرا کنید.

به‌طور پیش‌فرض، atest فقط آزمایش‌ها را در فایل‌های TEST_MAPPING به سمت بالا جستجو می‌کند (از فهرست فعلی یا داده‌شده به فهرست‌های اصلی). اگر شما هم می خواهید برای اجرای آزمون در فایل های TEST_MAPPING در زیر دایرکتوری ها، شما می توانید گزینه استفاده کنید --include-subdirs به زور atest به کسانی آزمون است.

آزمون presubmit اجرا در فایل های TEST_MAPPING در حال حاضر، پدر و مادر و زیر دایرکتوری:

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 تازه ایجاد شده است. Atest می توانید شی ء همراه با در حال اجرا ساخت acloud create و آزمون اجرا پس از AVD با موفقیت ایجاد شده است.

مثال ها:

  • شروع AVD قبل از اجرای آزمون در آن دستگاه به تازگی ایجاد شده:

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

  • شروع AVDS توسط مشخص acloud create استدلال و آزمون اجرا در آن دستگاه به تازگی ایجاد شده.

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

برای به دست آوردن جزئیات در مورد استفاده از استدلال، اجرا acloud create --help .

گزینه ها را به ماژول منتقل کنید

Atest می تواند گزینه ها را به ماژول ها منتقل کند. فرمت مختصر در Atest خط فرمان به اضافه کردن TradeFed گزینه خط فرمان است

atest test-to-run -- [CUSTOM_ARGS]
بر چسب [CUSTOM_ARGS] باید فرمان Tradefed فرمت گزینه خط دنبال کنید.

نمونه‌هایی از گذراندن گزینه‌های ماژول تست برای آماده‌کنندگان یا دونده‌های آزمایشی که در فایل پیکربندی تست تعریف شده‌اند:

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

برای اطلاعات بیشتر در آزمون تنها گزینه، و گزینه های عبور به ماژول