คำถามที่พบบ่อยเกี่ยวกับ CTS

โปรแกรมความเข้ากันได้ของ Android เป็นตัวขับเคลื่อนสำคัญในการรักษาผลตอบรับเชิงบวกสำหรับระบบนิเวศของ Android CTS เป็นเครื่องมือสำคัญในการรับรองคุณภาพของความเข้ากันได้ในเครื่องชั่ง ทีม Android ยังคงปรับปรุงเครื่องมือ CTS และการทดสอบความครอบคลุมอย่างต่อเนื่อง การเพิ่มกรณีทดสอบเป็นประจำทำให้คุณภาพของอุปกรณ์ที่รองรับมีการปรับปรุงอย่างมาก

คำถามทั่วไป

ส่วนนี้จะกล่าวถึงคำถามที่พบบ่อยเกี่ยวกับ CTS ทั่วไป

CTS ทดสอบอะไรบ้าง?

CTS ทดสอบว่ามี API ประเภทที่แข็งแกร่งของ Android ที่รองรับทั้งหมดอยู่และทำงานอย่างถูกต้อง CTS ยังทดสอบพฤติกรรมของระบบที่ไม่ใช่ API อื่นๆ เช่น วงจรการใช้งานและประสิทธิภาพของแอป

CTS ได้รับใบอนุญาตอย่างไร

CTS ได้รับอนุญาตภายใต้ Apache Software License 2.0 แบบเดียวกับที่ Android ส่วนใหญ่ใช้

ตัวแปลงสัญญาณได้รับการตรวจสอบโดย CTS หรือไม่

ใช่. ตัวแปลงสัญญาณบังคับทั้งหมดได้รับการตรวจสอบโดย CTS

คำถามเฉพาะการทดสอบ

ส่วนนี้ประกอบด้วยคำถามที่พบบ่อยที่ช่วยให้รันการทดสอบ CTS ได้อย่างมีประสิทธิภาพมากขึ้น

อะไรคือความแตกต่างระหว่าง CTS Sharding และ TF Sharding?

CTS Sharding และ TF Sharding เป็นแผนการทดสอบที่แตกต่างกันโดยสิ้นเชิง ซึ่งขับเคลื่อนโดยโค้ดเบสโครงสร้างพื้นฐานการทดสอบที่แตกต่างกัน แม้ว่าคำสั่ง run จะเหมือนกันในเวอร์ชันต่างๆ แต่ผลลัพธ์การแบ่งส่วนจะทำงานแตกต่างกัน CTS Sharding กำหนดกรณีทดสอบให้กับอุปกรณ์ที่อยู่ระหว่างการทดสอบ (DUT) แบบคงที่ดังนี้:

  • คำสั่ง: เรียกใช้ cts
  • การกำหนดค่าสำหรับ Android 8.1 และเวอร์ชันต่ำกว่า: /tools/cts-tradefed/res/config/cts.xml

TF Sharding กำหนดกรณีทดสอบให้กับ DUT ที่พร้อมใช้งานแบบไดนามิกดังนี้:

คาดหวังอะไรจากอุปกรณ์ที่รองรับ ABI หลายตัว

อุปกรณ์จะต้องผ่านการทดสอบ CTS และ CTS Verifier ทั้งหมดสำหรับโหมด ABI แต่ละโหมดที่อ้างว่ารองรับ ดังนั้นจึงจำเป็นต้องรันแอปสำหรับ ABI นั้นๆ หลักเกณฑ์สำหรับ ABI หลายรายการมีดังนี้:

  • สำหรับ CTS และ CTS Verifier มี การเผยแพร่ ARM และ x86 สำหรับแต่ละสถาปัตยกรรม แต่ละรายการสามารถรองรับโหมด 32- หรือ 64 บิต
  • สำหรับการทดสอบ CTS หากอุปกรณ์รองรับทั้ง ARM และ x86 อุปกรณ์นั้นจะต้องรันและผ่านการทดสอบ CTS ทั้ง ARM และ x86 ตามลำดับ

ดู CDD 3.3.1 Application Binary Interfaces สำหรับข้อกำหนด CDD บน ABI

เพียงพอหรือไม่ที่จะทำการทดสอบบน ABI หลักเท่านั้น (เช่น 64 บิต) เพื่อลดเวลาดำเนินการทดสอบ

ไม่ แอป Android ทำงานบนรันไทม์ 32 บิตหรือ 64 บิตของตัวเอง รหัสเครื่องจริง เส้นทางรหัส และสถานะจะแตกต่างกันระหว่าง 32 และ 64 หากคุณข้ามโหมดเดียว คุณจะครอบคลุม ABI ของอุปกรณ์เพียง 50% เท่านั้น

เหตุใดจึงมีกรณีทดสอบจำนวนมากรายงานว่าไม่ได้ดำเนินการ

คุณควรตรวจสอบหมายเลข Module Done แทนที่จะเป็นหมายเลข Not Executed

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

รายงานการรันโมดูลจนเสร็จสมบูรณ์ โมดูลยังไม่เสร็จสิ้น ในการร้องขอล่าสุด (done="false") ในรายงานในระหว่างต่อไปนี้:

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

  • ลองใหม่แล้ว (โดยใช้ตัวเลือก -r/--retry ) พร้อมตัวเลือกการกรองเพิ่มเติม เช่น:

    • --รวมตัวกรอง
    • --ไม่รวมตัวกรอง
    • -t/--test (ยังไม่รองรับตัวเลือกในการลองอีกครั้ง)
    • --ลองอีกครั้งล้มเหลว
    • --แผนย่อย

หากต้องการรับสถานะของ โมดูลเสร็จสิ้น (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 ของ args โมดูลสามารถรันซ้ำแบบแยกกันได้ผ่าน run cts -m CtsNNAPITestCases โดยตรง

ฉันจะหลีกเลี่ยงความล้มเหลวในการเตรียมการทดสอบหลังไฟร์วอลล์ขององค์กรได้อย่างไร

ชุดการทดสอบอัตโนมัติทั้งหมดพยายามดาวน์โหลดไฟล์สื่อ CTS หรือไฟล์ตรรกะทางธุรกิจในระหว่างรันไทม์ ในสภาพแวดล้อมขององค์กรหลายแห่ง ไฟร์วอลล์และพร็อกซีเป็นเรื่องปกติ ซึ่งทำให้การเตรียมการทดสอบล้มเหลว ดำเนินการบรรทัดต่อไปนี้หรือเพิ่มลงใน .profile (บน Ubuntu)

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

ฉันจำเป็นต้องมีซิมการ์ดสำหรับ CTS สำหรับ Secure Element หรือไม่

จำเป็นต้องใช้ซิมการ์ดสำหรับการทดสอบหรือไม่นั้นขึ้นอยู่กับความเข้าใจว่าอุปกรณ์ทดสอบรองรับฟีเจอร์นั้นหรือไม่

  • หากอุปกรณ์ของคุณ ไม่ จำเป็นต้องรองรับแอป Android ที่เข้าถึงองค์ประกอบที่ปลอดภัย—ไม่ว่าจะใน UICC (เช่น ซิมการ์ด) ที่เผยแพร่โดยผู้ให้บริการเครือข่ายมือถือ (ผู้ให้บริการ) หรือฝังอยู่ในอุปกรณ์ คุณสามารถกำหนดค่ารายการ HIDL ให้ไม่รวมไว้ด้วย องค์ประกอบ android.hardware.secure_element HAL ในกรณีนี้ android.se.omapi.SEService.getReaders() API จะรายงานรายการว่างและการทดสอบ CTS จะผ่านโดยอัตโนมัติและรายงานการผ่านสำหรับ CTS
  • หากอุปกรณ์ของคุณ จำเป็น ต้องรองรับแอป Android ที่เข้าถึงองค์ประกอบที่ปลอดภัย ไม่ว่าจะใน UICC (เช่น ซิมการ์ด) ที่จัดจำหน่ายโดยผู้ให้บริการเครือข่ายมือถือ (ผู้ให้บริการ) หรือฝังอยู่ในอุปกรณ์ คุณจะต้องใช้องค์ประกอบที่ปลอดภัยอย่างเหมาะสมและทดสอบ ในบ้าน การทดสอบ CTS สำหรับองค์ประกอบที่ปลอดภัย สรุปวิธีการเตรียมรันการทดสอบ CTS เพื่อให้แน่ใจว่าแพ็คเกจ android.se.omapi API ที่เพิ่มใน Android 9 นั้นใช้งานได้ เราขอแนะนำให้ทำการทดสอบเพิ่มเติมด้วยตนเอง เนื่องจากความครอบคลุมของการทดสอบ CTS นั้นน้อยมาก

ฉันจะรับซิมการ์ดสำหรับ CTS สำหรับ Secure Element ได้ที่ไหน

คุณสามารถติดต่อผู้จำหน่ายซิมที่คุณต้องการได้

เหตุใด Orange SIM จึงปรากฏบนหน้าจอล็อคระหว่างการดำเนินการ CTS ด้วยการแบ่งโทเค็น

กรณีทดสอบไม่เริ่มต้นเนื่องจากการทดสอบซิมการ์ดถูกล็อค ปิดใช้งาน การล็อคซิมการ์ด ใน **การตั้งค่าการล็อคซิมการ์ด ก่อนที่จะดำเนินการ CTS ด้วยการแบ่งโทเค็น