การพัฒนา CTS

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

ทำตามวิธีการจากการดาวน์โหลดแหล่งที่มาเพื่อรับ และสร้างซอร์สโค้ด 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 แบบอินเทอร์แอกทีฟ

สร้าง 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

สาขา การเผยแพร่เป้าหมาย
android15-tests-dev ap3a

เรียกใช้ CTS

ในคอนโซล 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 กรณีการใช้งานที่พบบ่อยที่สุด
เมธอดที่มีค่าคีย์ 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
    ชื่อแพ็กเกจ 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 อยู่ในนั้น

โดยทั่วไปแล้ว 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 ที่แพตช์ ใช้
  • พัฒนาหรือเลือก การเปลี่ยนแปลงไปยังกิ่งก้านการทดสอบที่ถูกต้องด้วย DO NOT MERGE หรือ RESTRICT AUTOMERGE ในข้อความคอมมิต

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

กำหนดการเปิดตัวและข้อมูลสาขา

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

เวอร์ชัน ระดับ API สาขาการพัฒนา ความถี่ในการเผยแพร่
16+ 36+ Gerrit ภายใน รายไตรมาส
15 35 android15-tests-dev รายไตรมาส
14 34 android14-tests-dev รายไตรมาส
13 33 android13-tests-dev รายไตรมาส

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

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

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

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

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

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

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

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

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