CTS من إنشاء المطوّرين

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

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

لا يمكن لمجموعة أدوات اختبار التوافق (CTS) للأجهزة إلا فرض ما يلي، تمامًا مثل مجموعة أدوات اختبار التوافق (CTS) وأداة CTS Verifier:

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

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

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

قواعد إنشاء اختبار مجموعة أدوات اختبار التوافق (CTS)

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

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

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

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

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

عملية إرسال مجموعة اختبار التوافق (CTS)

  1. كتابة اقتراح اختبار: يرسل مطوّر التطبيقات اقتراح اختبار باستخدام Issue Tracker في Google، ويصف المشكلة التي تم رصدها ويقترح إجراء اختبار للتحقّق منها. يجب أن يتضمّن الاقتراح معرّف متطلبات مستند تعريف معايير التوافق (CDD) المرتبط. يراجع فريق Android الاقتراح.
  2. تطوير اختبار CTS: بعد الموافقة على الاقتراح، ينشئ مقدِّم الاقتراح اختبار CTS على AOSP في فرع أحدث إصدار من Android (android17-release). يراجع فريق Android الرمز، وفي حال الموافقة عليه، يختار التغيير ويدمجه في فرع التطوير الداخلي. لمزيد من التفاصيل، يُرجى الاطّلاع على أين يمكنني اقتراح تغييرات على مشروع Android مفتوح المصدر (AOSP)؟.

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

  • اتّبِع دليل أسلوب كتابة رمز Java.
  • اتّبِع جميع الخطوات الموضّحة في تطوير مجموعة اختبار التوافق.
  • أضِف اختباراتك إلى خطة الاختبار المناسبة:
    • استخدِم 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.
  • تعامَل مع جميع التحذيرات والاقتراحات errorprone في build_error.log.
  • أعِد ضبط التغييرات على head. ويشمل ذلك خطتَي الاختبار cts-developer.xml وcts-developer-exclude.xml.
  • يمكنك التواصل مع جهة الاتصال الهندسية في Google لتحديد ما إذا كان يمكن تضمين حالة الاختبار في إحدى وحدات CTS الحالية. إذا لم يتمكّن من ذلك، سيساعدك في إنشاء وحدة جديدة.
  • لكل وحدة اختبار جديدة يتم إنشاؤها، أنشئ ملف OWNERS في دليل وحدة الاختبار الجديدة.
    • يجب أن يحتوي ملف OWNERS على المعلومات التالية التي تم الحصول عليها من مالك الاختبار في Google الذي تتعاون معه:
    • # Bug component: xxx
    • معرّف LDAP لمالك اختبار Google
  • في AndroidTest.xml، حدِّد المَعلمات التالية. راجِع الملفات النموذجية (1 و2) للاطّلاع على أمثلة:
    • Instant_app أو not_instant_app
    • secondary_user أو not_secondary_user
    • all_foldable_states أو no_foldable_states
  • لتحديد minSDK الصحيح، يُرجى الرجوع إلى مستندات <uses-sdk>.
  • عند تسجيل طرق أو فئات أو وحدات اختبار جديدة، أضِفها إلى خطة اختبار CTS-D واستبعِدها من خطة اختبار CTS الرئيسية بالطريقة نفسها المتبعة مع الاختبارات الجديدة.

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

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

لتنفيذ حالة اختبار معيّنة، استخدِم run cts --include-filter "test_module_name test_name".

للحصول على معلومات حول تشغيل مجموعة اختبارات التوافق الكاملة، يُرجى الاطّلاع على تشغيل اختبارات مجموعة اختبارات التوافق.

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

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

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