تطوير CTS ، تطوير 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 عبر العديد من أجهزة الإنتاج، لذا يجب أن تتبع الاختبارات القواعد التالية:

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

إضافة تعليق جافا

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

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

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

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

سي تي اس v1

لنظام 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

سي تي اس v2

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

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

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

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

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

سي تي اس v1

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

سي تي اس v2

استخدم نموذج الاختبار /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، اختر فرع التطوير الخاص بك بناءً على مستويات واجهة برمجة التطبيقات (API) التي ينطبق عليها التصحيح.

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

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

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

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

إصدار مستوى واجهة برمجة التطبيقات فرع تكرار
14 34 android14-اختبارات-ديف ربعي
13 33 android13-اختبارات-ديف ربعي
12 لتر 32 android12L-اختبارات-ديف ربعي
12 31 android12-اختبارات-ديف ربعي
11 30 android11-اختبارات-ديف ربعي
لم يتم التخطيط لإصدارات أخرى للإصدارات 10.0، 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 .

تدفق الدمج التلقائي

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

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

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

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

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