การพัฒนา 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 Testing API ตรวจสอบ ทดสอบ แอปของคุณ และการทดสอบที่มีอยู่ในไดเรกทอรี cts/tests การทดสอบ CTS ส่วนใหญ่เป็นไปตามรูปแบบเดียวกันกับที่ใช้ในการทดสอบอื่นๆ ของ Android

CTS ทำงานในอุปกรณ์เวอร์ชันที่ใช้งานจริงจำนวนมาก การทดสอบจึงต้องเกิดขึ้นตามมา กฎเหล่านี้

• พิจารณาขนาดหน้าจอ การวางแนว และรูปแบบแป้นพิมพ์ที่แตกต่างกัน
• ใช้เฉพาะเมธอด API สาธารณะเท่านั้น กล่าวคือ ให้หลีกเลี่ยงชั้นเรียน วิธีการ และฟิลด์ทั้งหมด ด้วยคำอธิบายประกอบ hide
• หลีกเลี่ยงการใช้เลย์เอาต์มุมมองหรือยึดตามขนาดของชิ้นงานซึ่งอาจไม่ได้อยู่ในบางรายการ อุปกรณ์
• อย่าพึ่งพาสิทธิพิเศษระดับรูท

เพิ่มคำอธิบายประกอบ Java

หากการทดสอบยืนยันลักษณะการทำงานของ API ให้ใส่คำอธิบายประกอบในโค้ดทดสอบด้วย @ApiTest และแสดงรายการ API ทั้งหมดที่เกี่ยวข้องในฟิลด์ apis ใช้รูปแบบที่เหมาะสมจาก ตัวอย่างต่อไปนี้

ประเภท API	รูปแบบคำอธิบายประกอบ	หมายเหตุ
วิธีการ	android.example.ClassA#methodA	Use Case ที่พบบ่อยที่สุด
เมธอดที่มีค่าคีย์	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 ซึ่งเป็นส่วนหนึ่งของ กระบวนการส่งข้อมูล 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
• ชื่อโมดูล (CTS v2 เท่านั้น)
  CTS v2 จัดระเบียบการทดสอบตามโมดูล ชื่อโมดูลมักจะเป็นสตริงที่สองของชื่อแพ็กเกจ Java (ใน เช่น widget)

โครงสร้างไดเรกทอรีและโค้ดตัวอย่างขึ้นอยู่กับว่าคุณใช้ CTS v1 หรือไม่ หรือ CTS v2

CTS 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

CTS เวอร์ชัน 2

สำหรับ 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 v1

หากคุณใช้ CTS v1 ให้ดูตัวอย่างใน cts/tests/tests/example และสร้างไดเรกทอรีใหม่ และ ตรวจสอบว่าได้เพิ่มชื่อโมดูลของแพ็กเกจใหม่จาก Android.mk แล้ว ถึง CTS_COVERAGE_TEST_CASE_LIST นิ้ว cts/CtsTestCaseList.mk build/core/tasks/cts.mk ใช้ไฟล์รูปแบบนี้ เพื่อรวมการทดสอบทั้งหมดและสร้างแพ็กเกจ CTS สุดท้าย

CTS เวอร์ชัน 2

ใช้การทดสอบตัวอย่าง /cts/tests/sample/ เพื่อเริ่มต้นโมดูลการทดสอบใหม่อย่างรวดเร็วด้วยขั้นตอนต่อไปนี้

1. หากต้องการสร้างไดเรกทอรีทดสอบและคัดลอกไฟล์ตัวอย่าง ให้เรียกใช้คำสั่งต่อไปนี้

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. ไปที่ cts/tests/module-name และแทนที่อินสแตนซ์ทั้งหมดของ "[Ss]เพียงพอ" พร้อมด้วย แบบแผนการตั้งชื่อที่แนะนำจากด้านบน
3. อัปเดต SampleDeviceActivity เพื่อใช้ฟีเจอร์ที่คุณกำลังทดสอบ
4. อัปเดต SampleDeviceTest เพื่อให้กิจกรรมสำเร็จหรือบันทึก ข้อผิดพลาด

ไดเรกทอรีเพิ่มเติม

ไดเรกทอรี Android อื่นๆ เช่น assets, jni, นอกจากนี้ คุณยังเพิ่ม libs และ res ได้ด้วย วิธีเพิ่มรหัส JNI สร้างไดเรกทอรีในรูทของโปรเจ็กต์ถัดจาก src ด้วยโฆษณาเนทีฟ และมีไฟล์ประเภท Android.mk อยู่ในนั้น

โดยปกติไฟล์จะมีการตั้งค่าต่อไปนี้

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 โปรดดู กำหนดการเผยแพร่และข้อมูลสาขาสำหรับรายการของ สาขาและข้อมูลเส้นทางการผสานอัตโนมัติ
• สำหรับการเปลี่ยนแปลงที่เฉพาะเจาะจงกับระดับ API เฉพาะ ให้พัฒนาหรือเลือกเฉพาะ การเปลี่ยนแปลงใน Branch ทดสอบที่ถูกต้องโดยมี DO NOT Merge หรือ จำกัดอัตโนมัติในข้อความคอมมิต

ทำตามเวิร์กโฟลว์การส่งแพตช์เพื่อมีส่วนร่วมในการเปลี่ยนแปลง CTS เราจะกำหนดให้ผู้ตรวจสอบตรวจสอบการเปลี่ยนแปลงของคุณตามนั้น

กําหนดการเผยแพร่และข้อมูลสาขา

โดย CTS จะปล่อยตามกำหนดการนี้

เวอร์ชัน	ระดับ API	สาขา	ความถี่
15	35	Android15-tests-dev	รายไตรมาส
14	34	Android14-tests-dev	รายไตรมาส
13	33	Android13-tests-dev	รายไตรมาส
12 ลิตร	32	Android12L-tests-dev	รายไตรมาส
12	31	Android12-tests-dev	รายไตรมาส

กำหนดการที่สำคัญระหว่างการเปิดตัว

• สิ้นสุดสัปดาห์แรก: โค้ดค้าง รวมการเปลี่ยนแปลงใน Branch แล้ว จนกว่าจะมีการระงับโค้ดสำหรับ CTS เวอร์ชันที่กำลังจะเปิดตัว การส่งผลงานไปยังสาขาหลังจากที่รหัสถูกระงับแล้ว หรือหลังจากผู้สมัครรับเลือกตั้ง มีการเลือกผลงานไว้ และจะพิจารณาสำหรับรุ่นต่อๆ ไป
• สัปดาห์ที่ 2 หรือ 3: 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) ผสานรวมอย่างไม่ถูกต้อง ระบบจะส่งผู้เขียนแพตช์ อีเมลพร้อมวิธีการแก้ไขความขัดแย้งดังกล่าว ส่วนใหญ่ ผู้เขียนแพตช์สามารถใช้คำแนะนำเพื่อข้ามการรวมอัตโนมัติ CL ที่ขัดแย้งกัน

หากสาขาที่เก่ากว่าต้องมีการเปลี่ยนแปลง แพตช์นั้นจะต้อง เลือก cherry จากสาขาที่ใหม่กว่า