โปรแกรมความเข้ากันได้กับอุปกรณ์ Android เป็นปัจจัยหลักในการคงผลตอบรับเชิงบวกสำหรับระบบนิเวศของ Android CTS เป็นเครื่องมือสําคัญในการตรวจสอบคุณภาพของความเข้ากันได้ในวงกว้าง ทีม Android ยังคงปรับปรุงเครื่องมือ CTS และการครอบคลุมการทดสอบอย่างต่อเนื่อง การเพิ่มกรณีทดสอบเป็นประจำช่วยปรับปรุงคุณภาพของอุปกรณ์ที่เข้ากันได้ได้อย่างมาก
คำถามทั่วไป
ส่วนนี้จะแสดงคําถามที่พบบ่อยทั่วไปเกี่ยวกับ CTS
CTS ทดสอบสิ่งใดบ้าง
CTS จะทดสอบว่า API แบบ Strong Type ทั้งหมดที่รองรับของ Android มีอยู่และทํางานอย่างถูกต้อง CTS ยังทดสอบลักษณะการทํางานของระบบที่ไม่ใช่ API อื่นๆ ด้วย เช่น วงจรชีวิตของแอปและประสิทธิภาพ
CTS ได้รับอนุญาตให้ใช้งานอย่างไร
CTS ได้รับอนุญาตภายใต้สัญญาอนุญาตซอฟต์แวร์ Apache 2.0 เดียวกับที่ Android ส่วนใหญ่ใช้
โค้ดเหล่านี้ได้รับการยืนยันโดย CTS หรือไม่
ได้ CTS จะยืนยันตัวแปลงรหัสที่จำเป็นทั้งหมด
คำถามเฉพาะสำหรับแต่ละข้อสอบ
ส่วนนี้แสดงคําถามที่พบบ่อยซึ่งช่วยให้การทดสอบ CTS มีประสิทธิภาพมากขึ้น
การแยกกลุ่ม CTS กับการแยกกลุ่ม TF แตกต่างกันอย่างไร
การแยกกลุ่ม CTS และการแยกกลุ่ม TF เป็นแผนการทดสอบที่แตกต่างกันโดยสิ้นเชิง ซึ่งขับเคลื่อนโดยโค้ดเบสโครงสร้างพื้นฐานการทดสอบที่แตกต่างกัน แม้ว่าคำสั่ง run จะเหมือนกันในเวอร์ชันต่างๆ แต่ผลลัพธ์การแยกข้อมูลจะทำงานแตกต่างกัน การแยกกลุ่ม CTS จะกำหนดกรณีทดสอบให้กับอุปกรณ์ทดสอบ (DUT) แบบคงที่ ดังนี้
- คำสั่ง: run cts
- การกําหนดค่าสําหรับ Android 8.1 และเวอร์ชันที่ต่ำกว่า /tools/cts-tradefed/res/config/cts.xml
การแยกกลุ่ม TF จะกำหนดกรณีทดสอบให้กับ DUT ที่พร้อมใช้งานแบบไดนามิก ดังนี้
- คำสั่ง: run cts
- การกําหนดค่าสําหรับ Android 9: /platform/test/suite_harness/+/pie-cts-dev/tools/cts-tradefed/res/config/cts-suite.xml
อุปกรณ์ที่รองรับ ABI หลายรายการจะทำงานอย่างไร
อุปกรณ์ต้องผ่านการทดสอบ CTS และ CTS Verifier ทั้งหมดสำหรับโหมด ABI แต่ละโหมดที่อ้างว่ารองรับ ดังนั้นจึงจำเป็นต้องเรียกใช้แอปสำหรับ ABI บางรายการ หลักเกณฑ์สำหรับ ABI หลายรายการมีดังนี้
- สำหรับ CTS และ CTS Verifier จะมีรุ่น ARM และ x86 สำหรับสถาปัตยกรรมแต่ละแบบ โดยแต่ละเวอร์ชันจะรองรับโหมด 32 หรือ 64 บิต
- สำหรับข้อกำหนดการทดสอบ CTS หากอุปกรณ์รองรับทั้ง ARM และ x86 อุปกรณ์จะต้องรันและผ่านข้อกำหนดการทดสอบ CTS ทั้ง ARM และ x86 ตามลำดับ
โปรดดู CDD 3.3.1 อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน สำหรับข้อกำหนด CDD เกี่ยวกับ ABI
การทดสอบเฉพาะ ABI หลัก (เช่น 64 บิต) เพื่อลดเวลาในการเรียกใช้การทดสอบเพียงพอไหม
ไม่ แอป Android ทำงานบนรันไทม์ 32 บิตหรือ 64 บิตของตนเอง รหัสเครื่อง เส้นทางโค้ด และสถานะจริงจะแตกต่างกันไประหว่าง 32 ถึง 64 หากข้าม 1 โหมด คุณจะครอบคลุม ABI ของอุปกรณ์เพียง 50%
เหตุใดจึงมีการรายงาน Test Case จำนวนมากว่า "ไม่ได้ดำเนินการ"
คุณควรตรวจสอบหมายเลขข้อบังคับที่เสร็จสิ้นแทนหมายเลขไม่ได้ดำเนินการ
ในเวอร์ชันก่อนหน้านี้ ระบบจะรายงานโมดูล CTS เป็นโมดูลเสร็จสิ้นเร็วเกินไปก่อนที่จะเสร็จสมบูรณ์ ดังนั้น ระบบจึงรายงานจํานวนข้อบังคับที่เสร็จสมบูรณ์โดยที่กรณีทดสอบยังไม่เสร็จสมบูรณ์ทั้งหมด แม้ว่าอุปกรณ์บางเครื่องจะมีปัญหาก็ตาม ชุดทดสอบใหม่จะอนุรักษ์นิยมมากขึ้นและรายงานการทดสอบที่ไม่ได้ดำเนินการจํานวนมากขึ้นเมื่อเกิดปัญหา
โมดูลที่ทํางานจนเสร็จสมบูรณ์จะรายงานโมดูลไม่เสร็จสิ้นในการเรียกใช้ครั้งล่าสุด (done="false") ในรายงานในช่วงต่อไปนี้
- การทดสอบโมดูลถูกขัดจังหวะเนื่องจากปัญหาการเชื่อมต่ออุปกรณ์
- ไม่ได้ทำการทดสอบที่คาดไว้ทั้งหมดสําหรับข้อบังคับ
ลองอีกครั้ง (ใช้ตัวเลือก
-r/--retry
) ด้วยตัวเลือกการกรองเพิ่มเติม เช่น- --include-filter
- --exclude-filter
- -t/--test (ตัวเลือกยังไม่รองรับในการลองอีกครั้ง)
- --retry-type ไม่สําเร็จ
- --subplan
หากต้องการดูสถานะโมดูลเสร็จสิ้น (done="true") สําหรับโมดูลเหล่านี้ ให้ลองดำเนินการต่อไปนี้อีกครั้งสําหรับการเรียกใช้ล่าสุด
run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions
โมดูลที่ทำงานโดยไม่มีปัญหาใดๆ ที่กล่าวถึงก่อนหน้านี้ (แม้ว่าจะมีการทดสอบเหลือ 0 รายการ) จะมีการทำเครื่องหมายเป็นโมดูลเสร็จสิ้นในรายงานใหม่
ข้อยกเว้น
- CtsNNAPITestCases มีปัญหาที่ทราบเนื่องจากข้อจํากัดของอาร์กิวเมนต์ใน Linux/OS
คุณสามารถเรียกใช้โมดูลแยกต่างหากได้ผ่าน
run cts -m CtsNNAPITestCases
โดยตรง
ฉันจะหลีกเลี่ยงการเตรียมการทดสอบที่ไม่สำเร็จหลังไฟร์วอลล์ของบริษัทได้อย่างไร
ชุดทดสอบอัตโนมัติทั้งหมดจะพยายามดาวน์โหลดไฟล์สื่อ CTS หรือไฟล์ตรรกะทางธุรกิจในระหว่างรันไทม์ ในสภาพแวดล้อมขององค์กรหลายแห่ง ไฟร์วอลล์และพร็อกซีเป็นสิ่งปกติ ซึ่งทําให้การเตรียมการทดสอบไม่สําเร็จ เรียกใช้บรรทัดต่อไปนี้หรือเพิ่มลงใน .profile (ใน Ubuntu)
export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'
ฉันต้องใช้ซิมการ์ดสำหรับ CTS สำหรับองค์ประกอบความปลอดภัยไหม
ความจำเป็นในการใช้ซิมการ์ดสำหรับการทดสอบขึ้นอยู่กับความเข้าใจว่าอุปกรณ์ทดสอบรองรับฟีเจอร์ดังกล่าวหรือไม่
- หากอุปกรณ์ไม่จําเป็นต้องรองรับแอป Android ที่เข้าถึงองค์ประกอบที่ปลอดภัย ไม่ว่าจะเป็นใน UICC (เช่น ซิมการ์ด) ที่ผู้ให้บริการเครือข่ายมือถือ (ผู้ให้บริการ) จัดจําหน่ายหรือฝังไว้ในอุปกรณ์ คุณสามารถกําหนดค่าไฟล์ Manifest ของ HIDL เพื่อไม่ให้รวมองค์ประกอบ
android.hardware.secure_element
HAL ในกรณีนี้ android.se.omapi.SEService.getReaders() API จะรายงานรายการว่าง และการทดสอบ CTS จะผ่านโดยอัตโนมัติและรายงานการผ่าน CTS - หากอุปกรณ์ต้องรองรับแอป Android ที่เข้าถึงองค์ประกอบที่ปลอดภัย ไม่ว่าจะเป็นใน UICC (เช่น ซิมการ์ด) ที่ผู้ดำเนินการเครือข่ายมือถือ (ผู้ให้บริการ) จัดจำหน่ายหรือฝังไว้ในอุปกรณ์ คุณต้องใช้องค์ประกอบที่ปลอดภัยอย่างถูกต้องและทดสอบภายในองค์กร การทดสอบ CTS สําหรับองค์ประกอบที่ปลอดภัยอธิบายวิธีเตรียมการเพื่อเรียกใช้การทดสอบ CTS เพื่อให้มั่นใจว่าแพ็กเกจ API android.se.omapi ที่เพิ่มใน Android 9 ใช้งานได้ นอกจากนี้ เราขอแนะนำให้ทำการทดสอบเพิ่มเติมด้วยตนเองเนื่องจากความครอบคลุมของการทดสอบ CTS มีเพียงเล็กน้อย
ฉันจะซื้อซิมการ์ดสำหรับ CTS สำหรับองค์ประกอบที่ปลอดภัยได้จากที่ใด
คุณสามารถติดต่อผู้ให้บริการซิมที่ต้องการ
เหตุใด Orange SIM จึงแสดงในหน้าจอล็อกระหว่างการเรียกใช้ CTS ด้วยการจัดสรรโทเค็น
เฟรมทดสอบไม่เริ่มต้นเนื่องจากซิมการ์ดที่ทดสอบถูกล็อก ปิดใช้ล็อกซิมการ์ดในการตั้งค่าการล็อกซิมการ์ดก่อนดำเนินการ CTS ด้วยการจัดสรรโทเค็น