تطوير CTS

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

جارٍ بدء عميل الريبو الخاص بك

اتبع التعليمات الواردة في تنزيل المصدر للحصول على شفرة مصدر 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:

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

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

tf> run cts --plan CTS

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

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

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

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

أضف تعليق Java التوضيحي

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

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

إذا كان اختبارك يتحقق من متطلبات العناية الواجبة ، فضع تعليقًا توضيحيًا على معرف المتطلبات (بما في ذلك معرف قسم CDD ومعرف المتطلبات) باستخدام @CddTest في كود اختبار CTS كما هو موضح في المثال التالي. في رسالة الالتزام الخاصة بك ، اذكر متطلبات العناية الواجبة التي يتم اختبارها من خلال اختبارك بالرجوع إلى معرفات متطلبات العناية الواجبة. معرفات متطلبات 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 Verifier ، قم بتعليق كل نشاط في AndroidManifest.xml الخاص بك بمعرف CDD ذي الصلة. تتشابه تنسيقات حقول القيمة مع تنسيقات تعليقات Java التوضيحية في CTS. في رسالة الالتزام ، اذكر متطلبات التحريات المسبقة عن العمالء التي يتم فرضها من خلال الرجوع إلى معرف متطلبات العناية الواجبة.


  <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 Issue Tracker كجزء من عملية إرسال 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 لاختبارات CTS هو اسم الحزمة للفئة التي يختبرها الاختبار ، متبوعًا بـ .cts . على سبيل المثال ، سيكون اسم الحزمة android.widget.cts .
  • اسم الفصل
    اسم الصنف لاختبارات CTS هو اسم الفصل الذي يتم اختباره مع ملحق "Test". على سبيل المثال ، إذا كان الاختبار يستهدف TextView ، فيجب أن يكون اسم الفئة TextViewTest .
  • اسم الوحدة (CTS v2 فقط)
    ينظم CTS v2 الاختبارات حسب الوحدة. عادةً ما يكون اسم الوحدة هو السلسلة الثانية من اسم حزمة Java (في مثالنا ، widget ).

تعتمد بنية الدليل وعينة التعليمات البرمجية على ما إذا كنت تستخدم CTS v1 أو CTS v2.

CTS الإصدار الأول

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

تبدو بنية الدليل في اختبارات CTS v1 كما يلي:

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

CTS الإصدار 2.0

لنظام التشغيل Android 7.0 أو أعلى ، استخدم CTS v2. للحصول على التفاصيل ، راجع نموذج الاختبار في مشروع Android مفتوح المصدر (AOSP) .

تبدو بنية دليل CTS v2 كما يلي:

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

حزم عينة جديدة

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

CTS الإصدار الأول

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

CTS الإصدار 2.0

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

  1. لإنشاء دليل الاختبار ونسخ ملفات العينة ، قم بتشغيل:
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. انتقل إلى cts/tests/ module-name واستبدل جميع مثيلات "[Ss] ample" باتفاقية التسمية الموصى بها أعلاه.
  3. قم بتحديث SampleDeviceActivity لممارسة الميزة التي تختبرها.
  4. قم بتحديث 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 في جذر المشروع لبناء الكود الأصلي والاعتماد عليه ، كما هو موضح أدناه:

# 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/master ثم انتقاء الكرز إلى أكثر فرع اختبار رئيسي. اسمح للمركب الآلي بدمج التغييرات المصب في فروع اختبار AOSP. راجع جدول الإصدار ومعلومات الفرع للحصول على قائمة الفروع ومعلومات مسار الدمج الآلي.
  • بالنسبة للتغييرات الخاصة بمستوى واجهة برمجة تطبيقات معين ، قم بتطوير أو اختيار التغييرات التي تم إجراؤها على فرع الاختبار الصحيح باستخدام عدم الدمج أو تقييد التشغيل التلقائي في رسالة الالتزام.

اتبع سير عمل إرسال التصحيحات للمساهمة بالتغييرات في CTS. سيتم تعيين مراجع لمراجعة التغيير الخاص بك وفقًا لذلك.

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

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

إصدار مستوى API فرع تكرار
13 33 android13-الاختبارات-ديف ربعي
12 لتر 32 android12L- الاختبارات- ديف ربعي
12 31 android12-الاختبارات-ديف ربعي
11 30 android11-الاختبارات-ديف ربعي
10 29 android10-Tests-dev ربعي
لم يتم التخطيط لإصدارات أخرى للإصدارات 9.0 و 8.1 و 8.0 و 7.1 و 7.0 و 6.0 و 5.1 و 5.0 و 4.4 و 4.3 و 4.2.

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

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

تدفق Automerge

تم إنشاء فروع تطوير CTS بحيث يتم دمج التغييرات المرسلة إلى كل فرع تلقائيًا في الفروع الأعلى.

لإجراء تغييرات مباشرة على فرع مطور اختبار AOSP ، يكون مسار الدمج التلقائي هو:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > aosp/master

لإجراء تغييرات فقط على إصدار Android التالي ، يكون مسار الدمج التلقائي هو:
aosp/master > <private-development-branch for Android 14 (AOSP experimental)> .

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

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