โครงการโอเพนซอร์ส 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 คือชุดการทดสอบหน่วยที่ออกแบบมาเพื่อผสานรวมเข้ากับเวิร์กโฟลว์ประจำวัน จุดประสงค์ของ CTS คือการเปิดเผยความไม่เข้ากันและ เพื่อให้มั่นใจว่าซอฟต์แวร์ยังคงใช้งานร่วมกันได้ตลอดกระบวนการพัฒนา
CTS และการทดสอบแพลตฟอร์มไม่เกี่ยวข้องกัน ต่อไปนี้คือคำถามทั่วไป หลักเกณฑ์:
- หากการทดสอบยืนยันความถูกต้องของฟังก์ชันหรือลักษณะการทำงานของ API เฟรมเวิร์ก และควรมีการบังคับใช้การทดสอบกับพาร์ทเนอร์ OEM โดยควรอยู่ใน CTS
- หากการทดสอบมีวัตถุประสงค์เพื่อตรวจหาการถดถอยระหว่างการพัฒนาแพลตฟอร์ม และอาจต้องได้รับอนุญาตเป็นสิทธิ์เฉพาะบุคคลในการดำเนินการ และ เกี่ยวกับรายละเอียดการนำไปใช้งาน (ตามที่เปิดตัวใน AOSP) แพลตฟอร์มนี้ควรเป็นแพลตฟอร์ม การทดสอบ
- บริการของ Google Mobile (GMS)
ชุดแอปและ API ของ Google ที่ติดตั้งล่วงหน้าในอุปกรณ์ได้
- 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) ทดสอบ API ของเฟรมเวิร์กโดยใช้เฟรมเวิร์ก Android API ที่ใช้งานอยู่อาจรวมถึง API ต่อไปนี้
- API สาธารณะที่มีไว้สำหรับแอปของบุคคลที่สาม
- API ที่ซ่อนไว้มีไว้สําหรับแอปที่มีสิทธิ์ ซึ่งได้แก่ API ของระบบหรือ API ส่วนตัว (
@hide
หรือprotected
,package private
)
- (ประเภท 2) เรียกใช้บริการของระบบ Android โดยใช้ Raw Binder หรือพร็อกซี IPC โดยตรง
- (ประเภท 3) โต้ตอบกับ HAL โดยตรงโดยใช้ API หรืออินเทอร์เฟซ IPC ระดับต่ำ
การทดสอบประเภทที่ 1 และ 2 มักเป็นการทดสอบเครื่องมือวัด ส่วนการทดสอบประเภทที่ 3 มักเป็นการทดสอบ GTest
สิ่งต่อไปที่ควรทำ
คุณอ่านรายละเอียดเพิ่มเติมในเอกสารได้ดังต่อไปนี้
หากคุณยังไม่ได้ศึกษาสถาปัตยกรรม Android โปรดดู ภาพรวมสถาปัตยกรรม
หากคุณกำลังสร้างอุปกรณ์ที่ใช้งานร่วมกับ Android ได้ โปรดดู ภาพรวมโปรแกรมความเข้ากันได้ของ Android
เพื่อผสานรวมการทดสอบโฮสต์สำหรับการวัดคุม ฟังก์ชันการทำงาน เมตริก และ JAR เป็นบริการทดสอบอย่างต่อเนื่องของแพลตฟอร์มดู ทดสอบเวิร์กโฟลว์การพัฒนา
หากต้องการตรวจจับและเสริมความแข็งแกร่งของอุปกรณ์จากช่องโหว่ ดูการทดสอบความปลอดภัย
ดูข้อมูลเกี่ยวกับการทดสอบการติดตั้งใช้งาน HAL และเคอร์เนลได้ที่ชุดทดสอบของผู้ให้บริการ (VTS) และโครงสร้างพื้นฐาน
สําหรับการทดสอบแอป โปรดอ่านพื้นฐานของการทดสอบแอป Android และทําAndroid ขั้นสูงใน Kotlin 05.1: พื้นฐานการทดสอบโดยใช้ตัวอย่างที่ให้ไว้
ดูข้อมูลเกี่ยวกับการทดสอบเบื้องต้นก่อนส่งที่ใช้ได้ผ่านฮุกของ repo ฮุกเหล่านี้สามารถใช้เรียกใช้โปรแกรมตรวจไวยากรณ์ ตรวจสอบการจัดรูปแบบ และเรียกใช้การทดสอบหน่วยก่อนดำเนินการต่อ เช่น การอัปโหลดการคอมมิต ฮุกเหล่านี้จะปิดอยู่โดยค่าเริ่มต้น ดูข้อมูลเพิ่มเติมได้ที่ AOSP Preupload Hook
หากต้องการอ่านเพิ่มเติมเกี่ยวกับการบันทึก โปรดดูที่ทำความเข้าใจการบันทึก
หากต้องการทำความเข้าใจวิธีแก้ไขข้อบกพร่องของโค้ด Android โปรดดู แก้ไขข้อบกพร่องของโค้ดแพลตฟอร์ม Android ที่มาพร้อมเครื่อง