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

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

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

برای اطلاعات در مورد ساختار کلی 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 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 با استفاده از دستور acloud یک AVD ایجاد می کند.
--[CUSTOM_ARGS] آرگومان های سفارشی را برای اجراکننده های آزمایشی مشخص می کند.
-a --all-abi آزمایش‌ها را برای تمام معماری‌های دستگاه موجود اجرا می‌کند.
--host تست را به طور کامل روی هاست بدون دستگاه اجرا می کند.
توجه: اجرای تست میزبانی که به دستگاهی با --host نیاز دارد با شکست مواجه خواهد شد.
--history نتایج آزمون را به ترتیب زمانی نشان می دهد.
--latest-result آخرین نتیجه آزمایش را چاپ می کند.

برای اطلاعات بیشتر در مورد -b ، -i و -t ، به بخش Specify Steps: build, install, or run مراجعه کنید.

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

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

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

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

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

اجرا از Android repo-root :

atest cts/tests/video

اجرا از Android 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 بیتی) و 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
  • هنگامی که یک شکست رخ داد یا تکرار به دور صدم رسید متوقف شوید. 
    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 تازه ایجاد شده اجرا کند. برای ایجاد یک 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

گزینه ها را به یک نوع دونده یا کلاس منتقل کنید: 

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

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