CTS بدعم من المطور

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

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

يمكن لـ CTS-D، مثل CTS وCTS Verifier، فرض ما يلي فقط:

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

تعتبر المتطلبات غير الضرورية، مثل "موصى به بشدة" و"ينبغي" و"مايو" اختيارية ولا يمكن اختبارها باستخدام CTS.

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

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

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

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

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

أهلية الاختبار

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

عملية تقديم CTS

  1. كتابة اقتراح اختبار: يقدم مطور التطبيق اقتراح اختبار باستخدام Google Issue Tracker ، مع وصف المشكلة التي تم تحديدها واقتراح اختبار للتحقق منها. يجب أن يتضمن الاقتراح معرف متطلبات CDD المرتبط. يقوم فريق Android بمراجعة الاقتراح.
  2. تطوير اختبار CTS: بعد الموافقة على الاقتراح، يقوم مقدمه بإنشاء اختبار CTS على AOSP على الفرع الرئيسي (AOSP/main). يقوم فريق Android بمراجعة الكود.
  3. اختبار النشر: أرسل CL الخاص بك على 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 .
  • تعامل مع جميع errorprone في build_error.log .
  • أعد صياغة تغييراتك إلى head . يتضمن ذلك خطط اختبار cts-developer.xml و cts-developer-exclude.xml .
  • اعمل مع جهة الاتصال الهندسية في Google لتحديد ما إذا كان من الممكن تضمين حالة الاختبار الخاصة بك في وحدة CTS الحالية. إذا لم يكن الأمر كذلك، فسوف يساعدونك في إنشاء وحدة نمطية جديدة.
  • لكل وحدة اختبار جديدة تم إنشاؤها، قم بإنشاء ملف OWNERS في دليل وحدة الاختبار الجديدة.
    • يجب أن يحتوي ملف OWNERS على المعلومات التالية، التي تم الحصول عليها من مالك اختبار Google الذي تعمل معه:
    • # Bug component: xxx
    • جوجل اختبار مالك ldap
  • في 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" .

للحصول على معلومات حول تشغيل CTS الكامل، راجع تشغيل اختبارات CTS .

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

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

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