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