مجموعة أدوات اختبار الأداء (CTS) التي يديرها المطور

توضّح هذه الصفحة إرشادات الاستخدام لميزة CTS التي ينشئها المطوّرون (CTS-D).

تغطية الاختبار

لا يمكن لخدمة CTS-D، مثل CTS وCTS Verifier، فرض ما يلي إلا:

  • جميع واجهات برمجة التطبيقات المتاحة للجميع والموضّحة في حزمة تطوير البرامج (SDK) للمطوّرين (developer.android.com) لمستوى معيّن من واجهة برمجة التطبيقات
  • يجب أن يتم تضمين جميع المتطلبات المضمّنة في مستند تعريف التوافق مع Android (CDD) لمستوى معيّن لواجهة برمجة التطبيقات.

إنّ المتطلّبات غير الحتمية، مثل "يُنصح بشدة" و"يجب" و"يمكن"، هي اختيارية ولا يمكن اختبارها باستخدام مجموعة اختبار التوافق (CTS).

بما أنّ جميع واجهات برمجة التطبيقات ومتطلبات CDD مرتبطة بمستوى معيّن لواجهة برمجة التطبيقات، فإنّ جميع اختبارات CTS (CTS وCTS-D وCTS Verifier) مرتبطة بمستوى واجهة برمجة التطبيقات نفسه المرتبط بواجهات برمجة التطبيقات أو المتطلبات المرتبط بها. إذا تم إيقاف واجهة برمجة تطبيقات معيّنة أو تغييرها، يجب إيقاف الاختبار المقابل لها أو تعديله.

قواعد إنشاء اختبارات CTS

  • يجب أن يقدّم الاختبار النتيجة الموضوعية نفسها بشكلٍ متّسق.
  • يجب أن يحدِّد الاختبار ما إذا كان الجهاز يجتاز الاختبار أو لا من خلال اختبار ذلك الجهاز مرة واحدة خارج العلبة.
  • على صنّاع الاختبار إزالة جميع العوامل المحتمَلة التي قد تؤثّر في نتائج الاختبار.
  • إذا كان الجهاز يحتاج إلى حالة/بيئة/إعدادات أجهزة معيّنة، يجب تحديد هذه الإعدادات بوضوح في رسالة التعليق التوضيحي. للحصول على أمثلة على تعليمات الإعداد، اطّلِع على مقالة إعداد CTS.
  • يجب عدم تنفيذ الاختبار لأكثر من 6 ساعات في المرة الواحدة. إذا كان يجب تشغيله مدّة أطول، يُرجى تضمين السبب في اقتراح الاختبار لنتمكّن من مراجعته.

في ما يلي مثال على مجموعة من شروط الاختبار لاختبار أحد قيود التطبيقات:

  • شبكة Wifi ثابتة (للاختبار الذي يعتمد على شبكة Wifi)
  • يظل الجهاز ثابتًا أثناء الاختبار (أو لا يظل ثابتًا، حسب الاختبار).
  • تم فصل الجهاز عن أي مصدر طاقة ويبلغ مستوى شحن البطارية %X.
  • لا يتم تشغيل أي تطبيقات أو خدمات تعمل في المقدّمة أو في الخلفية، باستثناء CTS.
  • تكون الشاشة مطفأة أثناء تشغيل CTS.
  • الجهاز ليس isLowRamDevice.
  • لم يتم تغيير قيود "توفير شحن البطارية" أو التطبيقات عن حالتها "التلقائية".

متطلبات الأهلية للاستفادة من الفترة التجريبية

نقبل الاختبارات الجديدة التي تفرض سلوكًا لا يتم اختباره من خلال اختبارات CTS أو CTS Verifier أو CTS-D الحالية. سيتم رفض أي اختبار يتحقّق من سلوك خارج نطاق تغطية الاختبار.

عملية إرسال CTS

  1. كتابة مقترح اختبار: يقدم أحد مطوري التطبيقات اقتراحًا للاختبار باستخدام أداة تتبع المشكلات من Google، حيث يصف المشكلة التي تم تحديدها، ويقترح اختبارًا للتحقق منها. يجب أن يتضمّن الاقتراح معرّف متطلبات CDD المرتبط به. يراجع فريق Android الاقتراح.
  2. تطوير اختبار CTS: بعد الموافقة على العرض، يُنشئ مقدّمه اختبار CTS على AOSP في الفرع الرئيسي (AOSP/الرئيسي). يراجع فريق Android الرمز البرمجي.
  3. نشر الاختبار: أرسِل طلب التغيير على AOSP/main، ثم اختَر المحتوى الذي تريده وأضِفه إلى الفرع الأحدث androidx-tests-dev. أصبح الاختبار متاحًا للجميع الآن.

إرشادات كتابة اختبار CTS-D

  • اتّبِع دليل أسلوب رمز Java.
  • اتّبِع جميع الخطوات الموضّحة في مقالة تطوير CTS.
  • أضِف اختباراتك إلى خطة الاختبار المناسبة:
    • استخدِم include-filters لإضافة اختباراتك الجديدة إلى خطة اختبار CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • استخدِم exclude-filters لاستبعاد اختباراتك الجديدة من خطة اختبار CTS الرئيسية: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • معالجة جميع التحذيرات والاقتراحات في errorpronebuild_error.log
  • غيِّر مصدر التغييرات إلى "head". ويشمل ذلك خطتَي الاختبار cts-developer.xml و cts-developer-exclude.xml.
  • يمكنك التعاون مع جهة الاتصال المسؤولة عن الهندسة في Google لتحديد ما إذا كان يمكن تضمين حالة الاختبار في وحدة CTS حالية. وإذا تعذّر ذلك، سيساعدك في إنشاء وحدة جديدة.
  • لكل وحدة اختبار جديدة يتم إنشاؤها، أنشئ ملف OWNERS في دليل وحدة الاختبار الجديد.
    • يجب أن يحتوي ملف OWNERS على المعلومات التالية، التي يتم الحصول عليها من مالك الاختبار في Google الذي تتعامل معه:
    • # Bug component: xxx
    • مالك الاختبار في Google ldap
  • في AndroidTest.xml، حدِّد المَعلمات التالية. يمكنك الرجوع إلى نماذج الملفات (1 و2) للاطّلاع على أمثلة:
    • ‫Instant_app أو not_instant_app
    • ‫secondary_user أو not_secondary_user
    • ‫all_foldable_states أو no_foldable_states
  • لتحديد الحد الأدنى الصحيح لإصدار حزمة تطوير البرامج (SDK)، يُرجى الرجوع إلى مستندات <uses-sdk>.
  • عند تسجيل طرق اختبار أو فئات أو وحدات جديدة، أضِفها إلى خطة اختبار CTS-D واستبعِدها من خطة اختبار CTS الرئيسية بالطريقة نفسها المتّبعة مع الاختبارات الجديدة.

إجراء اختبار CTS-D

شغِّل خطة اختبار CTS-D من سطر الأوامر باستخدام run cts --plan cts-developer.

لإجراء اختبار معيّن، استخدِم run cts --include-filter "test_module_name test_name".

للحصول على معلومات عن إجراء اختبار CTS الكامل، يُرجى الاطّلاع على مقالة إجراء اختبارات CTS.

القبول والإفراج

بعد إرسال طلب الاختبار، سيراجعه فريق داخلي للتأكّد من أنّه يختبر أحد متطلبات CDD أو أحد سلوكيات واجهة برمجة التطبيقات الموثَّقة. إذا تبيّن للفريق أنّ الاختبار يبحث عن شرط أو سلوك صالحَين، سيعيد توجيه حالة الاختبار هذه إلى أحد مهندسي Google لإجراء مراجعة إضافية. وسيتواصل معك مهندس Google لتقديم ملاحظات حول كيفية تحسين الاختبار قبل قبوله في CTS.

اطّلِع على الجدول الزمني للإصدار ومعلومات الفرع للحصول على تفاصيل عن الجدول الزمني لإصدار CTS.