البنية الأساسية للاختبار الآلي

يتضمّن الإصدار 9 من Android بنية أساسية لـ "مجموعة اختبار المورّدين" (VTS) لإجراء اختبار آلي لـ "مجموعة اختبار المورّدين" أو "مجموعة اختبار التوافق" أو اختبارات أخرى على أجهزة الشركاء التي تعمل بنظام التشغيل AOSP العام (GSI). في السابق، كان تنفيذ هذه الاختبارات يتطلّب إجراءً يدويًا إلى حدٍ كبير. تم تصميم البنية الأساسية الجديدة لاختبار VTS لدعم الاختبار الآلي عدة مرات في اليوم على عدة أجهزة.

هندسة معمارية

تستخدم بنية الاختبار الآلي لنظام التحكّم في المرور (VTS) البنية التالية:

بنية الاختبار المبرمَج

الشكل 1. بنية أساسية للاختبار الآلي في ميزة "التحقق من الأداء"

عند إجراء اختبار، تنفّذ البنية الأساسية للاختبار الآلي على VTS المهام التالية:

  1. تنشئ عمليات الجلب العناصر واختبار الموارد من مواقع جغرافية مختلفة:
    • إصدار Android من الشريك (PAB) لإطار عمل GSI وVTS وبعض الإصدارات الأخرى
    • نظام الملفات على الجهاز أو Google Cloud Storage أو أي نظام تصميم آخر خاص بالمورّد: مخصّص للشركاء الذين لا يخزّنون النُسخ فيسحابة Google الإلكترونية
  2. وميزات الفلاش هي عناصر الإنشاء (من الجهاز) ومجموعة البرامج الأساسية (من AOSP) على الأجهزة المتصلة.
  3. يُجري اختبارات VTS باستخدام TradeFed على الجهاز أو TradeFed في السحابة الإلكترونية.
  4. الإبلاغ عن نتائج الاختبار في لوحة بيانات مراقبة الأداء في الوقت الفعلي

يتم تنسيق العملية من خلال وحدة التحكّم في المضيف (HC) لاختبارات الفيديو المباشر (VTS)، وهي جهاز في المختبر يوجّه سلوك جميع الأجهزة المتصلة التي تخضع للاختبار. يتحمّل HC مسؤولية جلب أحدث الإصدارات وفلاشها على الأجهزة، و تشغيل الاختبارات (إما محليًا أو من خلال أداة التحكم). ويتواصل أيضًا مع جدولة السحابة الإلكترونية ويوجّه الزيارات بين جدولة مثيل TradeFed (أو بعض الأجهزة الأخرى) التي تعمل على HC. ولمعرفة تفاصيل عن وحدة التحكّم في المضيف، يُرجى الاطّلاع على بنية وحدة تحكّم المضيف.

مقدّمو الموارد

يتطلّب الاختبار الآلي موارد مثل عمليات إنشاء النظام وملفات الاختبار و عناصر VTS. على الرغم من أنّه من الممكن إنشاء هذه العناصر من المصدر، من الأسهل إنشاؤها من أحدث إصدار بشكل منتظم ثم نشر العناصر لتنزيلها.

يمكن للشركاء الوصول إلى موارد التشغيل الآلي باستخدام المواقع التالية:

  • إصدار Android للشركاء يتم منح إمكانية الوصول الآلي على أساس كل حساب.
  • نظام الملفات على الجهاز (أو ما شابه) بالنسبة إلى الشركاء الذين لا يستخدمون إصدار Android المخصّص للشركاء

لاستخدامها في إعادة تحميل البرامج الثابتة على الأجهزة لاحقًا، تتضمّن الموارد موفّري الإصدارات لكلٍّ من الخيارَين، بدءًا من build_provider.py واحد يخزّن الإصدارات في أدلة مؤقتة محلية.

إصدار Android للشريك

في الإصدار Android 8.1 والإصدارات الأقدم، كان على شركاء Android زيارة الموقع الإلكتروني للشركاء في إصدار Android Build (https://partner.android.com/build)، والانتقال إلى حساباتهم وجلب أحدث صور النظام من خلال واجهة المستخدم. لمساعدة الشركاء في تجنُّب هذه العملية البطيئة والمستهلكة للوقت، يتيح الإصدار Android 9 إمكانية تنزيل هذه المراجع تلقائيًا من PAB عند تقديم بيانات الاعتماد المناسبة.

منح إذن الوصول

يستخدم الوصول الآلي بروتوكول OAuth2 على Google APIs للوصول إلى إجراءات استدعاء الإجراء عن بُعد المطلوبة. باستخدام النهج العادي لإنشاء بيانات اعتماد OAuth2، على الشريك إعداد معرّف العميل/سر العميل مع Google. عندما يتم توجيه PartnerAndroidBuildClient إلى هذا السر لأول مرة، يتم فتح نافذة متصفّح للمستخدم لتسجيل الدخول إلى حسابه على Google، ما يؤدي إلى إنشاء بيانات اعتماد OAuth2 اللازمة للمتابعة. يتم تخزين بيانات اعتماد (رمز الوصول المميّز ورمز إعادة التحميل المميّز) على الجهاز، ما يعني أنّه على الشركاء تسجيل الدخول مرة واحدة فقط.

طلب POST لعنوان URL

يؤدي النقر على رابط مرجع في "مركز عملائي" إلى إرسال طلب POST يتضمّن البيانات اللازمة لهذا المرجع، بما في ذلك:

  • رقم تعريف الإصدار، وهدف الإصدار
  • اسم المورد
  • فرع
  • اسم الإصدار المحتمل وما إذا كان الإصدار المحتمل هو إصدار داخلي

يتم تلقّي طلب POST من خلال طريقة downloadBuildArtifact من buildsvc RPC، والتي تعرض عنوان URL يمكن استخدامه للوصول إلى المورد.

  • بالنسبة إلى موارد حِزمة APK Companion على الساعة، يكون عنوان URL هو عنوان URL قابل للقراءة ومستضاف على PAB (وهو محمي بواسطة المصادقة ويمكن الوصول إليه باستخدام بيانات اعتماد OAuth2 المناسبة).
  • بالنسبة إلى الموارد الأخرى، يكون عنوان URL طويلاً وغير محمي من واجهة برمجة التطبيقات الداخلية Android Build API (تنتهي صلاحيته بعد خمس دقائق).

الحصول على عنوان URL

لتجنُّب تزوير الطلبات من مواقع إلكترونية مختلفة، يتطلّب buildsvc RPC إرسال رمز XSRF المميّز باستخدام POST مع المَعلمات الأخرى. ومع أنّ هذا الرمز المميّز يجعل العملية أكثر أمانًا، فهو يزيد أيضًا من صعوبة الوصول الآلي لأنّ الرمز المميّز (المتوفّر فقط في JavaScript لصفحة PAB) مطلوبًا الآن أيضًا للوصول إليه.

لتجنُّب هذه المشكلة، يعيد نظام التشغيل Android 9 تصميم نظام تسمية عناوين URL لجميع الملفات (وليس حِزم APK فقط) لاستخدام أسماء عناوين URL متوقّعة للوصول إلى قوائم العناصر وعناوين URL الخاصة بها. يستخدم PAB الآن تنسيقًا مناسبًا لعناوين URL يتيح للشركاء تنزيل الموارد، ويمكن للنصوص البرمجية لبرنامج HC تنزيل حِزم APK هذه بسهولة، لأنّ تنسيق عنوان URL معروف، ويمكن لبرنامج HC تجاوز مشاكل XSRF/ملفات تعريف الارتباط لأنّه لا يحتاج إلى buildsvc RPC.

نظام الملفات على الجهاز

عند توفّر دليل يتضمّن قائمة (أو ملف مضغوط) بالعناصر، يضبط مقدّم عملية الإنشاء الصور ذات الصلة استنادًا إلى ما هو موجود في الدليل. يمكنك استخدام أداة gsutil لنسخ الملفات من Google Cloud Storage إلى دليل على الجهاز.

إصدارات Flash

بعد تنزيل أحدث صور الأجهزة إلى المضيف، يجب وميض هذه الصور على الأجهزة. ويتم ذلك باستخدام الأمرَين العاديَين adb وfastboot والعمليات الفرعية لـ Python، استنادًا إلى مسارات الملفات المؤقتة التي يخزّنها موفّرو عمليات الإنشاء.

الإجراءات المتاحة:

  • فلاش صورة النظام العام (GSI) فقط
  • وميض صور فردية من النظام الرئيسي (مثل fastboot flash boot boot.img)
  • يتم فلاش جميع الصور من النظام الرئيسي. مثال:
    • fastboot flashall (باستخدام الأداة المضمّنة flashall )
    • fastboot flash (واحد تلو الآخر)

إجراء الاختبارات

في Android 9، لا تتوافق البنية الأساسية للاختبار الآلي لميزة VTS إلا مع مجموعة أدوات الاختبار TradeFed، ولكن يمكن توسيعها لتتوافق مع أدوات أخرى في المستقبل.

بعد تجهيز الأجهزة، يمكنك تشغيل الاختبارات باستخدام أحد الخيارين التاليين:

  • عند استخدام TradeFed على الجهاز، استخدِم الأمر test في وحدة التحكّم المضيفة، والتي تحمل اسم خطة اختبار VTS (مثل vts-selftest) وتُجري الاختبار.
  • عند استخدام مجموعة TradeFed (متصلة اختياريًا بـ MTT)، استخدِم الأمر lease في وحدة تحكّم المضيف، والذي يبحث عن عمليات تنفيذ اختبار لم تكتمل.

في حال استخدام TradeFedCluster، يتم تشغيل TradeFed محليًا كمدير عن بُعد. وإذا لم يكن الأمر كذلك، يتمّ استدعاء الاختبارات باستخدام العمليات الفرعية في Python.

الإبلاغ عن النتائج

يتم إبلاغ بعض مشاريع لوحة بيانات VTS تلقائيًا بنتائج الاختبار من خلال VtsMultiDeviceTest.