โครงสร้างพื้นฐานการทดสอบอัตโนมัติ

Android 9 มีโครงสร้างพื้นฐานของ Vendor Test Suite (VTS) สำหรับการทดสอบ VTS, CTS หรือทดสอบอื่นๆ แบบอัตโนมัติในอุปกรณ์ของพาร์ทเนอร์ที่ใช้ AOSP Generic System Image (GSI) ก่อนหน้านี้ การเรียกใช้การทดสอบเหล่านี้เป็นการดำเนินการด้วยตนเองอย่างมาก โครงสร้างพื้นฐานการทดสอบ VTS ใหม่ออกแบบมาเพื่อรองรับการทดสอบอัตโนมัติหลายครั้งต่อวันในอุปกรณ์หลายเครื่อง

สถาปัตยกรรม

โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS ใช้สถาปัตยกรรมต่อไปนี้

รูปที่ 1 สถาปัตยกรรมโครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS

เมื่อมีการเรียกใช้การทดสอบ โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS จะทํางานต่อไปนี้

1. ดึงข้อมูลอาร์ติแฟกต์สำหรับบิวด์และทรัพยากรการทดสอบจากตำแหน่งต่างๆ ดังนี้
   • บิลด์ Android ของพาร์ทเนอร์ (PAB) สำหรับเฟรมเวิร์ก GSI, VTS และบิลด์อื่นๆ บางรายการ
   • ระบบไฟล์ในเครื่อง, Google Cloud Storage หรือระบบบิลด์อื่นๆ ที่เจาะจงผู้ให้บริการ สำหรับพาร์ทเนอร์ที่ไม่ได้จัดเก็บบิลด์ในระบบคลาวด์ของ Google
2. แฟลชอาร์ติแฟกต์การสร้าง (จากอุปกรณ์) และ GSI (จาก AOSP) ลงในอุปกรณ์ที่เชื่อมต่อ
3. เรียกใช้การทดสอบ VTS โดยใช้ TradeFed ในเครื่องหรือ TradeFed ในระบบคลาวด์
4. รายงานผลการทดสอบไปยังแดชบอร์ด VTS

กระบวนการนี้ได้รับการประสานงานโดยตัวควบคุมโฮสต์ VTS (HC) ซึ่งเป็นเครื่องในห้องทดลองที่ควบคุมลักษณะการทำงานของอุปกรณ์ที่เชื่อมต่อทั้งหมดที่อยู่ระหว่างการทดสอบ HC จะมีหน้าที่ดึงข้อมูลบิลด์ล่าสุด แฟลชบิลด์ลงในอุปกรณ์ และเรียกใช้การทดสอบ (ในเครื่องหรือผ่านผู้ควบคุม) นอกจากนี้ยังสื่อสารกับเครื่องมือจัดตารางเวลาระบบคลาวด์และกำหนดเส้นทางการรับส่งข้อมูลระหว่างเครื่องมือจัดตารางเวลากับอินสแตนซ์ TradeFed (หรือแฮนเดิลอื่นๆ) ที่ทำงานบน HC ดูรายละเอียดเกี่ยวกับตัวควบคุมของผู้จัดการประชุมได้ที่สถาปัตยกรรมตัวควบคุมของผู้จัดการประชุม

ผู้ให้บริการทรัพยากร

การทดสอบอัตโนมัติต้องใช้ทรัพยากร เช่น บิลด์ระบบ ไฟล์ทดสอบ และรายการต่างๆ ของ VTS แม้ว่าจะสร้างจากซอร์สโค้ดได้ แต่การสร้างจากยอดของต้นไม้เป็นประจำแล้วโพสต์อาร์ติแฟกต์ให้ดาวน์โหลดจะง่ายกว่า

พาร์ทเนอร์เข้าถึงแหล่งข้อมูลการทำงานอัตโนมัติได้โดยใช้ตำแหน่งต่อไปนี้

• บิลด์ Android ของพาร์ทเนอร์ สิทธิ์เข้าถึงแบบเป็นโปรแกรมที่มอบให้ตามบัญชี
• ระบบไฟล์ในเครื่อง (หรือที่คล้ายกัน) สําหรับพาร์ทเนอร์ที่ไม่ได้ใช้บิลด์ Android ของพาร์ทเนอร์

ทรัพยากรมีผู้ให้บริการบิลด์สำหรับทั้ง 2 ตัวเลือกเพื่อใช้ในการแฟลชอุปกรณ์ในภายหลัง โดยขยายจาก build_provider.py รายการเดียวที่จัดเก็บบิลด์ไว้ในไดเรกทอรีชั่วคราวในเครื่อง

บิลด์ Android ของพาร์ทเนอร์

ใน Android 8.1 และเวอร์ชันที่ต่ำกว่า พาร์ทเนอร์ Android ต้องไปที่เว็บไซต์บิลด์ Android ของพาร์ทเนอร์ (https://partner.android.com/build) ไปที่บัญชี และดึงข้อมูลอิมเมจระบบล่าสุดผ่านอินเทอร์เฟซผู้ใช้ Android 9 รองรับการดาวน์โหลดทรัพยากรเหล่านี้จาก PAB โดยอัตโนมัติเมื่อระบุข้อมูลเข้าสู่ระบบที่เหมาะสม เพื่อช่วยพาร์ทเนอร์หลีกเลี่ยงกระบวนการที่ช้าและซับซ้อนนี้

ตั้งค่าการเข้าถึง

การเข้าถึงแบบเป็นโปรแกรมใช้ OAuth2 ใน Google APIs เพื่อเข้าถึง RPC ที่จําเป็น เมื่อใช้แนวทางมาตรฐานในการสร้างข้อมูลเข้าสู่ระบบ OAuth2 พาร์ทเนอร์ต้องตั้งค่าคู่รหัส/รหัสลับไคลเอ็นต์กับ Google เมื่อมีการชี้ PartnerAndroidBuildClient ไปยังความลับนั้นเป็นครั้งแรก ระบบจะเปิดหน้าต่างเบราว์เซอร์เพื่อให้ผู้ใช้เข้าสู่ระบบบัญชี Google ซึ่งจะสร้างข้อมูลเข้าสู่ระบบ OAuth2 ที่จําเป็นต่อการดําเนินการต่อ ระบบจะจัดเก็บข้อมูลเข้าสู่ระบบ (โทเค็นการเข้าถึงและโทเค็นรีเฟรช) ไว้ในเครื่อง ซึ่งหมายความว่าพาร์ทเนอร์จะต้องเข้าสู่ระบบเพียงครั้งเดียว

คำขอ POST สำหรับ URL

การคลิกลิงก์แหล่งข้อมูลใน PAB จะส่งคําขอ POST ที่มีข้อมูลที่จําเป็นสําหรับแหล่งข้อมูลนั้น ซึ่งรวมถึงข้อมูลต่อไปนี้

• รหัสบิลด์ เป้าหมายการสร้าง
• ชื่อทรัพยากร
• สาขา
• ชื่อรุ่นที่อาจได้รับการเผยแพร่ และระบุว่ารุ่นที่อาจได้รับการเผยแพร่เป็นบิลด์ภายในหรือไม่

เมธอด downloadBuildArtifact ของ buildsvc RPC จะรับคําขอ POST ซึ่งจะแสดงผล URL ที่สามารถใช้เพื่อเข้าถึงแหล่งข้อมูล

• สำหรับทรัพยากร APK ของ Clockwork Companion URL จะเป็น URL ที่อ่านได้ซึ่งโฮสต์ใน PAB (ซึ่งได้รับการปกป้องด้วยการให้สิทธิ์และเข้าถึงได้ด้วยข้อมูลเข้าสู่ระบบ OAuth2 ที่เหมาะสม)
• สำหรับทรัพยากรอื่นๆ URL จะเป็น URL ยาวที่ไม่ได้ป้องกันจาก Android Build API ภายใน (ซึ่งจะหมดอายุหลังจากผ่านไป 5 นาที)

รับ URL

buildsvc RPC กำหนดให้ต้อง POST โทเค็น XSRF กับพารามิเตอร์อื่นๆ เพื่อหลีกเลี่ยงการปลอมแปลงคําขอข้ามเว็บไซต์ แม้ว่าโทเค็นนี้จะทําให้กระบวนการมีความปลอดภัยมากขึ้น แต่ก็ทําให้การเข้าถึงแบบเป็นโปรแกรมยากขึ้นมากด้วย เนื่องจากตอนนี้คุณต้องใช้โทเค็น (ซึ่งมีอยู่ใน JavaScript ของหน้า PAB เท่านั้น) ในการเข้าถึงด้วย

เพื่อหลีกเลี่ยงปัญหานี้ Android 9 ได้ออกแบบรูปแบบการตั้งชื่อ URL ใหม่สำหรับไฟล์ทั้งหมด (ไม่ใช่แค่ APK) เพื่อใช้ชื่อ URL ที่คาดเดาได้สำหรับการเข้าถึงรายการอาร์ติแฟกต์และ URL ของอาร์ติแฟกต์ ตอนนี้ PAB ใช้รูปแบบ URL ที่สะดวกซึ่งช่วยให้พาร์ทเนอร์ดาวน์โหลดทรัพยากรได้ สคริปต์ HC สามารถดาวน์โหลด APK เหล่านั้นได้อย่างง่ายดายเนื่องจากทราบรูปแบบ URL และ HC สามารถข้ามปัญหา XSRF/คุกกี้ได้เนื่องจากไม่จําเป็นต้องใช้ buildsvc RPC

ระบบไฟล์ในเครื่อง

เมื่อระบุไดเรกทอรีที่มีรายการ (หรือไฟล์ ZIP) ของอาร์ติแฟกต์ ผู้ให้บริการบิลด์จะตั้งค่ารูปภาพที่เกี่ยวข้องตามสิ่งที่อยู่ในไดเรกทอรี คุณสามารถใช้เครื่องมือ gsutil เพื่อคัดลอกไฟล์จาก Google Cloud Storage ไปยังไดเรกทอรีในเครื่อง

บิวด์ Flash

หลังจากดาวน์โหลดภาพล่าสุดของอุปกรณ์ลงในโฮสต์แล้ว จะต้องแฟลชภาพเหล่านั้นลงในอุปกรณ์ ซึ่งทำได้โดยใช้คำสั่ง adb และ fastboot มาตรฐานและกระบวนการย่อย Python โดยอิงตามเส้นทางไฟล์ชั่วคราวที่เก็บไว้โดยผู้ให้บริการบิลด์

การดำเนินการที่รองรับ

• การแฟลชเฉพาะ GSI
• การกะพริบรูปภาพแต่ละรูปจากระบบหลัก (เช่น fastboot flash boot boot.img)
• กำลังแฟลชรูปภาพทั้งหมดจากระบบหลัก ตัวอย่าง
  • fastboot flashall (ใช้ยูทิลิตี flashall ในตัว)
  • fastboot flash (ทีละรายการ)

เรียกใช้การทดสอบ

ใน Android 9 โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS รองรับเฉพาะชุดทดสอบ TradeFed เท่านั้น แต่อาจขยายการให้บริการเพื่อรองรับชุดทดสอบอื่นๆ ในอนาคต

หลังจากเตรียมอุปกรณ์แล้ว คุณสามารถเรียกใช้การทดสอบโดยใช้ตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้

• เมื่อใช้ TradeFed ในเครื่อง ให้ใช้คำสั่ง test ในคอนโทรลเลอร์โฮสต์ ซึ่งจะใช้ชื่อแผนทดสอบ VTS (เช่น vts-selftest) และทำการทดสอบ
• เมื่อใช้คลัสเตอร์ TradeFed (เชื่อมต่อกับ MTT หรือไม่ก็ได้) ให้ใช้คำสั่ง lease ในคอนโซลตัวควบคุมโฮสต์ ซึ่งจะค้นหาการทดสอบที่ยังไม่เสร็จสมบูรณ์

หากใช้ TradeFedCluster ทาง TradeFed จะทำงานในเครื่องเป็นผู้จัดการระยะไกล หากไม่ ระบบจะเรียกใช้การทดสอบโดยใช้กระบวนการย่อยของ Python

ผลลัพธ์ของรายงาน

VtsMultiDeviceTest จะรายงานผลการทดสอบไปยังโปรเจ็กต์แดชบอร์ด VTS บางโปรเจ็กต์โดยอัตโนมัติ