กลยุทธ์การทดสอบ

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

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

• ตรวจพบปัญหาโดยเร็วที่สุด
• ดำเนินการได้อย่างรวดเร็ว
• ระบุอย่างชัดเจนเมื่อต้องแก้ไขบางอย่าง

หน้านี้จะช่วยคุณตัดสินใจว่าจะใช้การทดสอบประเภทใด จะทำการทดสอบที่ใด และควรทดสอบบ่อยเพียงใด

พีระมิดการทดสอบ

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

*ความเที่ยงตรงหมายถึงความคล้ายคลึงกันของสภาพแวดล้อมรันไทม์ของการทดสอบกับสภาพแวดล้อมการใช้งานจริง

แอปส่วนใหญ่ควรมีการทดสอบขนาดเล็กหลายครั้งและการทดสอบขนาดใหญ่ค่อนข้างน้อย การกระจายการทดสอบในแต่ละหมวดหมู่ควรมีลักษณะเป็นพีระมิด โดยการทดสอบขนาดเล็กจำนวนมากจะอยู่ฐาน และการทดสอบขนาดใหญ่จำนวนน้อยจะอยู่ยอด

ลดต้นทุนของข้อบกพร่อง

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

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

ซึ่งหมายความว่ามีการทดสอบน้อยเกินไปก่อนที่จะผสานรวม หากมีข้อบกพร่อง การทดสอบอาจไม่พบข้อบกพร่องดังกล่าวจนกว่าจะมีการเรียกใช้การทดสอบจากต้นทางถึงปลายทางแบบรายคืนหรือรายสัปดาห์

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

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

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

กลยุทธ์การทดสอบที่ปรับขนาดได้

โดยทั่วไปแล้ว พีระมิดการทดสอบจะแบ่งออกเป็น 3 หมวดหมู่ ดังนี้

• การทดสอบหน่วย
• การทดสอบการผสานรวม
• การทดสอบตั้งแต่ต้นจนจบ

อย่างไรก็ตาม แนวคิดเหล่านี้ไม่มีคำจำกัดความที่ชัดเจน ดังนั้นทีมอาจต้องการ กำหนดหมวดหมู่ของตนเองในลักษณะที่แตกต่างออกไป เช่น ใช้ 5 เลเยอร์

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

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

	ขอบเขต	การเข้าถึงเครือข่าย	การลงมือปฏิบัติ	ประเภทบิวด์	วงจร
หน่วย	เมธอดหรือคลาสเดียวที่มีทรัพยากร Dependency น้อยที่สุด	ไม่	ในพื้นที่	แก้ไขข้อบกพร่องได้	ก่อนผสาน
ส่วนประกอบ	ระดับโมดูลหรือคอมโพเนนต์ หลายชั้นเรียนพร้อมกัน	ไม่	ภายใน Robolectric โปรแกรมจำลอง	แก้ไขข้อบกพร่องได้	ก่อนผสาน
ฟีเจอร์	ระดับฟีเจอร์ การผสานรวมกับคอมโพเนนต์ที่ทีมอื่นๆ เป็นเจ้าของ	จำลอง	Local Robolectric อุปกรณ์ โปรแกรมจำลอง	แก้ไขข้อบกพร่องได้	ก่อนผสาน
แอปพลิเคชัน	ระดับแอปพลิเคชัน การผสานรวมกับฟีเจอร์และ/หรือบริการที่ทีมอื่นๆ เป็นเจ้าของ	จำลอง เซิร์ฟเวอร์ Staging เซิร์ฟเวอร์ Prod	โปรแกรมจำลอง อุปกรณ์	แก้ไขข้อบกพร่องได้	ก่อนการผสาน หลังการผสาน
รุ่นที่อาจได้รับการเผยแพร่	ระดับแอปพลิเคชัน การผสานรวมกับฟีเจอร์และ/หรือบริการที่ทีมอื่นๆ เป็นเจ้าของ	เซิร์ฟเวอร์เวอร์ชันที่ใช้งานจริง	โปรแกรมจำลอง อุปกรณ์	บิลด์รุ่นที่ย่อขนาดแล้ว	ก่อนเผยแพร่หลังการผสาน

กำหนดหมวดหมู่การทดสอบ

โดยหลักการแล้ว คุณควรพิจารณาเลเยอร์ล่างสุดของพีระมิดที่สามารถ ให้ระดับความคิดเห็นที่เหมาะสมแก่ทีมได้

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

กลุ่มตัวอย่างที่ใช้ทดสอบ	คำอธิบายเกี่ยวกับสิ่งที่กำลังทดสอบ	หมวดหมู่การทดสอบ	ตัวอย่างประเภทการทดสอบ
ตรรกะของเครื่องมือตรวจสอบแบบฟอร์ม	คลาสที่ตรวจสอบความถูกต้องของอีเมลกับนิพจน์ทั่วไปและตรวจสอบว่ามีการป้อนฟิลด์รหัสผ่าน ไม่มีทรัพยากร Dependency	การทดสอบหน่วย	การทดสอบหน่วย JVM ในเครื่อง
ลักษณะการทำงานของ UI แบบฟอร์มลงชื่อเข้าใช้	แบบฟอร์มที่มีปุ่มซึ่งจะเปิดใช้ได้เมื่อมีการตรวจสอบแบบฟอร์มแล้วเท่านั้น	การทดสอบคอมโพเนนต์	การทดสอบลักษณะการทำงานของ UI ที่ทำงานใน Robolectric
ลักษณะ UI ของแบบฟอร์มลงชื่อเข้าใช้	แบบฟอร์มที่ทำตามข้อกำหนด UX	การทดสอบคอมโพเนนต์	การทดสอบภาพหน้าจอตัวอย่างการเขียน
การผสานรวมกับเครื่องมือจัดการการตรวจสอบสิทธิ์	UI ที่ส่งข้อมูลเข้าสู่ระบบไปยังเครื่องมือจัดการการตรวจสอบสิทธิ์และรับการตอบกลับซึ่งอาจมีข้อผิดพลาดต่างๆ	การทดสอบฟีเจอร์	การทดสอบ JVM ด้วยการจำลอง
กล่องโต้ตอบการลงชื่อเข้าใช้	หน้าจอที่แสดงแบบฟอร์มลงชื่อเข้าใช้เมื่อกดปุ่มเข้าสู่ระบบ	การทดสอบแอปพลิเคชัน	การทดสอบลักษณะการทำงานของ UI ที่ทำงานใน Robolectric
เส้นทางของผู้ใช้ที่สำคัญ: การลงชื่อเข้าใช้	ขั้นตอนการลงชื่อเข้าใช้ที่สมบูรณ์โดยใช้บัญชีทดสอบกับเซิร์ฟเวอร์ Staging	รุ่นที่อาจได้รับการเผยแพร่	การทดสอบลักษณะการทำงานของ Compose UI ตั้งแต่ต้นจนจบที่ทำงานบนอุปกรณ์

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

โปรดทราบว่าหมวดหมู่การทดสอบไม่ได้กำหนดประเภทการทดสอบ และไม่จำเป็นต้องทดสอบฟีเจอร์ทั้งหมดในทุกหมวดหมู่

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

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

กลยุทธ์การทดสอบต้องได้รับการสนับสนุนจากโครงสร้างพื้นฐานและเครื่องมือที่จะช่วยให้นักพัฒนาแอปทำการทดสอบอย่างต่อเนื่องและบังคับใช้กฎที่รับประกันว่าการทดสอบทั้งหมดจะผ่าน

คุณสามารถจัดหมวดหมู่การทดสอบตามขอบเขตเพื่อกำหนดเวลาและสถานที่ที่จะทำการทดสอบ ตัวอย่างเช่น ตามโมเดล 5 เลเยอร์

หมวดหมู่	สภาพแวดล้อม (ที่ไหน)	ทริกเกอร์ (เมื่อ)
หน่วย	[Local][4]	ทุกคอมมิต
ส่วนประกอบ	ในพื้นที่	ทุกคอมมิต
ฟีเจอร์	อุปกรณ์ในเครื่องและโปรแกรมจำลอง	ก่อนผสาน ก่อนผสาน หรือก่อนส่งการเปลี่ยนแปลง
แอปพลิเคชัน	ในเครื่อง โปรแกรมจำลอง โทรศัพท์ 1 เครื่อง โทรศัพท์แบบพับได้ 1 เครื่อง	หลังการผสาน หลังผสานหรือส่งการเปลี่ยนแปลง
รุ่นที่อาจได้รับการเผยแพร่	โทรศัพท์ 8 เครื่อง, อุปกรณ์แบบพับได้ 1 เครื่อง, แท็บเล็ต 1 เครื่อง	ก่อนเปิดตัว

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

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