توضّح هذه الصفحة إرشادات الاستخدام الخاصة بـ "نظام الإحالة الناجحة إلى المتجر التجاري الذي يديره المطوّر" (CTS-D).
تغطية الاختبار
لا يمكن لأداة CTS-D، مثل مجموعة أدوات اختبار التوافق (CTS) وأداة التحقّق في مجموعة أدوات اختبار التوافق (CTS)، فرض ما يلي فقط:
- جميع واجهات برمجة التطبيقات العامة الموضّحة في حزمة تطوير البرامج (SDK) الخاصة بالمطوّرين (developer.android.com) لمستوى معيّن من واجهات برمجة التطبيقات
- جميع متطلبات MUST المضمّنة في "مستند تعريف توافق Android" (CDD) لمستوى واجهة برمجة تطبيقات معيّن
المتطلبات غير الإلزامية، مثل "يُنصح بشدة" و"يجب" و"يجوز"، هي متطلبات اختيارية ولا يمكن اختبارها باستخدام مجموعة اختبار التوافق (CTS).
بما أنّ جميع واجهات برمجة التطبيقات ومتطلبات CDD مرتبطة بمستوى معيّن من واجهة برمجة التطبيقات، فإنّ جميع اختبارات CTS (مجموعة أدوات اختبار التوافق وCTS-D وCTS Verifier) مرتبطة بالمستوى نفسه من واجهة برمجة التطبيقات أو المتطلبات المرتبطة بها. في حال إيقاف واجهة برمجة تطبيقات معيّنة نهائيًا أو تغييرها، يجب إيقاف الاختبار المقابل نهائيًا أو تعديله.
قواعد إنشاء اختبارات مجموعة أدوات اختبار التوافق (CTS)
- يجب أن تؤدي الاختبارات إلى النتيجة الموضوعية نفسها باستمرار.
- يجب أن يحدّد الاختبار ما إذا كان الجهاز يجتاز الاختبار أو لا يجتازه من خلال اختبار هذا الجهاز مرة واحدة بعد إخراجه من العلبة.
- على صنّاع الاختبارات إزالة جميع العوامل المحتملة التي يمكن أن تؤثر في نتائج الاختبار.
- إذا كان الجهاز يحتاج إلى حالة/بيئة/إعدادات أجهزة معيّنة، يجب تحديد هذه الإعدادات بوضوح في رسالة الالتزام. للحصول على تعليمات حول الإعداد، اطّلِع على إعداد مجموعة اختبار التوافق.
- يجب ألا يستمر الاختبار لأكثر من 6 ساعات في المرة الواحدة. إذا كان يجب أن يستمر الاختبار لفترة أطول، يُرجى تضمين السبب في اقتراح الاختبار لنتمكّن من مراجعته.
في ما يلي مجموعة أمثلة على شروط الاختبار لاختبار قيود التطبيق:
- شبكة Wi-Fi ثابتة (بالنسبة إلى الاختبار الذي يعتمد على شبكة Wi-Fi).
- يظل الجهاز ثابتًا أثناء الاختبار (أو لا يظل ثابتًا، حسب الاختبار).
- تم فصل الجهاز عن أي مصدر طاقة ومستوى شحن البطارية هو X%.
- لا يتم تشغيل أي تطبيقات أو خدمات تعمل في المقدّمة أو الخلفية، باستثناء CTS.
- تكون الشاشة مطفأة أثناء تشغيل مجموعة اختبار التوافق (CTS).
- الجهاز ليس
isLowRamDevice. - لم يتم تغيير إعدادات "توفير شحن البطارية" أو قيود التطبيقات من حالة "الجهاز الجديد".
متطلبات الأهلية للاستفادة من الفترة التجريبية
نقبل اختبارات جديدة تفرض سلوكًا لم يتم اختباره من خلال اختبارات CTS أو CTS Verifier أو CTS-D الحالية. سيتم رفض أي اختبار يتحقّق من سلوك خارج نطاق تغطية الاختبار.
عملية إرسال مجموعة أدوات اختبار التوافق (CTS)
- كتابة اقتراح اختبار: يرسل مطوّر التطبيق اقتراح اختبار باستخدام Google Issue Tracker، ويصف فيه المشكلة التي تم رصدها ويقترح إجراء اختبار للتحقّق منها. يجب أن يتضمّن الاقتراح معرّف متطلبات العناية الواجبة بالعملاء المرتبط. يراجع فريق Android الاقتراح.
- تطوير اختبار CTS: بعد الموافقة على الاقتراح، ينشئ مقدِّم الاقتراح اختبار CTS على AOSP في فرع أحدث إصدار من Android (
android16-release). يراجع فريق Android الرمز، وفي حال الموافقة عليه، يختار التغيير ويدمجه في فرع التطوير الداخلي. لمزيد من التفاصيل، يُرجى الاطّلاع على أين يمكنني اقتراح تغييرات على مشروع Android مفتوح المصدر (AOSP)؟.
إرشادات كتابة اختبار 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.
- استخدِم
- تعامَل مع جميع التحذيرات والاقتراحات
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.