تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تطوير CTS

إعداد برنامج Repo

اتّبِع التعليمات الواردة في مقالة تنزيل رمز المصدر للحصول على رمز مصدر Android وإنشاءه. عند إصدار الأمر repo init، حدِّد فرع CTS معيّنًا باستخدام -b. يضمن ذلك تضمين تغييرات CTS في إصدارات CTS اللاحقة.

يوضّح مثال الرمز البرمجي التالي كيفية استخدام repo init.

mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8

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

نفِّذ الأوامر التالية لإنشاء CTS وبدء كونسول CTS التفاعلي:

ملاحظة: يمكنك استخدام aosp_x86_64 كبديل لرمز aosp_arm64.

إصدار CTS (AOSP 14 أو إصدار سابق)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

إنشاء CTS (AOSP 15 أو إصدار أحدث)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

يُرجى الرجوع إلى الجدول التالي لاختيار قيمة target-release:

Branch	الإصدار المستهدَف
android15-tests-dev	ap3a

في وحدة تحكّم CTS، أدخِل:

tf> run cts --plan CTS

كتابة اختبارات CTS

تستخدِم اختبارات CTS حزمة JUnit وواجهات برمجة تطبيقات اختبار Android. راجِع الدليل التعليمي لموضوع اختبار تطبيقك والاختبارات الحالية ضمن الدليل cts/tests. تلتزم اختبارات CTS في الغالب بالاصطلاحات نفسها المستخدَمة في اختبارات Android الأخرى.

يتم تنفيذ اختبارات CTS على العديد من الأجهزة العلنية، لذا يجب أن تلتزم الاختبارات بالقواعد التالية:

يجب مراعاة أحجام الشاشات واتجاهاتها وتخطيطات لوحات المفاتيح المختلفة.
استخدِم طرق واجهة برمجة التطبيقات المتاحة للجميع فقط. بعبارة أخرى، تجنَّب جميع الفئات والطُرق والحقول التي تحتوي على التعليق التوضيحي hide.
تجنَّب استخدام تنسيقات العرض أو الاعتماد على سمات مواد العرض التي قد لا تكون متوفّرة على بعض الأجهزة.
لا تعتمد على امتيازات الجذر.

إضافة تعليق توضيحي في Java

إذا كان اختبارك يتحقق من سلوك واجهة برمجة التطبيقات، أضِف تعليقًا توضيحيًا إلى رمز الاختبار باستخدام @ApiTest وأدرِج جميع واجهات برمجة التطبيقات المعنيّة في حقل apis. استخدِم التنسيق المناسب من بين المثالين التاليين:

نوع واجهة برمجة التطبيقات	تنسيق التعليق التوضيحي	ملاحظات
الطريقة	`android.example.ClassA#methodA`	حالة الاستخدام الأكثر شيوعًا.
طريقة تحتوي على قيم مفاتيح	`android.example.ClassB#methodB(KeyA)`	لا تستخدِم هذه الطريقة إلا عندما يستخدم اختبارك طريقة واجهة برمجة تطبيقات للتحقّق من صحة حقل، كما هو موضّح في هذا المثال.
الحقل	android.example.ClassC#FieldA	لا تستخدِم هذه الطريقة إلا عندما يُجري الاختبار عملية التحقّق من حقل واجهة برمجة التطبيقات مباشرةً، كما هو موضّح في هذا المثال.

إذا كان اختبارك يتحقق من متطلبات CDD، أضِف تعليقًا توضيحيًا على معرّف المتطلّب (بما في ذلك معرّف القسم في CDD ومعرّف المتطلّب) باستخدام @CddTest في رمز اختبار CTS كما هو موضّح في المثال التالي. في رسالة الإضافة، اذكر متطلبات CDD التي يتم اختبارها من خلال الاختبار من خلال الإشارة إلى أرقام تعريف متطلبات CDD. تتألف معرّفات متطلبات CDD من معرّف القسم ومعرّف المتطلّب، مع ربطهما بشرطة مائلة (/) كما في 7.3.1/C-1-1.


/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
    @CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
    public void testAddPasspointConfigWithUserCredential() throws Exception {
        if (!WifiFeature.isWifiSupported(getContext())) {
            // skip the test if WiFi is not supported
            return;
        }      testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
    }

بالنسبة إلى أداة التحقّق من CTS، أضِف تعليقًا توضيحيًا لكل نشاط في AndroidManifest.xml باستخدام معرّف CDD ذي الصلة. تشبه تنسيقات حقول القيم تنسيقات التعليقات التوضيحية في Java في CTS. في رسالة المراجعة، اذكر متطلّبات CDD التي يتم فرضها من خلال الإشارة إلى رقم تعريف متطلّبات CDD.


  <activity>
    ......
    <!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
    <meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />

    <!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
    <meta-data android:name="api_test"
               android:value="com.example.MyClass#myMethod" />

    <!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
    <meta-data android:name="non_compliance_test"
               android:value="detailed reasons" />
  </activity>

في رسالة الإتمام

يُرجى الإشارة بوضوح إلى سبب الحاجة إلى إضافة الاختبار، وإضافة روابط ذات صلة للحصول على الدعم. بالنسبة إلى اختبارات CTS-D ، يجب تضمين رابط إلى اقتراح الاختبار الذي أنشأته في أداة "تتبُّع المشاكل" من Google كجزء من عملية إرسال CTS-D.

إنشاء خطة فرعية

على سبيل المثال، يمكنك إضافة ملف SubPlan.xml في android-cts/subplans على النحو التالي:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<SubPlan version="2.0">
<Entry include="CtsSystemIntentTestCases" />
<Entry include="CtsSystemUiHostTestCases" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" />
</SubPlan>

لتشغيل الخطة الفرعية:

run cts --subplan aSubPlan

تنسيق إدخال الخطة الفرعية هو:

Include a module name as follows:
<Entry include="MODULE_NAME" />

Include a package:
<Entry include="MODULE_NAME PACKAGE_NAME" />

Include a class:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" />

Include an individual test:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />

اسم الاختبار وموقعه الجغرافي

تستهدف معظم حالات اختبار CTS فئة معيّنة في Android API. تتضمّن هذه الاختبارات أسماء حِزم Java التي تحتوي على اللاحقة cts وأسماء فئات تحتوي على اللاحقة Test. تتكوّن كل حالة اختبار من اختبارات متعددة، حيث ينفِّذ كل اختبار عادةً طريقة معيّنة من الفئة التي يتم اختبارها. يتم ترتيب هذه الاختبارات في بنية دليل يتم فيها تجميع الاختبارات في катеجوريات مختلفة، مثل "تطبيقات المصغّرة" أو "طرق العرض".

على سبيل المثال، اختبار CTS لحزمة Java android.widget.TextView هو android.widget.cts.TextViewTest مع اسم حزمة Java هو android.widget.cts واسم الفئة هو TextViewTest.

اسم حزمة Java
اسم حزمة Java لاختبارات CTS هو اسم حزمة الفئة التي يختبرها الاختبار، متبوعًا بعلامة .cts. في مثالنا، سيكون اسم الحزمة هو android.widget.cts.
اسم الفئة
اسم فئة اختبارات CTS هو اسم الفئة التي يتم اختبارها مع إلحاق "اختبار" بها. على سبيل المثال، إذا كان الاختبار يستهدف TextView، يجب أن يكون اسم الفئة هو TextViewTest.
اسم الوحدة (الإصدار 2 من CTS فقط)
يُنظِّم الإصدار 2 من CTS الاختبارات حسب الوحدة. يكون اسم الوحدة عادةً السلسلة الثانية من اسم حزمة Java (widget في مثالنا).

تعتمد بنية الدليل ونموذج الرمز على ما إذا كنت تستخدم الإصدار 1 من CTS أم الإصدار 2.

الإصدار 1 من CTS

بالنسبة إلى الإصدار 6.0 من نظام التشغيل Android أو الإصدارات الأقدم، استخدِم الإصدار 1 من CTS. بالنسبة إلى الإصدار 1 من CTS، يمكنك العثور على الرمز النموذجي على الرابط cts/tests/tests/example.

تظهر بنية الدليل في اختبارات الإصدار 1 من CTS على النحو التالي:

cts/
  tests/
    tests/
      package-name/
        Android.mk
        AndroidManifest.xml
        src/
          android/
            package-name/
              SampleDeviceActivity.java
              cts/
                SampleDeviceTest.java

الإصدار 2 من CTS

بالنسبة إلى الإصدار 7.0 من Android أو الإصدارات الأحدث، استخدِم الإصدار 2 من CTS. لمعرفة التفاصيل، يُرجى الاطّلاع على الاختبار النموذجي في "مشروع Android المفتوح المصدر" (AOSP).

تظهر بنية دليل CTS v2 على النحو التالي:

cts/
  tests/
    module-name/
      Android.mk
      AndroidManifest.xml
      src/
        android/
          package-name/
            SampleDeviceActivity.java
            cts/
              SampleDeviceTest.java

حِزم نماذج جديدة

عند إضافة اختبارات جديدة، قد لا يتوفّر دليل حالي لوضع اختبارك فيه. في هذه الحالات، عليك إنشاء الدليل ونسخ عيّنات الملفات المناسبة.

الإصدار 1 من CTS

إذا كنت تستخدم الإصدار 1 من CTS، راجِع المثال ضمن cts/tests/tests/example وأنشئ دليلاً جديدًا. بالإضافة إلى ذلك، احرص على إضافة اسم وحدة الحزمة الجديدة من Android.mk إلى CTS_COVERAGE_TEST_CASE_LIST في cts/CtsTestCaseList.mk. يستخدم build/core/tasks/cts.mk ملف makefile هذا لدمج جميع الاختبارات وإنشاء حزمة CTS النهائية.

الإصدار 2 من CTS

استخدِم نموذج الاختبار /cts/tests/sample/ لبدء وحدة الاختبار الجديدة بسرعة من خلال اتّباع الخطوات التالية:

لإنشاء الدليل التجريبي ونسخ نماذج الملفات، شغِّل:
```
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
```
انتقِل إلى cts/tests/module-name واستبدِل جميع مثيلات "[Ss]ample" باستخدام اصطلاح التسمية المقترَح من أعلاه.
عدِّل SampleDeviceActivity لاستخدام الميزة التي تختبرها.
عدِّل SampleDeviceTest لضمان نجاح النشاط أو تسجيله لأخطائه.

الأدلة الإضافية

يمكن أيضًا إضافة أدلة Android الأخرى، مثل assets وjni libs وres. لإضافة رمز JNI، أنشئ دليلاً في جذر المشروع بجانب src يحتوي على رمز الأصلي وملف Android.mk makefile.

يحتوي ملف الإنشاء عادةً على الإعدادات التالية:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libCtsSample_jni

# don't include this package in any target
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := list of source code files
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)

# Tag this module as a cts test artifact
LOCAL_COMPATIBILITY_SUITE := cts
LOCAL_SHARED_LIBRARIES := libnativehelper
LOCAL_SDK_VERSION := current
include $(BUILD_SHARED_LIBRARY)

ملف Android.mk

أخيرًا، عدِّل ملف Android.mk في جذر project لإنشاء الرمز الأصلي والاعتماد عليه، كما هو موضّح أدناه:

# All tests should include android.test.runner.
LOCAL_JAVA_LIBRARIES := android.test.runner

# Includes the jni code as a shared library
LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni

# Include for InstrumentationCtsTestRunner
LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner...
LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE)

#Tells make to look in subdirectories for more make files to include
include $(call all-makefiles-under,$(LOCAL_PATH))

إصلاح الاختبارات أو إزالتها

بالإضافة إلى إضافة اختبارات جديدة، يمكنك إصلاح الاختبار أو إزالته إذا كان مُشارَكًا عليه تعليقًا توضيحيًا باستخدام BrokenTest أو KnownFailure.

إرسال التغييرات

عند إرسال تصحيحات CTS أو VTS في AOSP، اختَر فرع التطوير استنادًا إلى مستويات واجهة برمجة التطبيقات التي ينطبق عليها التصحيح.

بالنسبة إلى التغييرات التي تنطبق على مستويات متعددة من واجهة برمجة التطبيقات، أولاً، أنشئ تصحيحًا في aosp/main، ثم اختَر العناصر التي تريدها لإضافتها إلى الفرع الأعلى في الاختبار. اسمح للدمج التلقائي بدمج التغييرات في الإصدارات اللاحقة في فروع اختبار AOSP. اطّلِع على جدول الإصدار ومعلومات الفرع للحصول على قائمة الفروع ومعلومات مسار الدمج التلقائي.
بالنسبة إلى التغييرات الخاصة بمستوى معيّن لواجهة برمجة التطبيقات، يمكنك تطوير التغييرات أو اختيارها بعناية وإضافتها إلى فرع الاختبار الصحيح باستخدام عدم دمج أو تقييد الدمج التلقائي في رسالة الإضافة.

اتّبِع خطوات إرسال الرقع للمساهمة في التغييرات على CTS. سيتم تعيين مراجع لمراجعة التغيير الذي أجريته وفقًا لذلك.

الجدول الزمني للإصدار ومعلومات الفرع

تتّبع إصدارات CTS هذا الجدول الزمني.

الإصدار	مستوى واجهة برمجة التطبيقات	Branch	التردد
15	35	android15-tests-dev	ربع سنوي
14	34	android14-tests-dev	ربع سنوي
13	33	android13-tests-dev	ربع سنوي
‫12L	32	android12L-tests-dev	ربع سنوي
12	31	android12-tests-dev	ربع سنوي

التواريخ المهمة أثناء الإصدار

نهاية الأسبوع الأول: تجميد الرموز البرمجية يتمّ النظر في التغييرات التي تمّ دمجها في الفرع إلى أن يتمّ تجميد الرمز البرمجي للإصدار القادم من CTS. إنّ المراجعات التي يتم إرسالها إلى الفرع بعد تجميد الرموز البرمجية أو بعد اختيار إصدار مرشح للنشر تُعتبر للإصدار اللاحق.
الأسبوع الثاني أو الثالث: يتم نشر CTS في AOSP.

مسار الدمج التلقائي

تم إعداد فروع تطوير CTS لكي يتم دمج التغييرات التي يتم إرسالها إلى كل فرع تلقائيًا مع الفروع الأعلى.

بالنسبة إلى التغييرات التي يتم إجراؤها مباشرةً على فرع التطوير والاختبار في AOSP، يكون مسار الدمج التلقائي على النحو التالي:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

بالنسبة إلى التغييرات على إصدار Android التالي فقط، يكون مسار الدمج التلقائي على النحو التالي:
aosp-main > <Internal git_main>.

إذا تعذّر دمج قائمة التغييرات (CL) بشكل صحيح، يتم إرسال رسالة إلكترونية إلى مؤلف التصحيح تتضمّن تعليمات حول كيفية حلّ التعارض. في معظم الحالات، يمكن لمؤلف التصحيح استخدام التعليمات لتخطّي الدمج التلقائي للطلب المتضارب.

إذا كان الفرع الأقدم يتطلّب إجراء التغيير، يجب أولاً اختيار التصحيح من الفرع الأحدث.