راه اندازی داشبورد VTS

داشبورد VTS یک رابط کاربری و رابط کاربری (UI) برای مشاهده نتایج آزمایش از سیستم یکپارچه سازی پیوسته VTS فراهم می کند. این برنامه از توسعه مبتنی بر آزمایش با ابزارهایی مانند اعلان‌های وضعیت آزمایش پشتیبانی می‌کند تا به توسعه‌دهندگان کمک کند مناطق رگرسیون را در طول چرخه توسعه پیدا کنند و از آن جلوگیری کنند (شامل نظارت بر تست و پشتیبانی تریاژ).

رابط کاربری داشبورد VTS از ویژگی‌هایی (مانند پوشش کد بومی) ارائه شده توسط زیرساخت VTS پشتیبانی می‌کند و نظارت مستمر عملکرد را برای ایجاد امکان توسعه ابزارهای عملکرد بهینه و مشخص شده ارائه می‌دهد.

الزامات

خدمات زیر برای استفاده از داشبورد VTS مورد نیاز است:

• Apache Maven ، برای ساخت و استقرار
• Google Cloud App Engine ، برای میزبانی وب سرویس
• Google Cloud Datastore ، برای ذخیره سازی
• Google Stackdriver ، برای نظارت

مشاهده پوشش آزمایشی متکی به یک REST API به یک سرور کد منبع (به عنوان مثال Gerrit) است که به وب سرویس امکان می دهد کد منبع اصلی را مطابق لیست های کنترل دسترسی موجود واکشی کند.

معماری

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

شکل 1 . معماری داشبورد VTS

نتایج وضعیت آزمایش به طور مداوم از طریق یک رابط REST در پایگاه داده Cloud Datastore بارگذاری می شود. VTS runner به طور خودکار نتایج را پردازش می کند و آنها را با استفاده از فرمت Protobuf سریال می کند.

سرورهای وب، نقطه دسترسی اولیه برای کاربران را تشکیل می دهند و داده ها را از پایگاه داده Datastore تحویل و پردازش می کنند. سرولت ها عبارتند از: یک سرور اصلی برای ارائه تمام تست ها، یک سرویس دهنده ترجیحات برای مدیریت علاقه مندی های کاربر، یک سرویس دهنده نتایج برای پر کردن جدول تست، یک سرویس دهنده گراف برای تهیه داده های پروفایل، و یک سرویس دهنده پوشش برای تهیه داده های پوشش برای مشتری. .

هر ماژول تست درخت اجداد Datastore خود را دارد و نتایج آزمایش با مهر زمانی یونیکس زمان شروع آزمون ایندکس می‌شود. داده های پوشش در پایگاه داده همراه با نتایج آزمایش به عنوان بردار شمارش (یعنی برای هر خط در فایل منبع اصلی) و شناسایی اطلاعات برای دریافت کد منبع از سرور کد منبع ذخیره می شود.

سرویس اطلاع رسانی با استفاده از صف های وظیفه، شناسایی تغییرات وضعیت آزمایشی و اطلاع رسانی به مشترکین اجرا می شود. اطلاعات Stateful در یک جدول وضعیت ذخیره می شود تا تازه بودن داده ها و خرابی های موجود را پیگیری کند. این به سرویس اعلان اجازه می دهد تا اطلاعات غنی در مورد خرابی ها و رفع مشکلات مورد آزمایش فردی ارائه دهد.

ساختار کد

اجزای ضروری داشبورد VTS شامل سرولت های پیاده سازی شده در جاوا، JSP های جلویی، شیوه نامه های CSS و فایل های پیکربندی است. لیست زیر به جزئیات مکان ها و توضیحات این مؤلفه ها می پردازد (همه مسیرهای مربوط به test/vts/web/dashboard ):

• pom.xml
  فایل تنظیمات که در آن متغیرهای محیطی و وابستگی ها تعریف می شوند.
• src/main/java/com/android/vts/api/
  حاوی نقاط پایانی برای تعامل با داده ها از طریق REST.
• src/main/java/com/android/vts/entity/
  شامل مدل های جاوا از موجودیت های Datastore است.
• src/main/java/com/android/vts/proto/
  حاوی فایل‌های جاوا برای Protobuf، از جمله VtsReportMessage.java ، که یک پیاده‌سازی جاوا از نوع Protobuf است که برای توصیف نتایج آزمایش VTS استفاده می‌شود.
• src/main/java/com/android/vts/servlet/
  حاوی فایل های جاوا برای سرولت ها.
• src/main/java/com/android/vts/util/
  حاوی فایل‌های جاوا برای توابع و کلاس‌های کاربردی است که توسط سرولت‌ها استفاده می‌شوند.
• src/test/java/com/android/vts/
  شامل تست های UI برای servlets و utils.
• src/main/webapp/
  حاوی فایل‌های مرتبط با رابط کاربری (JSP، CSS، XML):
  • js/ . حاوی فایل های جاوا اسکریپت است که توسط صفحات وب استفاده می شود.
  • WEB-INF/ . حاوی فایل های پیکربندی و رابط کاربری است.
  • jsp/ . حاوی فایل های JSP برای هر صفحه وب است.
• appengine-web.xml
  فایل تنظیمات که در آن متغیرهای محیط در متغیرها بارگذاری می شوند.
• web.xml
  فایل تنظیمات که در آن نگاشت سرورلت و محدودیت های امنیتی تعریف شده است.
• cron.xml
  فایل تنظیمات که وظایف برنامه ریزی شده را تعریف می کند (یعنی سرویس اعلان ها).

داشبورد را تنظیم کنید

برای راه اندازی داشبورد VTS:

1. یک پروژه Google Cloud App Engine ایجاد کنید و میزبان استقرار را با نصب:
   • جاوا 8
   • Google App Engine SDK
   • ماون
2. یک شناسه مشتری OAuth 2.0 در Google Cloud API Manager ایجاد کنید.
3. یک حساب سرویس ایجاد کنید و یک فایل کلید ایجاد کنید.
4. یک آدرس ایمیل به فهرست فرستنده مجاز API Email Engine App اضافه کنید.
5. یک حساب Google Analytics تنظیم کنید.
6. متغیرهای محیطی را در Dashboard pom.xml مشخص کنید:
   • شناسه مشتری را با شناسه OAuth 2.0 تنظیم کنید (از مرحله 2).
   • شناسه سرویس گیرنده را با شناسه موجود در فایل کلید (از مرحله 3) تنظیم کنید.
   • آدرس ایمیل فرستنده را برای هشدارها مشخص کنید (از مرحله 4).
   • دامنه ایمیلی را مشخص کنید که همه ایمیل ها به آن ارسال شوند.
   • آدرس سرور Gerrit REST را مشخص کنید.
   • محدوده OAuth 2.0 را برای استفاده برای سرور Gerrit REST مشخص کنید.
   • شناسه Google Analytics را مشخص کنید (از مرحله 5).
   • پروژه را بسازید و اجرا کنید.
7. در ترمینال، mvn clean appengine:update اجرا کنید.

ملاحظات امنیتی

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

برای جلوگیری از این تهدید، داشبورد به‌جای ارائه کد منبع با اطلاعات پوشش، مستقیماً بردار پوشش را کنترل می‌کند (یعنی بردار اجرای شمارش‌های نگاشت به خطوط در یک فایل منبع). همراه با بردار پوشش، داشبورد نام و مسیر پروژه Git را دریافت می کند تا مشتری بتواند کد را از یک API کد منبع خارجی دریافت کند. مرورگر مشتری این اطلاعات را دریافت می‌کند و از اشتراک‌گذاری منابع متقاطع (CORS) در جاوا اسکریپت برای پرس و جو از سرور کد منبع برای کد منبع اصلی استفاده می‌کند. کد به دست آمده با بردار پوشش ترکیب می شود تا یک صفحه نمایش ایجاد شود.

این رویکرد مستقیم سطح حمله را گسترش نمی‌دهد زیرا داشبورد از کوکی‌های کاربر برای احراز هویت با یک سرویس خارجی استفاده می‌کند (به این معنی که کاربری که نمی‌تواند مستقیماً به کد منبع دسترسی پیدا کند نمی‌تواند از داشبورد برای مشاهده اطلاعات حساس سوء استفاده کند).