الأسئلة الشائعة حول CTS

يعد برنامج توافق Android هو المحرك الرئيسي للحفاظ على التعليقات الإيجابية لنظام Android البيئي. CTS هي الأداة الرئيسية لضمان جودة التوافق في المقياس. يواصل فريق Android تحسين أداة CTS وتغطية الاختبار. تؤدي الإضافة المنتظمة لحالات الاختبار إلى تحسين كبير في جودة الأجهزة المتوافقة.

اسئلة عامة

يوفر هذا القسم الأسئلة الشائعة العامة حول CTS.

ما هي أنواع الأشياء التي يختبرها اختبار CTS؟

تختبر CTS أن جميع واجهات برمجة التطبيقات المدعومة بنظام Android موجودة وتعمل بشكل صحيح. يختبر CTS أيضًا سلوكيات النظام الأخرى غير المتعلقة بواجهة برمجة التطبيقات (API)، مثل دورة حياة التطبيق والأداء.

كيف يتم ترخيص CTS؟

تم ترخيص CTS بموجب نفس ترخيص برنامج Apache 2.0 الذي يستخدمه الجزء الأكبر من Android.

هل تم التحقق من برامج الترميز بواسطة CTS؟

نعم. يتم التحقق من جميع برامج الترميز الإلزامية بواسطة CTS.

أسئلة خاصة بالاختبار

يوفر هذا القسم الأسئلة الشائعة التي تساعد في تشغيل اختبارات CTS بكفاءة أكبر.

ما هو الفرق بين مشاركة CTS ومشاركة TF؟

تعد CTS Sharding وTF Sharding خطط اختبار مختلفة تمامًا مدعومة بقاعدة تعليمات برمجية مختلفة للبنية التحتية للاختبار. على الرغم من أن أمر التشغيل هو نفسه عبر الإصدارات المختلفة، إلا أن نتيجة التقسيم تتصرف بشكل مختلف. تقوم CTS Sharding بتعيين حالات الاختبار بشكل ثابت للأجهزة قيد الاختبار (DUTs) على النحو التالي:

تقوم TF Sharding بتعيين حالات الاختبار ديناميكيًا إلى DUTs المتاحة على النحو التالي:

ما هو المتوقع من جهاز يدعم واجهات ABI المتعددة؟

يجب أن يجتاز الجهاز جميع اختبارات CTS وCTS Verifier لكل وضع ABI يدعي أنه يدعمه. لذلك، من الضروري تنفيذ تطبيق لواجهات ABI المحددة. الإرشادات الخاصة بواجهات ABI المتعددة هي كما يلي:

  • بالنسبة إلى CTS وCTS Verifier، هناك إصدارات ARM وx86 لكل بنية. يمكن لكل واحد منهم دعم وضع 32 أو 64 بت.
  • بالنسبة لاختبارات CTS، إذا كان الجهاز يدعم كلاً من ARM وx86، فيجب عليه تشغيل واجتياز اختبارات ARM وx86 CTS على التوالي.

انظر CDD 3.3.1. واجهات التطبيق الثنائية لمتطلبات CDD على ABI.

هل يكفي إجراء اختبار فقط على واجهة برمجة التطبيقات (ABI) الأساسية (على سبيل المثال، 64 بت) لتقليل وقت تنفيذ الاختبار؟

لا، يعمل تطبيق Android على أوقات تشغيل 32 بت أو 64 بت. يختلف رمز الجهاز الفعلي ومسار الرمز والحالة بين 32 و64. إذا تخطيت وضعًا واحدًا، فإنك لا تغطي سوى 50% من واجهة برمجة التطبيقات (ABI) للجهاز.

لماذا يتم الإبلاغ عن العديد من حالات الاختبار على أنها لم يتم تنفيذها؟

يجب عليك التحقق من رقم "تم تنفيذ الوحدة" بدلاً من رقم "لم يتم تنفيذها" .

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

وحدة يتم تشغيلها حتى اكتمال تقارير الوحدة التي لم يتم تنفيذها في الاستدعاء الأخير (done = "false") في التقرير خلال ما يلي:

  • تمت مقاطعة التشغيل التجريبي للوحدة بسبب مشكلة في اتصال الجهاز.
  • لم يتم تنفيذ جميع عمليات التشغيل الاختبارية المتوقعة للوحدة.

  • إعادة المحاولة (باستخدام الخيار -r/--retry ) مع خيارات تصفية إضافية، مثل:

    • --include-filter
    • --exclude-filter
    • -t/--test (الخيار غير مدعوم بعد عند إعادة المحاولة)
    • --فشلت إعادة المحاولة
    • --subplan

للحصول على حالة تم الوحدة النمطية (تم = "صحيح") لهذه الوحدات، أعد محاولة ما يلي لأحدث استدعاء:

run retry --retry <session_id> for Android 9 and later versions

run cts --retry <session_id> for Android 8.1 and previous versions

تم وضع علامة على الوحدة التي تم تنفيذها دون أي من المشكلات المذكورة سابقًا (حتى مع عدم وجود اختبارات متبقية) على الوحدة النمطية في التقرير الجديد.

الاستثناءات

  • لدى CtsNNAPITestCases مشكلة معروفة بسبب قيود linux/OS على الوسائط. يمكن إعادة تشغيل الوحدة بمعزل عن طريق run cts -m CtsNNAPITestCases مباشرةً.

كيف يمكنني تجنب الفشل في التحضير للاختبار خلف جدار الحماية الخاص بالشركة؟

تحاول كافة مجموعات الاختبار الآلي تنزيل ملفات وسائط CTS أو ملفات منطق الأعمال أثناء وقت التشغيل. في العديد من بيئات الشركات، يعد جدار الحماية والوكيل نموذجيًا، مما يؤدي إلى فشل إعداد الاختبار. قم بتنفيذ السطر التالي أو قم بإضافته إلى .profile (على Ubuntu).

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

هل أحتاج إلى بطاقة SIM لـ CTS لـ Secure Element؟

تعتمد ما إذا كانت هناك حاجة إلى بطاقة SIM للاختبار على فهم ما إذا كانت الميزة مدعومة في جهاز الاختبار.

  • إذا كان جهازك لا يحتاج إلى دعم وصول تطبيقات Android إلى العناصر الآمنة - سواء في UICC (على سبيل المثال، بطاقة SIM) التي يوزعها مشغلو شبكات الهاتف المحمول (شركات الجوال) أو المضمنة في الجهاز - فيمكنك تكوين بيان HIDL بحيث لا يتضمن عنصر android.hardware.secure_element HAL. في هذه الحالة، تقوم واجهة برمجة التطبيقات android.se.omapi.SEService.getReaders() API بالإبلاغ عن قائمة فارغة ويجتاز اختبار CTS تلقائيًا ويبلغ عن نجاح CTS.
  • إذا كان جهازك يحتاج إلى دعم وصول تطبيقات Android إلى أي من العناصر الآمنة - إما في UICC (على سبيل المثال، بطاقة SIM) التي يوزعها مشغلو شبكات الهاتف المحمول (شركات الجوال) أو المضمنة في الجهاز - فأنت بحاجة إلى تنفيذ العنصر الآمن بشكل صحيح واختباره في بيت. يوضح اختبار CTS للعنصر الآمن كيفية الاستعداد لتشغيل اختبارات CTS التي تضمن عمل حزمة android.se.omapi API المضافة في Android 9. نوصي أيضًا بإجراء اختبارات إضافية بنفسك نظرًا لأن تغطية اختبار CTS ضئيلة.

أين يمكنني الحصول على بطاقات SIM الخاصة بـ CTS لـ Secure Element؟

يمكنك التواصل مع بائع بطاقة SIM المفضل لديك.

لماذا تظهر بطاقة Orange SIM على شاشة القفل أثناء تنفيذ CTS مع مشاركة الرمز المميز؟

لا تبدأ حالة الاختبار لأن اختبار بطاقة SIM مقفل. قم بتعطيل قفل بطاقة SIM في **إعدادات قفل بطاقة SIM قبل تنفيذ CTS بتقسيم الرمز المميز.