زیرساخت تست خودکار

Android 9 شامل یک زیرساخت مجموعه تست فروشنده (VTS) برای آزمایش خودکار VTS، CTS یا سایر آزمایش‌ها در دستگاه‌های شریکی است که تصویر سیستم عمومی AOSP (GSI) را اجرا می‌کنند. پیش از این، اجرای این آزمایش ها یک عملیات بسیار دستی بود. زیرساخت جدید تست VTS برای پشتیبانی از تست خودکار چندین بار در روز بر روی چندین دستگاه طراحی شده است.

معماری

زیرساخت تست خودکار VTS از معماری زیر استفاده می کند:

هنگامی که یک تست راه اندازی می شود، زیرساخت تست خودکار VTS وظایف زیر را انجام می دهد:

1. واکشی ها مصنوعات را می سازند و منابع را از مکان های مختلف آزمایش می کنند:
   • شریک ساخت اندروید (PAB) . برای GSI، چارچوب VTS، و برخی از بیلدهای دیگر.
   • سیستم فایل محلی، Google Cloud Storage یا سایر سیستم‌های ساخت خاص فروشنده . برای شرکای که ساخت‌ها را در فضای ابری Google ذخیره نمی‌کنند.
2. فلاش ها مصنوعات (از دستگاه) و GSI (از AOSP) را روی دستگاه(های) متصل می سازد.
3. تست های VTS را با استفاده از TradeFed محلی یا TradeFed در فضای ابری اجرا می کند.
4. نتایج آزمایش را به داشبورد VTS گزارش می دهد

این فرآیند توسط کنترل کننده میزبان VTS (HC) هماهنگ می شود، ماشینی در آزمایشگاه که رفتار همه دستگاه های متصل تحت آزمایش را هدایت می کند. HC مسئول واکشی آخرین ساخت‌ها، فلش کردن آن‌ها روی دستگاه‌ها و فراخوانی آزمایش‌ها (به صورت محلی یا از طریق فرمانده) است. همچنین با یک زمان‌بندی ابری ارتباط برقرار می‌کند و ترافیک بین زمان‌بندی و نمونه TradeFed (یا برخی مهارهای دیگر) در حال اجرا در HC را هدایت می‌کند. برای جزئیات بیشتر در مورد کنترل‌کننده میزبان، به معماری کنترل‌کننده میزبان مراجعه کنید.

ارائه دهندگان منابع

تست خودکار به منابعی مانند ساخت سیستم، فایل های آزمایشی و مصنوعات VTS نیاز دارد. در حالی که ساختن آنها از منبع امکان پذیر است، ساختن آنها از نوک درخت به طور منظم و سپس ارسال مصنوعات برای دانلود آسان تر است.

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

• شریک ساخت اندروید . دسترسی برنامه‌ای بر اساس هر حساب اعطا می‌شود.
• فایل سیستم محلی (یا مشابه). برای شرکای که از Partner Android Build استفاده نمی کنند.

برای استفاده در فلش کردن دستگاه‌ها بعداً، منابع شامل ارائه‌دهنده ساخت برای هر دو گزینه است که از یک build_provider.py گسترش می‌یابد که بیلدها را در فهرست‌های موقت محلی ذخیره می‌کند.

شریک ساخت اندروید

در نسخه‌های Android 8.1 و نسخه‌های پایین‌تر، شرکای Android باید از وب‌سایت Partner Android Build ( https://partner.android.com/build ) بازدید کنند، به حساب خود پیمایش کنند و آخرین تصاویر سیستم را از طریق رابط کاربری واکشی کنند. برای کمک به شرکای خود از این فرآیند آهسته و پرزحمت اجتناب کنند، Android 9 شامل پشتیبانی از دانلود خودکار این منابع از PAB در صورت ارائه اعتبارنامه مناسب است.

دسترسی را ایجاد کنید

دسترسی برنامه‌ریزی شده از OAuth2 در APIهای Google برای دسترسی به RPCهای مورد نیاز استفاده می‌کند. با استفاده از رویکرد استاندارد برای ایجاد اعتبارنامه OAuth2، شریک باید یک جفت شناسه مشتری/مخفی با Google راه‌اندازی کند. هنگامی که PartnerAndroidBuildClient برای اولین بار به آن راز اشاره می کند، یک پنجره مرورگر را برای کاربر باز می کند تا به حساب Google خود وارد شود، که اعتبارنامه OAuth2 مورد نیاز برای حرکت به جلو را تولید می کند. اعتبارنامه ها (توکن دسترسی و نشانه بازخوانی) به صورت محلی ذخیره می شوند، به این معنی که شرکا باید فقط یک بار وارد سیستم شوند.

درخواست POST برای URL

با کلیک بر روی پیوند منبع در PAB یک درخواست POST ارسال می شود که شامل داده های لازم برای آن منبع است، از جمله:

• ساخت شناسه، ساخت هدف
• نام منبع
• شاخه
• نام کاندید را منتشر کنید و اینکه آیا نامزد یک ساخت داخلی است یا خیر

درخواست POST توسط متد downloadBuildArtifact از buildsvc RPC دریافت می‌شود که یک URL را برمی‌گرداند که می‌توان از آن برای دسترسی به منبع استفاده کرد.

• برای منابع Clockwork Companion APK، URL یک URL قابل خواندن است که در PAB میزبانی شده است (که با اعتبارنامه OAuth2 مناسب محافظت شده و قابل دسترسی است).
• برای سایر منابع، URL طولانی و بدون محافظت از API داخلی Android Build است (که پس از پنج دقیقه منقضی می شود).

URL را دریافت کنید

برای جلوگیری از جعل درخواست های متقابل سایت، buildsvc RPC نیاز به یک توکن XSRF دارد تا با پارامترهای دیگر پست شود. در حالی که این توکن فرآیند را ایمن‌تر می‌کند، دسترسی برنامه‌ریزی شده را نیز بسیار سخت‌تر می‌کند، زیرا توکن (که فقط در جاوا اسکریپت صفحه PAB موجود است) اکنون برای دسترسی نیز مورد نیاز است.

برای جلوگیری از این مشکل، اندروید 9 طرح نام‌گذاری URL را برای همه فایل‌ها (و نه فقط APK) طراحی می‌کند تا از نام‌های URL قابل پیش‌بینی برای دسترسی به فهرست‌های مصنوع و نشانی‌های اینترنتی مصنوع استفاده کند. PAB اکنون از یک قالب URL مناسب استفاده می کند که شرکا را قادر می سازد منابع را دانلود کنند. اسکریپت های HC می توانند آن APK ها را به راحتی دانلود کنند، زیرا قالب URL شناخته شده است، و HC می تواند مشکلات XSRF/کوکی ها را دور بزند زیرا به buildsvc RPC نیاز ندارد.

فایل سیستم محلی

با توجه به فهرستی با فهرست (یا فایل فشرده) از مصنوعات، ارائه‌دهنده ساخت، تصاویر مربوطه را بر اساس آنچه در فهرست موجود است تنظیم می‌کند. می‌توانید از ابزار gsutil برای کپی فایل‌ها از Google Cloud Storage در فهرست محلی استفاده کنید.

فلش می سازد

پس از بارگیری جدیدترین تصاویر دستگاه در هاست، آن تصاویر باید بر روی دستگاه ها فلش شوند. این کار با استفاده از دستورات استاندارد adb و fastboot و زیر فرآیندهای پایتون، بر اساس مسیرهای موقت فایل ذخیره شده توسط ارائه دهندگان ساخت، انجام می شود.

اقدامات پشتیبانی شده:

• فقط جی اس آی فلش میشه
• فلش کردن تصاویر جداگانه از سیستم اصلی (به عنوان مثال، fastboot flash boot boot.img )
• فلش کردن تمام تصاویر از سیستم اصلی. مثال:
  • fastboot flashall (با استفاده از ابزار داخلی flashall )
  • fastboot flash (یکی در یک زمان)

تست ها را اجرا کنید

در اندروید 9، زیرساخت تست خودکار VTS فقط از مهار تست TradeFed پشتیبانی می کند، اما می تواند برای پشتیبانی از مهارهای دیگر در آینده گسترش یابد.

پس از آماده شدن دستگاه ها، می توانید با استفاده از یکی از گزینه های زیر تست ها را فراخوانی کنید:

• هنگام استفاده از TradeFed به صورت محلی، از دستور test در کنترلر میزبان استفاده کنید، که نام یک برنامه آزمایشی VTS (مثلا vts-selftest ) را می گیرد و آزمایش را اجرا می کند.
• هنگام استفاده از یک کلاستر TradeFed (به صورت اختیاری به MTT متصل است)، از دستور lease در کنسول کنترل کننده میزبان استفاده کنید، که به دنبال اجرای آزمایشی انجام نشده است.

اگر از TradeFedCluster استفاده می کنید، TradeFed به صورت محلی به عنوان یک مدیر راه دور اجرا می شود. در غیر این صورت، تست ها با استفاده از فرآیندهای فرعی پایتون فراخوانی می شوند.

گزارش نتایج

نتایج آزمایش به طور خودکار توسط VtsMultiDeviceTest به برخی از پروژه های داشبورد VTS گزارش می شود.