آزمایش نقشه برداری

این یک مقدمه مختصر از نقشه برداری آزمایشی و توضیحی در مورد نحوه شروع پیکربندی تست ها در پروژه متن باز اندروید (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 اجرا کنید

برای اجرای قوانین آزمون پیش ارسال به صورت محلی:

1. به دایرکتوری حاوی فایل TEST_MAPPING بروید.

2. دستور را اجرا کنید:

   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"
    }
  ]
}