ระบบอัตโนมัติสำหรับ Android Device Lab: เครื่องจริงและ Emulator

เปลี่ยนโทรศัพท์ Android และโปรแกรมจำลองจำนวนเล็กน้อยให้เป็นห้องปฏิบัติการอุปกรณ์ที่ทำซ้ำได้โดยมีสถานะเริ่มต้นที่ชัดเจน การตรวจสอบที่สังเกตได้ การรอแบบมีขอบเขต หลักฐานความล้มเหลว และกฎการสร้างและการซื้อที่ชัดเจน

คำตอบสั้นๆ คือ ทำให้วงจรการทำงานเป็นแบบอัตโนมัติ ไม่ใช่ชั้นวาง

ห้องปฏิบัติการอุปกรณ์ Android จะมีประโยชน์เมื่อการเรียกใช้ทุกครั้งเริ่มต้นจากสถานะที่ระบุชื่อ ทำการตรวจสอบแบบมีขอบเขตหนึ่งครั้ง ตรวจสอบเงื่อนไขภายหลัง และทิ้งหลักฐานที่บุคคลอื่นสามารถตรวจสอบได้ โทรศัพท์ ฮับ USB ขาตั้ง และป้ายกำกับเป็นเพียงเลเยอร์ทางกายภาพเท่านั้น ระบบอัตโนมัติในห้องปฏิบัติการอุปกรณ์ Android คือชั้นปฏิบัติการที่เปลี่ยนอุปกรณ์เหล่านั้นให้เป็นการตรวจสอบรุ่น การสนับสนุน และการแปลที่ทำซ้ำได้

หากคุณยังคงเลือกโทรศัพท์ สายไฟ แหล่งจ่ายไฟ หรือที่เก็บข้อมูล ให้เริ่มต้นด้วยคู่มือการตั้งค่าห้องปฏิบัติการอุปกรณ์ Android ราคาประหยัดบทความนี้เริ่มต้นหลังจากที่ฮาร์ดแวร์นั้นมีอยู่แล้ว โดยจะอธิบายวิธีรวมอุปกรณ์จริงและโปรแกรมจำลอง, กำหนดเมทริกซ์ทดสอบขนาดเล็ก, สร้างการ์ดรันอุปกรณ์, ซิงโครไนซ์กับสถานะที่สังเกตได้, จับภาพหน้าจอและบันทึก และตัดสินใจว่าเมื่อใดระบบคลาวด์ของอุปกรณ์ที่โฮสต์เป็นตัวเลือกที่ดีกว่า

เป้าหมายไม่ใช่การแทนที่การทดสอบหน่วย, การทดสอบการเขียน, Espresso, UI Automator, Appium, อุปกรณ์ที่มีการจัดการ Gradle หรือ Firebase Test Lab เครื่องมือเหล่านั้นมีขอบเขตที่แตกต่างกัน เครื่องมืออัตโนมัติของ AndroidAIมีประโยชน์มากที่สุดที่นี่ในฐานะเลเยอร์เวิร์กโฟลว์ที่มองเห็นได้สำหรับการตรวจสอบอุปกรณ์จริงที่ผู้ปฏิบัติงาน ผู้ตรวจสอบ QA และทีมสนับสนุนจำเป็นต้องเข้าใจ

ให้อุปกรณ์จริงและอีมูเลเตอร์ทำงานที่แตกต่างกัน

ห้องปฏิบัติการอุปกรณ์ไม่จำเป็นต้องมีการทดสอบทุกครั้งบนอุปกรณ์ทุกเครื่อง อีมูเลเตอร์สามารถสร้าง รีเซ็ต กำหนดพารามิเตอร์ และทำงานแบบขนานได้อย่างรวดเร็ว โทรศัพท์จริงอาจเปิดเผยเฟิร์มแวร์ของผู้จำหน่าย กล้องจริง บลูทูธ ข้อความแจ้งไบโอเมตริกซ์ ลักษณะการทำงานด้านความร้อน ข้อจำกัดในพื้นหลัง การส่งการแจ้งเตือน สถานะ USB และพื้นผิวอินพุตที่อุปกรณ์เสมือนอาจสร้างไม่ตรงตามความจริง ใช้ความแตกต่างเหล่านั้นเพื่อแบ่งความรับผิดชอบแทนที่จะโต้เถียงกันเพื่อแพลตฟอร์มสากลเดียว

รูปแบบเริ่มต้นที่ใช้งานได้จริงคือระดับเสมือนแบบกว้างและระดับทางกายภาพที่แคบ ดำเนินการตรวจสอบเชิงกำหนดอย่างรวดเร็วในการกำหนดค่าเสมือน จากนั้นกำหนดเส้นทางชุดข้อมูลสำคัญขนาดเล็กผ่านโทรศัพท์จริงสองหรือสามเครื่องที่เลือกไว้สำหรับความเสี่ยงที่เกิดขึ้นจริงของลูกค้า ขยายเฉพาะเมื่อข้อมูลความล้มเหลวแสดงให้เห็นว่ารุ่นอื่น เวอร์ชัน Android สถานที่ หรือพฤติกรรมของผู้ให้บริการเปลี่ยนแปลงผลลัพธ์

กำหนดเมทริกซ์อุปกรณ์ด้วยเหตุผลเดียวต่อแถว

Firebase Test Lab อธิบายเมทริกซ์การทดสอบว่าเป็นการผสมผสานระหว่างอุปกรณ์ที่เลือกและการกำหนดค่าการทดสอบ แนวคิดดังกล่าวใช้ได้กับห้องปฏิบัติการในท้องถิ่นด้วย แต่เมทริกซ์ควรอิงตามความเสี่ยงมากกว่าที่จะครอบคลุมทั้งหมด ทุกแถวต้องการเหตุผล เจ้าของ และการตัดสินใจที่คาดหวัง โทรศัพท์ที่มีอยู่เพียงเพราะว่ามีจำหน่ายจะใช้เวลาในการชาร์จ การรีเซ็ต และการบำรุงรักษาอย่างเงียบๆ โดยไม่เพิ่มความมั่นใจในการเปิดตัว

• เก็บพื้นฐาน Android ในปัจจุบันไว้หนึ่งรายการสำหรับเส้นทางการเผยแพร่หลัก
• รักษาระดับ API ที่รองรับเก่าไว้หนึ่งระดับเพื่อความเข้ากันได้และพฤติกรรมการอัปเกรด
• เพิ่มโทรศัพท์จริงเฉพาะผู้จำหน่ายหนึ่งเครื่องเฉพาะเมื่อเฟิร์มแวร์ สิทธิ์ นโยบายแบตเตอรี่ หรือส่วนแบ่งของลูกค้าสร้างความเสี่ยงที่ชัดเจน
• เพิ่มการกำหนดค่าหน้าจอขนาดเล็กหรือแบบอักษรสูงเมื่อเค้าโครงและการเข้าถึงมีความสำคัญ
• เพิ่มสถานที่ ธีม การวางแนว เครือข่าย หรือสถานะบัญชีเฉพาะเพื่อตรวจสอบว่าผลลัพธ์สามารถเปลี่ยนแปลงได้ภายใต้เงื่อนไขดังกล่าวเท่านั้น
• เลิกใช้แถวเมทริกซ์ที่ไม่พบข้อบกพร่องที่ชัดเจนหรือสนับสนุนกลุ่มลูกค้าปัจจุบันอีกต่อไป

ตั้งชื่อการตัดสินใจแต่ละแถวที่สนับสนุน: บล็อกรุ่น รวบรวมหลักฐานการตรวจสอบ สร้างกรณีการสนับสนุน หรือสำรวจความล้มเหลวเฉพาะอุปกรณ์ที่น่าสงสัย การตัดสินใจดังกล่าวจะควบคุมความน่าเชื่อถือ การแยกตัว และการรายงานแถวที่ต้องการ ตัวบล็อกการเผยแพร่ต้องใช้กฎการรีเซ็ตและการยืนยันที่เข้มงวดกว่าการตรวจสอบเชิงสำรวจภายใต้การดูแล

สร้างการ์ดแสดงการทำงานก่อนที่จะเขียนระบบอัตโนมัติ

ข้อมูลจำเพาะที่มีประโยชน์น้อยที่สุดสำหรับการตรวจสอบในห้องปฏิบัติการคือการ์ดรัน ช่วยป้องกันสมมติฐานที่ซ่อนอยู่ไม่ให้อยู่ในความทรงจำของผู้ปฏิบัติงานรายเดียว และช่วยให้ระบบอัตโนมัติมีสัญญาที่มั่นคง เขียนการ์ดด้วยเงื่อนไขที่สังเกตได้ก่อนที่จะเลือกโหนด ตัวเลือก หรือโค้ดเฟรมเวิร์ก

อย่านิยามความสำเร็จว่าเป็นลำดับของการแตะ กำหนดสถานะที่มองเห็นได้หรือมีโครงสร้างที่ต้องมีอยู่หลังลำดับ เค้าโครง UI เปลี่ยนไป เงื่อนไขทางธุรกิจมีความคงทนมากขึ้น การตรวจสอบการเข้าสู่ระบบสำเร็จเนื่องจากมีสถานะบัญชีและพื้นผิวหน้าแรกที่คาดหวัง ไม่ใช่เนื่องจากระบบอัตโนมัติแตะพิกัดที่เคยเป็นปุ่ม

รีเซ็ตสถานะโดยไม่ลบหลักฐาน

อุปกรณ์ที่ใช้ร่วมกันล้มเหลวในลักษณะที่ดูเหมือนข้อบกพร่องของแอป: บัญชีเก่า ความยินยอมในแคช การอัปเดตที่รอดำเนินการ สิทธิ์ที่เปลี่ยนแปลง พื้นที่เก็บข้อมูลเหลือน้อย แป้นพิมพ์ที่ไม่คาดคิด กล่องโต้ตอบของระบบเปิด การแจ้งเตือนซ้อนทับ หรือการเรียกใช้ครั้งก่อนทิ้งไว้กลางทางของการชำระเงิน รีเซ็ตเฉพาะสถานะที่กำหนดโดยการ์ดที่เรียกใช้ และบันทึกความล้มเหลวก่อนที่การกู้คืนจะเปลี่ยนแปลง

1. ระบุอุปกรณ์และสร้างก่อนสัมผัสสถานะ
2. จับภาพหน้าจอปัจจุบันเมื่อการทำงานครั้งก่อนสิ้นสุดลงอย่างกะทันหัน
3. คืนแอปกลับสู่สถานะเริ่มต้นที่ประกาศโดยใช้การรีเซ็ตแบบทำลายน้อยที่สุดที่เพียงพอ
4. ยืนยันเครือข่าย เวลา พื้นที่เก็บข้อมูล การวางแนว สถานที่ ขนาดแบบอักษร และการอนุญาตที่จำเป็น
5. ตรวจสอบเครื่องหมายสถานะเริ่มต้นก่อนดำเนินธุรกิจครั้งแรก
6. กักกันอุปกรณ์หากการรีเซ็ตซ้ำแล้วซ้ำอีกล้มเหลว อย่าแปลงข้อบกพร่องของโครงสร้างพื้นฐานให้เป็นข้อบกพร่องของผลิตภัณฑ์

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

ซิงโครไนซ์กับสถานะแทนที่จะนอนหลับนานขึ้น

คำแนะนำด้านความเสถียรในการทดสอบของ Android เตือนไม่ให้เข้าสู่โหมดสลีปเนื่องจากประสิทธิภาพของอุปกรณ์และการทำงานแบบอะซิงโครนัสแตกต่างกันไป ความล่าช้าคงที่อาจสั้นเกินไปสำหรับโทรศัพท์ที่ไม่ว่างและช้าโดยไม่จำเป็นสำหรับโทรศัพท์ที่เร็ว ต้องการรออย่างชัดเจนสำหรับเงื่อนไขที่มีความหมาย โดยมีการหมดเวลาและส่วนความล้มเหลวเมื่อเงื่อนไขนั้นไม่ปรากฏเลย

• หลังจากเปิดแอป ให้รอองค์ประกอบ UI หรือสถานะหน้าจอที่เสถียร แทนที่จะรอเป็นจำนวนวินาทีที่เดาได้
• หลังจากการแตะ ให้ตรวจสอบเงื่อนไขภายหลังก่อนที่จะส่งข้อมูลอินพุตถัดไป
• ใช้การกล่าวซ้ำแบบมีขอบเขตสำหรับรัฐที่ต้องการการเลือกตั้งอย่างแท้จริง บันทึกการสังเกตครั้งสุดท้ายเมื่อหมดเวลา
• ถือว่ากล่องโต้ตอบการอนุญาตของระบบ พร้อมท์การอัปเดต และโอเวอร์เลย์ของ OEM เป็นสาขาที่มีชื่อ ไม่ใช่สัญญาณรบกวนแบบสุ่ม
• หยุดเมื่อสถานะที่มองเห็นอยู่นอกชุดที่ได้รับอนุมัติ โดยเฉพาะก่อนการชำระเงิน การลบ การยินยอม หรือการเปลี่ยนแปลงบัญชี

สัญญา LaiCai Flow ปัจจุบันเป็นไปตามโมเดลที่มองเห็นได้นี้: การสังเกต UI, OCR, การจับคู่เทมเพลต และสถานะการสังเกตการจับภาพหน้าจอ โหนดอินพุตและตัวชี้ดำเนินการเพียงครั้งเดียว โหนดโฟลว์จัดการการรอ สาขา ลูปที่มีขอบเขต โฟลว์ย่อย การส่งคืน และการหยุด การแยกการสังเกต การตัดสินใจ และการดำเนินการออกจากกันทำให้ขั้นตอนการทำงานตรวจสอบได้ง่ายขึ้นและปลอดภัยยิ่งขึ้นในการบำรุงรักษา

สร้าง LaiCai Flow ที่อ่านได้สำหรับการตรวจสอบในห้องปฏิบัติการ

LaiCai Flow เป็นคุณสมบัติอัตโนมัติภายใน LaiCai Screen Mirroring สำหรับการเรียกใช้ห้องปฏิบัติการอุปกรณ์ ให้คงโฟลว์หลักไว้ที่ระดับที่ผู้ตรวจสอบ QA สามารถอ่านได้: เตรียมอุปกรณ์ เปิดเป้าหมาย ดำเนินการตรวจสอบที่สำคัญ รวบรวมหลักฐาน และเสร็จสิ้น ใส่รายละเอียดทางเทคนิคแบบหลายขั้นตอนลงในกระแสของเด็กเล็ก แทนที่จะเปิดเผยการแข่งขัน การเลือก การแตะ และการรอที่ต่อเนื่องยาวนาน คู่มือLaiCai Flowอธิบายวิธีการจัดระเบียบโปรไฟล์และโฟลว์

1. อ่านบริบทของอุปกรณ์ที่เชื่อมต่อและเลือกนามแฝงซีเรียลที่ต้องการ อย่าถือว่าอุปกรณ์แรกถูกต้อง
2. ยืนยันแพ็คเกจและสถานะ UI ปัจจุบันก่อนเปิดหรือเปลี่ยนแอป
3. ใช้สถานะ UI เมื่อข้อมูลการเข้าถึงมีเสถียรภาพ OCR เมื่อข้อความที่มองเห็นเป็นหลักฐาน และใช้เทมเพลตที่ตรงกันสำหรับเป้าหมายรูปภาพที่ได้รับการตรวจสอบแล้วเท่านั้น
4. ทำการรออย่างชัดเจนระหว่างการดำเนินการและการสังเกตที่ขึ้นอยู่กับหน้าจอในภายหลัง
5. ตรวจสอบสภาวะภายหลังทุกขั้นตอนที่เปลี่ยนหน้าจอหรือสถานะแอป
6. จับภาพหน้าจอหรือการบันทึกเฉพาะเมื่อรองรับการตัดสินใจตรวจสอบที่ระบุชื่อเท่านั้น
7. ส่งกลับผลลัพธ์เฟสที่ชัดเจน หยุดการรันเมื่อการดำเนินการถัดไปไม่สอดคล้องกับการสังเกตปัจจุบัน

ในระหว่างการเตรียมคู่มือนี้ บริบท LaiCai แบบอ่านอย่างเดียวรายงานประเภทโหนดที่ใช้ได้ 73 ประเภทและโทรศัพท์ Samsung Android 16 ที่เชื่อมต่อหนึ่งเครื่อง นั่นเป็นการยืนยันสัญญาปัจจุบันและเส้นทางการรับรู้อุปกรณ์ มันไม่ใช่เกณฑ์มาตรฐานประสิทธิภาพ ตรวจสอบแอป อุปกรณ์ สินทรัพย์ และการสนับสนุนรันไทม์ของคุณเองก่อนที่จะถือว่าโปรไฟล์เป็นโครงสร้างพื้นฐานที่เผยแพร่

รวบรวมแพ็กเก็ตที่ล้มเหลว ไม่ใช่จุดสีแดง

การตรวจสอบที่ล้มเหลวควรตอบคำถามว่าวิ่งไปที่ไหน วิ่งไปที่ไหน สิ่งที่ระบบสังเกต และเหตุใดการวิ่งจึงหยุดลง Firebase Test Lab เปิดเผยโมเดลที่เป็นประโยชน์โดยส่งคืนสถานะการทดสอบพร้อมกับบันทึก ภาพหน้าจอ และวิดีโอ หากมี ห้องปฏิบัติการอุปกรณ์ในพื้นที่จำเป็นต้องมีระเบียบวินัยเดียวกัน แม้ว่าพื้นที่จัดเก็บข้อมูลจะง่ายกว่าก็ตาม

• รหัสการรัน การประทับเวลา เวอร์ชันเวิร์กโฟลว์ เวอร์ชันบิลด์ และสภาพแวดล้อม
• รุ่นอุปกรณ์, เวอร์ชัน Android, นามแฝงอนุกรมที่เสถียร, ขนาดหน้าจอ, ภาษา, ธีม และการวางแนว
• สถานะเริ่มต้น ตัวระบุการติดตั้งอินพุต และระยะธุรกิจที่เสร็จสมบูรณ์ครั้งล่าสุด
• สภาวะภายหลังที่คาดไว้และผลลัพธ์ UI, OCR, รูปภาพ หรือเฟรมเวิร์กที่เลือกจริง
• ภาพหน้าจอก่อนการกู้คืน การบันทึกสั้นๆ เฉพาะเมื่อมีการเคลื่อนไหวมีความสำคัญ และข้อความที่ตัดตอนมาจากบันทึกที่เกี่ยวข้องแบบมีขอบเขต
• การจำแนกประเภท: ข้อบกพร่องของผลิตภัณฑ์ ข้อบกพร่องในการทดสอบ โครงสร้างพื้นฐานของอุปกรณ์ ข้อมูล สภาพแวดล้อม หรือต้องมีการตรวจสอบโดยมนุษย์

ใช้ชื่อไฟล์ที่เสถียรและรายการแทนที่จะเป็นโฟลเดอร์ภาพหน้าจอที่ไม่มีโครงสร้าง ปกปิดข้อมูลส่วนบุคคลหรือข้อมูลลับก่อนแชร์ อย่าอัปโหลดบันทึกอุปกรณ์ทั้งหมดเมื่อมีช่วงเวลาการฆ่าเชื้อสั้นๆ เกี่ยวกับความล้มเหลวเพียงพอ หลักฐานควรลดงานของบุคคลถัดไปโดยไม่สร้างปัญหาความเป็นส่วนตัวหรือการเก็บรักษาใหม่

เลือกการตรวจสอบที่ให้เวลาอุปกรณ์

นาทีของอุปกรณ์จริงนั้นมีน้อย เนื่องจากอุปกรณ์จำเป็นต้องชาร์จ ล้างข้อมูล อัปเดต และเข้าถึงโดยมนุษย์ มอบให้กับเวิร์กโฟลว์ที่พฤติกรรมที่มองเห็นได้หรือทางกายภาพมีความสำคัญ ตัวเลือกแรกที่ดี ได้แก่ การตรวจสอบควันหลังปรับใช้ การอนุญาตและเส้นทาง UI ของระบบ การตั้งค่ากล้องหรือ Bluetooth โฟลว์การแจ้งเตือน หลักฐานการแปล การถดถอยเฉพาะของผู้จำหน่าย และการจำลองการสนับสนุนที่แน่นอน

รักษาตรรกะทางธุรกิจ การแยกวิเคราะห์ การจัดรูปแบบ และพฤติกรรมของส่วนประกอบในการทดสอบที่รวดเร็วยิ่งขึ้นใกล้กับโค้ด ใช้อุปกรณ์จริงเพื่อพิสูจน์ขอบเขตที่การทดสอบเหล่านั้นไม่สามารถทำได้: โครงสร้างที่ติดตั้ง ระบบปฏิบัติการ แอปภายนอก พื้นผิวอินพุต การเปลี่ยนแปลงเครือข่าย หรือองค์ประกอบที่มนุษย์มองเห็นได้ การเปรียบเทียบเครื่องมือทดสอบอัตโนมัติของ Androidช่วยกำหนดข้อกำหนดแต่ละข้อให้กับเลเยอร์ที่เหมาะสม

ชุดการเดินทางที่เชื่อถือได้ห้าชุดที่สำคัญมีค่ามากกว่าห้าสิบโฟลว์ที่ไม่มีใครเชื่อถือ เริ่มต้นด้วยเส้นทางตัวแทนเดียว วัดการรีเซ็ตและต้นทุนการคัดแยก จากนั้นเพิ่มความครอบคลุมเฉพาะเมื่อเช็คใหม่ปกป้องการตัดสินใจเฉพาะเจาะจงในการเปิดตัว ลูกค้า หรือการปฏิบัติงาน

วัดค่าห้องปฏิบัติการก่อนที่จะปรับขนาด

ทีมที่หารือเกี่ยวกับฟาร์มอุปกรณ์ที่โฮสต์ด้วยตนเองจะกลับไปใช้อินพุตระหว่างบิลด์กับการซื้อซ้ำๆ กัน: พฤติกรรมของคิว การทำงานพร้อมกันสูงสุด เวลารอ ความล้มเหลวในการบูตหรือรีเซ็ต ความพยายามในการบำรุงรักษา และข้อบกพร่องที่ปรากฏบนอุปกรณ์ทางกายภาพเท่านั้น ติดตามสัญญาณเหล่านั้นสำหรับรอบการเปิดตัวหลายรอบก่อนที่จะซื้อฮาร์ดแวร์เพิ่มเติมหรือย้ายทุกอย่างไปยังระบบคลาวด์

• รอคิวตามเวลาของวันและลำดับความสำคัญของเวิร์กโฟลว์
• การใช้งานอุปกรณ์และเวลาไม่พร้อมใช้งานสำหรับการชาร์จ อัปเดต หรือซ่อมแซม
• สถานะเริ่มต้นหรือรีเซ็ตอัตราความล้มเหลวตามอุปกรณ์
• การเรียกใช้ซ้ำเกิดจากความไม่สม่ำเสมอของระบบอัตโนมัติมากกว่าการเปลี่ยนแปลงผลิตภัณฑ์
• เวลามัธยฐานจากความล้มเหลวไปจนถึงการจำแนกประเภทที่เป็นประโยชน์
• ข้อบกพร่องที่แตกต่างซึ่งพบเฉพาะในอุปกรณ์จริง ผู้จำหน่ายบางราย หรือเวอร์ชัน Android ที่ระบุเท่านั้น
• นาทีของผู้ปฏิบัติงานต่อการวิ่งที่สำเร็จและต่อเวิร์กโฟลว์ที่ได้รับการบำรุงรักษา

สิ่งเหล่านี้คือตัวชี้วัดการจัดการ ไม่ใช่แดชบอร์ดแบบไร้สาระ หากการรอคิวมีน้อยแต่การบำรุงรักษายังครอบงำ บริการแบบโฮสต์อาจลดต้นทุนการเป็นเจ้าของได้ หากความเป็นส่วนตัว อุปกรณ์ต่อพ่วงในพื้นที่ การแก้ไขข้อบกพร่องแบบโต้ตอบอย่างรวดเร็ว หรือการสนับสนุนซ้ำๆ มีความสำคัญมากกว่าการครอบคลุมโมเดลในวงกว้าง ห้องปฏิบัติการในพื้นที่ขนาดเล็กอาจยังคงเป็นศูนย์กลางที่เหมาะสม

ใช้กฎการสร้างและซื้อแบบไฮบริด

ห้องปฏิบัติการในท้องถิ่นและห้องปฏิบัติการที่โฮสต์เป็นส่วนเสริม Gradle Managed Devices สามารถกำหนดอุปกรณ์เสมือนในบิลด์และจัดกลุ่มเพื่อดำเนินการทดสอบได้ Firebase Test Lab สามารถขยายเมทริกซ์ทั่วทั้งอุปกรณ์เสมือนและอุปกรณ์จริงที่โฮสต์ไว้ และส่งคืนอาร์ติแฟกต์ที่มีการจัดการ พูลภายในเครื่องช่วยให้เข้าถึงได้ทันที มีอุปกรณ์ต่อพ่วงที่เป็นกรรมสิทธิ์ การดีบักที่ได้รับการดูแล และอุปกรณ์ที่เสถียรสำหรับการตรวจสอบการทำงานที่เกิดซ้ำ

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

รายการตรวจสอบการทำงานอัตโนมัติในห้องปฏิบัติการอุปกรณ์ Android

1. กำหนดวัตถุประสงค์และการตัดสินใจหนึ่งรายการให้กับแถวอุปกรณ์-เมทริกซ์ทุกแถว
2. แยกอีมูเลเตอร์ อุปกรณ์จริงในเครื่อง โฮสต์ การทดสอบเฟรมเวิร์ก และความรับผิดชอบของโฟลว์ภาพ
3. สร้างการ์ดรันด้วยบิลด์ อุปกรณ์ สถานะเริ่มต้น อินพุต เงื่อนไขภายหลัง การหยุด และหลักฐาน
4. ตรวจสอบสถานะเริ่มต้นก่อนดำเนินธุรกิจครั้งแรก
5. รอเงื่อนไขที่สังเกตได้แทนที่จะเพิ่มการนอนหลับแบบคนตาบอดให้นานขึ้น
6. เก็บการสังเกต การตัดสินใจ และการทำงานของอุปกรณ์เป็นขั้นตอนที่ตรวจสอบแยกกันได้
7. บันทึกหลักฐานก่อนที่จะรีเซ็ตหรือกู้คืนการเปลี่ยนแปลงความล้มเหลว
8. แยกประเภทโครงสร้างพื้นฐาน ข้อมูล การทดสอบ สภาพแวดล้อม และความล้มเหลวของผลิตภัณฑ์แยกกัน
9. ติดตามคิว การใช้งาน ความน่าเชื่อถือในการรีเซ็ต การรันซ้ำที่ไม่สม่ำเสมอ เวลาคัดแยก และข้อบกพร่องทางกายภาพเท่านั้น
10. ใช้กลยุทธ์แบบไฮบริดภายในและแบบโฮสต์เมื่อมีหลักฐานสนับสนุน

เริ่มต้นด้วยโทรศัพท์จริงหนึ่งเครื่อง การกำหนดค่าโปรแกรมจำลองหนึ่งเครื่อง และการ์ดการดำเนินการที่สำคัญต่อธุรกิจหนึ่งใบ ทำให้ลูปนั้นเชื่อถือได้และตรวจสอบได้ก่อนที่จะเพิ่มอุปกรณ์หรือเวิร์กโฟลว์อื่น เมื่อเลเยอร์ห้องปฏิบัติการอุปกรณ์ที่สังเกตได้เหมาะกับทีมของคุณ ให้สำรวจระบบอัตโนมัติของ Android ของAI ด้วย LaiCai Flowและเก็บรายละเอียดการใช้งานไว้ในคำแนะนำขั้นตอนการทำงานที่ทราบตำแหน่ง

หมายเหตุบรรณาธิการ:BeePOS LLCบริษัทที่อยู่เบื้องหลัง LaiCai Screen Mirroring ค้นคว้าคู่มือนี้โดยใช้เอกสาร Android และ Firebase อย่างเป็นทางการที่ลิงก์ด้านล่าง สัญญาผลิตภัณฑ์ LaiCai แบบอ่านอย่างเดียวปัจจุบัน และการสนทนา QA สาธารณะ ความสามารถของผลิตภัณฑ์จะถูกระบุแยกจากคำแนะนำขั้นตอนการทำงานที่เป็นกลาง สามารถส่งคำถามหรือการแก้ไขไปที่ support@laicaiapp.com

• นักพัฒนา Android: ปรับขนาดการทดสอบของคุณด้วยอุปกรณ์ที่มีการจัดการ Gradle
• นักพัฒนา Android: ทดสอบความเสถียร
• Firebase Test Lab: เริ่มต้นการทดสอบ Android
• Reddit r/QualityAssurance: รักษาโครงสร้างพื้นฐานของโปรแกรมจำลอง Android
• Android Developers: UI Automator