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

اندروید ۹ شامل یک زیرساخت Vendor Test Suite (VTS) برای تست خودکار VTS، CTS یا سایر تست‌ها روی دستگاه‌های همکار است که تصویر سیستم عمومی AOSP (GSI) را اجرا می‌کنند. پیش از این، اجرای این تست‌ها یک عملیات بسیار دستی بود؛ زیرساخت تست جدید VTS به گونه‌ای طراحی شده است که از تست خودکار چندین بار در روز روی چندین دستگاه پشتیبانی کند.

معماری

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

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

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

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

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

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

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

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

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

ساخت اندروید همکار

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

ایجاد دسترسی

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

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

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

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

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

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

آدرس اینترنتی (URL) را دریافت کنید

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

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

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

با دریافت یک دایرکتوری حاوی لیستی (یا فایل زیپ) از مصنوعات، ارائه‌دهنده‌ی ساخت، تصاویر مربوطه را بر اساس آنچه در دایرکتوری است، تنظیم می‌کند. می‌توانید از ابزار gsutil برای کپی کردن فایل‌ها از فضای ذخیره‌سازی ابری گوگل به یک دایرکتوری محلی استفاده کنید.

ساخت‌های فلش

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

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

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

اجرای تست‌ها

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

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

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

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

گزارش نتایج

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