เริ่มต้นไคลเอ็นต์ 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 แบบโต้ตอบ:
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
ใช้รูปแบบที่เหมาะสมจากตัวอย่างต่อไปนี้:
ประเภทเอพีไอ | รูปแบบคำอธิบายประกอบ | หมายเหตุ |
---|---|---|
วิธี | android.example.ClassA#methodA | กรณีการใช้งานที่พบบ่อยที่สุด |
วิธีการที่มีค่าคีย์ | android.example.ClassB#methodB(KeyA) | ใช้เฉพาะเมื่อการทดสอบของคุณใช้วิธีการ API เพื่อตรวจสอบความถูกต้องของฟิลด์ ดังใน ตัวอย่างนี้ |
สนาม | android.example.ClassC#FieldA | ใช้เมื่อการทดสอบของคุณตรวจสอบฟิลด์ API โดยตรงตาม ตัวอย่างนี้ เท่านั้น |
หากการทดสอบของคุณตรวจสอบข้อกำหนด 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/
เพื่อเริ่มต้นโมดูลการทดสอบใหม่ของคุณอย่างรวดเร็วด้วยขั้นตอนต่อไปนี้:
- หากต้องการสร้างไดเร็กทอรีทดสอบและคัดลอกไฟล์ตัวอย่าง ให้รัน:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
- ไปที่
cts/tests/ module-name
และแทนที่อินสแตนซ์ทั้งหมดของ "[Ss]ample" ด้วย รูปแบบการตั้งชื่อที่แนะนำ จากด้านบน - อัปเดต
SampleDeviceActivity
เพื่อใช้ฟีเจอร์ที่คุณกำลังทดสอบ - อัปเดต
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 เป็นไปตามกำหนดการนี้
เวอร์ชัน | ระดับเอพีไอ | สาขา | ความถี่ |
---|---|---|---|
14 | 34 | android14-การทดสอบ-dev | รายไตรมาส |
13 | 33 | android13-การทดสอบ-dev | รายไตรมาส |
12ลิตร | 32 | android12L-การทดสอบ-dev | รายไตรมาส |
12 | 31 | android12-การทดสอบ-dev | รายไตรมาส |
11 | 30 | android11-การทดสอบ-dev | รายไตรมาส |
ไม่มีการวางแผนการเผยแพร่เพิ่มเติมสำหรับเวอร์ชัน 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 และ 4.2 |
วันสำคัญระหว่างการเปิดตัว
- สิ้นสุดสัปดาห์แรก: การหยุดโค้ด การเปลี่ยนแปลงที่ผสานในสาขาจนกระทั่งการหยุดโค้ดจะได้รับการพิจารณาสำหรับ 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 ที่ขัดแย้งกันโดยอัตโนมัติ
หากสาขาเก่าจำเป็นต้องทำการเปลี่ยนแปลง ก็จะต้องเลือกแพทช์จากสาขาที่ใหม่กว่า