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

این یک مقدمه مختصر از نقشه برداری آزمایشی و توضیحی در مورد چگونگی شروع آسان پیکربندی تست ها در پروژه متن باز اندروید (AOSP) است.

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

نقشه برداری آزمایشی یک رویکرد مبتنی بر Gerrit است که به توسعه دهندگان این امکان را می دهد تا قوانین تست قبل و بعد از ارسال را مستقیماً در درخت منبع اندروید ایجاد کنند و تصمیمات شاخه ها و دستگاه ها را به زیرساخت آزمایش بسپارند. تعاریف نگاشت آزمایشی فایل‌های JSON با نام TEST_MAPPING هستند که می‌توانند در هر فهرست منبعی قرار گیرند.

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

این نمونه ها را ببینید:

آزمایش‌های پیش ارسال را به TEST_MAPPING برای services.core اضافه کنید

برای ابزار/دکستر با استفاده از واردات، آزمایش‌های پیش ارسال را به TEST_MAPPING اضافه کنید

نقشه برداری آزمایشی برای اجرای آزمایش ها و گزارش نتایج به مهار تست فدراسیون تجارت (TF) متکی است.

گروه های آزمایشی را تعریف کنید

آزمون نقشه برداری آزمایشی گروه های آزمایشی از طریق یک گروه آزمایشی . نام یک گروه آزمایشی می تواند هر رشته ای باشد. برای مثال، presubmit می‌تواند برای گروهی از آزمایش‌ها باشد که هنگام اعتبارسنجی تغییرات اجرا شوند. و پس از ادغام تغییرات می‌توان از تست‌های postsubmit برای اعتبارسنجی ساخت‌ها استفاده کرد.

قوانین اسکریپت ساخت بسته

برای اینکه Trade Federation Test Harness ماژول های آزمایشی نقشه برداری آزمایشی را برای یک ساخت معین اجرا کند، این ماژول ها باید test_suite را برای Soong یا LOCAL_COMPATIBILITY_SUITE برای Make در یکی از این دو مجموعه داشته باشند:

• آزمایش‌های عمومی - آزمایش‌هایی که به عملکرد خاص دستگاه بستگی ندارند (مانند سخت‌افزار خاص فروشنده که اکثر دستگاه‌ها ندارند). بیشتر تست‌ها باید در مجموعه تست‌های عمومی باشند، حتی اگر مختص یک ABI یا bitness یا ویژگی‌های سخت‌افزاری مانند HWASan باشند (برای هر ABI یک هدف test_suites جداگانه وجود دارد)، و حتی اگر باید روی یک دستگاه اجرا شوند.
• تست های دستگاه - تست هایی که به عملکرد خاص دستگاه بستگی دارد. معمولاً این آزمایش‌ها در قسمت vendor/ یافت می‌شوند. از آنجایی که «ویژه دستگاه» به عملکرد ABI یا SoC اشاره نمی‌کند که دستگاه‌های دیگر ممکن است داشته باشند یا نداشته باشند، بلکه فقط به عملکردی اشاره دارد که برای یک دستگاه منحصر به فرد است، این مورد برای تست‌های JUnit به اندازه آزمایش‌های بومی GTest (که معمولاً باید انجام شود) اعمال می‌شود. general-tests باشند حتی اگر مخصوص ABI باشند).

مثال ها:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

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

برای اجرای یک آزمایش در داخل یک مجموعه آزمایشی، آزمایش:

• نباید ارائه دهنده ساخت داشته باشد.
• باید پس از اتمام آن پاک شود، به عنوان مثال، با حذف هر فایل موقتی که در طول آزمایش ایجاد شده است.
• تنظیمات سیستم را به مقدار پیش فرض یا اصلی تغییر دهید.
• نباید دستگاهی را در وضعیت خاصی فرض کنیم، مثلاً روت آماده باشد. اکثر تست ها برای اجرا نیازی به دسترسی روت ندارند. اگر آزمایشی باید به روت نیاز داشته باشد، باید آن را با یک 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": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

صفات را تنظیم کنید

در مثال بالا، presubmit و postsubmit نام هر گروه آزمایشی است. برای اطلاعات بیشتر در مورد گروه های آزمایشی به تعریف گروه های آزمایشی مراجعه کنید.

نام ماژول تست یا نام آزمون یکپارچه سازی فدراسیون تجارت (مسیر منبع به فایل XML آزمایشی، به عنوان مثال، uiautomator/uiautomator-demo ) را می توان در مقدار مشخصه name تنظیم کرد. توجه داشته باشید که فیلد نام نمی تواند از name کلاس یا name روش تست استفاده کند. برای محدود کردن تست‌ها برای اجرا، می‌توانید از گزینه‌هایی مانند include-filter در اینجا استفاده کنید. ( استفاده از نمونه شامل فیلتر ) را ببینید.

تنظیمات میزبان یک تست نشان می‌دهد که آیا تست یک تست بدون دستگاه است که روی میزبان اجرا می‌شود یا خیر. مقدار پیش‌فرض false است، به این معنی که آزمایش برای اجرا به یک دستگاه نیاز دارد. انواع تست های پشتیبانی شده عبارتند از HostGTest برای باینری های GTest و HostTest برای تست های JUnit.

ویژگی file_patterns به شما امکان می دهد لیستی از رشته های regex را برای مطابقت با مسیر نسبی هر فایل کد منبع (نسبت به دایرکتوری حاوی فایل TEST_MAPPING) تنظیم کنید. در مثال بالا، آزمایش CtsWindowManagerDeviceTestCases در پیش ارسال فقط زمانی اجرا می‌شود که هر فایل جاوا با Window یا Activity شروع شود، که در همان فهرست فایل TEST_MAPPING یا هر یک از زیر شاخه‌های آن وجود دارد، تغییر کند. اسلش های برگشتی \ باید همانطور که در یک فایل JSON هستند حذف شوند.

ویژگی imports به شما امکان می‌دهد بدون کپی کردن محتوا، آزمایش‌ها را در سایر فایل‌های TEST_MAPPING قرار دهید. توجه داشته باشید که فایل های TEST_MAPPING در دایرکتوری های والد مسیر وارد شده نیز شامل خواهند شد. نقشه برداری آزمایشی اجازه واردات تودرتو را می دهد. این بدان معنی است که دو فایل TEST_MAPPING می توانند یکدیگر را وارد کنند و نقشه برداری آزمایشی می تواند به درستی تست های ارائه شده را ادغام کند.

ویژگی گزینه شامل گزینه های اضافی خط فرمان TradeFed است.

برای دریافت لیست کاملی از گزینه های موجود برای یک آزمون معین، اجرا کنید:

tradefed.sh run commandAndExit [test_module] --help

برای جزئیات بیشتر در مورد نحوه عملکرد گزینه ها به TradeFed Option Handling مراجعه کنید.

تست ها را با 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 مشخص کنید. دستور زیر تمام تست های ارسال ارسال مربوط به فایل های دایرکتوری 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"
    }
  ]
}