การพัฒนา CTS

เริ่มต้นไคลเอ็นต์ Repo

ทำตามวิธีการจากการดาวน์โหลดซอร์สโค้ดเพื่อรับและสร้างซอร์สโค้ด Android เมื่อออกคําสั่ง repo init ให้ระบุสาขา CTS ที่เฉพาะเจาะจงโดยใช้ -b วิธีนี้ช่วยให้มั่นใจว่าการเปลี่ยนแปลง CTS ของคุณจะรวมอยู่ใน CTS รุ่นต่อๆ ไป

โค้ดตัวอย่างต่อไปนี้แสดงวิธีใช้ repo init

สร้างและเรียกใช้ CTS

เรียกใช้คําสั่งต่อไปนี้เพื่อสร้าง CTS และเริ่มคอนโซล CTS แบบอินเทอร์แอกทีฟ

บิลด์ 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

เรียกใช้ CTS

ในคอนโซล CTS ให้ป้อนข้อมูลต่อไปนี้

tf> run cts --plan CTS

เขียนการทดสอบ CTS

การทดสอบ CTS ใช้ JUnit และ API การทดสอบของ Android ตรวจสอบบทแนะนำทดสอบแอปและการทดสอบที่มีอยู่ในส่วนไดเรกทอรี cts/tests การทดสอบ CTS ส่วนใหญ่เป็นไปตามรูปแบบเดียวกับที่ใช้กับการทดสอบอื่นๆ ของ Android

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

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

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

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

หากการทดสอบยืนยันข้อกําหนด 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 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
  ชื่อแพ็กเกจ Java สำหรับการทดสอบ CTS คือชื่อแพ็กเกจของคลาสที่การทดสอบกำลังทดสอบ ตามด้วย .cts ในตัวอย่างนี้ ชื่อแพ็กเกจจะเป็น android.widget.cts
• ชื่อคลาส
  ชื่อคลาสสําหรับการทดสอบ CTS คือชื่อคลาสที่ทดสอบโดยต่อท้ายด้วย "Test" เช่น หากการทดสอบกําหนดเป้าหมายเป็น TextView ชื่อชั้นเรียนควรเป็น TextViewTest
• ชื่อโมดูล (CTS v2 เท่านั้น)
  CTS v2 จัดระเบียบการทดสอบตามโมดูล โดยปกติแล้วชื่อโมดูลจะเป็นสตริงที่ 2 ของชื่อแพ็กเกจ 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 v2

สำหรับ 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 ใช้ไฟล์ makefile นี้เพื่อรวมการทดสอบทั้งหมดและสร้างแพ็กเกจ CTS สุดท้าย

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

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

ระบบจะมอบหมายผู้ตรวจสอบให้ตรวจสอบการเปลี่ยนแปลงของคุณและเลือกการเปลี่ยนแปลงที่จะนำไปไว้ใน Gerrit ภายใน

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

การเผยแพร่ CTS จะเป็นไปตามกำหนดการนี้

วันสำคัญระหว่างการเผยแพร่

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

ขั้นตอนการผสานอัตโนมัติ

เราได้ตั้งค่าสาขาการพัฒนา CTS เพื่อให้การเปลี่ยนแปลงที่ส่งไปยังแต่ละสาขาผสานรวมกับสาขาที่สูงกว่าโดยอัตโนมัติ

สำหรับการเปลี่ยนแปลงในสาขานักพัฒนาซอฟต์แวร์การทดสอบ AOSP โดยตรง เส้นทางการผสานอัตโนมัติคือ
android13-tests-dev > android14-tests-dev > android15-tests-dev

• สำหรับ CTS เวอร์ชัน 16 ขึ้นไป ผู้ตรวจสอบจะเลือกการเปลี่ยนแปลงมาใส่ใน Gerrit ภายในตามความเหมาะสม

หากผสานรายการการเปลี่ยนแปลง (CL) ไม่สำเร็จ ระบบจะส่งอีเมลพร้อมวิธีการแก้ไขข้อขัดแย้งไปยังผู้เขียนแพตช์ ในกรณีส่วนใหญ่ ผู้เขียนแพตช์สามารถใช้วิธีการเพื่อข้ามการผสาน CL ที่ขัดแย้งกันโดยอัตโนมัติ

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

สำหรับการเปลี่ยนแปลงการทดสอบที่ใช้กับ Android เวอร์ชันถัดไป หลังจากที่คุณอัปโหลดการเปลี่ยนแปลงที่เสนอแล้ว Google จะตรวจสอบการเปลี่ยนแปลงดังกล่าว และหากยอมรับ ก็จะเลือกการเปลี่ยนแปลงนั้นมาไว้ใน Gerrit ภายใน