โครงการโอเพนซอร์ส Android (AOSP) มีเครื่องมือและชุดทดสอบมากมาย ในการทดสอบส่วนต่างๆ ของการติดตั้งใช้งาน ก่อนใช้หน้าต่างๆ ใน คุณควรทำความคุ้นเคยกับคำต่อไปนี้:
- อุปกรณ์ที่เข้ากันได้กับ Android
- อุปกรณ์ที่เรียกใช้แอปของบุคคลที่สามซึ่งเขียนโดยนักพัฒนาแอปบุคคลที่สามได้ โดยใช้ Android SDK และ NDK อุปกรณ์ที่เข้ากันได้กับ Android ต้องเป็นไปตาม ข้อกำหนดของ เอกสารข้อกำหนดความเข้ากันได้ (CDD) และส่ง ความเข้ากันได้ของชุดทดสอบ (CTS) ใช้ร่วมกับ Android ได้ อุปกรณ์มีสิทธิ์เข้าร่วมในระบบนิเวศ Android ซึ่งรวมถึง การอนุญาตให้ใช้สิทธิของ Google Play, การอนุญาตให้ใช้สิทธิที่เป็นไปได้ของ ชุดบริการของ Google Mobile (GMS) แอปและ API และการใช้เครื่องหมายการค้าของ Android ทุกคนสามารถ ใช้ซอร์สโค้ดของ Android แต่จะถือว่าเป็นส่วนหนึ่งของระบบนิเวศของ Android อุปกรณ์ต้องใช้งานกับ Android ได้
- อาร์ติแฟกต์
- บันทึกที่เกี่ยวข้องกับบิลด์ที่ช่วยให้แก้ปัญหาในเครื่องได้
- เอกสารคำจำกัดความความเข้ากันได้ (CDD)
- เอกสารที่แจกแจงข้อกำหนดด้านซอฟต์แวร์และฮาร์ดแวร์สำหรับ อุปกรณ์ที่เข้ากันได้กับ Android
- ชุดเครื่องมือทดสอบความเข้ากันได้ (CTS)
ชุดทดสอบฟรีเชิงพาณิชย์ ดาวน์โหลดเป็นไฟล์ไบนารี หรือดาวน์โหลดเป็น ต้นฉบับใน AOSP CTS คือชุดการทดสอบ 1 หน่วยที่ออกแบบมาเพื่อผสานรวมใน เวิร์กโฟลว์ประจำวันของคุณ จุดประสงค์ของ CTS คือการเปิดเผยความไม่เข้ากันและ เพื่อให้มั่นใจว่าซอฟต์แวร์ยังคงใช้งานร่วมกันได้ตลอดกระบวนการพัฒนา
CTS และการทดสอบแพลตฟอร์มไม่เกี่ยวข้องกัน ต่อไปนี้คือคำถามทั่วไป หลักเกณฑ์:
- หากการทดสอบยืนยันความถูกต้องของฟังก์ชันหรือลักษณะการทำงานของ API เฟรมเวิร์ก และควรมีการบังคับใช้การทดสอบกับพาร์ทเนอร์ OEM โดยควรอยู่ใน CTS
- หากการทดสอบมีวัตถุประสงค์เพื่อตรวจหาการถดถอยระหว่างการพัฒนาแพลตฟอร์ม และอาจต้องได้รับอนุญาตเป็นสิทธิ์เฉพาะบุคคลในการดำเนินการ และ เกี่ยวกับรายละเอียดการนำไปใช้งาน (ตามที่เปิดตัวใน AOSP) แพลตฟอร์มนี้ควรเป็นแพลตฟอร์ม การทดสอบ
- บริการของ Google Mobile (GMS)
คอลเล็กชันของแอป Google และ API ที่ติดตั้งล่วงหน้าในอุปกรณ์ได้
- GoogleTest (GTest)
กรอบการทดสอบและการจำลองสำหรับ C++ โดยทั่วไปแล้วไบนารีของ GTest เข้าถึงเลเยอร์ Abstraction ระดับล่างหรือทำ IPC ดิบกับระบบต่างๆ บริการต่างๆ วิธีการทดสอบสำหรับ GTest มักจะเชื่อมโยงกันอย่างเหนียวแน่นกับ บริการที่กำลังทดสอบอยู่ โดย CTS จะมีเฟรมเวิร์ก GTest
- การทดสอบการใช้เครื่องมือ
สภาพแวดล้อมการดำเนินการทดสอบพิเศษ เปิดใช้ด้วยคำสั่ง
am instrument
โดยที่กระบวนการของแอปที่กำหนดเป้าหมาย จะรีสตาร์ทและเริ่มต้นโดยมีบริบทพื้นฐานของแอป เทรดการใช้เครื่องมือจะเริ่มต้นภายในกระบวนการของแอปทางออนไลน์ อุปกรณ์ CTS มีการทดสอบการใช้เครื่องมือ- Logcat
เครื่องมือบรรทัดคำสั่งที่สร้างบันทึกของข้อความระบบ รวมถึง สแต็กเทรซเมื่ออุปกรณ์แสดงข้อผิดพลาดและข้อความที่คุณได้รับ ที่เขียนจากแอปของคุณพร้อมกับชั้นเรียน
Log
- การบันทึก
การใช้บันทึกเพื่อติดตามเหตุการณ์ของระบบคอมพิวเตอร์ เช่น เป็นข้อผิดพลาด การบันทึกใน Android มีความซับซ้อนเนื่องจากทั้งมาตรฐานที่ใช้ซึ่ง จะรวมกันในเครื่องมือ Logcat
- การทดสอบหลังส่ง
การทดสอบ Android ที่ดำเนินการเมื่อมีการยืนยันแพตช์ใหม่ สาขาเคอร์เนลทั่วไป เมื่อป้อน
aosp_kernel
เป็นชื่อสาขาบางส่วน คุณจะ ดูรายการของสาขาเคอร์เนลที่มีผลลัพธ์ได้ เช่น ผลลัพธ์android-mainline
มีอยู่ที่ https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid- ส่งการทดสอบล่วงหน้า
การทดสอบที่ใช้เพื่อป้องกันการนำความล้มเหลวไปใช้ใน เคอร์เนลทั่วไป
- สหพันธ์การค้า
หรือที่เรียกว่า Tradefed ซึ่งเป็นการทดสอบอย่างต่อเนื่อง ที่ออกแบบมาให้ใช้การทดสอบในอุปกรณ์ Android ตัวอย่างเช่น Tradefed ใช้ในการเรียกใช้ชุดทดสอบความเข้ากันได้และการทดสอบชุดทดสอบของผู้ให้บริการ
- ชุดทดสอบสำหรับผู้ให้บริการ (VTS)
ชุดความสามารถที่ครอบคลุมสำหรับ การทดสอบ Android, การส่งเสริมกระบวนการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ และการทำให้ การทดสอบเลเยอร์แอบสแตรกของฮาร์ดแวร์ (HAL) และการทดสอบเคอร์เนลของระบบปฏิบัติการ
ประเภทการทดสอบแพลตฟอร์ม
โดยปกติแล้ว การทดสอบแพลตฟอร์มจะโต้ตอบกับระบบ Android อย่างน้อย 1 ระบบ หรือชั้น HAL ฟังก์ชันของสิ่งที่อยู่ภายใต้การทดสอบ และยืนยันความถูกต้องของ ผลการทดสอบ การทดสอบแพลตฟอร์มอาจมีประโยชน์ดังนี้
- (ประเภท 1) Exercise Framework API โดยใช้เฟรมเวิร์ก Android มี API บางรายการ
การออกกำลังกายอาจรวมถึง
- API สาธารณะที่มีไว้สำหรับแอปของบุคคลที่สาม
- API ที่ซ่อนไว้ซึ่งมีไว้สำหรับแอปที่ได้รับสิทธิ์ ได้แก่ API ของระบบหรือ
API ส่วนตัว (
@hide
หรือprotected
,package private
)
- (ประเภท 2) เรียกใช้บริการของระบบ Android โดยใช้ Raw Binder หรือพร็อกซี IPC โดยตรง
- (ประเภท 3) โต้ตอบกับ HAL โดยตรงโดยใช้ API หรืออินเทอร์เฟซ IPC ระดับต่ำ
การทดสอบประเภท 1 และ 2 มักเป็นการทดสอบการใช้เครื่องมือ ในขณะที่การทดสอบประเภท 3 โดยปกติจะเป็น GTests
สิ่งต่อไปที่ควรทำ
คุณอ่านรายละเอียดเพิ่มเติมในเอกสารได้ดังต่อไปนี้
หากคุณยังไม่ได้ศึกษาสถาปัตยกรรม Android โปรดดู ภาพรวมสถาปัตยกรรม
หากคุณกำลังสร้างอุปกรณ์ที่ใช้งานร่วมกับ Android ได้ โปรดดู ภาพรวมโปรแกรมความเข้ากันได้ของ Android
เพื่อผสานรวมการทดสอบโฮสต์สำหรับการวัดคุม ฟังก์ชันการทำงาน เมตริก และ JAR เป็นบริการทดสอบอย่างต่อเนื่องของแพลตฟอร์มดู ทดสอบเวิร์กโฟลว์การพัฒนา
หากต้องการตรวจจับและเสริมความแข็งแกร่งของอุปกรณ์จากช่องโหว่ ดูการทดสอบความปลอดภัย
ดูข้อมูลเกี่ยวกับการทดสอบการใช้งาน HAL และเคอร์เนลได้ที่ Vendor Test Suite (VTS) และโครงสร้างพื้นฐาน
สำหรับการทดสอบแอป โปรดอ่าน พื้นฐานในการทดสอบ Android แอป และดำเนินการ Advanced Android ใน Kotlin 05.1:Testing ข้อมูลเบื้องต้น โดยใช้ ตัวอย่างที่มีให้
เรียนรู้เกี่ยวกับการทดสอบการส่งล่วงหน้าแบบพื้นฐานที่พร้อมให้คุณใช้งานผ่านฮุกที่เก็บ คุณสามารถใช้ฮุกเหล่านี้เพื่อเรียกใช้โปรแกรมวิเคราะห์โค้ด ตรวจสอบการจัดรูปแบบ และทริกเกอร์หน่วย ก่อนที่จะดำเนินการต่อ เช่น การอัปโหลดคอมมิต ปิดใช้ฮุกเหล่านี้แล้ว โดยค่าเริ่มต้น ดูข้อมูลเพิ่มเติมได้ที่ AOSP Preupload Hook
หากต้องการอ่านเพิ่มเติมเกี่ยวกับการบันทึก โปรดดูที่ทำความเข้าใจการบันทึก
หากต้องการทำความเข้าใจวิธีแก้ไขข้อบกพร่องของโค้ด Android โปรดดู แก้ไขข้อบกพร่องของโค้ดแพลตฟอร์ม Android ที่มาพร้อมเครื่อง