การพัฒนา CTS

เริ่มต้นไคลเอ็นต์ Repo ของคุณ

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

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

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

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

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

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

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

หากการทดสอบของคุณตรวจสอบข้อกำหนด CDD ให้ใส่คำอธิบายประกอบ ID ข้อกำหนด (รวมถึง ID ส่วน CDD และ ID ความต้องการ) ด้วย @CddTest ในโค้ดทดสอบ CTS ดังที่แสดงในตัวอย่างต่อไปนี้ ในข้อความยืนยันของคุณ ให้ระบุว่าข้อกำหนด CDD ใดที่ได้รับการทดสอบโดยการทดสอบของคุณโดยอ้างอิงถึง ID ข้อกำหนด 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 ID ที่เกี่ยวข้อง รูปแบบของฟิลด์ค่าจะคล้ายกับรูปแบบของคำอธิบายประกอบ Java ใน CTS ในข้อความคอมมิต ให้ระบุว่าข้อกำหนด CDD ใดที่บังคับใช้โดยอ้างอิง ID ข้อกำหนด 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 คือชื่อของคลาสที่กำลังทดสอบโดยต่อท้าย "Test" ตัวอย่างเช่น หากการทดสอบกำหนดเป้าหมายไปที่ 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 ใช้ makefile นี้เพื่อรวมการทดสอบทั้งหมดและสร้างแพ็คเกจ 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 หรือ VTS ใน AOSP ให้เลือกสาขาการพัฒนาของคุณตามระดับ API ที่จะนำไปใช้กับแพตช์

• สำหรับการเปลี่ยนแปลงที่ใช้กับ API หลายระดับ ขั้น แรก ให้พัฒนาแพตช์ใน aosp/main จากนั้นเลือกเชอร์รี่ไปที่ สาขาการทดสอบอัปสตรีมที่สุด อนุญาตให้บริษัทรวมตัวกันอัตโนมัติรวมการเปลี่ยนแปลงดาวน์สตรีมในสาขาการทดสอบ AOSP ดู กำหนดการเผยแพร่และข้อมูลสาขา สำหรับรายชื่อสาขาและข้อมูลเส้นทางการรวมอัตโนมัติ
• สำหรับการเปลี่ยนแปลงที่เฉพาะเจาะจงกับระดับ API เฉพาะ ให้พัฒนาหรือเลือกการเปลี่ยนแปลงในสาขาการทดสอบที่ถูกต้องด้วย DO NOT MERGE หรือ RESTRICT AUTOMERGE ในข้อความคอมมิต

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

กำหนดการวางจำหน่ายและข้อมูลสาขา

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

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

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

กระแสการผสานอัตโนมัติ

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

สำหรับการเปลี่ยนแปลงโดยตรงกับสาขา AOSP test dev เส้นทางการรวมอัตโนมัติคือ:
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 ที่ขัดแย้งกันโดยอัตโนมัติ

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