การพัฒนา 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 และ Android Testing API โปรดอ่านบทแนะนำ Test your app และ การทดสอบที่มีอยู่ในไดเรกทอรี 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 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
  ชื่อแพ็กเกจ 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 โดยมีโค้ดเนทีฟและ MakeFile 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 ที่ แพตช์ใช้
• พัฒนาหรือเลือก (Cherry-pick) การเปลี่ยนแปลงไปยังสาขาการทดสอบที่ถูกต้องโดยใช้ DO NOT MERGE หรือ RESTRICT AUTOMERGE ในข้อความคอมมิต

ระบบจะกำหนดผู้ตรวจสอบเพื่อตรวจสอบการเปลี่ยนแปลงของคุณและเลือก (Cherry-pick) การเปลี่ยนแปลงไปยัง Gerrit ภายใน ตามความเหมาะสม

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

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

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

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

โฟลว์การผสานรวมอัตโนมัติ

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

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

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

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

หากสาขาเก่ากว่าต้องมีการเปลี่ยนแปลง คุณจะต้องเลือก (Cherry-pick) แพตช์จากสาขาใหม่กว่า

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