مجموعة أدوات اختبار الأداء (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 ساعات في المرة الواحدة. إذا كانت بحاجة إلى التشغيل لمدة يُرجى تضمين الأسباب في اقتراح الاختبار لكي نتمكّن من مراجعته.

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

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

الأهلية لإجراء الاختبار

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

عملية تقديم CTS

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

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

  • اتّبِع دليل استخدام JavaScript.
  • اتّبِع جميع الخطوات الموضّحة في تطوير 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
    • مالك الاختبار في Google 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 أو سلوك واجهة برمجة التطبيقات الموثق. إذا كان الاختبار التأكد من التحقق من مطلب أو سلوك صالح، فإن الفريق سنعيد توجيه هذه الحالة الاختبارية إلى أحد مهندسي Google لمراجعتها مرة أخرى. فريق أحد المهندسين لتقديم ملاحظات حول كيفية تحسين الاختبار قبل قبوله في CTS.

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