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

يتضمّن الإصدار 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. لمعرفة التفاصيل حول وحدة التحكّم بالمضيف، يُرجى الاطّلاع على Host Controller Architecture (بنية وحدة التحكّم بالمضيف).

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

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

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

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

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

إصدار Android المخصّص للشركاء

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

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

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

طلب POST لعنوان URL

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

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

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

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

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

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

لتجنُّب هذه المشكلة، يعيد نظام التشغيل 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.

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

يتم تلقائيًا تسجيل نتائج الاختبار في بعض مشاريع لوحة بيانات مراقبة الزيارات من خلال VtsMultiDeviceTest.