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

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 ที่มีข้อมูลที่จําเป็นสําหรับแหล่งข้อมูลนั้น ซึ่งรวมถึงข้อมูลต่อไปนี้

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

คำขอ POST จะมาจากเมธอด downloadBuildArtifact ของ buildsvc RPC ซึ่งจะแสดง URL ที่ใช้เพื่อเข้าถึงทรัพยากรได้

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

รับ URL

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

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

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

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

บิวด์ Flash

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

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

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

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

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

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

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

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

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

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