این یک مقدمه مختصر از نقشه برداری آزمایشی و توضیحی در مورد نحوه شروع پیکربندی تست ها در پروژه متن باز اندروید (AOSP) است.
درباره نقشه برداری آزمایشی
نقشه برداری آزمایشی یک رویکرد مبتنی بر Gerrit است که به توسعهدهندگان اجازه میدهد قوانین آزمایشی قبل و بعد از ارسال را مستقیماً در درخت منبع Android ایجاد کنند و تصمیمات شاخهها و دستگاهها را به زیرساخت آزمایش بسپارند. تعاریف نگاشت آزمایشی فایلهای JSON با نام TEST_MAPPING
هستند که میتوانید در هر فهرست منبعی قرار دهید.
Atest می تواند از فایل های TEST_MAPPING
برای اجرای آزمایش های پیش ارسال در فهرست های مرتبط استفاده کند. با نقشه برداری آزمایشی، می توانید همان مجموعه آزمایش ها را برای ارسال چک ها با حداقل تغییر در درخت منبع اندروید اضافه کنید.
این نمونه ها را ببینید:
آزمایشهای پیش ارسال را به
TEST_MAPPING
برایservices.core
اضافه کنیدبرای
tools/dexter
با استفاده از واردات، آزمایشهای پیش ارسال را بهTEST_MAPPING
اضافه کنید
نقشه برداری آزمایشی برای اجرای آزمایش ها و گزارش نتایج به مهار آزمون فدراسیون تجارت (TF) متکی است.
گروه های آزمایشی را تعریف کنید
آزمایش گروه های نقشه برداری تست با یک گروه آزمایشی . نام یک گروه آزمایشی می تواند هر رشته ای باشد. به عنوان مثال، presubmit میتواند نام گروهی از آزمایشها باشد که هنگام تأیید تغییرات اجرا میشوند. و postsubmit میتواند آزمایشهایی باشد که برای تأیید اعتبار ساختها پس از ادغام تغییرات استفاده میشوند.
قوانین اسکریپت ساخت بسته
برای اینکه مهار تست فدراسیون تجارت بتواند ماژولهای آزمایشی را برای یک ساخت معین اجرا کند، این ماژولها باید test_suites
را برای Soong یا LOCAL_COMPATIBILITY_SUITE
تنظیم شده برای Make در یکی از این دو مجموعه داشته باشند:
-
general-tests
برای تستهایی است که به قابلیتهای خاص دستگاه (مانند سختافزار خاص فروشنده که اکثر دستگاهها ندارند) بستگی ندارد. بیشتر تستها باید در مجموعهgeneral-tests
باشند، حتی اگر مختص یک ABI یا bitness یا ویژگیهای سختافزاری مانند HWASan باشند (برای هر ABI یک هدفtest_suites
جداگانه وجود دارد)، و حتی اگر باید روی یک دستگاه اجرا شوند. -
device-tests
برای تست هایی است که به قابلیت های خاص دستگاه بستگی دارد. معمولاً این آزمایشها در قسمتvendor/
یافت میشوند. Device-specific فقط به قابلیتهایی اشاره دارد که منحصر به یک دستگاه هستند، بنابراین این مورد برای تستهای JUnit و همچنین تستهای GTest (که معمولاً باید به عنوانgeneral-tests
حتی اگر مختص ABI باشند) اعمال میشود.
مثال ها:
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
تست ها را برای اجرا در مجموعه آزمایشی پیکربندی کنید
برای اجرای یک آزمایش در داخل یک مجموعه آزمایشی، آزمایش:
- نباید هیچ ارائه دهنده ساخت داشته باشد.
- باید پس از اتمام آن پاک شود، به عنوان مثال، با حذف هر گونه فایل موقتی که در طول آزمایش ایجاد شده است.
- باید تنظیمات سیستم را به مقدار پیش فرض یا اصلی تغییر دهید.
نباید فرض کنیم که یک دستگاه در وضعیت خاصی است، به عنوان مثال، آماده root است. اکثر تست ها برای اجرا نیازی به دسترسی روت ندارند. اگر آزمایشی باید به روت نیاز داشته باشد، باید آن را با
RootTargetPreparer
درAndroidTest.xml
آن مشخص کند، مانند مثال زیر:<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
فایل های نقشه برداری آزمایشی ایجاد کنید
برای دایرکتوری که نیاز به پوشش آزمایشی دارد، یک فایل TEST_MAPPING
JSON شبیه به مثال اضافه کنید. این قوانین تضمین میکنند که تستها در بررسیهای پیشارسال زمانی که فایلهایی در آن فهرست یا هر یک از زیر شاخههای آن لمس میشوند، اجرا میشوند.
یک مثال را دنبال کنید
در اینجا یک فایل TEST_MAPPING
نمونه است (با فرمت JSON اما با نظرات پشتیبانی می شود):
{
"presubmit": [
// JUnit test with options and file patterns.
{
"name": "CtsWindowManagerDeviceTestCases",
"options": [
{
"include-annotation": "android.platform.test.annotations.RequiresDevice"
}
],
"file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
},
// Device-side GTest with options.
{
"name" : "hello_world_test",
"options": [
{
"native-test-flag": "\"servicename1 servicename2\""
},
{
"native-test-timeout": "6000"
}
]
}
// Host-side GTest.
{
"name" : "net_test_avrcp",
"host" : true
}
],
"postsubmit": [
{
"name": "CtsDeqpTestCases",
"options": [
{
// Use regex in include-filter which is supported in AndroidJUnitTest
"include-filter": "dEQP-EGL.functional.color_clears.*"
}
]
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
صفات را تنظیم کنید
در مثال ، presubmit
و postsubmit
نام هر گروه آزمایشی است. برای اطلاعات بیشتر در مورد گروه های آزمایشی به تعریف گروه های آزمایشی مراجعه کنید.
می توانید نام ماژول تست یا نام آزمون یکپارچه سازی فدراسیون تجارت (مسیر منبع به فایل XML آزمایشی، به عنوان مثال، uiautomator/uiautomator-demo
) را در مقدار مشخصه name
تنظیم کنید. توجه داشته باشید که فیلد name
نمی تواند name
کلاس یا name
روش تست استفاده کند. برای محدود کردن تستها برای اجرا، از گزینههایی مانند include-filter
استفاده کنید. ( استفاده از نمونه include-filter
) را ببینید.
تنظیمات host
یک تست نشان میدهد که آیا تست یک تست بدون دستگاه است که روی میزبان اجرا میشود یا خیر. مقدار پیشفرض false
است، به این معنی که آزمایش برای اجرا به یک دستگاه نیاز دارد. انواع تست های پشتیبانی شده عبارتند از HostGTest
برای باینری های GTest و HostTest
برای تست های JUnit.
ویژگی file_patterns
به شما امکان می دهد لیستی از رشته های عبارت منظم را برای مطابقت با مسیر نسبی هر فایل کد منبع (نسبت به دایرکتوری حاوی فایل TEST_MAPPING
) تنظیم کنید. در مثال ، آزمایش CtsWindowManagerDeviceTestCases
در پیش ارسال تنها زمانی اجرا میشود که یک فایل جاوا با Window
یا Activity
که در همان فهرست فایل TEST_MAPPING
یا هر یک از زیر شاخههای آن وجود دارد، شروع شود. اسلشهای برگشتی `` باید حذف شوند زیرا در یک فایل JSON هستند.
ویژگی imports
به شما امکان میدهد بدون کپی کردن محتوا، آزمایشها را در سایر فایلهای TEST_MAPPING
قرار دهید. فایل های TEST_MAPPING
در دایرکتوری های والد مسیر وارد شده نیز گنجانده شده است. نقشه برداری آزمایشی اجازه واردات تودرتو را می دهد. این بدان معنی است که دو فایل TEST_MAPPING
می توانند یکدیگر را وارد کنند و نقشه برداری آزمایشی می تواند آزمایش های ارائه شده را ادغام کند.
ویژگی options
شامل گزینه های اضافی خط فرمان Tradefed است.
برای دریافت لیست کاملی از گزینه های موجود برای یک آزمون معین، اجرا کنید:
tradefed.sh run commandAndExit [test_module] --help
برای جزئیات بیشتر در مورد نحوه کار گزینه ها به مدیریت گزینه در Tradefed مراجعه کنید.
تست ها را با Atest اجرا کنید
برای اجرای قوانین آزمون پیش ارسال به صورت محلی:
- به دایرکتوری حاوی فایل
TEST_MAPPING
بروید. دستور را اجرا کنید:
atest
همه آزمایشهای پیشارسال پیکربندی شده در فایلهای TEST_MAPPING
دایرکتوری فعلی و دایرکتوریهای والد آن اجرا میشوند. Atest دو تست را برای پیش ارسال (A و B) پیدا کرده و اجرا می کند.
این سادهترین راه برای اجرای آزمایشهای پیش ارسال در فایلهای TEST_MAPPING
در فهرست راهنمای فعلی (CWD) و دایرکتوریهای والد است. Atest فایل TEST_MAPPING
را در CWD و همه فهرستهای والد آن مکانیابی میکند و از آن استفاده میکند.
کد منبع ساختار
این مثال نشان می دهد که چگونه می توانید فایل های TEST_MAPPING
را در درخت منبع پیکربندی کنید:
src
├── project_1
│ └── TEST_MAPPING
├── project_2
│ └── TEST_MAPPING
└── TEST_MAPPING
محتوای src/TEST_MAPPING
:
{
"presubmit": [
{
"name": "A"
}
]
}
محتوای src/project_1/TEST_MAPPING
:
{
"presubmit": [
{
"name": "B"
}
],
"postsubmit": [
{
"name": "C"
}
],
"other_group": [
{
"name": "X"
}
]}
محتوای src/project_2/TEST_MAPPING
:
{
"presubmit": [
{
"name": "D"
}
],
"import": [
{
"path": "src/project_1"
}
]}
فهرست های هدف را مشخص کنید
میتوانید یک فهرست هدف را برای اجرای آزمایشها در فایلهای TEST_MAPPING
در آن فهرست تعیین کنید. دستور زیر دو تست (A, B) را اجرا می کند:
atest --test-mapping src/project_1
قوانین آزمون postsubmit را اجرا کنید
همچنین میتوانید از این دستور برای اجرای قوانین تست postsubmit تعریفشده در TEST_MAPPING
در src_path
(پیشفرض CWD) و دایرکتوریهای والد آن استفاده کنید:
atest [--test-mapping] [src_path]:postsubmit
فقط تست هایی را اجرا کنید که نیازی به دستگاه ندارند
میتوانید از گزینه --host
برای Atest استفاده کنید تا فقط آن دسته از آزمایشهایی را که روی میزبان پیکربندی شدهاند و به هیچ دستگاهی نیاز ندارند، اجرا کنید. بدون این گزینه، Atest هر دو تست را اجرا میکند، تستهایی که به دستگاه نیاز دارند و تستهایی که روی میزبان اجرا میشوند و نیازی به دستگاه ندارند. آزمون ها در دو مجموعه مجزا اجرا می شوند:
atest [--test-mapping] --host
گروه های آزمایشی را مشخص کنید
می توانید گروه های آزمایشی را در دستور Atest مشخص کنید. دستور زیر تمام تست های postsubmit
مربوط به فایل های دایرکتوری src/project_1
را اجرا می کند که فقط یک تست (C) دارد.
یا می توانید از :all
برای اجرای تمام تست ها بدون در نظر گرفتن گروه استفاده کنید. دستور زیر چهار تست (A، B، C، X) را اجرا می کند:
atest --test-mapping src/project_1:all
شامل زیر شاخه ها
بهطور پیشفرض، اجرای آزمایشها در TEST_MAPPING
با Atest فقط آزمایشهایی را از پیش ارسال میکند که در فایل TEST_MAPPING
در CWD (یا دایرکتوری دادهشده) و فهرستهای والد آن پیکربندی شدهاند. اگر میخواهید آزمایشها را در همه فایلهای TEST_MAPPING
در زیر شاخهها اجرا کنید، از گزینه --include-subdir
استفاده کنید تا Atest را مجبور کنید آن تستها را نیز شامل شود.
atest --include-subdir
بدون گزینه --include-subdir
، Atest فقط تست A را اجرا می کند. با گزینه --include-subdir
، Atest دو تست (A, B) را اجرا می کند.
نظر در سطح خط پشتیبانی می شود
میتوانید یک نظر با فرمت //
در سطح خط اضافه کنید تا فایل TEST_MAPPING
را با توضیح تنظیمات زیر تکمیل کنید. ATest و فدراسیون تجارت TEST_MAPPING
بدون نظر در قالب JSON معتبر پیش پردازش می کنند. برای تمیز نگه داشتن فایل JSON، فقط نظر قالب سطح خط //
پشتیبانی می شود.
مثال:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}